Monthly Gentoo Council Reminder for March

classic Classic list List threaded Threaded
80 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Monthly Gentoo Council Reminder for March

Mike Frysinger
This is your monthly friendly reminder !  Same bat time (typically
the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel
(#gentoo-council @ irc.freenode.net) !

If you have something you'd wish for us to chat about, maybe even
vote on, let us know !  Simply reply to this e-mail for the whole
Gentoo dev list to see.

Keep in mind that every GLEP *re*submission to the council for review
must first be sent to the gentoo-dev mailing list 7 days (minimum)
before being submitted as an agenda item which itself occurs 7 days
before the meeting.  Simply put, the gentoo-dev mailing list must be
notified at least 14 days before the meeting itself.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Monthly Gentoo Council Reminder for March

Raúl Porcel
I want to propose to the council to talk about the amd64 arch team and
its big bug list [1] considering they are the most staffed arch team.

They have some bugs that are more than a month old and they are the last
arch. Same for security bugs, and i think amd64 is an important arch and
has a lot of users, and ATs. x86 doesn't have any AT active and we only
have less than 10 bugs, amd64 has 144 bugs, and i'm talking about bugs
with STABLEREQ keywords, just look at [1].

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.

There's even a bug that is a blocker...


[1]: http://tinyurl.com/3dms4y
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Monthly Gentoo Council Reminder for March

Rich Freeman
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 think this may be more a question of what our policy should be
regarding level of testing/stability accepted.  I'm sure manpower is a
factor as well (number of devs isn't necessarily directly proportional
to number of hours spent by those devs per week on gentoo).

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.

Also, the more critical a package is the less likely I am to keyword it
without care - I'm not going to keyword apache stable unless I've
installed it and put several of my php/cgi-perl apps through a fair
number of chores since I know that people who run apache generally care
that it works.

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.

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.

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.
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Monthly Gentoo Council Reminder for March

Christian Faulhammer-4
Hi,

Richard Freeman <[hidden email]>:

> 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/>

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: Monthly Gentoo Council Reminder for March

Raúl Porcel
Christian Faulhammer wrote:
[snip]

I agree 100%, thanks for explaining it better than me :P

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Monthly Gentoo Council Reminder for March

Peter Faraday Weller
In reply to this post by Raúl Porcel
On Saturday 01 March 2008 10:55:06 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.

Oh, I'd be more than happy to accept help from developers like that. It's just
a case of what the "big bosses" think of it. Plus there's the fact that some
other arches operate on a "it compiles, mark it stable" policy, and we don't
want developers to bring that attitude to the amd64 team.
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Monthly Gentoo Council Reminder for March

Peter Faraday Weller
In reply to this post by Raúl Porcel
On Saturday 01 March 2008 10:55:06 Raúl Porcel wrote:
[..snip..]

There are also a number of problems with people on the team who are there
soley so that they don't have to ask the team to mark a package stable for
them - they can just go and stable it themselves. OK, this may help the amd64
team in a minor way, but it would be much more preferable if they actually
did any work *outside* of this.

Now, some of you may have noticed a certain level of inactivity from me
lately, but rest assured that now that I have my new Core 2 Duo laptop more
or less up and running, I'll be able to do more amd64 stuff.

welp
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Monthly Gentoo Council Reminder for March

Raúl Porcel
In reply to this post by Peter Faraday Weller
Peter Weller wrote:
>
> Oh, I'd be more than happy to accept help from developers like that. It's just
> a case of what the "big bosses" think of it. Plus there's the fact that some
> other arches operate on a "it compiles, mark it stable" policy, and we don't
> want developers to bring that attitude to the amd64 team.

Hope you're not referring to any of my arches because that's not true :)
In fact, if i did that, i wouldn't crash the alpha dev box so often,
right Tobias?

And that just leaves arm,hppa,mips,ppc,ppc64,s390,sh :P
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Monthly Gentoo Council Reminder for March

pva0xd
In reply to this post by Peter Faraday Weller

В Сбт, 01/03/2008 в 14:39 +0000, Peter Weller пишет:
> There are also a number of problems with people on the team who are there
> soley so that they don't have to ask the team to mark a package stable for
> them - they can just go and stable it themselves.

It'll be even better if we prohibit such things by telling that
maintainer is not allowed to stabilize his/her packages. That said, 1. I
know that some packages will never be stabilized without such practice
but we could have list of such packages somewhere; 2. some archs do not
have enough developer to enforce this policy but x86 and amd64 are not
among them.

--
Peter.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Monthly Gentoo Council Reminder for March

Rich Freeman
In reply to this post by Raúl Porcel
Raúl Porcel wrote:

> Peter Weller wrote:
>>
>> Oh, I'd be more than happy to accept help from developers like that.
>> It's just a case of what the "big bosses" think of it. Plus there's
>> the fact that some other arches operate on a "it compiles, mark it
>> stable" policy, and we don't want developers to bring that attitude to
>> the amd64 team.
>
> Hope you're not referring to any of my arches because that's not true :)
> In fact, if i did that, i wouldn't crash the alpha dev box so often,
> right Tobias?
>

I dunno - I just hit bug 211021 today while trying to clean out old
bugs.  Already stable on one arch and not a word from the maintainer.

I do agree with many of the posts in this thread by others - a big issue
is manpower.  However, I did want to mention that stabling packages
without input from maintainers seems to be a moderately-common practice.
 I'm sure the arch team leaders would welcome help if it were offered,
but it is more important that packages keyworded stable actually work
than for the latest-and-greatest package to be marked stable.
Interested users can volunteer to be ATs as well - in my past experience
as an AT when I keyworded a bug STABLE I could expect to see it
committed by a dev within a few hours.

While amd64 is a lot more mainstream than it used to be you can't just
assume that upstream wouldn't have released something if it didn't work
perfectly on amd64.

Somebody had commented that there are cases where there are
already-stable packages with bugs in them that are causing problems.
Feel free to ping one of us, or start a discussion on the -amd64 mailing
list, or email the amd64@ alias if necessary if something in particular
is causing major headaches.  Simply posting a comment in bug 37 out of
250 probably won't get much attention.  I'm sure all the amd64 devs want
to do what they can to help out those with more obscure packages.  There
are a LOT of packages marked stable on amd64 though, and while it has
improved greatly upstream still doesn't support it as well as it does
x86 (though I'm sure we won't get much sympathy from most of the other
archs in this regard :)  ).

No disputing that there is a problem - we just want to be careful that
the solution isn't worse than the problem...
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Monthly Gentoo Council Reminder for March

Christian Faulhammer-4
Hi,

Richard Freeman <[hidden email]>:
> > Hope you're not referring to any of my arches because that's not
> > true :) In fact, if i did that, i wouldn't crash the alpha dev box
> > so often, right Tobias?
> I dunno - I just hit bug 211021 today while trying to clean out old
> bugs.  Already stable on one arch and not a word from the maintainer.

 As I was the one ccing arches, I should explain here...humpback has
not reacted on tor bugs for a long time, not even security ones.  So I
did bumps and minor fixes for some time now, including stabilisation
requests.  My only failure here was, that I did not add myself to
metadata.xml.
 My policy is to ask for stabilisation --> no reaction for one week
(if it is urgent), I call arches.

> While amd64 is a lot more mainstream than it used to be you can't just
> assume that upstream wouldn't have released something if it didn't
> work perfectly on amd64.

 Here you are right, and I must admit I sometimes only compile-test. I
test everything I can, for special hardware I ask around in the team,
but if there is no one I have no other choice.
 
> No disputing that there is a problem - we just want to be careful that
> the solution isn't worse than the problem...

 What we propose is proper testing and keywording by anyone
around...not just team members.

V-Li

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

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

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Monthly Gentoo Council Reminder for March

Raúl Porcel
In reply to this post by Rich Freeman
Richard Freeman wrote:

> Raúl Porcel wrote:
>> Peter Weller wrote:
>>> Oh, I'd be more than happy to accept help from developers like that.
>>> It's just a case of what the "big bosses" think of it. Plus there's
>>> the fact that some other arches operate on a "it compiles, mark it
>>> stable" policy, and we don't want developers to bring that attitude to
>>> the amd64 team.
>> Hope you're not referring to any of my arches because that's not true :)
>> In fact, if i did that, i wouldn't crash the alpha dev box so often,
>> right Tobias?
>>
>
> I dunno - I just hit bug 211021 today while trying to clean out old
> bugs.  Already stable on one arch and not a word from the maintainer.
>
> I do agree with many of the posts in this thread by others - a big issue
> is manpower.  However, I did want to mention that stabling packages
> without input from maintainers seems to be a moderately-common practice.

I've never seen that, unless the maintainer doesn't respond, like in
this case, humpback has been ignoring his bugs for a long time, like
other devs(unfortunately). Maybe the council should talk about that:
devs ignoring his bugs for months, but i don't know how would they
enforce that.

What i've seen is some bugs where the arches were cc'ed by users or by a
developer, but in this case, someone of the arch team that knows that
the dev is active, just uncc's all the arches until the maintainer
responds, but in this case, humpback didn't say anything about the
previous tor stabilization request for months. So you should be glad
someone active like Christian, took over the maintenance and he is
responsible if something goes wrong with the stabilization.

>  I'm sure the arch team leaders would welcome help if it were offered,
> but it is more important that packages keyworded stable actually work
> than for the latest-and-greatest package to be marked stable.
> Interested users can volunteer to be ATs as well - in my past experience
> as an AT when I keyworded a bug STABLE I could expect to see it
> committed by a dev within a few hours.

IIRC you are from the blubb era, i'm i right? Blubb did a really god job
with amd64, and in fact amd64 started 'slacking' since blubb left.
Unfortunately that doesn't work anymore, in a lot of bugs i've seen an
AT of yours posting his results, when i was going to do my arches. So i
was more faster even that i have no ATs.

And look at x86, we don't have any ATs, god, we even had some that moved
to amd64! drac, mlangc, etc etc.
For example, bug 205242. Look, its mlangc! :P
>
> While amd64 is a lot more mainstream than it used to be you can't just
> assume that upstream wouldn't have released something if it didn't work
> perfectly on amd64.
>

Indeed, but on x86 we don't assume it either :) I don't understand how
you having so many users, have manpower problems, you have two channels
on IRC, x86 only has one and nobody says anything.
It's just a though, i'm not blaming anyone.

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Monthly Gentoo Council Reminder for March

Ed Wildgoose-2
At one time there were some apps which reported back "usage" from
people's systems and showed package versions in use?  Now, whilst this
in itself is not an indication of package quality or bug-freeness.  
Perhaps it would be an interesting datastream to assist in deciding
whether to mark a package stable or not?

An incremental improvement to such a plan might be to consider how to
split the data into high quality devs and testers running stuff stuff,
keen users and dev boxes (which might be crashing and are of low quality).

Sure it's a fairly low quality data source, but it might give a bit of
confidence to take a punt unmasking a package if you can see that others
are using it "actively"?

Just my 2p

Ed W
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Monthly Gentoo Council Reminder for March

Rich Freeman
In reply to this post by Raúl Porcel
Raúl Porcel wrote:
>
> IIRC you are from the blubb era, i'm i right? Blubb did a really god job
> with amd64, and in fact amd64 started 'slacking' since blubb left.
> Unfortunately that doesn't work anymore, in a lot of bugs i've seen an
> AT of yours posting his results, when i was going to do my arches. So i
> was more faster even that i have no ATs.
>

Yup - blubb is certainly missed.  I can't point any fingers myself - I
try to find and stabilize packages as I'm able to, but I can only spend
so much time on gentoo.  Every little bit helps though, even if I'm not
high on the commits/day rankings.

There are amd64 ATs out there - which brings up the other thread
floating around.  We need better ways to flag bugs that have been
touched by an AT - for all I know there are a dozen open bugs that an AT
has tested, but if there aren't any keywords or anything else I can
query for, I can't get them stabilized.

>
> Indeed, but on x86 we don't assume it either :) I don't understand how
> you having so many users, have manpower problems, you have two channels
> on IRC, x86 only has one and nobody says anything.
> It's just a though, i'm not blaming anyone.
>

My observation is that there are heavy-lifters who do a disproportionate
share of the work.  I'm certainly not one of them, and I really do
appreciate these folks.  If a heavy-lifter gives attention to something,
it will shine.  However, Gentoo is a volunteer-driven organization, and
you can't order heavy-lifters to work on something in particular - it is
their passion for what they choose to work on that makes them so
effective.  I guess what we need is processes that enable lots of small
contributors to make a big difference - the bazzar approach.

Another reply on this thread pointed out that it would be nice to be
able to tell what packages people are using - if we could tell what is
being used it would help guide stabilization without sacrificing testing
(our users would be de-facto ATs without realizing it).  The power of a
thousand people doing very little can add up - many users would gladly
sign up to have their packages monitored if it would help the gentoo cause.

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Re: Monthly Gentoo Council Reminder for March

Rich Freeman
In reply to this post by Christian Faulhammer-4
Christian Faulhammer wrote:
>
>  What we propose is proper testing and keywording by anyone
> around...not just team members.
>

Thanks for the info - inactive maintainers are obviously a problem.
Maybe the proper approach is for a more "Free-for-all" system like you
suggest, with arch teams focusing on more arch-specific aspects of
gentoo (such as the 32-bit libs for amd64, etc), and with arch teams
having a QA oversight role for their arch.  Perhaps arch teams should
publish clear (and reasonably simple) policies they would like to see
followed with their archs, and then devs could feel free to follow them
on their own initiative.  Accountability would obviously matter, but we
don't want to chop off hands for first offenses, either.

The Gentoo dev community is fairly closed - it isn't like just anybody
can go keywording packages left and right.

However, we do need to make sure that QA is followed.
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Re: Monthly Gentoo Council Reminder for March

Steve Dibb
In reply to this post by Christian Faulhammer-4
Christian Faulhammer wrote:

>  What we propose is proper testing and keywording by anyone
> around...not just team members.

I agree... our main problem is manpower -- people actually working on
the stable bugs.  I've tried to do it myself a few times, but each time
it just burns me out to the point where I don't want to (and won't) work
on anything Gentoo-related for a time.

I've mostly resigned myself to working on just security bugs, but even
those are so common that we need people looking at them all the time as
well.

Anyway, I'm all for a policy of if you have an amd64 box, and you're on
a team / herd that wants to move forward with stable plans, just consult
the amd64 team and then go ahead with it.  Anything to spread the
workload so that people don't get fed up with the bottlenecks.

Steve
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Re: Monthly Gentoo Council Reminder for March

George Shapovalov
Sunday, 2. March 2008, Steve Dibb Ви написали:
> Christian Faulhammer wrote:
> >  What we propose is proper testing and keywording by anyone
> > around...not just team members.
>
> I agree... our main problem is manpower -- people actually working on
> the stable bugs.  I've tried to do it myself a few times, but each time
> it just burns me out to the point where I don't want to (and won't) work
> on anything Gentoo-related for a time.
So, may be we should expand the number of "stability classes"? (something akin
to my origina proposal, parst of which has been implemented, but looks like
there is yet another usefull issue or two that did not make it yet :) (bug
#1523, though probably not worth studying a this point as it mostly contains
old stuff by now)).

Right now with packages being only "in testing" and "stable" we basically
cover the audiences with stances "original dev says it works - it's fine for
me" and "I want it rigorously tested". There should be plenty of people, who
would be happy with an intermediate level of control. May be we should add an
intermediate category with a somewhat automated workflow? So that the
evolution of packages in the tree would follow such pattern (plus, of course,
there are overlays for even less stable stuff):

1. as the package gets released it goes into the "testing", as it does now

2. After say 2-4 wekks (take your pick) without issues and possibly going
trhough some compile-farm (automatically scheduled at the end of this period
if no open bugs (normal or more severe) are detected) the package is marked
as belonging to the "tested" category. This is where many users would set
their running stability level and, in a way, participate in testing things
for the next level.

If, any time after entering the "tested" state, package gets a bug assigned
against it (again, normal or more severe) we start a countdown of, perhaps a
few days, to let developers take care of the bug and if it does not get
resolved within this time frame the package goes back to "testing". The
decision to mask it or pull it off the tree completely remains with the
respective devs, as it is now.
Some packages can be marked as "critical" to make them go back to "testing"
immediately upon getting an open bug, should such effect be desired (might be
usefull for some security-sensitive system packages, or may be not, due to
possible breakage this may introduce. Still we are having such downgrade
situations already from time to time).

3. "completely stable" profile, to which packages only go when explicitly
requested and processed by stabilization team, as they are now. We should
probably impose the requirement, that stabilization can only be requested for
packages in the "tested" category.

The good thing about this approach is that it only requires an initial
investment of organizing and automating things but does not add any regular
work to the devs. In fact, if the "tested" category becomes popular enough,
it can cut the work for stable testers, may be even by something like a
factor of 10 eventually (due to less requests for explicit stabilizaion being
issued)..

George
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Re: Monthly Gentoo Council Reminder for March

Santiago M. Mola
In reply to this post by Christian Faulhammer-4
On Sat, Mar 1, 2008 at 7:45 PM, Christian Faulhammer <[hidden email]> wrote:
>
>   What we propose is proper testing and keywording by anyone
>  around...not just team members.
>

Writing test plans like emacs team does really helps too. I waste too
much time figuring out how to test properly some packages, and I'm
sure me and other ATs miss a lot of important use cases.

--
Santiago M. Mola
Jabber ID: [hidden email]
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Re: Monthly Gentoo Council Reminder for March

Rich Freeman
In reply to this post by George Shapovalov
George Shapovalov wrote:
> The good thing about this approach is that it only requires an initial
> investment of organizing and automating things but does not add any regular
> work to the devs. In fact, if the "tested" category becomes popular enough,
> it can cut the work for stable testers, may be even by something like a
> factor of 10 eventually (due to less requests for explicit stabilizaion being
> issued)..
>

We might also aim to make it easy for users to mix-and-match levels of
stability by package.  I know it is possible already, but perhaps it
could be improved, or pre-canned lists of packages that users might
typically want bleeding-edge vs stable could be compiled.

I think there are a large number of users who wouldn't mind less
stability on packages that won't prevent booting or network-access or
general use of their system.  If some nice-to-have utility breaks I
don't mind reverting it, but if baselayout goes haywire I could spend
hours just getting my system to boot.

I like your idea though.
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Re: Monthly Gentoo Council Reminder for March

Jan Kundrát
Richard Freeman wrote:
> We might also aim to make it easy for users to mix-and-match levels of
> stability by package.  I know it is possible already, but perhaps it
> could be improved, or pre-canned lists of packages that users might
> typically want bleeding-edge vs stable could be compiled.

Tusnam said it better than I would, so I'll just post a link --
http://tsunam.org/2008/01/29/arch/

Cheers,
-jkt

--
cd /local/pub && more beer > /dev/mouth


signature.asc (260 bytes) Download Attachment
1234