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.