On Tue, Apr 24, 2001 at 11:48:18AM +0100, Alistair Crooks wrote:
> Maybe I wasn't very explicit in my previous message:  you have now
> added a tree, equal in size to that of the current pkgsrc.  Are you
> going to put that up for ftp as well? 

Certainly. The .tar.gz file isn't that big

> Who is going to manage the
> stable tree?

I think a lot of us can. On my servers I run an old pkgsrc, on which I port
things from -current I need (e.g. apache, ssh ...), which means back out
changes like COMMENTS

>  Who is going to organise pullups to the branch?  Who is
> going to test any pullups that are made to the branch?

This clearly requires more resources, especially hardware. We need one
machine of each CPU type running the last release (we can compile for older
releases using chroot and emulation; I do this on a recular basis for
sparc 1.4 on a 1.5 machine)

> 
> We go to considerable trouble at the moment to make sure that any
> changes we do are backwards compatible.  Take the COMMENT change, for
> example.  It was enough work making that in the trunk.  To do that on
> the branch as well, after a suitable time interval in which testing
> has taken place, would be cruelty to the poor people who look after
> this stuff.  Then we have the distinfo changes.  I don't like to think

Such large changes shoudln't be done on the branch. What I want is something
like the netbsd-1-5-RELEASE tag in pkgsrc, but turned into a branch so that
we can update softwares with security issues, which is the main goal here
(or at last mine).

> how long it took us to do all of them. If you don't intend to update
> the branch like that, but rather leave it static, only updating
> packages for security fixes, fine, then it's not a problem.  But I am

Yes, only packages for security fixes; or eventually new versions of
standalone packages (i.e. don't go upgrading PNG on the branch).
It may even be OK to not upgrade a package for security fix; just patch
it if a patch against our version has been published.

The goal in my mind is to provide binary packages up to date with security,
nothing more.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--