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
Date: Mon, 27 Jan 2003 14:41:38 -0500 (EST)
From: Igor Pechtchanski <pechtcha AT cs DOT nyu DOT edu>
Reply-To: cygwin AT cygwin DOT com
To: cygwin AT cygwin DOT com
Subject: Re: Cygwin Release process
In-Reply-To: <5.2.0.9.0.20030127132032.031f91e0@pop.nycap.rr.com>
Message-ID: <Pine.GSO.4.44.0301271422260.26400-100000@slinky.cs.nyu.edu>
Importance: Normal
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit

Bill,

The "Keep" button is in the setup CVS already.  Try a setup snapshot. ;-)

There does seem to be a tendency that most of the problems are introduced
when a major new version of a package (*-1) is released.  The *-[2-9]
versions are usually bugfixes applied specifically to the Cygwin port of
the package.  What I suggest is marking the *-1 versions of any package
"experimental" initially, rather than "curr" (as it was done with perl).
Subsequent versions could also be marked "experimental" until the
maintainer feels there will not be further complaints, at which point the
package could be promoted to "curr" (which could happen with a *-1 as
well).  This way, people who want "stability" would only upgrade to
"curr".  People who like to use the latest and greatest will have to use
"experimental" as their preferred mode (persistent setup options could
help here).  We could introduce a fourth category, "testing", to go
between "curr" and "experimental", so that we reserve "experimental" for
stuff that's really "out on a limb", although, from what I've seen
"experimental" used for (perl 5.8), I think "experimental"  should do
fine.  Just my 2¢, sorry for the rant.
	Igor

On Mon, 27 Jan 2003, William A. Hoffman wrote:

> The new View:Partial does help.  I can now easily see what will get updated.
> It would be nice if there was a button, that set all of them to keep.
> Often times, I want to update only a single package, and that makes it
> easier.
>
> 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. You said
> this has come up before.   Can you give me the search string so that I can look
> at the old discussions.  I searched on release, but did not find anything
> relevant.
>
> -Bill
>
>
> At 12:13 PM 1/27/2003 -0500, lhall AT pop DOT ma DOT ultranet DOT com wrote:
>
> >Bill,
> >
> >This subject has been discussed before on this list.  May I suggest you
> >review the email archives if you plan to further pursue the discussion
> >here?
> >It would be a great help if any discussion of this topic covered some new
> >ground.
> >
> >As it stands, the Cygwin distribution as available through cygwin.com and
> >it's mirrors contain the current version (or versions) that the maintainers
> >of the packages feel comfortable supporting.  These are the packages that
> >users should install if they want to be able to ask the list for help with
> >any issues they might encounter when using the packages.  Supporting other
> >versions of these packages (older or newer) is at the discretion of the
> >individual package maintainers.
> >
> >Currently, there is no configuration management to the releases of Cygwin.
> >Convenient mechanisms for tracking package version dependencies don't exist
> >yet in setup.exe.  This, at least, would be a requirement before setup.exe
> >could support a notion of what you're talking about.  But this is only a
> >minor part of the requirements the your "request" implies.  For now, if you
> >need this kind of control, it needs to be managed by a local mirror.  Doing
> >this gives you full control over the packages available and the versions.
> >Without volunteers to support more, this is likely to be your best option
> >at this time.
> >
> >HTH,
> >
> >Larry

-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor AT watson DOT ibm DOT com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune


--
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/