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

[Aron Griffis]

At this point I've made a couple suggestions, and developers have
voiced either support or objections, and raised some good arguments
either way.  I'm hoping this email will summarize the three suggested
approaches, their pros and cons, and we can eventually converge on a
single solution.

Proposed solutions:

    I. "stable" keyword
    -------------------
    pros
        - not tied to architecture keywords
        - not dependent on order of keywords
        - clearly nominates an ebuild as stable per the package
          maintainer without ambiguity
        - it's easy to tell which packages are following this standard
          and which ones are not

    cons
        - requires developer behavior change (marking ebuilds with
          "stable" keyword)
        - requires changes throughout the tree
        - uses another keyword
        - no indication of maintainer's arch (might be considered good
          or bad)
        - *requires* changes to portage on *user* systems to
          ignore/handle the "stable" keyword, otherwise portage spits
          out this error:
            IOError: Profile dir does not exist:
            /usr/local/home/agriffis/portage/profiles/default-stable-1.4

    II. "marked keyword" indicates maintainer's arch
    ------------------------------------------------
    pros
        - not dependent on order of keywords
        - clearly nominates an ebuild as stable per the package
          maintainer without ambiguity
        - easy to tell which packages are following this standard and
          which are not
        - doesn't use a new keyword
        - calls out maintainer's arch(es)
        - does not require developer behavior change, because it can
          be handled automatically by ekeyword and repoman

    cons
        - requires changes throughout the tree
        - depends on architecture keywords
        - *requires* changes to portage on *user* systems to
          ignore/handle the new marking, otherwise portage spits out
          this error:
            IOError: Profile dir does not exist:
            /usr/local/home/agriffis/portage/profiles/default-+x86-1.4

    III. first keyword marks maintainer's arch
    ------------------------------------------
    pros
        - takes advantage of existing order already present in *some*
          ebuilds
        - doesn't require changes throughout the tree, only in
          packages that aren't already following this standard
        - doesn't require any changes to portage on *user* systems,
          only developer systems (repoman and ekeyword changes)
        - does not require developer behavior change, because it can
          be handled automatically by ekeyword and repoman

    cons
        - dependent on order of keywords
        - not as unambiguous as the other two approaches
        - not easy to tell which packages are following this standard
          and which are not
        - doesn't use a new keyword
        - calls out only one of the maintainer's arch(es), so it might
          be misleading
        - keywords jump around in the list

    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?

    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.

    All my objections stated :-) I would still like to hear about it
    if you think this is the better way to do things.  It's possible
    that I'm missing a key point.

Common attributes:

    - None of the proposed solutions attempts to enforce behavior.
    - Each provides a lightweight method of communication from the
      package maintainers to the arch maintainers.
    - Each can be recognized and maintained with ekeyword/repoman
      with very little developer behavior change.

Personal leaning:

    I like solution II, "marked keyword", best because it clearly
    calls out the maintainer's tested arch(es).  That seems like
    valuable information to me.  Additionally it doesn't require
    developer behavior change, since ekeyword could determine
    automatically (1) you're the package maintainer, (2) you're
    marking a package stable, (3) what arch you're currently running.
    (Of course ekeyword would also support explicitly marking instead
    of automatic.)  Not requiring developer behavior change these days
    is a lot easier than requiring it.  We have a lot of developers,
    and they don't change behavior quickly or easily.

    The only thing I really dislike about the "marked keyword"
    approach is that it requires changes in the *user's* portage to
    handle the marking.  But only solutions III and IV avoid that so
    far.

I would like to hear feedback so that we can make a choice, do the
necessary steps for implementation, and bring about a positive QA
change in the portage tree.  Hopefully along with an improvement in
the package/arch-maintainer relationship :-)

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer