[gentoo-dev] Pinboard of outdated ports

[gentoo-dev] Pinboard of outdated ports

[Johannes Weiner]

[-- Attachment #1: Type: text/plain, Size: 2520 bytes --]

Outdated ebuild reporting system
--------------------------------

Why
  Reporting outdated ebuilds via bugzilla is in my opinion not the best
  solution.
  An outdated port isn't really a 'bug' and so there are many obsolete
  reporting fields when posting a too old ebuild. The process should be
  handled on its own, more efficient and specific way.

Concept
  A pinboard-like list that shows the developers outdated packages.
  For this we need a form with:
    * dropbox for the package category
    * dropbox for the packagename itself (perhaps incl. version?)
    * textbox for the target-version
      - This will be compared with the portage version.
        If the target-version and the portage version the same, the
        entry will
        be deleted. This helps to decrease the 0-days-spam. See below.

  There should be a page before this form with a software-news-ticker,
  like the Freshmeat RSS feed, and a note that nothing should be posted
  that is listed here.
  This will prevent at least some of the 0-days-spam.
  Also a textfield where users have to agree with the conditions:
  
        18:06 <ciaranm> include a textbox into which the user must type
                        "I am not spamming. I have left this for at least
                        a week following the announcement. I have checked
                        that the package is not already in the tree. I have
                        searched for existing bugs."

  Good idea. :)

Problems
  * 0-days-spammer
    People who post all the most current news on freshmeat or other
    announcements. Noone needs this, the devs can read for themselves.
    To avoid 0-days-spamming there is the textbox ciaranm thought of.

  * Endless list growing
    To prevent the list from growing up like hell, there should be a
    mechanism that compares the list entrys' target-versions with the
    portage-version and removes the entry if the package is uptodate.

  * More staff needed
    Despite the autodeletion of uptodate packages there has to be
    someone attending the list. Remove real spam or uptodate packages
    where the targetversion is principally right but not in the correct 
    format, so the autodeletion doesn't match.


This is still expandable. This document will be updated at:
	http://hnaz.exa-ds.com/files/update-pinboard.txt
For suggestions mail at:
	hannes <hnaz@we-are-root.org>

-- 
Today is Pungenday, the 70th day of Discord in the YOLD 3171

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Pinboard of outdated ports

[Tom Martin]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

On Mon, May 23, 2005 at 07:11:38PM +0200, Johannes Weiner <hnaz@tutorialzone.de> wrote:
>   * More staff needed
>     Despite the autodeletion of uptodate packages there has to be
>     someone attending the list. Remove real spam or uptodate packages
>     where the targetversion is principally right but not in the correct 
>     format, so the autodeletion doesn't match.

How does it fit in with metadata.xml, and the maintainers and herds
listed therein?

Tom

-- 
Tom Martin, http://dev.gentoo.org/~slarti
AMD64, net-mail, shell-tools, vim, recruiters
Gentoo Linux

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Pinboard of outdated ports

[Johannes Weiner]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

On Mon, May 23, 2005 at 08:46:51PM +0100, Tom Martin wrote:
> On Mon, May 23, 2005 at 07:11:38PM +0200, Johannes Weiner <hnaz@tutorialzone.de> wrote:
> >   * More staff needed
> >     Despite the autodeletion of uptodate packages there has to be
> >     someone attending the list. Remove real spam or uptodate packages
> >     where the targetversion is principally right but not in the correct 
> >     format, so the autodeletion doesn't match.
> 
> How does it fit in with metadata.xml, and the maintainers and herds
> listed therein?

I don't get the context. Why metadata.xml? And why maintainers and herds
listed?

Confusion, hannes

-- 
Today is Prickle-Prickle, the 71st day of Discord in the YOLD 3171

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Pinboard of outdated ports

[Tom Martin]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

On Tue, May 24, 2005 at 12:47:51AM +0200, Johannes Weiner <hnaz@tutorialzone.de> wrote:
> On Mon, May 23, 2005 at 08:46:51PM +0100, Tom Martin wrote:
> > On Mon, May 23, 2005 at 07:11:38PM +0200, Johannes Weiner <hnaz@tutorialzone.de> wrote:
> > >   * More staff needed
> > >     Despite the autodeletion of uptodate packages there has to be
> > >     someone attending the list. Remove real spam or uptodate packages
> > >     where the targetversion is principally right but not in the correct 
> > >     format, so the autodeletion doesn't match.
> > 
> > How does it fit in with metadata.xml, and the maintainers and herds
> > listed therein?
> 
> I don't get the context. Why metadata.xml? And why maintainers and herds
> listed?

Well, if this just creates an entry to the list with no mention of the
email address of the maintainer, if given in metadata.xml, then it's
pretty pointless in my opinion as no-one but the maintainer could/should
bump software unless you've got a go-ahead from the maintainer or there
are exceptional circumstances.

My request is that when a new entry is added to the list, the software
used checks the package's metadata.xml and includes the herd and
maintainer on the list. If there is a maintainer specified, it sends an
email to the maintainer.

Maybe it would be better to tell maintainers to just subscribe to
projects on freshmeat?

Hope that makes sense now,
Tom

-- 
Tom Martin, http://dev.gentoo.org/~slarti
AMD64, net-mail, shell-tools, vim, recruiters
Gentoo Linux

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Pinboard of outdated ports

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

On Tuesday 24 May 2005 16:47, Tom Martin wrote:
> Maybe it would be better to tell maintainers to just subscribe to
> projects on freshmeat?
That doesn't work too well usually.
Unfortunately I have at least two packages I maintain (one directly, one as 
video herd) which I'm subscribed to but sends the freshmeat emails just after 
one or two weeks.
I usually subscribe to sf.net/berlios.de notify when present, if not, their 
own mailing lists, rss feed and if nothing is there, I just cycle through 
some of them every two days.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Pinboard of outdated ports

[Rob Cakebread]

Tom Martin wrote:

> Maybe it would be better to tell maintainers to just subscribe to
> projects on freshmeat?

I whipped up this site because the herds I'm in have a gazillion
packages:
http://gentooexperimental.org/meatoo/

It needs some work but it'd be easy to send out mail to
subscribers by herd or maintainer email instead of subscribing to
dozens of individual freshmeat packages. Or when the command-line
tool is done you can check whenever you want by herd name.


-- 
Rob Cakebread
Gentoo Linux Developer
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x96BA679B
Key fingerprint = 5E1A 57A0 0FA6 939D 3258  8369 81C5 A17B 96BA 679B
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Pinboard of outdated ports

[Johannes Weiner]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

> I whipped up this site because the herds I'm in have a gazillion
> packages:
> http://gentooexperimental.org/meatoo/
> 
> It needs some work but it'd be easy to send out mail to
> subscribers by herd or maintainer email instead of subscribing to
> dozens of individual freshmeat packages. Or when the command-line
> tool is done you can check whenever you want by herd name.

This is even cooler than the pinboard idea. Nice one!

-- 
Today is Prickle-Prickle, the 71st day of Discord in the YOLD 3171

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Pinboard of outdated ports

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johannes Weiner wrote:
> Outdated ebuild reporting system
> --------------------------------
> 
> Why
>   Reporting outdated ebuilds via bugzilla is in my opinion not the best
>   solution.
>   An outdated port isn't really a 'bug' and so there are many obsolete
>   reporting fields when posting a too old ebuild. The process should be
>   handled on its own, more efficient and specific way.

I really like having all the Gentoo things I need to do in one location.
Right now, that location is Bugzilla. Having to look in more places to
figure out what to do seems like it would just waste more time.

Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCkjQDXVaO67S1rtsRAiOyAKDtJty+m/6QyCsxHA+jElVKDNOOpACfQkX0
HCEpo8HnioEpitTnRZkEoaA=
=I0qo
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Pinboard of outdated ports

[Johannes Weiner]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

> I really like having all the Gentoo things I need to do in one location.
> Right now, that location is Bugzilla. Having to look in more places to
> figure out what to do seems like it would just waste more time.

One more tab in ${BROWSER}.. And it shouldn't make more work. It should
ease the work already there.
Having submitted an outdated port seems to be more comfortable to me
than checking your portrepo everyday for actuality.

-- 
Today is Prickle-Prickle, the 71st day of Discord in the YOLD 3171

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Pinboard of outdated ports

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johannes Weiner wrote:
> One more tab in ${BROWSER}.. And it shouldn't make more work. It should
> ease the work already there.
> Having submitted an outdated port seems to be more comfortable to me
> than checking your portrepo everyday for actuality.

What it seems like you're doing here is saying more work for the
developers is fine, if it makes things easier for the users. (Developers
will just cvs up, which is likely faster than dealing with a web interface.)

Although that may be nice in concept, in reality developers may have
quite limited time. Most things that detract from the time they spend on
development rather than on searching around and figuring out what to do
makes Gentoo worse. It has yet to be proven that your suggestion would
take more time, but that's the feeling I have.

If one knows how to search bugzilla and understands how maintainers are
indicated, this can be comparably easy already. Something like this
could give you a search:

1. Use herdstat to find the maintainer, if you aren't comfortable with
the metadata.xml files.

$ herdstat --metadata xorg-x11
Package:         x11-base/xorg-x11
Herds(1):        x11
Maintainers(0):  none
Homepage:        http://xorg.freedesktop.org/
Description:     X11 implementation by X.Org Foundation

2. Search for Enhancement bugs assigned to that herd/maintainer in
Bugzilla. In this case, it would be bugs assigned to x11@gentoo.org.

3. Profit!

Thanks,
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCkmKxXVaO67S1rtsRArXJAJ4gx6G+v4CJkXxx2NCd6ZN1Yw/aBgCfTrGl
2wOH333zS11rgRLePRM3jxw=
=GV1a
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Pinboard of outdated ports

[Johannes Weiner]

[-- Attachment #1: Type: text/plain, Size: 1467 bytes --]

> What it seems like you're doing here is saying more work for the
> developers is fine, if it makes things easier for the users. (Developers
> will just cvs up, which is likely faster than dealing with a web interface.)

I dunno if it's really big work to have a look at one site to see if
there are ebuilds you missed when they were updated.
It was not my intention to make really more work. It was just to find a faster
way for outdated ebuilds getting updated.

> Although that may be nice in concept, in reality developers may have
> quite limited time. Most things that detract from the time they spend on
> development rather than on searching around and figuring out what to do
> makes Gentoo worse. It has yet to be proven that your suggestion would
> take more time, but that's the feeling I have.
> 
> If one knows how to search bugzilla and understands how maintainers are
> indicated, this can be comparably easy already. Something like this
> could give you a search:
> 
> 1. Use herdstat to find the maintainer, if you aren't comfortable with
> the metadata.xml files.
> 
> $ herdstat --metadata xorg-x11
> Package:         x11-base/xorg-x11
> Herds(1):        x11
> Maintainers(0):  none
> Homepage:        http://xorg.freedesktop.org/
> Description:     X11 implementation by X.Org Foundation

Will try this, my idea seems to be refused anyway.

-- 
Today is Prickle-Prickle, the 71st day of Discord in the YOLD 3171

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Pinboard of outdated ports

[David Stanek]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

On Tue, May 24, 2005 at 07:26:49AM +0200, Johannes Weiner wrote:
> > What it seems like you're doing here is saying more work for the
> > developers is fine, if it makes things easier for the users. (Developers
> > will just cvs up, which is likely faster than dealing with a web interface.)
> 
> I dunno if it's really big work to have a look at one site to see if
> there are ebuilds you missed when they were updated.
> It was not my intention to make really more work. It was just to find a faster
> way for outdated ebuilds getting updated.

If it is difficult for the users, maybe it needs to be documented
better. Might be as simple as a "Report old ebuild" links on the
Bugzilla homepage. Somehow I don't think it is all that difficult
though.

To make a clean separation for other Bugzilla content a new
Component may be added. This should ease an searching issues as long
as the users searching are aware of the new component. But then we'd
probably still see a bunch of confused, headless chickens running
around squaking "ebuilds, old ebuilds".

-- 
David Stanek
www.roninds.net

GPG keyID #6272EDAF on http://pgp.mit.edu
Key fingerprint = 8BAA 7E11 8856 E148 6833  655A 92E2 3E00 6272 EDAF

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Pinboard of outdated ports

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

On Tue, 2005-05-24 at 07:26 +0200, Johannes Weiner wrote:
> > What it seems like you're doing here is saying more work for the
> > developers is fine, if it makes things easier for the users. (Developers
> > will just cvs up, which is likely faster than dealing with a web interface.)
> 
> I dunno if it's really big work to have a look at one site to see if
> there are ebuilds you missed when they were updated.
> It was not my intention to make really more work. It was just to find a faster
> way for outdated ebuilds getting updated.

There is really only one way to do this.  Figure out how to give the
developers more time to develop.

Having to search through bugs.gentoo.org, plus some external site, would
increase the time needed to find packages in need of upgrade, as some
will be filed as bugs, which would need to be resolved, so they would
have to be searched for *anyway* in bugzilla.

The most productive thing you could do, would be to figure out a simple
way of testing ebuilds, marking them as tested, and assigning them to
the proper parties quicker than is being done now.

What we really need is to have the AT program extended from just amd64
to every arch, including x86 (which desperately needs an arch team).

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Pinboard of outdated ports

[R Hill]

Chris Gianelloni wrote:
>>I dunno if it's really big work to have a look at one site to see if
>>there are ebuilds you missed when they were updated.
>>It was not my intention to make really more work. It was just to find a faster
>>way for outdated ebuilds getting updated.

> There is really only one way to do this.  Figure out how to give the
> developers more time to develop.

Right.  I think most maintainers keep on top of what's happening with 
their charges.  It's not that they've missed the fact that a new version 
has been released, it's that they haven't had the time to bump it yet. 
This might be less true for pkgs that don't have a single maintainer but 
are covered by a herd, but even in that case it's a matter of having 
time, not being oblivious that there's an update.

> Having to search through bugs.gentoo.org, plus some external site, would
> increase the time needed to find packages in need of upgrade, as some
> will be filed as bugs, which would need to be resolved, so they would
> have to be searched for *anyway* in bugzilla.
> 
> The most productive thing you could do, would be to figure out a simple
> way of testing ebuilds, marking them as tested, and assigning them to
> the proper parties quicker than is being done now.

I like this.  It could probably be done through keywording, and in fact 
the keywords are already there (ebuild and tested)[1].  They just never 
get used. ;)  Maybe raising people's (user's) awareness of their 
existence and how to use them properly would help.  I'd be willing to 
write up a Bugzilla user-guide if there's any interest in it; I've been 
meaning to write one for the wiki/forum anyways.

As for what happens after a ebuild is tested, I see a couple options. 
Devs can always just keep doing what they do now and just use the tested 
keyword as a handy at-a-glance reference.  Or, you could implement the 
Bugzilla request system[2][3] to allow a tester to flag a bug ready for 
review by a developer.  I think this would both improve the turn-around 
time on bumps and save some time for the devs by letting them know that 
any such request both has an ebuild attached and that ebuild has been 
tested by the community.  Adding a review request flag does add a little 
more complexity to the process of using bugzilla, but with proper user 
documentation I think the benefit will outweigh the cost.

> What we really need is to have the AT program extended from just amd64
> to every arch, including x86 (which desperately needs an arch team).

Really?  What does such a team do?

--de.


[1]https://bugs.gentoo.org/describekeywords.cgi
[2]http://www.bugzilla.org/features/#rs
[3]https://bugzilla.mozilla.org/flag-help.html

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Pinboard of outdated ports

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

On Tuesday 24 May 2005 22:44, R Hill wrote:
> I like this.  It could probably be done through keywording, and in fact
> the keywords are already there (ebuild and tested)[1].
TESTED is not something a simple user should ever use.
That's used by Arch Tester to let developers know they have tried it 
themselves.
Users *must not* use that keyword.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Pinboard of outdated ports

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Diego 'Flameeyes' Pettenò wrote:
> On Tuesday 24 May 2005 22:44, R Hill wrote:
> 
>>I like this.  It could probably be done through keywording, and in fact
>>the keywords are already there (ebuild and tested)[1].
> 
> TESTED is not something a simple user should ever use.
> That's used by Arch Tester to let developers know they have tried it 
> themselves.
> Users *must not* use that keyword.

Except for all the areas lacking these arch testers...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCk5iuXVaO67S1rtsRAlKqAJwKDeDj1yMVlZy0wpuXS5KFqubVSwCeNFhy
Nrn9XGfl2nINu0lMXyRDDAk=
=1Ngd
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Pinboard of outdated ports

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

On Tuesday 24 May 2005 23:12, Donnie Berkholz wrote:
> Except for all the areas lacking these arch testers...
Better avoid messing with it if ATs are missing... you fool up the results of 
a query based on those keywords.

Until ATs are just amd64-only, better avoid using that keyword elsewhere... 
another keyword can be useful, in case.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Pinboard of outdated ports

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

On Tue, 2005-05-24 at 14:12 -0700, Donnie Berkholz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Diego 'Flameeyes' Pettenò wrote:
> > On Tuesday 24 May 2005 22:44, R Hill wrote:
> > 
> >>I like this.  It could probably be done through keywording, and in fact
> >>the keywords are already there (ebuild and tested)[1].
> > 
> > TESTED is not something a simple user should ever use.
> > That's used by Arch Tester to let developers know they have tried it 
> > themselves.
> > Users *must not* use that keyword.
> 
> Except for all the areas lacking these arch testers...

The idea behind the program was to extend it to all architectures.  I'm
sure every architecture has at least one or two users that provide very
good feedback and are willing to help, but aren't necessarily able to
dedicate the time to being a full-fledged arch developer.  An AT
basically has elevated privileges in bugzilla, allowing them to make
changes to bugs to allow their respective developers to get work done
easier and quicker.

http://www.gentoo.org/proj/en/base/amd64/tests/index.xml?part=1&chap=1

This idea really should be extended, as it seems to have had very
positive results with the amd64 team.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Pinboard of outdated ports

[Homer Parker]

On Tue, 2005-05-24 at 14:44 -0600, R Hill wrote:
> > What we really need is to have the AT program extended from just
> amd64
> > to every arch, including x86 (which desperately needs an arch team).
> 
> Really?  What does such a team do?

	Glad you asked ;) 

<http://www.gentoo.org/proj/en/base/amd64/tests/index.xml>

-- 
Homer Parker
Gentoo/AMD64 Arch Tester Operational Lead
hparker@gentoo.org


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Pinboard of outdated ports

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2283 bytes --]

On Tue, 2005-05-24 at 14:44 -0600, R Hill wrote:
> > The most productive thing you could do, would be to figure out a simple
> > way of testing ebuilds, marking them as tested, and assigning them to
> > the proper parties quicker than is being done now.
> 
> I like this.  It could probably be done through keywording, and in fact 
> the keywords are already there (ebuild and tested)[1].  They just never 
> get used. ;)  Maybe raising people's (user's) awareness of their 
> existence and how to use them properly would help.  I'd be willing to 
> write up a Bugzilla user-guide if there's any interest in it; I've been 
> meaning to write one for the wiki/forum anyways.
> 
> As for what happens after a ebuild is tested, I see a couple options. 
> Devs can always just keep doing what they do now and just use the tested 
> keyword as a handy at-a-glance reference.  Or, you could implement the 
> Bugzilla request system[2][3] to allow a tester to flag a bug ready for 
> review by a developer.  I think this would both improve the turn-around 
> time on bumps and save some time for the devs by letting them know that 
> any such request both has an ebuild attached and that ebuild has been 
> tested by the community.  Adding a review request flag does add a little 
> more complexity to the process of using bugzilla, but with proper user 
> documentation I think the benefit will outweigh the cost.
> 
> > What we really need is to have the AT program extended from just amd64
> > to every arch, including x86 (which desperately needs an arch team).
> 
> Really?  What does such a team do?

They do exactly what is said above.  They test ebuilds that are
submitted.  They also test patches and just about anything else that
goes into bugzilla.  Basically, they are a group of people that own a
certain architecture that are willing to possibly destroy their machines
in the name of the greater good of QA and Gentoo.  In fact, a good
number of the amd64 arch testers have started to become developers, so
it is a good path into development, as the AT is very familiar with our
practices and has already demonstrated his abilities.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Pinboard of outdated ports

[R Hill]

Chris Gianelloni wrote:
> On Tue, 2005-05-24 at 14:44 -0600, R Hill wrote:

>>Really?  What does such a team do?
> 
> They do exactly what is said above.  They test ebuilds that are
> submitted.  They also test patches and just about anything else that
> goes into bugzilla.  Basically, they are a group of people that own a
> certain architecture that are willing to possibly destroy their machines
> in the name of the greater good of QA and Gentoo.

Well, I already destroy my machine on a weekly basis in the name of 
"what does this do", but I think I could fit some Gentoo-goodness in 
there.  If there is an x86 team formed, count me in.

--de.

-- 
gentoo-dev@gentoo.org mailing list