[csw-maintainers] RFD: Releases and staging proposal

James Lee james at opencsw.org
Tue Feb 9 20:10:23 CET 2010


On 08/02/10, 21:05:43, Dagobert Michelsen <dam at opencsw.org> wrote regarding
Re: [csw-maintainers] RFD: Releases and staging proposal:

> > You've already put release candidate packages under experimental, so is
> > it just a proposal?   Ref also:
> > http://wiki.opencsw.org/automated-release-process
> > no mention of proposition status.

> Do you like it? If you have ideas to make this easier or more
> useful just say so. Additionally, I haven't changed anything on
> testing/, so, yes, it is still a proposal. If I get no feedback
> it may become the new standard.

That's exactly what I don't like.  Propose it, consider in the
official way, if approved then adopt.


> > The wording defines the matter so is inseparable - it's a written
> > proposal.  I've already question the naming and that there isn't much
> > materially different to what has happened, at least there is not
> > sufficient detail such that I can tell what distinguishes the proposal,
> > perhaps it could explain?  i.e. make incremental on previous.

> I'm sorry, I don't understand what you are asking. Really. What do
> you mean by "what distinguishes the proposal"?

Highlight and detail what is different.


> > 6 month cycles make releases harder because it's harder to hold stuff
> > back the longer the gap is.  This situation afflicts us now having to
> > accommodate a period of great change and innovation.  Only regularly
> > updated packages occur in every cycle and these tend not to be the
> > problematic ones anyway.

> Ok, so you are suggesting shortening release cycles to 4 or 3 month.

No.  I'm not making a proposal.  It is the proposer that suggests
lengthening the previous cycle.

I'm pointing out that doubling the length does not make the task twice
as easy and the long span we currently have is a major factor in not
moving forward.  I can tell you the first stable release in 2005 which
spanned maybe 2 years was by far the hardest.



James.


More information about the maintainers mailing list