Hi,

Richard Freeman <[EMAIL PROTECTED]>:

> Raúl Porcel wrote:
> > 
> > So it would be cool if they accepted help from other devs who don't
> > have an amd64 system but have access to one and can test stuff. Cla
> > is willing to help.
[...]
> I don't keyword a package stable unless I've done at least a moderate 
> amount of testing on the package to ensure that it works.  If a
> package looks simple but obscure I might go ahead and install it and
> play with it, but I'd probably never keyword an emacs package stable,
> since I don't ever use emacs and I won't pretend that all there is to
> it is installing it and typing "hello world" and figuring out how to
> quit.

 Hah, got you.  Emacs team has a collection of test plans, that are
understandable and have a step-by-step guide to the package.  You may
not have noticed because at the moment, Emacs teams handles nearly all
stabilisation requests itself on amd64.
 Yes, testing is crucial, but it eases your pain if you have an arch
tester going over it beforehand and amd64 is well equipped with that.
 
> If there are folks out there who can test on amd64 systems then I'm
> sure that the amd64 team would look forward to their help (just
> contact kingtaco about it) - either by arch testing or perhaps by
> just keywording as appropriate.  However, we do need to be careful
> about just going on a hunt to close bugs - "if it builds then it's
> stable" isn't really a policy I think we want to follow.  As an amd64
> user as well as a dev I know that I'd rather be a little further
> behind on package foo (with the ability to accept ~amd64 on it if I
> wanted to) than to have packages breaking every other week because
> somebody keyworded them just because it compiled and didn't have any
> glaring faults.

 There are dozens of bugs out there for amd64, that are no
stabilisation requests but contain a patch or simple requests that
could be handled in a fast way....problem is, nobody does.  Don't get
Raul or myself wrong, we are not here to accuse someone or do a mud
fight.  We care and are worried about the state of amd64, but do not
want to lower the work invested by some members of the team, so don't
take anything personal or try to justify by all means.
 As a matter of fact amd64 has some broken packages in the stable tree
where bugs exist and noone seems to care.

> I think we also need better coordination across gentoo regarding when 
> packages should be stabilized.  I've seen amd64 CC'ed on stablereq
> bugs filed by end users, and arch teams keywording them left and
> right, and there is no sign that the package maintainer wants the
> package stabilized.  I know that I'd be annoyed if arch teams
> stabilized a package that I maintained and I didn't intend for it to
> become stable for whatever reason.  At the very least maintainers
> should be contacted before packages go stable - and they should
> probably document their intent in STABLEREQ bugs before everybody
> goes crazy closing them out.

 This happens seldomly...and normally stabilisations are assigned to
the maintainer which should react and cc arches.  Only
maintainer-wanted is directly cced with arches by bug wranglers.  So
such problems occur if developers/trusted users create the stabilisation
bug.

> I think that if we have the right policies then we'll be where we
> want to be.  Personally, it doesn't concern me a great deal that
> there are tons of bugs open on an arch in and of itself (although
> blockers and security bugs are a different matter).  I'd rather that
> then keyword something stable anytime one person (usually not the
> maintainer) asks us to.  And users who feel like they're being held
> up should feel free to ping a dev to talk about it - and comments by
> users and maintainers in bugs indicating how stable a package really
> is make people like me more warm and fuzzy about keywording it
> without as much personal testing.

 Again, this is not a question of not testing but a question of getting
more work done (by more people).  Sometimes I do amd64 bugs although I
am not on the team, my only test system is a remote machine with
hardened kernel (miranda), but I do test the packages I mark stable.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

Attachment: signature.asc
Description: PGP signature

Reply via email to