[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpreplay: ChangeLog tcpreplay-3.4.5_beta2.ebuild

[Duncan]

Jeroen Roovers posted on Sun, 31 Oct 2010 18:36:25 +0100 as excerpted:

[Duncan wrote...]

>> However, Gentoo policy has always been that even ~arch is only
>> upstream- stable packages, the ~arch keyword denoting Gentoo package
>> testing (basically, the ebuild script and dependencies), /not/ upstream
>> testing. In with certain exceptions, in particular for packages where
>> Gentoo itself is upstream, if it's not a package that could at least in
>> theory be Gentoo- stable if no bugs appear during the 30-day standard
>> stabilizing period, it's not supposed to be ~arch keyworded either.
>
> This doesn't even make sense.

Well, then, perhaps the developer handbook and devmanual versions
make sense to you:

Developer Handbook:

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap4

1.d QA policy, under ~ARCH in KEYWORDS

"""""
There is a difference between using package.mask and ~arch for ebuilds.
The use of ~arch denotes an ebuild requires testing. The use of
package.mask denotes that the application or library itself is deemed
unstable. For example, if gimp-1.2.0 is the stable release from Gimp
developers, and a new bug fix release is available as 1.2.1, then a
developer should mark the ebuild as ~arch for testing in portage because
the release is deemed to be stable. In another example, if Gimp decides to
release an unstable/development series marked as 1.3.0, then these ebuilds
should be put in package.mask because the software itself is of
development quality and is not recommended by the developers for
distribution.
"""""

Devmanual:

http://devmanual.gentoo.org/keywording/index.html

"""""
The different levels of keyword are: 

arch (x86, ppc-macos) 
 Both the package version and the ebuild are widely tested, known to
 work and not have any serious issues on the indicated platform. 
~arch (~x86, ~ppc-macos) 
 The package version and the ebuild are believed to work and do not
 have any known serious bugs, but more testing is required before the
 package version is considered suitable for arch. 
"""""

As I said, ~arch keywords denote Gentoo package testing, /not/ upstream
testing.  ~arch should be stable upstream, or it belongs in package.mask,
not ~arch.  (In practice, there are exceptions, the biggest one being
where Gentoo's the upstream, such as with portage itself.  The reasoning
as I understand it is that upstream needs testing to stabilize, and since
Gentoo's it's own upstream in these cases...)

So there is indeed /some/ developer responsibility for maintaining a
reasonably stable system, even for ~arch.  If it's known-broken or
upstream is deliberately labeling it beta and saying it's not ready
for general use, it doesn't belong in ~arch either, but rather in
package.mask.

So here's your original statement to which I took issue:

>>> I didn't push it on all users. Maybe ~arch users, but they get to keep
>>> the pieces when they break their systems, if I recall correctly.

My reply:

>> To some extent, yes[, however, Gentoo policy, the top quote above]

To which you say:

> No, to the full extent.

The point that I'm making is that the clear Gentoo policy as outlined
in the quotes above, is that if it's known broken, upstream beta clearly
not intended for general usage yet, or hasn't been tested by the committing
dev, it's that dev's responsibility.  Thus, the "to some extent" on the
"~arch users get to keep the pieces" bit.  It's known to be less well
tested and in fact is ~arch for the /purpose/ of getting that testing,
but if there are known serious issues, or if upstream itself doesn't
call it ready for general distribution, in general, it shouldn't be in
~arch at all, but in package.mask.

That's the clearly stated policy, whether it "makes sense" to you or not.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman