Mark de Wever <[EMAIL PROTECTED]>:
> On Sun, Mar 02, 2008 at 09:06:48AM -0500, Eric S. Raymond wrote:
> > I think we should shorten our stable-release interval to 6 months.
>
> Personally I think the current cycle of about one year is rather nice. A
> release costs quite some resources for final polishing. Which means the
> effective time for developing new features will be reduced.
Frankly I think that might be a good thing. We should be doing new features
in small, well-contained pieces. Anything that takes most of a year
to implement was probably architecturally wrong to begin with.
> > (In retrospect, I think it was in
> > a stagnant period when I joined -- and I think the commit-frequency
> > graphs on Ohloh confirm this.)
>
> I think the available time for most developers fluctuates quite a lot,
> at least it does for me.
Agreed. The sum of lots of individual random variations is what
naturally produces a bursty activity graph. Still, there are trends
over the cycle, and I've seen them both here and in other projects.
> > Late last year I lost some initial members of my UI test group simply
> > because 1.4 was too far in the future to sustain their interest --
> > they weren't going to get to see the fruits of their labor soon
> > enough, lost motivation, and drifted away. (This is what specifically
> > started me thinking our release interval is a problem.)
>
> I see that as a problem, but I fear that we get the opposite with short
> cycles. Devs losing interest since there's not enough time to implement
> features and they spend too much time polishing for a release. I *do*
> like new releases and also to polish them, but I like coding new
> features much more.
I'm not worried. Six months is more than enough time to implement any
individual thing on anyone's plans list. As long as each dev
continues to get at least one large thing done per cycle I doubt
anyone will bail on us for that reason.
In truth, I think we could do a release cycle as short as *four* months
and not have a problem that way. Less than that would be iffy.
> If we get accepted for SoC this is impossible since the end date for SoC
> is the 18th of Augustus. Personally I think this might be a nice point
> to do a bug stomp party.
Good point. Revised proposal follows:
Present -> 18 May: Open development
19 May -> 26 May: "Week of Bug-Stomping" -- soft feature freeze in effect
27 May -> 18 July: Open development
19 July -> 18 Aug: Feature freeze, bug stomping, translations
19 Aug: 1.6 release
I think this is worth a try at least once. If it proves too constraining
we could go back to a 12-month cycle, but I don't think it will.
> I'm not following the release schedules of distros but I think it's
> impossible, regardless of the cycle length, to 'get it right' for all
> distros. It might even cause some slower distros to be a full cycle behind.
Getting it right for everybody isn't possible, true. But with a six-month
release cycle we'd double our chances of having a fresh release available
at each distro's drop-dead point.
We could also make use of the fact that distro commit points aren't
evenly distributed around the year. The clear trend is for distros to
have Spring and Fall releases. Thus, the best timing for releasing
ito them would be to have one semiannual cycle end with August and a
second end with February.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
