I'm new to the list, but I went back through the archives to follow this
thread a bit.
I've been watching James for some time now (at least a year), and one change
that may help the ship/fix issues, as well as sate the featur-itis crowd, is
to establish a more standardized release process.
Basically, adopt the dot/dot-dot process: new features go in dot releases
(2.x), fixes go in dot-dot releases (2.1.x). To state the obvious, new
features do not go in dot-dots.
Simple and used almost everywhere, as you all know. Another part of the
process that is vital is a published release criteria containing four
things:
-- What new features will be in the release (for dot-dot releases, what
known high-profile bugs will be fixed)
-- What new tests will be created for this release.
-- What the bug profile will look like--how many bugs of each
priority/severity. For instance, zero showstoppers, 5 pri1, 20 pri2, 30
pri3, etc.
-- Docs match code 100%. No release should ever have TODOs in the docs.
Written and agreed to before any coding on a release begins, this document
(and subsequent branch name) shapes the efforts for the given release and
gives everyone a good idea of what to expect with the next release. This
document should be front-and-center on the web site, ideally with tracking
stats to show how the work is going.
A publicly-published release criteria doc also helps the team figure out
when they are done. All the feature work may be in, and when the bug
profile matches the release criteria, off it goes.
This process probably isn't news to anyone; I can't tell from the James site
if any process (the current TODO list is not a process) is being followed.
My guess, from the veto discussion, is that there's no defined goal for each
release; if there was, people wouldn't be arguing about vetoes at the end of
the release, but at the beginning, where consensus-building should take
place.
Final note, James needs to release a lot more often than it does now. A
major release every year, with quarterly dot-dots is not outside the realm
of reason. With this process, users could look at a release plan and decide
if they want to wait for it or use the existing released version. It is
okay to release less-than-perfect software if people know what they are
getting.
As for source control, the main line represents the _next_ release on the
schedule, and _planned_ future releases live on a branch. Planned means the
release criteria for that release has been written.
Again, this is pretty standard stuff, and it would be good for the James
community to adopt it as a process keep development moving in a consistent
and meaningful direction.
Matt Bishop
[EMAIL PROTECTED]
"We are all here on earth to help others. What I can't figure out is what
the others are here for."
- W. H. Auden
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
