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

Re: Some thoughts about problems within Debian

On Fri, Jan 04, 2002 at 09:15:41PM +0100, Michael Meskes wrote:
> On Fri, Jan 04, 2002 at 11:37:46PM +1000, Anthony Towns wrote:
> > > I agree completely. With our current testing setup this shouldn't be too
> > > difficult to do. 
> > It's already pretty split-up: we have base, we have standard, and we
> That's what I meant to say. The only think we don't have is the release of
> base/standard without extra etc.

But like I said, that wouldn't buy as anything: the *hardest* parts are
getting base and standard working properly, once they're done, it's not overly
difficult to get the rest working: packages with bugs (and things that depend
on them) can just be dropped. Dropping glibc, base-passwd, and postgresql,
otoh, would all cause complaints, I think.

> > You can solve this by *completely ignoring* the extra set of packages
> > (ie not distributing them at all), but you can't divide them up and get
> > rid of the complexity, particularly.
> Once again I agree. And I do not think ignoring extra makes sense at all.
> It's just that an extra package should not prevent us from a new "core"
> release.

Well, in a sense they don't: it's the fact that the core packages aren't
in a releasable state that's preventing us from releasing.

And in another sense, they absolutely have to: you can't just update
python and ignore the fact that that makes (eg) postgresql uninstallable
and useless, and release the new python and expect people to just
uninstall postgres and sing happy songs. For "postgresql" read any `extra'
package that people use.

> How about a new "core" consisting of base/standard every 6 months
> and a new full release every year. The full release could then be based on
> the next to last "core" release.

I'm sorry, I just can't see this working, let alone being easier than what
we're currently doing.

> > > Use Debian GNU/Linux! Use PostgreSQL!
> > For example, postgresql has a bunch of serious and grave bugs that've
> > been open for over a month, that, afaict, no one's doing anything about,
> That's new to me. Yes, I've been too busy to follow thinks closely enough,
> but the last time I checked therer was just one about an upgrade problem.

"Just" an upgrade problem. You do realise that's an absolutely horrible
attitude to take? While you (and, evidently, everyone else who knows about
postgresql) are sitting there saying "Yay! Postgres has no bugs that
matter", I'm sitting here saying "Great. Postgres has RC bugs. Should
I remove it from the distribution, or wait, or find someone to buy me a
ski holiday?" If the bug really is RC (and the severity descriptions are
fairly clear these days) it has to be fixed. It's that simple. If it's not
RC, then it shouldn't be marked that way, and it should be fixed anyway.


Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

The daffodils are coming. Are you?
      linux.conf.au, February 2002, Brisbane, Australia
                                --- http://linux.conf.au/

Attachment: pgplxGTsxECbA.pgp
Description: PGP signature

Reply to: