| 1 |
On Thu, 2004-07-01 at 22:17, Donnie Berkholz wrote: |
| 2 |
> Barry Shaw said: |
| 3 |
> > Is there any policy/ideas/consensus among developers about how long a |
| 4 |
> > particular "version" will remain supported in portage? If not, it might |
| 5 |
> > be a useful idea to set sunset dates for particular "versions" of gentoo |
| 6 |
> > (as I doubt they are all going to be supported indefinitely). If there |
| 7 |
> > is a clear end date, it prevents anyone being caught out unexpectedly. |
| 8 |
> |
| 9 |
> I generally keep a minimum of two ebuilds in, so testing for a newly |
| 10 |
> introduced problem is easier. If I put out seven ebuilds in two weeks for |
| 11 |
> some ungodly reason, I don't expect to be maintaining some sort of minimum |
| 12 |
> lifetime for each ebuild -- just the newest two will stick around. |
| 13 |
> |
| 14 |
> We have no policy stating a minimum support lifetime for any given version |
| 15 |
> right now (AFAIK, of course), despite a push for it amidst emphasis for |
| 16 |
> Gentoo in the enterprise. |
| 17 |
|
| 18 |
As Donnie said, there is no policy laid out. |
| 19 |
|
| 20 |
In general, I will keep 2 versions in portage. Usually it is a stable |
| 21 |
version, and a testing version. Depending on the ebuild, I will leave |
| 22 |
more versions. For example, look at PXES or VMware Workstation. PXES |
| 23 |
is something that would be in use and probably not easily upgraded for |
| 24 |
everyone, so I have left every stable version in portage since I added |
| 25 |
the package. VMware Workstation is a licensed product, so I leave one |
| 26 |
version per license in the tree (3.x and 4.x). There are currently 2 |
| 27 |
4.x ebuilds simply because one is still in testing. |
| 28 |
|
| 29 |
Then you have packages like gcc/glibc, which usually stay in the tree |
| 30 |
for much, much longer. |
| 31 |
|
| 32 |
With an enterprise version of Gentoo, there will need to be much more |
| 33 |
help in maintaining certain packages, simply because patches will need |
| 34 |
to be back-ported to older versions and other such headaches that most |
| 35 |
other distributions must deal with. |
| 36 |
|
| 37 |
Right now, we simply don't have the manpower to keep up with such |
| 38 |
things, which is why we do not make things version dependent, where |
| 39 |
possible. |
| 40 |
|
| 41 |
-- |
| 42 |
Chris Gianelloni |
| 43 |
Release Engineering QA Manager/Games Developer |
| 44 |
Gentoo Linux |
| 45 |
|
| 46 |
Is your power animal a penguin? |
Archives