| 1 |
On Mon, 2006-11-27 at 13:02 +0000, Stuart Herbert wrote: |
| 2 |
> I think the original poster hit the nail on the head. The real |
| 3 |
> barrier preventing a slower-moving tree is cultural. |
| 4 |
|
| 5 |
Somewhat. |
| 6 |
|
| 7 |
As I have said, I've mentioned several times the idea of doing a |
| 8 |
"release tree" to go along with each release. Support on these trees |
| 9 |
would be essentially equivalent to our security support model. We would |
| 10 |
support only packages marked stable. Of course, we also understand that |
| 11 |
since we're building off upstream's work, there *will* be times when a |
| 12 |
version bump is necessary to reduce our workload. Basically, our rule |
| 13 |
is kinda like this. |
| 14 |
|
| 15 |
No version changes on any packages, except those which are necessary due |
| 16 |
to a security violation, or a vulnerable package's dependencies. |
| 17 |
|
| 18 |
Now, I don't know if it is the best approach, but it is the best one |
| 19 |
that I could come up with on my own that allows for a slow-moving tree |
| 20 |
with higher QA done on it (as the release trees are what we use for |
| 21 |
releases, they undergo an enormous amount of testing, in the default |
| 22 |
configuration, of course) and minimal changes. |
| 23 |
|
| 24 |
Something that would be useful would be for package maintainers that |
| 25 |
wish to participate to perform further testing and validation on |
| 26 |
packages in the release snapshot prior to its final freeze. This would |
| 27 |
give us even more eyes on the tree and hopefully provide a much higher |
| 28 |
quality snapshot once we're done. |
| 29 |
|
| 30 |
Since it seems that there is still interest in the idea, I'll start |
| 31 |
working on it some more. |
| 32 |
|
| 33 |
-- |
| 34 |
Chris Gianelloni |
| 35 |
Release Engineering Strategic Lead |
| 36 |
Alpha/AMD64/x86 Architecture Teams |
| 37 |
Games Developer/Council Member/Foundation Trustee |
| 38 |
Gentoo Foundation |
Archives