Periodic Releases

[Stephen Rust <srust valpo edu>]

Just a thought,

	There has been mention that the best way for developers (the
non-core developers, also) to retrieve the latest code is by updating
their local cvs tree, perhaps by doing a full cvs checkout nightly via
cron, etc.  I have a few issues to address regarding this technique.

For one, while it is true the code is in development and might not compile
correctly, the cvs code is often in a state that is not compilable, not
runnable, and thus not testable.  This is perfectly fine for the main core
developers, but makes it hard for someone in their spare time to
contribute and add a feature to something they don't have a huge knowledge
of (since they're doing this in spare moments of the day), and have no way
to test a feature they'd try to add since the code doesn't run straight
out of cvs.

Also, I don't think doing away with periodic releases is a good solution.
The linux kernel certainly has periodic releases.  It gives developers a
point of reference when applying patches.  This is also important because
for debugging statistics, you can tell between what releases a feature
might have been broken or when talking about changes, reference certain
releases, etc.  It makes it easier than just saying "checkout the latest
from the cvs tree, and apply your patch", when the latest checkout is
often times quite unstable, whereas it would have been stable a few days
before.  I think, being sometimes slightly behind bleeding edge, rather
than in the middle of someone's debug/new feature work, could have
advantages.

For example, if you were working on the linux kernel and a patch came for
something, the patch might be applied, but it is not applied to a release
where anyone but the core developers can get access to it (And often only
Linus).  So lets say that the patch happened to break the compile for an
hour, before the core developers had a time to make the appropriate
changes.  If that patch was applied to the public cvs tree, people who
were updating their trees during that time would be working on code that
didn't compile.

This is only an example, and not a very good one, but it touches on some
of the problems that could occur, and do occur, for the casual developer,
currently.  And if perhaps a later more recent release is really
troublesome, there would be earlier releases to fall back on, where the
guy who codes 5 minutes a day could add his innocent patch on to a part,
that could be added on to the more recent releases/cvs tree at a later
time when it was more stable.  Point being, the casual developer would
have a chance to do work on the code, and not be forced into spending a
lot of time getting a new entire cvs checkout to work, when it doesn't
build and/or has other problems.

Just a thought, as to why periodic revisions are a good thing.  But as
might be the case, to work on the inner workings of Gnome, one might just
have to be a core developer with an above average amount of time to spend
on it, rather than a casual developer, and perhaps Gnome isn't yet ready
for the casual developer to have a large part in the development process.

Questions, comments, etc. ?

Thanks for listening,
Steve