| 1 |
On Tue, 2003-10-07 at 00:08, Ian Leitch wrote: |
| 2 |
> As I'm sure all devs know, ~arch is used for other things than just |
| 3 |
> testing ebuilds. |
| 4 |
> |
| 5 |
> "The purpose of ~arch is for testing new packages added to Portage. This |
| 6 |
> is not the equivalent of "testing" of "unstable" in other |
| 7 |
> distributions." - Development Policy |
| 8 |
|
| 9 |
Well then that is a violation of policy. Developers who do this should |
| 10 |
'change their ways'. |
| 11 |
|
| 12 |
> Making these changes would sort out this little problem/mess whatever |
| 13 |
> you want to call it. I also think the extra unstable branch would take |
| 14 |
> some weight off package.mask, which could then be reserved for the need |
| 15 |
> to mask a package for temporary licensing issues etc.. without removing |
| 16 |
> it from portage. |
| 17 |
|
| 18 |
I think package.mask is indeed not the best solution for development |
| 19 |
versions of packages, but neither do i think we should have an official |
| 20 |
'unstable branch'. We have trouble enough to keep 'stable' stable and |
| 21 |
up-to-date as it is, no need to add another official burden to it. |
| 22 |
|
| 23 |
> Stable would also gradulay become more stable. We can't match Debian for |
| 24 |
> stability but we could have the best of both worlds: up-to-date, |
| 25 |
> reasonably stable software. This must be pretty attractive to those |
| 26 |
> using Gentoo on the server and more importantly, those thinking about |
| 27 |
> it. |
| 28 |
|
| 29 |
How would stable become more stable ? Stable should be stable as it is, |
| 30 |
if it isn't because of development packages, then that is because |
| 31 |
developers do not follow policy as it stands (or interpret it the wrong |
| 32 |
way). That was put into place to ensure stability. |
| 33 |
|
| 34 |
The only reason i see for adding an extra layer is for 'big' stuff that |
| 35 |
needs serious testing : KDE/GNOME development series maybe, arch |
| 36 |
additions to the tree (amd64 anyone), introduction of new eclasses, etc. |
| 37 |
Those should be entered to the tree in some special protected |
| 38 |
environment first, where they get proper testing (maybe by a selected |
| 39 |
few) and then when reaching stability can be added to the tree with |
| 40 |
relative ease (not one developer throwing in his local tree one night at |
| 41 |
once). |
| 42 |
|
| 43 |
- foser |
| 44 |
|
| 45 |
|
| 46 |
-- |
| 47 |
gentoo-dev@g.o mailing list |
Archives