Re: [gentoo-dev] summary: proposed solutions to arches/stable problem

[Ciaran McCreesh]

On Tue, 22 Jun 2004 17:33:09 -0400 Aron Griffis <agriffis@g.o>
wrote:
|     IV. <maintainernotes> in metadata.xml
|     -------------------------------------
|     This was suggested by Ciaran, and I'm including it for
|     completeness, though I can't say I completely understand it.
|     Ciaran's reasons were "much cleaner, provides much more
|     information, doesn't imply meaning in an existing field which does
|     not currently provide any information".  Ciaran, do you feel like
|     following up with a better explanation for how this would work?

Hypothetical example for an app named foo:

<maintainernotes><![CDATA[
>=foo-1.2 has problems when the alsa USE flag is enabled (see bug
#12345). Avoiding marking this as stable on x86 until this issue is
resolved. No other problems known.
]]>

This shows the arch teams that there are specific reasons to stick with
versions below 1.2 (rather than that the maintainer is just lazy and
doesn't pay much attention to the package). It also lets sparc
developers know that they can ignore the maintainer's arch and go ahead
and keyword later versions if necessary, since ALSA isn't available for
that arch.

The information provided is the kind of information arch teams would be
after when contacting the maintainer to find out why they were keeping
their arch's stable version down.

|     Instinctively I'm against it because it requires more work on the
|     part of the package maintainer, and I'm trying to avoid the extra
|     work all around.  I *think* that suggestions I and II above both
|     avoid the implication of meaning by making it explicit.
|     Regarding providing "much more information", I'm concerned that
|     could result in duplication of information between the bugs
|     database and metadata.xml, a duplication that the package
|     maintainer has to keep updated.

Regarding the amount of work, it's effectively the same as is required
for I and II. If a package maintainer *isn't* keeping a close enough
track of a package to know about the issues then chances are the arch
teams know just as much as the package maintainer anyway.

This method (like I and II) has the advantage that if nothing is
present, then arch teams can carry on using the existing method (ya
know, the one that's working fine), and if it *is* there, then the extra
information that would usually be obtained by pestering people on IRC is
already present. Contrast this with III, where we end up with a messy
situation that arch teams don't know whether the first keyword is really
the maintainer's arch or whether it just happens to be there, and
whether the maintainer is just not really maintaining the package or
whether they're holding back for a reason.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm