FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 01-18-2012, 01:42 PM
Tobias Klausmann
 
Default How help in arch testing work

Hi!

On Wed, 18 Jan 2012, Agostino Sarubbo wrote:
> 4) Nobody knows how work all packages in tree, so there are
> obvious packages like a browsers, IM, audio player,that is easy
> decide if is ok or not, but there are also packages that an
> Arch tester has never seen, so is a lack of time everytime
> google about it or ask to maintainer, so, please specify what
> test you want for this package; e.g.
>
> -only compile test
> -compile test and make sure src_test goes well
> -make sure /usr/bin/${foo} works properly in ${that} manner
> -see 5) about library
>
> So, you can write one time 'how to' and copy/paste for the
> future stablereq; I guess I'm not asking a long and difficult
> task.

I'd like to point out that the Emacs people have a very nifty
list of "how to test our stuff":

http://overlays.gentoo.org/proj/emacs/wiki/test%20plans

If you want to be an awesome maintainer, have something like this
for the archtesters, especially for the more obscure packages as
Agostino pointed out.

Regards,
Tobias
 
Old 01-18-2012, 01:55 PM
Alexis Ballier
 
Default How help in arch testing work

Hi,

On Wed, 18 Jan 2012 15:23 +0100
Agostino Sarubbo <ago@gentoo.org> wrote:

> 2) _Before_ filing a request, please run repoman full, to be sure
> that there is nothing to fix, then take a look at the ebuild and make
> sure your ebuild have a minimum of QA; all external binary called in
> the ebuild(sed, mv, cp, ln, rm, and so on) should have 'die'; if you
> don't use EAPI4, make sure that all portage helper[2] have also '||
> die'.
>
> 3) Check your rdepend, where is possible with scanelf[3] and if you
> declare it, please, as you said, exclude gcc/glibc and all package
> from @system


imho this has nothing to do with stabilization, every single package
should have these 2 points addressed.
however, fact is that a second pair of eyes reviewing the ebuild (which
is what arch testers usually do) usually spots more than the author.
there are obvious problems (reports from repoman) that indeed
should be fixed before asking for stabilization, but others are more
difficult to spot (automagics, missing die's/typos), and, as a
maintainer, the reviewing done by arch testers is usually a good help.


> 4) Nobody knows how work all packages in tree, so there are obvious
> packages like a browsers, IM, audio player,that is easy decide if is
> ok or not, but there are also packages that an Arch tester has never
> seen, so is a lack of time everytime google about it or ask to
> maintainer, so, please specify what test you want for this package;
> e.g. -only compile test
> -compile test and make sure src_test goes well
> -make sure /usr/bin/${foo} works properly in ${that} manner
> -see 5) about library
>
> So, you can write one time 'how to' and copy/paste for the future
> stablereq; I guess I'm not asking a long and difficult task.

what i dislike in this approach is that arch testers will follow a
test plan which the maintainer has obviously tested before and knows
it works.
sending people into the jungle of 'try to do something with $pkg' may
make them encounter problems the maintainer hadnt thought about.

Regards,

Alexis.
 
Old 01-18-2012, 02:05 PM
Mike Frysinger
 
Default How help in arch testing work

On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote:
> So, everytime, I must suggest the same things and I can say that at some
> point it gets boring.

so put it into a Gentoo guide and refer people to that

> 3) Check your rdepend, where is possible with scanelf[3] and if you declare
> it, please, as you said, exclude gcc/glibc and all package from @system

portage generates a NEEDED file in the vdb

> 4) Nobody knows how work all packages in tree, so there are obvious

sounds like a candidate for metadata.xml
-mike
 
Old 01-18-2012, 02:44 PM
Rich Freeman
 
Default How help in arch testing work

On Wed, Jan 18, 2012 at 9:55 AM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Wed, 18 Jan 2012 15:23 +0100
> Agostino Sarubbo <ago@gentoo.org> wrote:
>> 3) Check your rdepend, where is possible with scanelf[3] and if you
>> declare it, please, as you said, exclude gcc/glibc and all package
>> from @system
>
> imho this has nothing to do with stabilization, every single package
> should have these 2 points addressed.

True, although unless I'm missing something I don't see the harm in
listing packages as (R)DEPENDS that are in @system. If anything this
would help to reduce churn down the road as we try to minimize the
system set. If including packages from @system does break things like
stage3s I'll rescind my remarks, but my impression is that all the
circular deps necessitated some level of hard-coding in the scripts
already...

>> So, you can write one time 'how to' and copy/paste for the future
>> stablereq; I guess I'm not asking a long and difficult task.
>
> what i dislike in this approach is that arch testers will follow a
> test plan which the maintainer has obviously tested before and knows
> it works.
> sending people into the jungle of 'try to do something with $pkg' may
> make them encounter problems the maintainer hadnt thought about.

Yes and no. First, maintainers often run ~arch packages with ~arch
dependencies. They are also likely to test on one of x86/amd64, but
not both, or perhaps only in a 32-bit chroot where stuff like init
scripts isn't really running/etc. Arch teams should be testing on
stable systems running consistently on the same arch (no chroots,
minimal package.keywords, etc). Arch teams due to dumb luck are also
likely to be running different USE flags. So, I don't consider
repeating tests as a real waste (trust me, at work I'm all over this
sort of thing as we waste a lot of time running tests we know will
pass due to NIH syndrome).

Also, a maintainer might be able to suggest things that are more
likely to break, or which are more likely to cause their users pain.
If some aspect of a package is more fragile, then pointing that out to
a tester is a good thing.

No harm in having the arch team bumbling about a little, but unless a
package is perceived as being fairly important I suspect most won't do
a great deal of this.

All that said, this is Gentoo - if you want a distro with 3 releases
per year with coordinated beta cycles where everything is tested
together, look elsewhere. Without doing this sort of thing we're
going to have to accept that bugs are more likely to crop up (but will
likely be fixed faster when they do) - release somewhat early, release
very often is a pretty good summary about what we're about.

Rich
 
Old 01-18-2012, 02:48 PM
Donnie Berkholz
 
Default How help in arch testing work

On 10:05 Wed 18 Jan , Mike Frysinger wrote:
> On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote:
> > 3) Check your rdepend, where is possible with scanelf[3] and if you
> > declare it, please, as you said, exclude gcc/glibc and all package
> > from @system
>
> portage generates a NEEDED file in the vdb

Awesome, never seen that before!

--
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux <http://dberkholz.com>
Analyst, RedMonk <http://redmonk.com/dberkholz/>
 

Thread Tools




All times are GMT. The time now is 03:59 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org