It's been pretty quiet on the release front. I was just looking over the
past thread (toward the bottom of "Defragmenting the LiveCD", and noticed
that there seems to be some confusion over who is the release manager. Hisham
is presuming that Lucas is, but Carlo also said that he would be willing to
do so. Would the real release manager please stand up? :)
Given that 014RC1 (which apparently was really 014Beta1) was released over
three months ago, it seems to me that the development process needs to be
more transparent. What's been fixed? What still needs to be fixed?
While it's too late in the process to implement now, may I make the
following suggestions for 015?
1. Clear roadmap. Use the wiki for this. Once 014 is released, announce on
the forums and mailing lists that suggestions for 015 are open for a limited
time period (say one month). That way, everyone can contribute to what they
think should be in 015. Obviously, there will be items that won't be
attainable, but for the first month, let everyone brainstorm. If there are
people interested in implementing a functionality, that would also be the
place to volunteer. At the end of the month, go through the suggestions and
from that, create the roadmap.
2. Transparent development. 013 was supposed to be the release that would
allow the process to become more transparent. Unfortunately, that didn't
happen. My suggestion is this: once the roadmap has been completed, it's an
easy matter to create a progress page of how things are developing. I'm
thinking of something similar to what KDE does: three categories (not
started - red, in progress - yellow, completed - green), with sub-categories
under that listing areas of development (e.g. Scripts, Installer, etc.) The
problem with KDE's progress reports was that it was rarely updated in
real-time, but that's probably due to the fact that it wasn't a wiki, but
someone else had to make the changes to the page, rather than the person who
had done the work. The advantage is that it becomes immediately obvious what
needs work, and how much remains before the next release.
3. Clear release schedules. Rather than waiting for months on end between
releases that unexpectedly appear, create a schedule and stick to it. The
long wait periods just sap energy and excitement. Speaking personally, I
*need* a deadline if I really want to get work done. If I don't have a date,
then things tend to slip. Simply as a suggestion, here is a six-month
schedule that seems reasonable in its "do-ability":
Jan 1-31: Community brainstorming time. Create roadmap and progress page
at the end of this time period.
Feb. 1 - Apr 30: Chief development time; update progress page as things
develop.
May 1: Beta release issued, so that everyone can "re-sync" with
development.
May 21: RC1 released.
Jun. 12 RC2 released.
Jul. 1 Final released.
I put the releases three weeks apart, since that seems to be peak testing
time. People test it for a week, week and a half, and then generally move on.
With proper assignment, bug fixes can be prepared in time before the next
release. Whatever the dates are, what is important is that there are dates,
and that they are followed as closely as possible.
What say you all?
:Peter
_______________________________________________
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
