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

Re: new release process (package pool) being proposed



On Mon, Oct 25, 1999 at 03:18:47AM -0200, Lalo Martins wrote:
> Also, could you people please stop for a moment and really evaluate
> the ammount of code needed? Get real: this is _trivial_.

We'd need code to:

	* make life easy for the mirrors (either a working package pool,
	  or the hard links thing). I've tried writing code to create a
	  package pool, it's not that tricky, but it's a pain. I haven't
	  looked at dinstall at all ever, so I've no idea how hard it'd
	  be to modify dinstall to cope with it. Dealing with hard links
	  sounds much more reasonable, but it gets rid of all the 

	* do `installability checking'. I've done some code (see my
	  previous mail) that checks depends/conflicts within main.
	  It's about 2000 LOC, bits of which are incredibly horrible
	  and complicated.

	* work out how to choose subsets of packages that don't make
	  hundreds of others uninstallable --- so that you don't
	  install the new lesstif unless you also update all the other
	  programs that the new lesstif will make uninstallable. This
	  alone is non-trivial.

	* interface with the BTS. Note that working out which bugs belong
	  to a package has been something of a hack until today, even.
	  Really, having the BTS be able to tell you which bugs apply to
	  which versions of a package would be desirable to implement this
	  properly.

> Please make a list of the code we would need.
> Please make a list of the added burdens on the ftpmasters.

Erm. As proposer, this is really /your/ job.

> > Third, voting on `this is what these people will spend their time on in
> > future' is completely inappropriate. If it's really a better way, they'll
> > spend their time on it because they want to. If it's a bit ambiguous,
> > you can spend your time on it if you want to.
> No, nobody could just go and implement this radical change in
> the way we work without consulting the other developers.

Of course they could. In exactly the same way Debconf appeared. People
discussed it, someone went off and implemented it, and now that we've
got an implementation, we're ready to start using it, and consider adding
it to policy.

Here, we ought to be discussing what we need (which we've done for over
a year now), implementing it, and /then/ working out whether we want to
actually use it or not.

Cheers,
aj

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

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
        results in slower code, and it results in more bugs.''
                                        -- Linus Torvalds

Attachment: pgp1JabHIvrFZ.pgp
Description: PGP signature


Reply to: