Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <114780-220031127202612954@M2W065.mail2web.com>
Reply-To: lhall AT rfk DOT com
From: "lhall AT pop DOT ma DOT ultranet DOT com" <lhall AT pop DOT ma DOT ultranet DOT com>
To: maxb AT ukf DOT net, cygwin AT cygwin DOT com, billlist AT nycap DOT rr DOT com
Subject: Re: Cygwin Release process
Date: Mon, 27 Jan 2003 15:26:12 -0500
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

And, at the risk of raising tempers of those in the current round of this 
thread, can we please not cover old ground on this one?  If you're not 
willing to look up in the email archives and review the old thread to make 
sure you're not interjecting the same arguments for and against, the result 
of this current thread is going to be no different from the last (yes, I
know 
- I've been asked to provide the thread pointer - I still have to look it 
up... but don't let that stop anyone here from looking it up too/instead! 
;-) )  

I think we can all agree there are benefits and detriments to having/not
having a "stable version" (assuming there's even agreement on what a 
"stable version" is).  Debating that back and forth is an exercise in 
futility.  I would only ask that the interested parties recognize this and
take steps to avoid such a "debate" in this thread.

Thanks,

Larry

 
Original Message:
-----------------
From: Max Bowsher maxb AT ukf DOT net
Date: Mon, 27 Jan 2003 20:07:16 -0000
To: cygwin AT cygwin DOT com, billlist AT nycap DOT rr DOT com
Subject: Re: Cygwin Release process


William A. Hoffman wrote:
> So, from the feedback I am getting, it really boils down to a "not
> enough people to maintain the feature" issue.  I don't think that
> people don't think that a stable release of cygwin would be a bad
> thing, it is just that there
> is no one to maintain it.
>
> The least intrusive approach I can think of is the following:
>
> Once a quarter, there is a cygwin release.   All packages in curr, get
> automatically moved to cygwin-cur once a quarter.
>
> cygwin-curr, prev, curr, exp
>
> If bugs are reported for packages in cygwin-curr, they can be fixed,
> but no new versions are allowed.   I would expect that this would
> provide a more stable cygwin with not much manual effort.
>
> I guess the problem is to convince folks, that this is a useful thing
> to do. As a cygwin user, I think it would provide a more stable
> platform.

I think it would unnecessarily delay people from updating to latest package
versions.
The point is *[curr] is meant to be stable*. Occasionally a problem may slip
through. Fine. That's what the option of reverting a package to [prev] is
for. When problems arise, they are fixed quickly, or the package is pulled,
and the [prev] reinstated to [curr].

If this is not good enough for you, then *just burn a CD*. There is no need
to force this artificial 'release' policy on the Cygwin project.


Max.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/