You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(19) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
(12) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Ethan G. <ega...@na...> - 2009-05-20 14:48:56
|
Ton Voon wrote: > On 20 May 2009, at 15:32, Ethan Galstad wrote: > >> Hi Guys - >> >> I'm setting up a special "devteams.nagios.org" server that will all us >> and future teams to host what we need. With this setup, you'd both >> get >> full shell access, which would allow us to have official: >> >> git.nagios.org >> >> and >> >> tinderbox.nagios.org >> >> If we need something else, let me know and I'll get on it. > > Cool. I'm happy to do the work to migrate tinderbox.opsera.com to this > server. Are you picturing that nagios-plugins tinderbox tests go here > too? > > Ton > They certainly could, and I think that would be ideal. Let me if you think the other plugin devs need shell accounts and I'll get them setup as well. Can you guys send me your public SSH keys (off the list) so I can add them to your accounts? The server should be online in about 30 minutes. - Ethan Galstad |
From: Andreas E. <ae...@op...> - 2009-05-20 14:48:01
|
Ethan Galstad wrote: > Top posting because its easier. :-) > As the Pope of Nagios, I suspect you can bestow a healthy dose of absolution on yourself for that ;-) > I see your pain with CVS and believe that we should move to git. It > will take a while for me to get up to speed on git, as I have more than > a full plate of things to take care of in the next month. > > What I would suggest is this: > > 1. We make a 3.1.1 release with bugfixes and let people test it out > 2. After a bit of testing, a 3.2 stable release is made > 3. After 3.2, we ditch CVS and move to git completely. > > There aren't too many more patches that would need to be applied to make > a 3.1.1 release, so that can probably come out late this week. After a > 3.2 release we switch to git and proceed on a development path that we > can all discuss at the conference in two weeks. > > Is this a reasonable scenario for you Andreas? > Sounds awesome. It's good to have something to look forward to. As for getting up to speed on git, I'd be happy to give you a quick crash-course when we meet in stockholm. 10 minutes of face-to-face explanation is probably worth about 20 hours of browsing online documentation. It'd also give you an insight into how I work with git, both for Nagios' sake and all of the Nagios-related stuff at op5, which I'm sure will come in handy at some point. I haven't booked a return train to gothenburg yet. I'm actually planning on staying in Stockholm over the following weekend to party with some friends. Depending on your plans we might have plenty of time even though I suspect much of it will be interrupted by suits wanting to discuss pieces of paper. With any luck, there's a boat involved this year too ;-) -- Andreas Ericsson and...@op... OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Register now for Nordic Meet on Nagios, June 3-4 in Stockholm http://nordicmeetonnagios.op5.org/ Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. |
From: Ton V. <to...@ma...> - 2009-05-20 14:36:44
|
On 20 May 2009, at 15:32, Ethan Galstad wrote: > Hi Guys - > > I'm setting up a special "devteams.nagios.org" server that will all us > and future teams to host what we need. With this setup, you'd both > get > full shell access, which would allow us to have official: > > git.nagios.org > > and > > tinderbox.nagios.org > > If we need something else, let me know and I'll get on it. Cool. I'm happy to do the work to migrate tinderbox.opsera.com to this server. Are you picturing that nagios-plugins tinderbox tests go here too? Ton |
From: Ethan G. <ega...@na...> - 2009-05-20 14:32:26
|
Hi Guys - I'm setting up a special "devteams.nagios.org" server that will all us and future teams to host what we need. With this setup, you'd both get full shell access, which would allow us to have official: git.nagios.org and tinderbox.nagios.org If we need something else, let me know and I'll get on it. Ethan Galstad President ___ Nagios Enterprises, LLC Office: (888)NAGIOS-1 x701 Fax: (651)204-9103 Mobile: (651)278-1477 Email: ega...@na... Web: www.nagios.com |
From: Ethan G. <ega...@na...> - 2009-05-20 14:30:09
|
Top posting because its easier. :-) I see your pain with CVS and believe that we should move to git. It will take a while for me to get up to speed on git, as I have more than a full plate of things to take care of in the next month. What I would suggest is this: 1. We make a 3.1.1 release with bugfixes and let people test it out 2. After a bit of testing, a 3.2 stable release is made 3. After 3.2, we ditch CVS and move to git completely. There aren't too many more patches that would need to be applied to make a 3.1.1 release, so that can probably come out late this week. After a 3.2 release we switch to git and proceed on a development path that we can all discuss at the conference in two weeks. Is this a reasonable scenario for you Andreas? - Ethan Galstad Andreas Ericsson wrote: > Ton Voon wrote: >> On 20 May 2009, at 11:41, Andreas Ericsson wrote: >> >>> This is a bit rantish. Sorry about that. >> I agree that CVS is a pain (I'm more in tune with SVN). >> >> I haven't tried to preach about the specific SCM tool because I think >> it is more important to be making changes to the code, rather than >> arguing over the technology. >> > > I agree, but CVS is getting in my way of doing that. I'd be fine > with practically anything that lets me stash stuff locally and revisit > later, as it helps enormously when working with patches from the list. > >> But if you do the work required to move to git (which includes adding >> some helper docs on basic commands, updating snapshots to use, >> updating release process, etc), then I'd support that. >> > > I will indeed, but for this to be officially blessed, I'd feel better > if that official repo was under Ethan's control and in the nagios.org > domain, and Ethan will have to make an announcement. > > The snapshot I'm using is up-to-date, and I keep it that way although > I don't necessarily publish it instantly on git.op5.org (I'm wary of > sending patches that aren't in CVS, so I'm a bit more cautious than I > would otherwise be). > > Documentation exists in abundance. Hendrik Baecker sent me a HOWTO > he's written which I can adapt to make it usable for core Nagios. > > Release-process is easy enough, really. I can just copy that from our > own hooks, so each time a push is made to the 'master' branch in the > official repository, tarballs are built with an auto-deduced version > name (decided from tags and number of commits since then). > > With this scheme, pushing the tag "nagios-3.1.1-beta1" would result > in the tarball "nagios-3.1.1-beta1.tar.gz". Someone else later pushing > 3 commits on top of that would result in "nagios-3.1.1-beta1.p3.tar.gz". > This require shell access to the machine where it'll be running, and > possibly an ftp account on the site where the tarballs are supposed to > be shipped to. I'll set it up on git.op5.org for now and we'll see how > it works out. > -- |
From: Andreas E. <ae...@op...> - 2009-05-20 13:13:43
|
Ton Voon wrote: > On 20 May 2009, at 11:41, Andreas Ericsson wrote: > >> This is a bit rantish. Sorry about that. > > I agree that CVS is a pain (I'm more in tune with SVN). > > I haven't tried to preach about the specific SCM tool because I think > it is more important to be making changes to the code, rather than > arguing over the technology. > I agree, but CVS is getting in my way of doing that. I'd be fine with practically anything that lets me stash stuff locally and revisit later, as it helps enormously when working with patches from the list. > But if you do the work required to move to git (which includes adding > some helper docs on basic commands, updating snapshots to use, > updating release process, etc), then I'd support that. > I will indeed, but for this to be officially blessed, I'd feel better if that official repo was under Ethan's control and in the nagios.org domain, and Ethan will have to make an announcement. The snapshot I'm using is up-to-date, and I keep it that way although I don't necessarily publish it instantly on git.op5.org (I'm wary of sending patches that aren't in CVS, so I'm a bit more cautious than I would otherwise be). Documentation exists in abundance. Hendrik Baecker sent me a HOWTO he's written which I can adapt to make it usable for core Nagios. Release-process is easy enough, really. I can just copy that from our own hooks, so each time a push is made to the 'master' branch in the official repository, tarballs are built with an auto-deduced version name (decided from tags and number of commits since then). With this scheme, pushing the tag "nagios-3.1.1-beta1" would result in the tarball "nagios-3.1.1-beta1.tar.gz". Someone else later pushing 3 commits on top of that would result in "nagios-3.1.1-beta1.p3.tar.gz". This require shell access to the machine where it'll be running, and possibly an ftp account on the site where the tarballs are supposed to be shipped to. I'll set it up on git.op5.org for now and we'll see how it works out. -- Andreas Ericsson and...@op... OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Register now for Nordic Meet on Nagios, June 3-4 in Stockholm http://nordicmeetonnagios.op5.org/ Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. |
From: Ton V. <to...@ma...> - 2009-05-20 10:51:13
|
On 20 May 2009, at 11:41, Andreas Ericsson wrote: > This is a bit rantish. Sorry about that. I agree that CVS is a pain (I'm more in tune with SVN). I haven't tried to preach about the specific SCM tool because I think it is more important to be making changes to the code, rather than arguing over the technology. But if you do the work required to move to git (which includes adding some helper docs on basic commands, updating snapshots to use, updating release process, etc), then I'd support that. Ton |
From: Andreas E. <ae...@op...> - 2009-05-20 10:41:49
|
This is a bit rantish. Sorry about that. I'm struggling awfully with CVS right now. I'll happily spend the entire weekend migrating to git if that means I never, ever have to touch CVS again as far as Nagios is concerned (yes, I loathe it that much). Problem nr 1: I can't see which patches are applied and which aren't. I can't make sense of the CVS log output, as it doesn't seem to include a sensible log message. Problem nr 2: Local changes are utterly and irrevocably lost when update'ing the CVS tree. There's absolutely no sense of checkpointing local work, or moving it on top of the current master, or actually *working* with patches and improving them in-tree without risking losing a sane state. Problem nr 3: Reverting uncommitted changes seem well-nigh impossible. So far I've resorted to moving the original checkout out of the way, re-doing the checkout, running diff on the two directories and hand-munging the patch(es) to apply the good parts and discard the bad ones, before finishing up in the CVS tree and committing the state I'm happy with. Naturally, I have to repeat all the steps if someone else commits something while I'm fiddling with things (at least if there are conflicts). It's driving me nuts. Problem nr 4: I can't publish changes inside CVS that end up easily reviewable and mergeable later. I'd love to put stuff up for testing that we can merge *after* it's actually been through the public beta testing cycle, but CVS has no (sane) notion of branches, it can't merge and whenever someone does a checkout they will always end up with the "default" line of development. Ethan, I know you haven't worked with git before. If you send me your public SSH-key I can make a playground repository on git.op5.org with current Nagios in it that you can play around with and try things out on without it affecting anyone else. I'd be happy to help you get up to speed on git if you feel you need it. It really isn't hard once you get the concept of "commit" only recording changes to your local clone of the repository instead of making them publicly available instantly. I'd be happy to help set up an official git repository, complete with hooks for sending mails on pushes and stuff like that. Just let me know how you want to move forward with this. The current situation is so frustrating I'm actually worried about picking up patches for fear of all the work it entails. -- Andreas Ericsson and...@op... OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Register now for Nordic Meet on Nagios, June 3-4 in Stockholm http://nordicmeetonnagios.op5.org/ Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. |
From: Ton V. <to...@ma...> - 2009-05-13 09:09:40
|
On 13 May 2009, at 10:02, Andreas Ericsson wrote: > Anyways, to make the import as accurate as possible so we can re-use > it if we move to using git as the primary scm later, I'd like to know > what email-addresses you'd like to be listed for your author names. I'd like mine to be to...@ma... please. Ton |
From: Andreas E. <ae...@op...> - 2009-05-13 09:02:28
|
Hi fellas. I've been trying to cooperate with CVS, but I just can't manage that properly (especially since I need branches for experimental features), so I'll create a git repository where I can do my work and then I'll bulk-apply the patches to CVS later, probably with some script. Anyways, to make the import as accurate as possible so we can re-use it if we move to using git as the primary scm later, I'd like to know what email-addresses you'd like to be listed for your author names. It helps if it's a real one that you actually use, since they are used by some scripts to Cc the original author so he/she can provide comments when automailing patches. For now, I've used ton...@op... and ega...@na... for your names. It can be changed afterwards, but I'd rather not alter it after the repository is published. Thanks -- Andreas Ericsson and...@op... OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Register now for Nordic Meet on Nagios, June 3-4 in Stockholm http://nordicmeetonnagios.op5.org/ Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. |
From: Ethan G. <ega...@na...> - 2009-05-12 23:25:57
|
Hey guys - I think we should all put a photo and some text up on the development team page. Good idea to let more people have a feel for who we are. I put some default text there for the both of you. http://community.nagios.org/wiki/index.php/Development_Teams Ethan Galstad President ___ Nagios Enterprises, LLC Office: (888)NAGIOS-1 x701 Fax: (651)204-9103 Mobile: (651)278-1477 Email: ega...@na... Web: www.nagios.com |
From: Ethan G. <ega...@na...> - 2009-05-12 22:16:46
|
Ton Voon wrote: > > On 12 May 2009, at 22:55, Ethan Galstad wrote: > >> Andreas and Ton - >> >> Welcome to the new nagios-devteam mailing list! >> >> I'm starting to look into bug trackers, and Mantis and Trac seem to be >> two good options. Based on what I've seen elsewhere I'd lean towards >> Mantis. Any preference on these or other suggestions? > > I haven't tried Mantis. I think Trac is good. We use it for Opsview > (http://trac.opsview.org), but we're migrating to Jira > (http://www.atlassian.com/software/jira/) because that's what the rest > of Opsera use. I think Jira's pretty good too, but probably has more > admin overhead. > >> I can get a tracker hosted at http://tracker.nagios.org for us to track >> bugs, patches, etc. I can't stand the Sourceforge options. > > Agree re: SF. > > Ton Trac and Mantis are now in the idea factory: http://ideas.nagios.org/akira/ideafactory.do?discussionID=1753 - Ethan Galstad |
From: Ethan G. <ega...@na...> - 2009-05-12 21:55:57
|
Andreas and Ton - Welcome to the new nagios-devteam mailing list! I'm starting to look into bug trackers, and Mantis and Trac seem to be two good options. Based on what I've seen elsewhere I'd lean towards Mantis. Any preference on these or other suggestions? I can get a tracker hosted at http://tracker.nagios.org for us to track bugs, patches, etc. I can't stand the Sourceforge options. - Ethan Galstad |