Re: Cygwin Release process

[Randall R Schulz]

Jim,

At 19:15 2003-01-30, Jim Kleckner wrote:


Larry Hall (RFK Partners, Inc) wrote:


At 09:54 PM 1/30/2003, Jim Kleckner wrote:
[snip ]

Thanks!  While you have the code in hand, would it be
possible to allow the setup window to be resized?
I'm constantly wanting to see more lines at once...

Have you been reading the email archives?  I think I've heard that 
request before! :-)

I see the answer here:
http://sources.redhat.com/ml/cygwin/2002-11/msg00309.html

Sorry to duplicate.  I guess every single thing needs to be searched
before replying...


Only if you haven't been paying close attention for at least two years 
and have a good memory. If you meet those criteria, then you only need 
to review the archives when you're experiencing more than a little uncertainty.


You can always download the archives and search them locally. I find 
that much more useful. Actually, I have everything back to Jan. 2001 in 
Eudora mailbox files, so I can use all the Eudora search capabilities, 
which are pretty good (though in regular expression mode it's kind of 
slow), but all in all it's far better than on-line searching.


I really need to follow through on Glimpse. I got it working under 
Cygwin, but never set it up to actually index my system.


Jim



Randall Schulz 


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

Re: Cygwin Release process

[Jim Kleckner]

Larry Hall (RFK Partners, Inc) wrote:


At 09:54 PM 1/30/2003, Jim Kleckner wrote:

[snip ]

Thanks!  While you have the code in hand, would it be
possible to allow the setup window to be resized?
I'm constantly wanting to see more lines at once...


Have you been reading the email archives?  I think I've heard 
that request before! :-)

I see the answer here:
http://sources.redhat.com/ml/cygwin/2002-11/msg00309.html

Sorry to duplicate.  I guess every single thing needs to be searched
before replying...

Jim


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

Re: Cygwin Release process

[Larry Hall (RFK Partners, Inc)]

At 09:54 PM 1/30/2003, Jim Kleckner wrote:

>Max Bowsher wrote:
>
>>William A. Hoffman wrote:
>[snip]
>>>2. Failing that, it would be nice if the setup program had a button that
>>>set all the values to Keep.   The problem is that if I want a new
>>>package X, I have to click 20 other packages to Keep, or risk an
>>>update of everything. There should be a way to update one single
>>>package.   Is there a way?
>>It's in CVS. The next snapshot will have it.
>>Max.
>
>Thanks!  While you have the code in hand, would it be
>possible to allow the setup window to be resized?
>I'm constantly wanting to see more lines at once...



Have you been reading the email archives?  I think I've heard 
that request before! :-)



Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX


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

Re: Cygwin Release process

[Jim Kleckner]

Max Bowsher wrote:


William A. Hoffman wrote:

[snip]

2. Failing that, it would be nice if the setup program had a button that
set all the values to Keep.   The problem is that if I want a new
package X, I have to click 20 other packages to Keep, or risk an
update of everything. There should be a way to update one single
package.   Is there a way?


It's in CVS. The next snapshot will have it.

Max.


Thanks!  While you have the code in hand, would it be
possible to allow the setup window to be resized?
I'm constantly wanting to see more lines at once...

Thanks again - Jim


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

Re: cygwin Release process

[Randall R Schulz]

Mark,

At 09:38 2003-01-28, Mark Himsley wrote:

On Tue, 28 Jan 2003 08:27:26 -0800 Randall R Schulz wrote:


>>Arthur Dent got an announcement before his home was demolished
>>for a bypass (apologies to those who don't get the HHGTTG reference). :-)
>
>Isn't "hitchhiker" one word? (Even Eudora's meager dictionary thinks so.)

Not in this context.

http://www.bbc.co.uk/h2g2/guide/


I guess I shouldn't be surprised. Apparently "worldwide" isn't either.



--
Mark Himsley



Randall Schulz 


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

Re: cygwin Release process

[Mark Himsley]

On Tue, 28 Jan 2003 08:27:26 -0800 Randall R Schulz wrote:


>>Arthur Dent got an announcement before his home was demolished 
>>for a bypass (apologies to those who don't get the HHGTTG reference). :-)
>
>Isn't "hitchhiker" one word? (Even Eudora's meager dictionary thinks so.)

Not in this context.

http://www.bbc.co.uk/h2g2/guide/

-- 
Mark Himsley

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

RE: cygwin Release process

[Randall R Schulz]

Scott,

At 08:02 2003-01-28, Scott Prive wrote:


...

I don't disagree that the change was "announced". In hindsight, I see 
it was. Arthur Dent got an announcement before his home was demolished 
for a bypass (apologies to those who don't get the HHGTTG reference). :-)

Isn't "hitchhiker" one word? (Even Eudora's meager dictionary thinks so.)


Randall Schulz 


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

RE: cygwin Release process

[Scott Prive]

> -Original Message-
> From: Christopher Faylor [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 27, 2003 6:08 PM
> To: [EMAIL PROTECTED]
> Subject: Re: cygwin Release process
> 
> 
> On Mon, Jan 27, 2003 at 04:54:25PM -0500, Scott Prive wrote:
> >William,
> >
> >The "ntsec" problem by all accounts was a one-time switch 
> that burned a
> >lot of people.  It seems like a great feature (not 
> completely using it
> >myself), and when I upgraded to it I had NO idea of the impending
> >change.  I should have known better than to perform blind upgrades.
> >
> >I've been using Cywin for maybe 3 years (?) now and that's the only
> >major problem I ever had.  It's STILL not resolved, and I do not have
> >time to attempt correcting it since I have required level of
> >functionality.
> >
> >I'd love to see a release process something like Redhat's or 
> Debian's.
> >But that's not enough -- someone has to maintain it.  As a FORMER ;-)
> >Debian user I can say there are some downsides to too much process...
> >like a "stable" tag that's so old almost no one runs 100% from that
> >branch.
> 
> Ok, that's three people complaining about the ntsec change.  Don't you
> see some faulty reasoning here?  How long do you suppose CYGWIN=ntsec
> existed?  It was around for years.  Lots of people used it.  There was
> no way to anticipate that it would cause problems for some people.

I tried to use my experience to bring William around to your point of view. Because 
William is concerned about future upgrades, I presented some scenarios for guarding 
against upgrades. 

I presume you're using Cygwin in a development context -- where it's good if you have 
more eyeballs testing the current code. I'll go out on a limb and assume William used 
Cygwin in a production environment -- where the opposite is true. You stay on 
something you understand, and if you don't knowingly apply major upgrades.
> 
> If we had made the decision to turn CYGWIN=ntsec on in the next major
> "stable" release, then all of horrendous problems that were suffered
> (which, AFAIK, are "solved" these days by saying CYGWIN=nontsec) would
> still have manifested.
> 
> The change *was* announced.  The functionality *was* 
> previously tested.

I don't disagree that the change was "announced". In hindsight, I see it was. Arthur 
Dent got an announcement before his home was demolished for a bypass (apologies to 
those who don't get the HHGTTG reference). :-)

To this day, it's still not on the Cygwin.com home page under "What's New". I don't 
doubt it is mentioned under a particular Release announcement. For better or worse, 
people in the Windows space wouldn't look there anyways. They wouldn't proactively 
subscribe to a mailing list and look for problem reports. What many users would assume 
is a setup utility provides a mechanism for a packager to provide critical warnings 
that must be acknowledged.  

I can't offer that improvement as a patch -- the best I can do is stay out of the way 
by assuming responsibility for my own upgrade testing. But it would be nice :-)

I'd like to end this thread with the following comment:

The hours I lost on my ntsec upgrade (and my botched attempts to fix it which probably 
made it worse) are *insignificant* to the hours of productivity I GAINED by having a 
mostly-complete GNU environment under Windows. 

Cygwin saved me from a complete rewrite task, of scripts which always assumed Linux. I 
can't understate how much I gained here. You made the `almost impossible', possible. 
Thank you (everyone).



> This is not an argument for a stable release.  On the 
> contrary, it's an
> argument for quick corrective releases to fix the problem.
> 
> You make a good point about the old, stable release.  That's 
> one of the
> drawbacks of such a plan.  What about errata?  Are errata going to be
> supplied for the stable release?  Who is going to decide when to make
> a new release?  Is there going to be a voting process?  Who gets to
> vote?  Who gets to arbitrate disputes?
> 
> Debian has a structure for this kind of thing.  So does Red 
> Hat.  I don't
> see any evidence that the Cygwin community has the type of committment
> required for this kind of activity and, I, certainly don't want to be
> worrying about stuff like this.  It requires someone with 
> both the desire
> and organizational skills to pull it together.  The effort to do this
> can't be trivialized.

Agreed.
> 
> I will happily provide the disk space for this but I am not 
> going to be
> changing the

Re: cygwin Release process

[Christopher Faylor]

On Mon, Jan 27, 2003 at 04:54:25PM -0500, Scott Prive wrote:
>William,
>
>The "ntsec" problem by all accounts was a one-time switch that burned a
>lot of people.  It seems like a great feature (not completely using it
>myself), and when I upgraded to it I had NO idea of the impending
>change.  I should have known better than to perform blind upgrades.
>
>I've been using Cywin for maybe 3 years (?) now and that's the only
>major problem I ever had.  It's STILL not resolved, and I do not have
>time to attempt correcting it since I have required level of
>functionality.
>
>I'd love to see a release process something like Redhat's or Debian's.
>But that's not enough -- someone has to maintain it.  As a FORMER ;-)
>Debian user I can say there are some downsides to too much process...
>like a "stable" tag that's so old almost no one runs 100% from that
>branch.

Ok, that's three people complaining about the ntsec change.  Don't you
see some faulty reasoning here?  How long do you suppose CYGWIN=ntsec
existed?  It was around for years.  Lots of people used it.  There was
no way to anticipate that it would cause problems for some people.

If we had made the decision to turn CYGWIN=ntsec on in the next major
"stable" release, then all of horrendous problems that were suffered
(which, AFAIK, are "solved" these days by saying CYGWIN=nontsec) would
still have manifested.

The change *was* announced.  The functionality *was* previously tested.
This is not an argument for a stable release.  On the contrary, it's an
argument for quick corrective releases to fix the problem.

You make a good point about the old, stable release.  That's one of the
drawbacks of such a plan.  What about errata?  Are errata going to be
supplied for the stable release?  Who is going to decide when to make
a new release?  Is there going to be a voting process?  Who gets to
vote?  Who gets to arbitrate disputes?

Debian has a structure for this kind of thing.  So does Red Hat.  I don't
see any evidence that the Cygwin community has the type of committment
required for this kind of activity and, I, certainly don't want to be
worrying about stuff like this.  It requires someone with both the desire
and organizational skills to pull it together.  The effort to do this
can't be trivialized.

I will happily provide the disk space for this but I am not going to be
changing the way I release the packages I provide.  If someone wants to
take my packages, decide if they are "experimental" or "stable", and put
them into a different release framework then more power to them.  Seriously.
I'll applaud and commend their efforts.

cgf

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

RE: Cygwin Release process

[Scott Prive]

William,

The "ntsec" problem by all accounts was a one-time switch that burned a lot of people. 
It seems like a great feature (not completely using it myself), and when I upgraded to 
it I had NO idea of the impending change. I should have known better than to perform 
blind upgrades.

I've been using Cywin for maybe 3 years (?) now and that's the only major problem I 
ever had. It's STILL not resolved, and I do not have time to attempt correcting it 
since I have required level of functionality.

I'd love to see a release process something like Redhat's or Debian's. But that's not 
enough -- someone has to maintain it. As a FORMER ;-) Debian user I can say there are 
some downsides to too much process... like a "stable" tag that's so old almost no one 
runs 100% from that branch.



Here are some suggestions for you William:
1) maintain an internal mirror. Mirroring is very very easy to set up, and you will 
save your company money by eliminating random bandwidth spikes every time someone 
upgrades.

2) Make it EASY for your users to use your mirror (see step 3)

3) In the setup.exe GUI, you can manually add in a custom mirror. Find out if you can 
"preload" your mirror into the GUI, and remove "standard" mirrors. You may need to 
rebuild setup.exe; I'm not certain.

4) Make it more difficult for users to NOT use your mirror. If you're evil. >:-)

5) If you're running internal software/testsuites on top of Cygwin, you can build a 
table of version numbers you expect, and what you see on the system. You can automate 
the building of this table so it is not a hassle every time you "approve" upgrade 
snapshots. If you think some users will install from the net anyways -- this will save 
you some debugging/triage time.


disclaimer: I do *not* know what the current capabilities of setup.exe are. You might 
find discussion along these lines in the archives.

Hope this helps!

Scott





 



> -Original Message-
> From: William A. Hoffman [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 27, 2003 3:24 PM
> To: Max Bowsher; [EMAIL PROTECTED]
> Subject: Re: Cygwin Release process
> 
> 
> Well, if I am the only person with this opinion, then you are right.
> I should stop complaining and burn a CD.   However, I suspect 
> that I am
> not alone in wanting a more stable cygwin.It will be hard 
> to prove my
> case, as the folks that read this list and post to it, tend to
> be more developer oriented, and are more interested in not missing
> out on the latest features than having a stable platform.
> 
> There must be some reason that RedHat, Debian and all the major linux 
> distributions have releases.   
> 
> I belive that if this were setup, and download stats were 
> created, it would
> be come the most common type of download for cygwin. 
> 
> 
> -Bill
> 
> 
> 
> At 08:07 PM 1/27/2003 +, Max Bowsher wrote:
> 
> >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/
> 
> 
> 

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

Re: Cygwin Release process

[William A. Hoffman]

I realize it is a volunteer effort, and a good one, it
really makes windows much nicer to work with!  I am not
demanding or expecting anything.   I am only trying to 
start a discussion that could lead to a possible solution.

I think that this could be done without "much" effort, or
the work of a single person.  I think with a little bit of
work, (and some extra disk), a system could be set up where
most of the work was pushed to the package maintainers.   

I (being a package maintainer) would not mind the extra work.

If there were say a release of cygwin three times a year, where
all the curr packages where moved to cygwin-curr.   And only bug
fixes where allowed into the cygwin-curr setup tag.   Maintainers
of individual packages could either fix bugs found in the cygwin-curr,
or post a read me explaining the work-around.   

Of course this is just an idea, and I do not have the time or the knowledge
of how setup.exe works to implement it.


-Bill





At 08:15 AM 1/28/2003 +1100, Robert Collins wrote:


>Bill, IMO you are missing a key point:
>
>Cygwin is volunteer maintained. No release manager volunteer, and no
>stable release maintainer (who will maintain stable packages after they
>become stale) have stepped up.
>
>The *only* way you will get a stable release is to:
>1) offer to take on all the extra workload needed.
>2) ask (nicely :}) for disk space at sources.redhat.com to hold (1)
>possibly outdated copy of each package.
>3) patch setup.exe, or talk nicely to me :} to give it the functionality
>needed to support such an endeavour.
>
>I've spoken in favour of such an arrangement before, but didn't have the
>time or personal need to justify making it happen.
>
>Oh, and if a 'stable' cygwin became the most downloaded one, I'm sure
>you would get more assistance from the community - but trying to
>convince us to do it is pretty pointless: we are already contributing
>time and effort, and there has been plenty of opportunity for an extant
>maintainer to pipe up with "I'll do it".
>
>Cheers,
>Rob
>-- 
>GPG key available at: .



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

Re: cygwin Release process

[Christopher Faylor]

On Tue, Jan 28, 2003 at 08:15:01AM +1100, Robert Collins wrote:
>Bill, IMO you are missing a key point:
>
>Cygwin is volunteer maintained. No release manager volunteer, and no
>stable release maintainer (who will maintain stable packages after they
>become stale) have stepped up.
>
>The *only* way you will get a stable release is to:
>1) offer to take on all the extra workload needed.
>2) ask (nicely :}) for disk space at sources.redhat.com to hold (1)
>possibly outdated copy of each package.
>3) patch setup.exe, or talk nicely to me :} to give it the functionality
>needed to support such an endeavour.
>
>I've spoken in favour of such an arrangement before, but didn't have the
>time or personal need to justify making it happen.
>
>Oh, and if a 'stable' cygwin became the most downloaded one, I'm sure
>you would get more assistance from the community - but trying to
>convince us to do it is pretty pointless: we are already contributing
>time and effort, and there has been plenty of opportunity for an extant
>maintainer to pipe up with "I'll do it".

I will provide space on sources.redhat.com, if someone is interested in
doing this.

For the record, I have no interest in changing anything.  DJ and I were
well aware of the fact that the Cygwin release process would be
different from Red Hat or Debian when we instituted the current policy.
I don't see anything particularly broken in the process now* so I'm not
going to be making any fixes.  However, I'll support someone with disk
space if they want to experiment with doing things differently.

cgf

*But I will, if pressed, offer many more opinions on this thread, so be
warned.

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

Re: Cygwin Release process

[Robert Collins]

Bill, IMO you are missing a key point:

Cygwin is volunteer maintained. No release manager volunteer, and no
stable release maintainer (who will maintain stable packages after they
become stale) have stepped up.

The *only* way you will get a stable release is to:
1) offer to take on all the extra workload needed.
2) ask (nicely :}) for disk space at sources.redhat.com to hold (1)
possibly outdated copy of each package.
3) patch setup.exe, or talk nicely to me :} to give it the functionality
needed to support such an endeavour.

I've spoken in favour of such an arrangement before, but didn't have the
time or personal need to justify making it happen.

Oh, and if a 'stable' cygwin became the most downloaded one, I'm sure
you would get more assistance from the community - but trying to
convince us to do it is pretty pointless: we are already contributing
time and effort, and there has been plenty of opportunity for an extant
maintainer to pipe up with "I'll do it".

Cheers,
Rob
-- 
GPG key available at: .



signature.asc
Description: This is a digitally signed message part

Re: Cygwin Release process

[[EMAIL PROTECTED]]

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 [EMAIL PROTECTED]
Date: Mon, 27 Jan 2003 20:07:16 -0000
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
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/

Re: Cygwin Release process

[William A. Hoffman]

Well, if I am the only person with this opinion, then you are right.
I should stop complaining and burn a CD.   However, I suspect that I am
not alone in wanting a more stable cygwin.It will be hard to prove my
case, as the folks that read this list and post to it, tend to
be more developer oriented, and are more interested in not missing
out on the latest features than having a stable platform.

There must be some reason that RedHat, Debian and all the major linux 
distributions have releases.   

I belive that if this were setup, and download stats were created, it would
be come the most common type of download for cygwin. 


-Bill



At 08:07 PM 1/27/2003 +, Max Bowsher wrote:

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

Re: Cygwin Release process

[Max Bowsher]

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/

Re: Cygwin Release process

[Max Bowsher]

Igor Pechtchanski wrote:
> The "Keep" button is in the setup CVS already.  Try a setup snapshot.

These aren't auto-generated. The latest one doesn't have this in, yet.

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/

Re: Cygwin Release process

[Igor Pechtchanski]

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, [EMAIL PROTECTED] 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/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,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/

Re: Cygwin Release process

[William A. Hoffman]

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, [EMAIL PROTECTED] 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



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

Re: Cygwin Release process

[[EMAIL PROTECTED]]

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
 
Original Message:
-
From: William A. Hoffman [EMAIL PROTECTED]
Date: Mon, 27 Jan 2003 11:30:43 -0500
To: [EMAIL PROTECTED]
Subject: Re: Cygwin Release process


What I am suggesting is taking the same approach as Debian.
Each package in Debian is in one of these states:
Stable, Testing, or Unstable.

Stable packages - should work.
Testing packages - working on becoming the next stable version
Unstable packages - all other packages, might be working towards Testing
status.

At some point in time, all Stable packages are collected up, and
a Stable Debian release is made.   Only security patches can be applied
to the packages that make up a stable release.   

I think it is very important to have an entire cygwin that is stable.
As it is now, when you run Setup, you have no idea what you will get.
It is likely to be very different than the machine you did last week.

Almost every time I update cygwin I get some sort of unexpected problem.
Last time it was the ntsecurity stuff, that is now fixed, but for a week or
two,
the "Stable" cygwin, did not work on networked XP machines.   Just this
last time, I got a copy of tclsh83.exe installed into /usr/bin that does
not follow the naming convention, (it should be cygtclsh83)   This caused
problems on my machine.  

If I run Setup today, I may get some other problem.   There really needs to
be a stable snapshot of the entire cygwin.   It would be a known quantity,
with
expected problems.It is much like working with CVS.
You have periodic releases of the software that are put on a CVS release
branch, the
branch only gets serious errors fixes, but no new development is done on
the branch.
Brave folks and developers, that need the current development, can cvs
update from
the main tree.

I realize that software changes quickly, but there are folks that just want
to use cygwin.   We still have machines that ran setup a year ago, and for
what they need to do, cygwin works fine.I really do not think it would
be
that much to ask for a stable snapshot of the all the packages in cygwin
three times
a year.   Only serious bugs and security problems can be patched on the
packages 
in the release of cygwin.

"Moving to Fast" is exactly the problem.   You can not have stable and fast
moving
development at the same time.  Stable means working and un-changed.   

Lets say I have ten computers that I want to install cygwin on.   If I go
around
to each computer and run setup, by the time I am done, I could have 10
different installations of cygwin, and each computer may run slightly
different.   I do not
see how that is stable.

stable:
- Resistant to change of position or condition; not easily moved or
disturbed: a house built on stable ground; a stable platform. 
- Not subject to sudden or extreme change or fluctuation: a stable economy;
a stable currency. 

As a whole cygwin is a very un-stable platform, because each of the
packages that make
up cygwin, are in constant motion.


-Bill


At 01:55 PM 1/23/2003 -0800, Randall R Schulz wrote:
>William,
>
>At 13:39 2003-01-23, William A. Hoffman wrote:
>>Is there any way to control the versions of programs you get from
setup.exe?
>>The cygwin environment is different on almost every machine at our
company.
>>It all depends on when you ran the setup program.I have two
suggestions:
>
>The Cygwin Setup.exe installer offers you the current release-level
version, the previous version (if any) and, sometimes, a forward-looking
"experimental" version.
>
>
>>1. It would be nice, if the

Re: Cygwin Release process

[Max Bowsher]

William A. Hoffman wrote:
> What I am suggesting is taking the same approach as Debian.
> Each package in Debian is in one of these states:
> Stable, Testing, or Unstable.
>
> Stable packages - should work.

We have this. Its called [curr]

> Testing packages - working on becoming the next stable version
> Unstable packages - all other packages, might be working towards
> Testing status.

We don't differentiate these. We call such packages [test].

> At some point in time, all Stable packages are collected up, and
> a Stable Debian release is made.   Only security patches can be
> applied to the packages that make up a stable release.

This requires a large amount of organization. It's not going to happen. It's
also unneccessary since [curr] should be stable anyway, at any point.

> I think it is very important to have an entire cygwin that is stable.
> As it is now, when you run Setup, you have no idea what you will get.
> It is likely to be very different than the machine you did last week.

Cygwin works on a basis of continual upgrades. If this worries you, then
burn a CD, or create a network share. Instant frozen version.

> Almost every time I update cygwin I get some sort of unexpected
> problem.
> Last time it was the ntsecurity stuff, that is now fixed, but for a
> week or two,
> the "Stable" cygwin, did not work on networked XP machines.   Just
> this
> last time, I got a copy of tclsh83.exe installed into /usr/bin that
> does
> not follow the naming convention, (it should be cygtclsh83)   This
> caused
> problems on my machine.

It's obvious (in hindsight) that the ntsec change should have been done much
slower, or not at all.

Things like this haven't happened often, and I imagine that the lesson of
the ntsec change will be remembered.

> If I run Setup today, I may get some other problem.

You might. But its very unlikely. There are very many people running a
continuously updated Cygwin. Even if a problem arises, you can always roll
back a version.

> There really needs to be a stable snapshot of the entire cygwin.

Do you volunteer to maintain such a thing? If not, who do you expect to do
it?

> It would be a known quantity, with expected problems.


> It is much like working with CVS.
> You have periodic releases of the software that are put on a CVS
> release branch, the branch only gets serious errors fixes, but no
> new development is done on the branch. Brave folks and developers,
> that need the current development, can
> cvs update from the main tree.

And many small projects use CVS, but don't do branches, because there are
not enough developers to support seperate streams of development.

> I realize that software changes quickly, but there are folks that
> just want to use cygwin. We still have machines that ran setup a
> year ago, and for what they need to do, cygwin works fine. I really
> do not think it would be that much to ask for a stable snapshot of
> the all the packages in cygwin three times a year. Only serious
> bugs and security problems can be patched on
> the packages in the release of cygwin.
>
> "Moving to Fast" is exactly the problem.   You can not have stable
> and fast moving development at the same time.  Stable means working and
un-changed.
>
> Lets say I have ten computers that I want to install cygwin on.   If
> I go around
> to each computer and run setup, by the time I am done, I could have
> 10 different installations of cygwin, and each computer may run
> slightly different.   I do not
> see how that is stable.
>
> stable:
> - Resistant to change of position or condition; not easily moved or
> disturbed: a house built on stable ground; a stable platform.
> - Not subject to sudden or extreme change or fluctuation: a stable
> economy; a stable currency.

You made your point several paragraphs ago. Now you're ranting.
As I said above: You want a snapshot? Make one. Download, burn to CD or put
on internal network. Done.

> As a whole cygwin is a very un-stable platform, because each of the
> packages that make up cygwin, are in constant motion.

My experience does not support this opinion.


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/

Re: Cygwin Release process

[William A. Hoffman]

What I am suggesting is taking the same approach as Debian.
Each package in Debian is in one of these states:
Stable, Testing, or Unstable.

Stable packages - should work.
Testing packages - working on becoming the next stable version
Unstable packages - all other packages, might be working towards Testing status.

At some point in time, all Stable packages are collected up, and
a Stable Debian release is made.   Only security patches can be applied
to the packages that make up a stable release.   

I think it is very important to have an entire cygwin that is stable.
As it is now, when you run Setup, you have no idea what you will get.
It is likely to be very different than the machine you did last week.

Almost every time I update cygwin I get some sort of unexpected problem.
Last time it was the ntsecurity stuff, that is now fixed, but for a week or two,
the "Stable" cygwin, did not work on networked XP machines.   Just this
last time, I got a copy of tclsh83.exe installed into /usr/bin that does
not follow the naming convention, (it should be cygtclsh83)   This caused
problems on my machine.  

If I run Setup today, I may get some other problem.   There really needs to
be a stable snapshot of the entire cygwin.   It would be a known quantity, with
expected problems.It is much like working with CVS.
You have periodic releases of the software that are put on a CVS release branch, the
branch only gets serious errors fixes, but no new development is done on the branch.
Brave folks and developers, that need the current development, can cvs update from
the main tree.

I realize that software changes quickly, but there are folks that just want
to use cygwin.   We still have machines that ran setup a year ago, and for
what they need to do, cygwin works fine.I really do not think it would be
that much to ask for a stable snapshot of the all the packages in cygwin three times
a year.   Only serious bugs and security problems can be patched on the packages 
in the release of cygwin.

"Moving to Fast" is exactly the problem.   You can not have stable and fast moving
development at the same time.  Stable means working and un-changed.   

Lets say I have ten computers that I want to install cygwin on.   If I go around
to each computer and run setup, by the time I am done, I could have 10 different 
installations of cygwin, and each computer may run slightly different.   I do not
see how that is stable.

stable:
- Resistant to change of position or condition; not easily moved or disturbed: a house 
built on stable ground; a stable platform. 
- Not subject to sudden or extreme change or fluctuation: a stable economy; a stable 
currency. 

As a whole cygwin is a very un-stable platform, because each of the packages that make
up cygwin, are in constant motion.


-Bill


At 01:55 PM 1/23/2003 -0800, Randall R Schulz wrote:
>William,
>
>At 13:39 2003-01-23, William A. Hoffman wrote:
>>Is there any way to control the versions of programs you get from setup.exe?
>>The cygwin environment is different on almost every machine at our company.
>>It all depends on when you ran the setup program.I have two suggestions:
>
>The Cygwin Setup.exe installer offers you the current release-level version, the 
>previous version (if any) and, sometimes, a forward-looking "experimental" version.
>
>
>>1. It would be nice, if there was a cygwin-stable that had a list of stable
>>packages that you could download.   This would be updated two to three times a
>>year, with testing.   I belive Debian does something like this.
>
>The software comprising Cygwin moves much too fast to have releases only a "few 
>times" each year. The "current" release is always deemed stable by the authors and / 
>or maintainers. It usually is (stable, i.e.).



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

Re: cygwin Release process

[Christopher Faylor]

On Fri, Jan 24, 2003 at 03:39:46PM -, Steve Fairbairn wrote:
>How cliquey?  I reckon us outsiders should make a mass exodus if
>Christopher *in-most-mother-esq-tone-I-can-manage* fails to explain
>himself.

It's simple:  Corinna works for me.

cgf

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

RE: cygwin Release process

[Steve Fairbairn]

How cliquey?  I reckon us outsiders should make a mass exodus if Christopher
*in-most-mother-esq-tone-I-can-manage* fails to explain himself.

-Original Message-
From: Christopher Faylor [mailto:[EMAIL PROTECTED]]
Sent: 24 January 2003 15:34

Actually, in a way, I guess I did say it.

cgf
(inside joke)

*** 
This email has originated from Perwill plc (Registration No. 1906964) 
Office registered at: 13A Market Square, Alton, Hampshire, GU34 1UR, UK 
Tel: +44 (0)1420 545000 
Fax: +44 (0)1420 545001 
www.perwill.com 
*** 
Privileged, confidential and/or copyright information may be contained 
in this email, and is only for the use of the intended addressee. 
To copy, forward, disclose or otherwise use it in any way if you are not 
the intended recipient or responsible for delivering to him/her is
prohibited.
If you receive this email by mistake, please advise the sender immediately, 
by using the reply facility in your email software.

We may monitor the content of emails sent and received via our network 
for the purposes of ensuring compliance with policies and procedures. 
This message is subject to and does not create or vary any contractual 
relationships between Perwill plc and the recipient. 
*** 
Any opinions expressed in the email are those of the sender and not 
necessarily of Perwill plc.
*** 
This email has been scanned for known viruses using 
McAfee WebShield 4.5 MR1a 
*** 



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

Re: cygwin Release process

[Christopher Faylor]

On Fri, Jan 24, 2003 at 10:55:54AM +0100, Corinna Vinschen wrote:
>On Thu, Jan 23, 2003 at 04:39:21PM -0500, William A. Hoffman wrote:
>> Is there any way to control the versions of programs you get from setup.exe?
>> The cygwin environment is different on almost every machine at our company.
>> It all depends on when you ran the setup program.I have two suggestions:
>> 
>> 1. It would be nice, if there was a cygwin-stable that had a list of stable 
>> packages that you could download.   This would be updated two to three times a
>> year, with testing.   I belive Debian does something like this.
>> 
>> 2. Failing that, it would be nice if the setup program had a button that
>> set all the values to Keep.   The problem is that if I want a new package X,
>> I have to click 20 other packages to Keep, or risk an update of everything.
>> There should be a way to update one single package.   Is there a way?
>
>3. Download a current state of the packages and set up your own mirror used 
>   exclusively in your company.  This way you have full control which
>   packages are used on all machines.

Dang.  I was going to say this.

Actually, in a way, I guess I did say it.

cgf
(inside joke)

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

Re: Cygwin Release process

[Corinna Vinschen]

On Thu, Jan 23, 2003 at 04:39:21PM -0500, William A. Hoffman wrote:
> Is there any way to control the versions of programs you get from setup.exe?
> The cygwin environment is different on almost every machine at our company.
> It all depends on when you ran the setup program.I have two suggestions:
> 
> 1. It would be nice, if there was a cygwin-stable that had a list of stable 
> packages that you could download.   This would be updated two to three times a
> year, with testing.   I belive Debian does something like this.
> 
> 2. Failing that, it would be nice if the setup program had a button that
> set all the values to Keep.   The problem is that if I want a new package X,
> I have to click 20 other packages to Keep, or risk an update of everything.
> There should be a way to update one single package.   Is there a way?

3. Download a current state of the packages and set up your own mirror used 
   exclusively in your company.  This way you have full control which
   packages are used on all machines.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

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

Re: Cygwin Release process

[Randall R Schulz]

Max,

At 14:10 2003-01-23, Max Bowsher wrote:

Randall R Schulz wrote:
>> 2. Failing that, it would be nice if the setup program had a button
>> that
>> set all the values to Keep.   The problem is that if I want a new
>> package X, I have to click 20 other packages to Keep, or risk an
>> update of everything. There should be a way to update one single
>> package.   Is there a way?
>
> Your request sounds familiar and it or something like it probably has
> already been suggested. I'm sure that if you'd like to contribute the
> patches necessary to realize that feature, it would be considered
> seriously for incorporation into the mainstream source base.

Already there!
Commited to CVS by me 2003/01/19 20:31:52.


A few releases per year indeed.

RRS



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/

Re: Cygwin Release process

[Max Bowsher]

Randall R Schulz wrote:
>> 2. Failing that, it would be nice if the setup program had a button
>> that 
>> set all the values to Keep.   The problem is that if I want a new
>> package X, I have to click 20 other packages to Keep, or risk an
>> update of everything. There should be a way to update one single
>> package.   Is there a way? 
> 
> Your request sounds familiar and it or something like it probably has
> already been suggested. I'm sure that if you'd like to contribute the
> patches necessary to realize that feature, it would be considered
> seriously for incorporation into the mainstream source base.

Already there!
Commited to CVS by me 2003/01/19 20:31:52.

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/

Re: Cygwin Release process

[Randall R Schulz]

William,

At 13:39 2003-01-23, William A. Hoffman wrote:

Is there any way to control the versions of programs you get from setup.exe?
The cygwin environment is different on almost every machine at our company.
It all depends on when you ran the setup program.I have two suggestions:


The Cygwin Setup.exe installer offers you the current release-level 
version, the previous version (if any) and, sometimes, a 
forward-looking "experimental" version.


1. It would be nice, if there was a cygwin-stable that had a list of stable
packages that you could download.   This would be updated two to three times a
year, with testing.   I belive Debian does something like this.


The software comprising Cygwin moves much too fast to have releases 
only a "few times" each year. The "current" release is always deemed 
stable by the authors and / or maintainers. It usually is (stable, i.e.).


2. Failing that, it would be nice if the setup program had a button that
set all the values to Keep.   The problem is that if I want a new package X,
I have to click 20 other packages to Keep, or risk an update of everything.
There should be a way to update one single package.   Is there a way?


Setup.exe only offers to update packages that are already installed. It 
does always initialize the package selection display to the latest 
release-quality version. I happen to think that's a good idea even 
though at the moment I'm repeatedly rolling the Cygwin package back to 
1.3.17 and the Perl ahead to 5.8.0 (both "Keep" for my current installation).

Your request sounds familiar and it or something like it probably has 
already been suggested. I'm sure that if you'd like to contribute the 
patches necessary to realize that feature, it would be considered 
seriously for incorporation into the mainstream source base.


-Bill



Randall Schulz 


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

Re: Cygwin Release process

[Max Bowsher]

William A. Hoffman wrote:
> Is there any way to control the versions of programs you get from
> setup.exe? The cygwin environment is different on almost every
> machine at our company. It all depends on when you ran the setup
> program.I have two suggestions:
>
> 1. It would be nice, if there was a cygwin-stable that had a list of
> stable packages that you could download.   This would be updated two
> to three times a year, with testing.   I belive Debian does something
> like this.

Theoretically, all [curr] packages are stable.
Besides, where do you propose we get a load of testers from, two or three
times a year?

> 2. Failing that, it would be nice if the setup program had a button
> that
> set all the values to Keep.   The problem is that if I want a new
> package X, I have to click 20 other packages to Keep, or risk an
> update of everything. There should be a way to update one single
> package.   Is there a way?

It's in CVS. The next snapshot will have it.


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/