| 1 |
On Fri, 2004-06-18 at 17:45 +0100, Ciaran McCreesh wrote: |
| 2 |
> On Fri, 18 Jun 2004 00:04:21 +0200 foser <foser@g.o> wrote: |
| 3 |
> | So the only one with full knowledge about the package, who handles the |
| 4 |
> | Gentoo bugreports, follows upstream development, interacts with users, |
| 5 |
> | etc. is the actual 'package maintainer'. Only he has the full picture |
| 6 |
> | and therefore decides when a certain version of a package can go |
| 7 |
> | stable. |
| 8 |
> |
| 9 |
> ...which would be fine, except that as an arch maintainer, I can tell |
| 10 |
> you that the majority of problems we get are arch specific. It's not |
| 11 |
> just because of endianness, 32 vs 64 and so on -- different archs have |
| 12 |
> completely different versions of core libraries and toolchain |
| 13 |
> components. For example, any gcc3.4 related bugs aren't an issue at all |
| 14 |
> for x86 right now, but they are on amd64 and mips. Similarly, we all use |
| 15 |
> different kernel headers, glibc versions and toolkit versions. |
| 16 |
|
| 17 |
Well, core & toolchain are sort of expected out of the rule situations |
| 18 |
given their lowlevel nature and I guess the arch devs are more involved |
| 19 |
in the development of those tools than say the general package built on |
| 20 |
top of it. Although i still assume everything happens in discussion with |
| 21 |
base-sys devs. |
| 22 |
|
| 23 |
> Besides, if a package version is really that buggy, why isn't it in |
| 24 |
> package.mask? The ~ keyword shouldn't be used for dodgy experimental |
| 25 |
> releases, it should be used for packages which are candidates to become |
| 26 |
> stable after a reasonable (package and arch dependent) period. If an |
| 27 |
> ebuild is in the tree and not-*/.mask'ed, we consider it a fair target |
| 28 |
> for going stable. |
| 29 |
|
| 30 |
~arch is a testing ground, it's meant to expose those (little) bugs that |
| 31 |
have not yet been found. The maintainer gets to know about those bugs |
| 32 |
that pop-up, the arch maintainers don't get all CC-ed (and i assume the |
| 33 |
arches are happy that it is that way). So it is a fair target for going |
| 34 |
stable if the one actually taking the bugs for it sais so. |
| 35 |
|
| 36 |
> Incidentally, it would be nice if stable keywording wasn't the domain of |
| 37 |
> the package maintainers at all. That should be a job for arch teams, |
| 38 |
> since individual package maintainers don't know the state of any given |
| 39 |
> arch. Unfortunately, I don't think the x86 team is big enough to keep up |
| 40 |
> with that kind of thing yet, given the number of packages keyworded for |
| 41 |
> them... |
| 42 |
|
| 43 |
The 'x86 team' (again in this thread 'x86' gets confused with 'package |
| 44 |
maintainer') is not meant to handle general stabilization of packages, |
| 45 |
that's what the 'package maintainer' does. That 'package maintainer' |
| 46 |
correlates with 'x86' is not relevant, that the 'package maintainer' has |
| 47 |
the overview over a package's development cycle/bugs is relevant. |
| 48 |
|
| 49 |
Yes 'x86' is historically the most important arch and that influences |
| 50 |
how things work right now, but actually the 'package maintainers' vs |
| 51 |
'arch maintainers' differentiation paves the way for other arches being |
| 52 |
as important as x86 Gentoo-wise. If you wouldn't be so focused on the 'i |
| 53 |
do with my arch what i want to do with it' thought, you could actually |
| 54 |
appreciate it for what it in the big picture gives to all non-x86 arches |
| 55 |
and where that will take us in the future. |
| 56 |
|
| 57 |
- foser |
Archives