| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
|
| 5 |
| |
| 6 |
| So, with that said, thoughts, comments and other ideas are welcome. |
| 7 |
| |
| 8 |
|
| 9 |
So far most of the discussion seems to center around stable portage as |
| 10 |
snapshots of the main tree taken at regular intervals. These snapshots |
| 11 |
contain only packages marked as stable, and only security updates are |
| 12 |
applied to the snapshots. |
| 13 |
|
| 14 |
It might be worth considering instead a model where a snapshot is taken |
| 15 |
then only security patches are applied, with the exception that should a |
| 16 |
particular version of an application become depreciated, it can then |
| 17 |
also be upgraded (provided the upgraded version is also considered stable). |
| 18 |
|
| 19 |
This would enable snapshots to last for a longer period (I think four a |
| 20 |
year is going to be too much work), it prevents any requirement for |
| 21 |
backporting (which I think is a bad idea as it makes ebuild maintainers |
| 22 |
into application maintainers) and it would also make the maintenence of |
| 23 |
older snapshots more viable as there would be less work to do in general. |
| 24 |
|
| 25 |
Some of the current discussion on the length of time snapshots are |
| 26 |
maintained is concerning as production servers, in my experience, remain |
| 27 |
in the same state for years - a one year maintenence period is not long |
| 28 |
enough (it would be for workstations however as these are easier to take |
| 29 |
out of service for an hour or so and upgrade). |
| 30 |
|
| 31 |
In reality, if a application on a production server reaches a state |
| 32 |
where it is unmaintained in favour of a newer version, then its likely |
| 33 |
that the admins would upgrade the application to the supported version. |
| 34 |
~ Most responsible program maintainers provide upgrade paths anyways, so |
| 35 |
as long non security related package upgrade wasn't forced on |
| 36 |
subscribers to the stable tree, it shouldn't be too bad. At the least |
| 37 |
if such a change could be signalled, people would be prepared. |
| 38 |
|
| 39 |
I guess what I'm describing isn't strictly an enterprise gentoo (which I |
| 40 |
don't think the community has the resources to support), more of a |
| 41 |
slowed down version of the main portage tree. In my experience |
| 42 |
maintaining a couple of hundred of gentoo machines centrally, its the |
| 43 |
rapid pace of change in the main tree that causes problems. We only |
| 44 |
only upgrade packages for security reasons, but whenever we do this, we |
| 45 |
are forced to upgrade a multitude of other packages because they've |
| 46 |
dropped out of portage. If we only had to upgrade packages for security |
| 47 |
and depreciation reasons it would make for a much more stable |
| 48 |
environment for the end users (which is what we're after ultimately) and |
| 49 |
~ it would make maintenence more manageable. |
| 50 |
|
| 51 |
Baz |
| 52 |
|
| 53 |
|
| 54 |
-----BEGIN PGP SIGNATURE----- |
| 55 |
Version: GnuPG v1.2.1 (GNU/Linux) |
| 56 |
|
| 57 |
iD8DBQFA/c0gJvZkjpKMF2wRAiZXAKCAngA2ZVztXnGg0zXRmhtaqYGV5ACcDs5m |
| 58 |
cO4fxnbFP+5ulb4CHfI6uN4= |
| 59 |
=9/gh |
| 60 |
-----END PGP SIGNATURE----- |
| 61 |
|
| 62 |
-- |
| 63 |
gentoo-dev@g.o mailing list |
Archives