[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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