Because I know that this email will not have any effect probably I suggest we
change our policy for releasing new versions (version as in 0.7.5, 0.8, etc.)
to:
============================================
1. ALL issues with the given target version in the bugtracker must be
resolved, closed or assigned a different target version. NO release with a
single open issues in the roadmap page (= with the given target version).
2. NO release if there are any issues with block/crash severity and no target
version. They must be assigned a target version first, which will cause rule 1
to hit maybe.
============================================
While i can sypathise with what you are saying, i'd like to point out that this
is not the best policy, mainly because that would automatically collapse freenet
into 2/2/0.5 rule. Look at the way more and more software is being developped
today in an agile world, what is stationary *is* the date, and it's the features
that are changed.
Look at Ubuntu for example. With all its flaws the good thing is their
predictable release schedule. I know when the next version will come out
(2011-April), i know what is the most recent version (2010-October) simply by
looking at the callendar.
I think a better set of rules would be:
1. No new features are taken on board until the critical bugs get fixed.
2. When a new feature is asked for (i'm thinking of a new GUI for example), it
must be stated which features planned for the next release, but not yet
implemented, are proposed to be abandoned.
3. There is a cut-off date for the proposals of new features that would be
implemented in this version (but not for the complete patches to be applied).
4. The release dates get can get pushed back (slightly) only for critical bug
fixing, but never for new awesome features.
- Volodya
--
http://freedom.libsyn.com/ Echo of Freedom, Radical Podcast
"None of us are free until all of us are free." ~ Mihail Bakunin
_______________________________________________
Devl mailing list
[email protected]
http://freenetproject.org/cgi-bin/mailman/listinfo/devl
