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 12-17-2011, 02:22 PM
"Paweł Hajdan, Jr."
 
Default mass stabilization and non-x86-non-amd64 arches

For several mass-filed stabilization bugs I got comments why I didn't cc
arches like ppc.

One problem is that I cc x86 and amd64 via "edit many bugs at once"
Bugzilla feature, and when filing bugs the script checks that it's
repoman-possible to stabilize given package on x86 and amd64.

Not all packages are even keyworded ~ppc, and I guess there are packages
that can be stabilized on x86 and amd64, but not ppc because of ~ppc
dependencies.

All of that is of course solvable with a smarter script, however I'm
really worried about the additional load on the "rare arches". I
frequently notice they drop stable keywords when asked for a
stabilization of some rare package (and I'm fine with that), and they
may be annoyed by stabilization requests for minor and revision bumps
(which are fine at least for x86, because of the batch-stabilization
workflow; of course other arches are welcome to adopt it too).

What do you think? Should I make my scripts smarter, or is it fine to
just cc x86 and amd64? Is anyone from non-x86-non-amd64 arch teams
annoyed by the queue of stabilization bugs?
 
Old 12-17-2011, 02:38 PM
Pacho Ramos
 
Default mass stabilization and non-x86-non-amd64 arches

El sáb, 17-12-2011 a las 16:22 +0100, "Paweł Hajdan, Jr." escribió:
> For several mass-filed stabilization bugs I got comments why I didn't cc
> arches like ppc.
>
> One problem is that I cc x86 and amd64 via "edit many bugs at once"
> Bugzilla feature, and when filing bugs the script checks that it's
> repoman-possible to stabilize given package on x86 and amd64.
>
> Not all packages are even keyworded ~ppc, and I guess there are packages
> that can be stabilized on x86 and amd64, but not ppc because of ~ppc
> dependencies.
>
> All of that is of course solvable with a smarter script, however I'm
> really worried about the additional load on the "rare arches". I
> frequently notice they drop stable keywords when asked for a
> stabilization of some rare package (and I'm fine with that), and they
> may be annoyed by stabilization requests for minor and revision bumps
> (which are fine at least for x86, because of the batch-stabilization
> workflow; of course other arches are welcome to adopt it too).
>
> What do you think? Should I make my scripts smarter, or is it fine to
> just cc x86 and amd64? Is anyone from non-x86-non-amd64 arch teams
> annoyed by the queue of stabilization bugs?
>

I am not in ppc* teams but, from my point of view, looks like they are
understaffed and I doubt they could handle so many requests. For mass
stabilization purposes I would keep the script for amd64/x86 only for
now :-/
 
Old 12-17-2011, 02:53 PM
Jeroen Roovers
 
Default mass stabilization and non-x86-non-amd64 arches

On Sat, 17 Dec 2011 16:38:31 +0100
Pacho Ramos <pacho@gentoo.org> wrote:

> El sáb, 17-12-2011 a las 16:22 +0100, "Paweł Hajdan, Jr." escribió:
> > For several mass-filed stabilization bugs I got comments why I
> > didn't cc arches like ppc.

And correctly so.

> > One problem is that I cc x86 and amd64 via "edit many bugs at once"
> > Bugzilla feature, and when filing bugs the script checks that it's
> > repoman-possible to stabilize given package on x86 and amd64.
> >
> > Not all packages are even keyworded ~ppc, and I guess there are
> > packages that can be stabilized on x86 and amd64, but not ppc
> > because of ~ppc dependencies.

I would think you'd stabilise only packages for which a previous
version is already stable. If you focused on that, the problem of
dependencies being unstable wouldn't exist. ~arch on all ebuilds
simply means no security support, so asking to go stable means adding
that, and this changes the entire purpose of your stabilisation bugs
when you ask arch teams to go stable for the first time.

> > All of that is of course solvable with a smarter script, however I'm
> > really worried about the additional load on the "rare arches".

Um, so somebody else will have to go through the whole load of bug
reports to fix the arch teams you left out? Because your script doesn't
do it?

> > What do you think? Should I make my scripts smarter, or is it fine
> > to just cc x86 and amd64? Is anyone from non-x86-non-amd64 arch
> > teams annoyed by the queue of stabilization bugs?

I'd like you to file correct stabilisation bug reports. Which means
CCing all arches that have /previous/ ebuilds stable. We've always done
it like this.

> I am not in ppc* teams but, from my point of view, looks like they are
> understaffed and I doubt they could handle so many requests.

Same goes for all the less popular architectures.

> For mass stabilization purposes I would keep the script for amd64/x86
> only for now :-/

The only way to maintain these architectures properly is to not exclude
them in the first place. Once you start doing that, you might as well
stop supporting security, go ~arch or drop them entirely.

The only way to show there is a problem with staffing and/or the
availability of supported systems is to include these arch teams in
stabilisation bugs and then draft in more developers. In a volunteer
project, hiding the problems makes sure no one will come in and fix
them.

The good thing about including slow arch teams is that when you've
gathered up a couple hundred or thousand bug reports, you can make a
very good case about dropping the old stable ebuilds, effectively
moving the slow arch to unstable.


jer
 
Old 12-17-2011, 06:09 PM
Samuli Suominen
 
Default mass stabilization and non-x86-non-amd64 arches

On 12/17/2011 05:22 PM, "Paweł Hajdan, Jr." wrote:

For several mass-filed stabilization bugs I got comments why I didn't cc
arches like ppc.

One problem is that I cc x86 and amd64 via "edit many bugs at once"
Bugzilla feature, and when filing bugs the script checks that it's
repoman-possible to stabilize given package on x86 and amd64.

Not all packages are even keyworded ~ppc, and I guess there are packages
that can be stabilized on x86 and amd64, but not ppc because of ~ppc
dependencies.

All of that is of course solvable with a smarter script, however I'm
really worried about the additional load on the "rare arches". I
frequently notice they drop stable keywords when asked for a
stabilization of some rare package (and I'm fine with that), and they
may be annoyed by stabilization requests for minor and revision bumps
(which are fine at least for x86, because of the batch-stabilization
workflow; of course other arches are welcome to adopt it too).

What do you think? Should I make my scripts smarter, or is it fine to
just cc x86 and amd64? Is anyone from non-x86-non-amd64 arch teams
annoyed by the queue of stabilization bugs?



For reference, it's http://bugs.gentoo.org/394021

So in this case ppc has stable keyword in x11-misc/fireflies package,
then leaving out ppc from the CC in the bug will only increase the
workload for the maintainers since they need to reopen the old
stabilization bug or file a new one just for ppc.


So i'd rather not see any arches added to CC list at all, if you don't
do it properly all the way.
 

Thread Tools




All times are GMT. The time now is 01:01 PM.

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