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.
Michael
--
Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH
meskes@topsystem.de | Europark A2, Adenauerstr. 20
meskes@debian.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:dwarf@polaris.net]
> 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
> schedule.
>
> Twice a year IS once every six months. If you freeze every three
> months
> you get 4 releases per year.
>
> A freeze every six months with a 3 month testing cycle to release,
> gets
> two releases out every 12 months.
>
> The problems that I see with this, are just the problems we have had
> while
> trying to get hamm to a release...bo gets no attention. It is the
> overlaps
> 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
> under
> development.
>
> I see this as requiring some direction and control over the
> development
> effort. It will require that maintainers who want to work on packaging
> for
> 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
> set
> 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
> were
> too complex for a simple release cycle. It was necessary in this case,
> but
> 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
> strictly
> tied to any particular release, but grow slowly from release to
> release.
> Part of the difficulty is keeping those projects active without
> impacting
> release schedules.
>
> Waiting is,
>
> Dwarf
> --
> _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
>
> aka Dale Scheetz Phone: 1 (850) 656-9769
> Flexible Software 11000 McCrackin Road
> e-mail: dwarf@polaris.net Tallahassee, FL 32308
>
> _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: