Re: Release management - technical

1998-06-23 Thread Luis Francisco Gonzalez
Enrique Zanardi wrote: On Mon, Jun 22, 1998 at 01:38:21PM +0100, Ian Jackson wrote: Enrique Zanardi writes (Re: Release management - technical): On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote: ... I think we can only do one of these. With hamm we're doing the latter

Re: Release management - technical

1998-06-22 Thread Ian Jackson
Enrique Zanardi writes (Re: Release management - technical): On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote: ... I think we can only do one of these. With hamm we're doing the latter; in the future I think we should do the former. Fine, as long as we have some long term goals

Re: Release management - technical

1998-06-22 Thread Craig Sanders
On Mon, 22 Jun 1998, Ian Jackson wrote: We should continue to have `long term goals', and I applaud people who work towards them, but we must be able to make a release even when they are not met. It is better to have a release now and goals later than no release now and goals later ! and

Re: Release management - technical

1998-06-22 Thread Meskes, Michael
! | Fax: (+49) 2405/4670-10 -Original Message- From: Craig Sanders [SMTP:[EMAIL PROTECTED] Sent: Monday, June 22, 1998 4:17 PM To: Ian Jackson Subject:Re: Release management - technical anyway, what i really wanted to say here

Re: Release management - technical

1998-06-22 Thread Enrique Zanardi
On Mon, Jun 22, 1998 at 01:38:21PM +0100, Ian Jackson wrote: Enrique Zanardi writes (Re: Release management - technical): On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote: ... I think we can only do one of these. With hamm we're doing the latter; in the future I think we

Re: Release management - technical

1998-06-22 Thread Grant Bowman
At 5:38 AM -0700 6/22/98, Ian Jackson wrote: David Engel writes (Re: Release management - technical): On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote: Q. What are we trying to achieve ? A. There are two possibilities that I can see - Timely and good-quality releases

Re: Release management - technical

1998-06-11 Thread Andreas Jellinghaus
Incoming - unstable - unreleased - stable 100% agree. some times unstable is so stable, that many people use it. this is bad, if it's stable, it should have been released. some times unstable is absolutelyy not useable, and it breaks my system (grep bug, bash bug, new xxx without new

Re: Release management - technical

1998-06-11 Thread LeRoy D. Cressy
Ian Jackson wrote: I think that in order to make sense of what's being said here we need to step back a bit, and think about abstractions rather than implementation. Lots of people (myself included) have been posting rather detailed proposals. Q. What are we trying to achieve ? A.

Re: Release management - technical

1998-06-10 Thread David Engel
On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote: Q. What are we trying to achieve ? A. There are two possibilities that I can see - Timely and good-quality releases, or - Releases which meet some predefined set of goals. I think we can only do one of these. With hamm

Release management - technical

1998-06-09 Thread Ian Jackson
I think that in order to make sense of what's being said here we need to step back a bit, and think about abstractions rather than implementation. Lots of people (myself included) have been posting rather detailed proposals. Q. What are we trying to achieve ? A. There are two possibilities that

Re: Release management - technical

1998-06-09 Thread Bdale Garbee
In article [EMAIL PROTECTED] you wrote: : We need to think about what kinds of thing need to happen to a package : or to a distribution before we release it as `stable'. Yes. I find it impossible to completely divorce the conceptual model from any reference to details of the present or any

Re: Release management - technical

1998-06-09 Thread Enrique Zanardi
On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote: I think that in order to make sense of what's being said here we need to step back a bit, and think about abstractions rather than implementation. Lots of people (myself included) have been posting rather detailed proposals. Q.