We've been around this loop before. Given enough resources a
	-stable pkgsrc branch would be wonderful, however until someone
	decides to pay a developer full time, its not going to be realistic.
	This is distinct from tagging pkgsrc, which is already done.

	We are working towards producing regular bulk-builds of pkgsrc
	for each major release and platform. Anyone interesting in helping
	is invited to subscribe to bulk-packages@netbsd.org.

-- 
		David/absolute		-- www.netbsd.org: No hype required --


On Thu, 18 Oct 2001, Jeremy C. Reed wrotee:

> > > pkgsrc tree is "10 Sep 2001" (which I assume is "stable" for 1.5.2).
> > > (Please feel free to tell me other tags or other ways to fetch "stable" pkgsrc.)
> >
> > Sorry, there is no "stable" pkgsrc -- there's no branching at all. Even
> > rolling back to the netbsd-1-5-PATCH001 tag, the last released "pkgsrc",
> > won't necessarily help you if you've already installed packages built
> > from newer pkgsrc, although that would otherwise be your "stable" tag.
>
> I misunderstand this. I thought that there is a freeze of the pkgsrc right
> before a release is done so that the pkgsrc for that release can be
> considered "stable".
>
> I chose that date -D "10 Sep 2001" because it corresponded with the last
> release. (I guess I should have used "-r netbsd-1-5-PATCH002" instead.)
>
> > The best we can do is to resolve not to do it again. Maybe for 1.6* we
> > should consider going back to separate collections for 1.6, 1.6.1, and
> > so on, so at least we have a chance to gloss over certain mistakes, and
> > still produce one single consistent collection of binary packages.
>
> What were some reasons that was stopped?
>
> What can be done to create a "stable" pkgsrc branch?
>
> This stable branch will only be updated when:
>
>  - a problem with dependencies/requirements were noticed (and a dependency
>    needs to be changed, such as a version number incremented);
>
>  - a serious bug is found and the package needs to be patched;
>
>  - a new official stable release of NetBSD is being made (such as 1.5.2 to
>    1.5.3 or 1.5 to 1.6).
>
> This stable branch will not be updated:
>
>  - to add new packages;
>
>  - to patch current patches for enhancements or bug fixes other than
>    serious security issues.
>
> The benefits of having a "stable" pkgsrc branch:
>
>  - users who use CVS for pkgsrc (unless they purposely want current) won't
>    have conflicts with binary packages fetched from FTP servers;
>
>  - the stable branch will become better and better over a few weeks --
>    without any issues of adding newer packages; there should be no
>    conflicts (which is now very common with regular up-to-date pkgsrc);
>
>  - admins can easily track the stable branch to keep up-to-date with
>    security fixes without worrying about problems with current
>    dependencies.
>
> Some problems with a stable pkgsrc branch:
>
>  - need volunteer(s) to care for it;
>
>  - updating entire "stable" collection to current pkgsrc may be a lot of
>    work. But maybe not -- require (or suggest) that any change to stable
>    must have a similar and appropriate change for the current collection;
>    i.e. if stable's apache pkgsrc is patched for a minor security issue
>    and the current version of apache pkgsrc is upgraded to later version
>    (which also includes security fix), then you don't have to worry about
>    it.
>
> Can someone setup a branch for pkgsrc that has a purpose of rarely being
> changed? (Should I send-pr this?)
>
> (I know I have mentioned this before.)
>