On Thu, 2009-07-02 at 12:33 -0700, David Brownell wrote:
> On Thursday 02 July 2009, Zach Welch wrote:
> > At this point, I will probably finish this release by hand, but I want
> > to have the community check the recipe before I start using it.  Have I
> > missed anything important here?
> 
> Hmm, I think one month between releases puts them kind of
> into the "noise" level.  Too frequent.  Folk barely have
> time to dive in before the next one is there...
> 
> I'd remove the commitment to once-a-month and leave it
> open.  Sometimes a month might be right.  Sometimes more
> will be appropriate.

Yeah.  I thought about that.  At this point, I think it is better to
shoot for a one month cycle but allow for it to take two months. ;)

Really, the Release Manager should be the one that makes these calls.
If a hundred big patches get committed in a week, it might be time to
stop and push a new release; if nothing gets committed for two months,
then even that might be too frequent.  The RM should keep track of these
things and use their best judgment, while keeping the community informed
of their perspective and decisions as they change over time.

Right now, I would rather we produce "noise" than risk producing less
volume than users and distributions demand.  Presently, we have no way
of characterizing these demands, and it seems better to over-deliver in
this key area.  At worst, users will simply start skipping releases, and
I would rather have that happen than see them demanding more releases.
Anyone can complain if releases are "too long"; it's hard to make a
convincing claim that they are too short (e.g. "nightly snapshots"),
particularly if we always list the most recent "stable" release(s).

Finally, I still see a considerable volume of patches pending.  For this
reason alone, one month cycles sound fine for several releases to come;
after that, I would be happy to tune this particular policy as needed.
Right now, I see a clear and present need for frequent releases, since
my own vision can see hundreds of patches waiting to be crafted.

Please provide additional feedback on this, if you think this is wrong.
Regardless of any plans proposed today, I do not want any release cycle
to be decided in advance and followed with mindless rigor.  I thought I
put something in there to this effect, but I may have missed this idea.

Cheers,

Zach

_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to