[cvsnt] Re: Q to CVSNT committers: CVSNT maintenance - how does it happen?

[Kevin McGuire]

Thanks Tony for the quick reply, this is exactly the info I needed.

Cheers,
Kevin

"Tony Hoyle" <tmh at nodomain.org> wrote in message
news:b2h0fs$s2u$1 at sisko.nodomain.org...
> Kevin McGuire wrote:
>
>
> > Q: If a bug is fixed in the Linux version, how and when does it get
> > migrated to CVSNT?
>
> If someone reports it here, or it's major (such as the double-free bug
> a few weeks ago) then it's fixed as soon as I hear about it (there are
> communication channels between the Unix and cvsnt teams for security
> issues).
>
> > Q: Similary, if a new CVS Linux version is released, how does this
migrate
> > to a CVSNT version?
>
> They don't really correlate...  it hasn't mattered because the Unix
> development cycle is slower (they favour stability over features, whereas
I
> try to balance the two).  If there's a feature that someone wants they'll
> usually ask about it on the list & it'll get implemented if it looks good
> or is needed for a specific reason (if one of the WinCVS or TortoiseCVS
> developers request something it'll generally get in faster as they're in
my
> 'supported' list.  There's no reason that Eclipse couldn't be done on that
> basis, too).
>
> > Q: Aside from NT specific areas, do fixes in CVSNT find their way back
to
> > Linux, and how/when?  Or, is there a common code base that always moves
> > forward on Linux and then is migrated?
>
> There's no reason why the Unix CVS developers can't use CVSNT code, but
> there hasn't been much the other way yet.  AFAIK some of the Unix cvs
> developers do read this list so they are presumably aware of what's being
> developed, etc.
>
> > Q:  How many active committers are there on CVSNT and how often do they
> > work
> > on it?  I am trying to understand the size of the push behind CVSNT
> > maintenance and the frequency.
>
> It tends to be just me, with people reporting bugs & sending patches that
I
> integrate.  The load is quite low, since in reality not so much changes...
> it looks like a lot sometimes but most of the features that have been
added
> recently have been less than a days' work.
>
> At the moment I'm on a stability push, since I did some much needed
> restructuring of the RCS code but it made some of it a bit fragile.  Build
> 72 seems to have reached a level of stability I'm happy with, so I can
slow
> down for a bit and maybe think about what features there are still on my
> 'todo' list.
>
> > Q:  What problems do you see with the maintenance process?  For example,
> > do you find it works well, or do you need more active committers, or
> > committers who can spend more time on CVSNT?
>
> There is a test script that runs on both NT and Linux, but it's not
complete
> enough yet... I add to it whenever a problem occurs so I'll catch it next
> time.  Hopefully it'll get to the point that I can say each release is
> solid based on the test results.
>
> Mostly I just need feedback... especially from people willing to try the
> 'experimental' features such as atomic commits.   There are some other
> projects that could probably do with external input (such as distributed
> repositories).  In an ideal world the server could be progressively
> rewritten but I've tried that a few times and there really isn't the time
> to do it and maintain the release at the same time.
>
> > Q:  Are there people who work on both CVSNT and CVS linux mainteance?
>
> There is communication both ways but basically they're separate.
>
> > Q:  It seems that the appearance of CVSNT versions is somewhat
> > uncorrelated
> > with Linux versions.  For example, there may be nothing for CVSNT for
> > awhile, then several versions (usually minor 'letter' version upgrades).
> > Is
> > this accurate, and if so how does this come about?  For example, is it
> > because a committer will book off some time and work a lot on CVSNT,
then
> > can't for awhile due to requirements of their "day job"?
>
> The 'letter' upgrades were what happened after I branched a development
> release and forgot to leave a gap in the numbering system for the releases
> to continue.  We're back to numbers now.
>
> Ideally the release cycle would be every couple of weeks but it isn't
> planned as such, it just happens when there's something that is stable
> enough to release.
>
> Because of the rapid releases I generally don't mind if people are using
> 'old' releases... I recommend that people use the one that works for them
> and only upgrade if they have problems.
>
> Any changes to the cvsnt output are usually 'consistent' as I try to keep
> the output parseable - for example the extra fields in 'log' are just
> appended to a semicolon-separated list that is already there, and the
extra
> lines in 'status' are in the identical format to other lines.  I try not
to
> break things, but relying on the output remaining static is probably a bad
> idea.  If you see an incompatible change in the future I'm always open to
> negotiation if changing it slightly will make things easier to parse.
>
> Tony
>