RE: so what? Re: Debian development modem
So I misunderstood the original mail. Yes, you were right I meant the 3
month development + 3 months freeze. But that one could contain some
development for the next version, as we do now. The problem as I see it,
is that there are major bugs in hamm that no one cares about, because we
are already working on slink. I still don't fully understand why we
can't get hamm out of the door.
Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH
email@example.com | Europark A2, Adenauerstr. 20
firstname.lastname@example.org | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10
> -----Original Message-----
> From: Dale Scheetz [SMTP:email@example.com]
> Sent: Thursday, May 28, 1998 4:26 PM
> To: Meskes, Michael
> Subject: RE: so what? Re: Debian development modem
> On Thu, 28 May 1998, Meskes, Michael wrote:
> > IMO six months is too long. How about freeze every three months and
> > release twice a year at fixed dates? Something like the NetBSD
> Twice a year IS once every six months. If you freeze every three
> you get 4 releases per year.
> A freeze every six months with a 3 month testing cycle to release,
> two releases out every 12 months.
> The problems that I see with this, are just the problems we have had
> trying to get hamm to a release...bo gets no attention. It is the
> that cause problems.
> If, on the other hand what you meant was: Three months of development,
> followed by three months of testing frozen to produce a release, then
> there is no overlap and attention is being payed to only the release
> I see this as requiring some direction and control over the
> effort. It will require that maintainers who want to work on packaging
> the "next" release, will hold that work until work begins on that next
> release, so as not to clutter up the current release. A well defined
> of simple goals for each release cycle would expidite the schedule.
> Our current problem with releasing 2.0 is that we took on goals that
> too complex for a simple release cycle. It was necessary in this case,
> we should work harder in the future at keeping a more narrow focus on
> short term goals when working on a release.
> We still need to be able to run projects (like apt) which are not
> tied to any particular release, but grow slowly from release to
> Part of the difficulty is keeping those projects active without
> release schedules.
> Waiting is,
> _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
> aka Dale Scheetz Phone: 1 (850) 656-9769
> Flexible Software 11000 McCrackin Road
> e-mail: firstname.lastname@example.org Tallahassee, FL 32308
> _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
> To UNSUBSCRIBE, email to email@example.com
> with a subject of "unsubscribe". Trouble? Contact
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com