[gentoo-dev] Gentoo ~arch testing policy?

[Ryan Finnie]

(Please forgive me for ranting a bit...  I could just cool off before
posting this, but where's the fun in that?)

I love Gentoo.  I am currently in the middle of converting about 30
servers from RHL7 to Gentoo.  I submit new ebuilds of software I find,
test ~arch ebuilds when they come out, submit bug reports, and add
commentary to bugs that are relevant to me.  I am also in the process of
going through and testing what I can on amd64.

Today I tested (among others) clamav-0.65, a version bump that was added
yesterday.  So I reported my success on each platform in bug #38876.  It
was closed as resolved/invalid shortly later because of the fact that the
build was only submitted yesterday.  I explained myself and SpanKY replied
with "so we'll add it in a few weeks, bug us then" and marked it
resolved/later.

I'm still trying to figure out the reasoning behind this.  If the idea is
to not leave tickets open, what about the other 4758 open tickets?  I
would consider the most logical procedure for testing to be:
1. Version bump (or whatever reason), new version committed to cvs as
~arch.
2. User tests new version, opens a bug and reports success (or lack
thereof).
3. More users test, commenting on original bug #.
4. If enough people report success (or enough time goes by after initial
verification), ebuild is marked stable and bug is closed.

I can't find any documentation of a process here, but this is what I
gather:
1. Version bump (or whatever reason), new version committed to cvs as
~arch.
2. Somebody with cvs commit access stumbles on the ebuild sometime in the
future, checks bugzilla, sees no problems submitted, and marks stable.

Sorry, but I'm not feeling the greatest motivation to test ebuilds when
reports of "it works!" are met with "we don't care!"  If anything, I'd
like to see answers to 1) is there a policy for this stuff?  and 2) if
not, why not?

RF

--
gentoo-dev@g.o mailing list