On Wed, Sep 02, 2009 at 10:18:24AM +0200, ermo | Rune Morling wrote:
> So, at the time I asked the original question, there were 30+ open
> issues filed with 'fix for version 2.1.2' and another ten or so filed
> against '2.0.x' - I merely wanted to point out that either those issues
> should be deferred to 2.2 or they should be triaged and fixed before we
> release. And if we fixed a bunch of simple issues, we might have to do
> more promotes before we got to the point where we could in good
> conscience cut a 2.1.2 release with ISOs, release notes and the works.
> You said it yourself earlier in the thread: We suffer from "Be there
> (IRC) or be square"-itis. This is my attempt at trying to change that.
good! thank you.
> But I'm curious to know what your definition of ready is and whether you
> have another proposal for how to instrument our release 'process'?
i would not even think in terms of releases, but rolling updates of
individual components. if any component is stable it should be promoted
regardless of the state of the rest of the system. so if we have a new
version of firefox, why wait until all 'fix for version 2.1.2' are
closed to make a release. just push firefox out and move on.
when it comes to making big releases with ISOs and announcements i still
believe we should wait for gnome which is coming out in 3 weeks. i do
not believe we can make two releases within a month.
i also consider it a good idea to promote stuff to stable before a
release is made, this way the stuff which ends up on the ISOs will get
some more testing by those who use stable. consider that people getting
the ISO are most likely to be first time users who could benefit from
that extra testing.
further, promoting stuff now gets it out of the way from the gnome
update later, and should the gnome update not be successfull, we can
still make a release with whatever is in stable by then.
so in short:
* promote what is stable now,
* try to fix all 'fix for version 2.1.2' and older bugs in the next few
weeks.
* make a big release with ISOs and possibly the new gnome at the end of
this month.
generally i'd like to suggest the following:
* promoting to stable should be done whenever stuff is stable
(and we can continue to trust doniphon or ken or whoever else is in
that position to make that decision, unless they want to delegate
that (eg to qa testers))
* promotions should not be held up for a release
* releases should be made from whatever is in stable at a time when we
feel it is right (eg when all designated bugs are fixed or after
certain stuff (like gnome) has been promoted to stable)
* for a continuous update of released apps, timely promotes are more
interesting than timely releases since the main beneficiaries are
those who already use foresight, not new users who get the ISOs (which
will be out of date a few weeks after a release anyways)
* releases (with ISOs) are not important to reach foresights goals (of
providing timely updates of stable upstream bits) but are mostly
useful for new users and new installs. as such, new ISOs should be
done whenever stable has accumulated enough updates so that installing
from an old ISO would make the following updateall to much of a pain.
* as a consequence maybe it would make sense to replace our use of the
term 'rolling releases' with 'rolling updates' since that is much
closer to reality.
greetings, martin.
--
cooperative communication with sTeam - caudium, pike, roxen and unix
searching contract jobs: programming, training and administration - anywhere
--
pike programmer working in china community.gotpike.org
foresight developer foresightlinux.org open-steam.org
unix sysadmin iaeste.(tuwien.ac|or).at caudium.org
Martin Bähr http://www.iaeste.or.at/~mbaehr/ is.schon.org
_______________________________________________
Foresight-devel mailing list
Foresight-devel@lists.rpath.org
http://lists.rpath.org/mailman/listinfo/foresight-devel
