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

[Aron Griffis]

Hi Ciaran,

Thanks for taking the time to write up this explanation.

Ciaran McCreesh wrote:	[Tue Jun 22 2004, 06:28:29PM EDT]
> <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.

I see your point here.  I'm very concerned about this approach,
though.  First, it isn't checkable by repoman.  Second, it isn't
visible to arch maintainers unless they check for it.  Third, it
implies a green light when the information is missing, when it might
simply be that the package maintainer hasn't had a chance to add the
information to metadata.  Fourth, it's no longer enough for a package
maintainer to close a bug in the bug database, now it's required to
modify metadata.xml to show when major bugs are opened/closed.  Fifth,
this information is already available to arch maintainers by looking
in the bug database (and yes, this last one is part of the reason that
the current system, while not perfect, hasn't fallen apart entirely ;-)

> 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.

*nod*  I agree that the stuff I have proposed so far is only a one-way
communication channel, and it's a unary channel at that.  What I mean
is that the proposals so far are only reliable if STABLE="yes" or
KEYWORDS="+x86" or whichever way you like.  If it's STABLE="no" then
you can't tell whether the maintainer might have been shopping for 9
weeks (was that brandy's record?)

Your proposal provides for much broader communication by caching a
broadcast message in metadata.

> |     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.

Right, that is certainly the case sometimes.  However I disagree about
the amount of work.  You seem to be assuming that a PM has only one or
two packages that they take care of, so it shouldn't be too hard to
update metadata.xml with information like this.  But the fact is that
most package maintainers are working on a large number of packages, a
result of our herd system, natural relationships between packages, and
the simple fact that 20% of the developers do 80% of the work.

I think that whatever solution we choose should create as little extra
work as possible for developers.  (Of course, the hope is that the
extra communication channel and clearer bug responsibility will
actually decrease the amount of work.  That would be ideal!)
Unfortunately I don't think that adding phrases to metadata for that
communication is possible to do without increasing the workload.

> 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),

*grin*

> 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.

I think you're right about III.  I proposed it, liked it, argued for
it, but it has such significant weaknesses that I don't think it is
a viable solution.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer