Re: [gentoo-dev] GLEP 19, reloaded (again)

[Barry Shaw <baz@scms.waikato.ac.nz>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kurt Lieber wrote:

| Second, there was some question about how often the tree would be updated.
| The GLEP doesn't really specify this, but I think once a year is a
| reasonable timeframe.
|
| Third, many folks want long-term support of these releases.  I *don't*
| think this is viable and am not willing to personally sponsor this.  A
core
| component of this GLEP is that we will *not* be backporting security
fixes.
| (at least not as a rule)  We will be relying on the versions that the
| original authors provide except in very unusual circumstances.  The reason
| for this is simple -- we don't have the resources to guarantee that we can
| backport things (and, more importantly, guarantee that they'll work right
| once backported)  Suppporting a profile for four or more years almost
| guarantees you'll be doing a lot of backporting.  I don't plan to
| incorporate long-term support as part of this GLEP.  That might, however,
| be an excellent opportunity for commercial companies with greater finanial
| resources than us.
|

My main concern here is that if you've got a core server, which
typically has lifetime of 3 to 4 years, you don't want to be
reinstalling it every year (in many cases you can't).  That said, I
agree that its unlikely there are resources to maintain a tree for years
on end.  As a compromise, if some consideration was given to easing
migration, that would be suitable.  Given the fact that servers have a
very minimal level of software on them anyway, its probably not too much
of a big deal.

|
| Finally, the current GLEP doesn't really address how to ensure a minimum
| life for all ebuilds in the tree.  I'm open to suggestions on this,
but the
| best idea I've heard so far is using a separate rsync module and removing
| the --delete option from the command used to populate it.
|

I like this idea.  That way if the end user doesn't want to upgrade, the
original ebuild stays in portage and they can stick with that.

Backporting has been mentioned in Greg k-h's post and I think thats
something we want to stay away from.  Ebuild maintainers may not have
the programming skill necessary to backport fixes from one version of
the software to another.  The upstream maintainers are the experts in
that respect and thats where that decision should stay.  In my
experience once the upstream maintainer stops maintaining a certain
version of the software, migration to the new version is necessary anyway.

The other downside to backporting is that it causes tonnes of false
positives if you do any proactive network scanning.  Not a major really,
but its one of my pet hates 8)

| So, at this point, I'm suggesting three changes to the GLEP:
|
| 1) specify annual updates for the stable tree
| 2) replacing the stable keywording stuff with stable profiling stuff
| 3) adding a separate rsync module for the stable portage tree (or one for
|    each release of the stable portage tree)
|

These all sound like good alterations, keeping the GLEP focussed is a
sensible idea.

Baz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBFys7JvZkjpKMF2wRAutzAJ9pyJb/0VHtvuEOE3ggv2CIMpOGZACfZ2Cm
sjiNxtYa8Q1HB+RKlZv9RzA=
=630p
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list