| 1 |
On Thu, 2004-06-17 at 15:54 -0400, Jon Portnoy wrote: |
| 2 |
> This has come up a few times, mostly specifically related to GNOME |
| 3 |
> packages, but there hasn't been much recent discussion on the pros/cons |
| 4 |
> involved. |
| 5 |
> |
| 6 |
> Apparently, some package maintainers think it's a major problem if an |
| 7 |
> arch other than x86 marks an ebuild stable before it's stable on x86. |
| 8 |
> Speaking as someone who's maintained many packages as well as two |
| 9 |
> non-x86 architectures, could someone please explain why, precisely, it's |
| 10 |
> such an issue if an architecture chooses to give their stable users |
| 11 |
> versions not yet marked stable on the maintainer's preferred |
| 12 |
> architecture? |
| 13 |
|
| 14 |
You say two different things here. First you say 'x86', next |
| 15 |
'maintainers arch'. It's the 'maintainers arch' this is about, although |
| 16 |
this is mostly x86 in reality ofcourse. |
| 17 |
Recently this has indeed come up, because before recently this was |
| 18 |
implied knowledge afaicr, only the treatment of several newer (at the |
| 19 |
time experimental) archs has obscured this knowledge. |
| 20 |
The reasoning is simple, there's 'package (ebuild) maintainers' & |
| 21 |
there's 'arch maintainers' : the 'package maintainer' takes care of |
| 22 |
overall ebuild maintenance/updates/handling bugreports/adding patches/ |
| 23 |
etc. & the 'arch maintainer' takes care of making a package available to |
| 24 |
that specific arch/add arch specific patches/mark packages stable for |
| 25 |
the arch involved. |
| 26 |
So the only one with full knowledge about the package, who handles the |
| 27 |
Gentoo bugreports, follows upstream development, interacts with users, |
| 28 |
etc. is the actual 'package maintainer'. Only he has the full picture |
| 29 |
and therefore decides when a certain version of a package can go stable. |
| 30 |
If an 'arch maintainer' already marks a package stable for his |
| 31 |
particular arch before the 'package maintainer' does, that arch is |
| 32 |
really is using a package as stable that isn't deemed stable by the |
| 33 |
'package maintainer'. There might be known problems (not necessarily |
| 34 |
known by the 'arch maintainer'), a general patch in bugzilla or upstream |
| 35 |
that needs to be added before it can go stable, etc. |
| 36 |
That pretty much sums it all up. An 'arch maintainer' has not the same |
| 37 |
level of involvement in a certain ebuild usually to judge it for it's |
| 38 |
overall stability as the 'package maintainer' : Quality is not Assured. |
| 39 |
Now there is no official way of knowning the 'package maintainers' |
| 40 |
architecture of choice (although it's probably x86 >90% of the time) at |
| 41 |
this point so an unintended mess-up can happen, but it's usually |
| 42 |
implicitly known. And there is the possibility a certain architecture |
| 43 |
needs a newer version sooner than other arches because they need a |
| 44 |
certain fix for example, in those cases -preferably after discussion |
| 45 |
with the 'package maintainer'- a package can go stable on an |
| 46 |
architecture that is not the maintainers architecture. |
| 47 |
|
| 48 |
- foser |
| 49 |
|
| 50 |
PS. 'package maintainer' usually is a herd of course. |
| 51 |
|
| 52 |
PS.2 I started with some remark about 'experimental arches' : at a |
| 53 |
certain point there were some new arches added to the tree that were |
| 54 |
allegedly experimental in nature. In that time I said the same thing to |
| 55 |
those arches, but they apparently needed a lot of the latest stuff to |
| 56 |
work and just marked everything latest version stable to begin with. In |
| 57 |
that time it was told me it was ok if they did so (ia64/amd64, some |
| 58 |
others maybe.. i forgot), although I didn't agree much with that view at |
| 59 |
the time either. I do not believe these arches are still as |
| 60 |
experimental, although the same liberal QA hurting attitude towards |
| 61 |
package stabilization is being used in my experience. |
Archives