Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Jon Portnoy]

On Wed, Sep 14, 2005 at 12:06:13AM -0400, Curtis Napier wrote:
> I'm not an ebuild dev so I may not know enough about this situation to 
> competantly comment on it but it seems to me that QA should have some 
> sort of limited ability to "temporarily" take away write access to the 
> tree until devrel has a chance to look over the evidence and come to a 
> decision. This would fix the problem of "devrel takes to long" plus it 
> would really help to ensure higher quality work is submitted (because 
> ebuild devs WILL stop purposely commiting bad work if they know a QA 
> team member can take away their write access at a moments notice for 
> repeated violations).

The other thing that'd fix the 'devrel takes so long' problem would be 
if people would let devrel fix its resolution policies 8) (see recent 
-devrel ml thread)

> 
> As Lance said in an earlier post, infra already does this "temporary 
> removal of access" if it is an immediate security threat and then 
> submits the evidence to devrel for followup. Why can't it work exactly 
> the same for the QA team? If they have done their due diligence by 
> contacting the dev in question, pointing out their mistakes and offering 
> assistance to correct the mistakes and the dev just keeps right on 
> commiting bad stuff QA should be able to "temporarily" stop them until 
> devrel has a chance to follow up and investigate. That's what QA is, 
> Quality Assurance, if they have no power to actually "Assure Quality" 
> then why does this team even exist?
> 

QA and devrel have two different jobs. QA doesn't have to be devrel's 
problem and devrel tasks don't have to be QA's problem (how much do the 
QA folks really want to deal with the usual bitchfest when somebody 
with a lot of friends gets suspended for something?) if they work 
together on repeated problem developers.

> I'll give an example: Saturn car company has a great big red "STOP" 
> button at every point in the assembly line that can turn off the entire 
> manufacturing line if QA spots a mistake. The QA team does not have to 
> ask anyone first, they simply push the button so the low quality car 
> does not get through, remove the offending car from the line 
> "temporarily" until a team investigates and decides if the quality is 
> good enough to put it back on the assembly line. Saturn is known for the 
> quality of it's cars because of this. The gentoo QA team should have 
> this same ability.
> 

Does Saturn's stop button also kick the apparently responsible 
individual out of the building? Otherwise this analogy would work better 
if applied to ebuilds and the maintainership thereof, not developers and 
their CVS access.

(And on another note, Saturn? Known for quality? Bwahahahah... err. :) )

-- 
Jon Portnoy
avenj/irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Curtis Napier]

Lance Albertson wrote:
snip
...

I tend to agree with Donnie on this partially. Devrel's main focus isn't
the QA of the tree, its dealing with developers. QA should have the
authority to limit access to the tree if someone isn't following the
guidelines properly. They are the ones with the technical know how to
make the judgment on that. Obviously, they will need to come up with
guidelines if someone does make a goof up. Give them some probationary
time, maybe make them take the quiz again to improve their ebuild
skills. I just don't think devrel is the right place for that kind of
authority.



I'm not an ebuild dev so I may not know enough about this situation to 
competantly comment on it but it seems to me that QA should have some 
sort of limited ability to "temporarily" take away write access to the 
tree until devrel has a chance to look over the evidence and come to a 
decision. This would fix the problem of "devrel takes to long" plus it 
would really help to ensure higher quality work is submitted (because 
ebuild devs WILL stop purposely commiting bad work if they know a QA 
team member can take away their write access at a moments notice for 
repeated violations).


As Lance said in an earlier post, infra already does this "temporary 
removal of access" if it is an immediate security threat and then 
submits the evidence to devrel for followup. Why can't it work exactly 
the same for the QA team? If they have done their due diligence by 
contacting the dev in question, pointing out their mistakes and offering 
assistance to correct the mistakes and the dev just keeps right on 
commiting bad stuff QA should be able to "temporarily" stop them until 
devrel has a chance to follow up and investigate. That's what QA is, 
Quality Assurance, if they have no power to actually "Assure Quality" 
then why does this team even exist?


I'll give an example: Saturn car company has a great big red "STOP" 
button at every point in the assembly line that can turn off the entire 
manufacturing line if QA spots a mistake. The QA team does not have to 
ask anyone first, they simply push the button so the low quality car 
does not get through, remove the offending car from the line 
"temporarily" until a team investigates and decides if the quality is 
good enough to put it back on the assembly line. Saturn is known for the 
quality of it's cars because of this. The gentoo QA team should have 
this same ability.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Mike Frysinger]

On Tuesday 13 September 2005 11:10 pm, Jon Portnoy wrote:
> As far as devrel goes, call me a traditionalist but I think while infra
> should be able to do emergency deactivations (and afaik nobody's ever
> said they shouldn't) devrel should continue to be responsible for
> disciplinary issues including repeated QA violations reported by the QA
> team

works for me ... best to keep the number of 'bad guys' down to a min :D
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Corey Shields]

On Tuesday 13 September 2005 5:22 pm, Lance Albertson wrote:
> I would like there to be a clause that infra has the ability to at least
> temporarily revoke access to have the ability to protect our servers if
> something came up quickly. I've always made sure any permanent removals
> go through devrel first.

that's always been policy, but yeah wouldn't hurt to put it in print 
somewhere..

-C

-- 
Corey Shields
Gentoo Linux Infrastructure Team
Gentoo Foundation Board of Trustees
http://www.gentoo.org/~cshields
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] GNOME 2.12.0 Final - Testing

[John N. Laliberte]

Hello all,

The GNOME herd is now ready for 2.12.0 to be tested.

The gnome-2.12.0.ebuild should hit the mirrors shortly. ( just committed)

Please see this document for information on how to test:
http://dev.gentoo.org/~allanonjl/gnome/2.12.0/testing.instructions.txt

Thanks, and happy bug hunting!
John N. Laliberte ( AllanonJL )
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug 80905

[Richard Fish]

Frank Schafer wrote:


I'm still on the kernel from the life-cd. The self compiled kernel has
the highmem option set to off (I have only 1GB). I'm on x86 Intel
Celeron M and have CHOST set to i686-pc-linux-gnu and CFLAGS="-O2
-march=pentium2"
 



Um, why pentium2?  The Celeron-M is the same core as a Pentium-M with 
less cache and lower clock speeds, so it seems to me that your -march 
should really be pentium-m.


Anyway, I'll be back on gentoo-user if you want to discuss this thread 
more there.


-Richard

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Jon Portnoy]

On Tue, Sep 13, 2005 at 10:21:42PM -0400, Nathan L. Adams wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Mike Frysinger wrote:
> > if you read this whole thread you'll find that it is a grey area with 
> > different devrel people saying/thinking different things in terms of what 
> > devrel's responsibilities are
> 
> It sounds like somebody needs to take a look at all of the existing
> documentation for this topic, write a GLEP that clarifies the matter,
> and present it to the council for a vote.
> 
> - - who should enforce Gentoo policy (technical or otherwise)?
> - - what are the procedures for getting the enforcement done?
> - - what checks and balances are in place (and are more/clarification
> needed)?
> - - etc.
> 

Sounds to me more like people who aren't familiar with the internal 
structure of Gentoo don't need to be the peanut gallery when it comes to 
internal structural issues, but that's just me 8)

As far as devrel goes, call me a traditionalist but I think while infra 
should be able to do emergency deactivations (and afaik nobody's ever 
said they shouldn't) devrel should continue to be responsible for 
disciplinary issues including repeated QA violations reported by the QA 
team

-- 
Jon Portnoy
avenj/irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Nathan L. Adams]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mike Frysinger wrote:
> GLEP's are developed after the details are ironed out in public developer 
> forums ... their purpose isnt to fast track changes through the Gentoo 
> council to kill long threads
> 
> not saying that is what you meant, just making sure everyone is on the same 
> track ;)

I wasn't suggesting fast tracking or killing long threads; but I think
it would be easier for you dev types to iron out the details if you had
a draft GLEP to target your flames... er... 'discussion' at. ;)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDJ4yV2QTTR4CNEQARAnpbAJ4s4P38g40LliScob4ovFs+DphBYwCfRzbE
Tz1G1kRKPr73KpChE96ZvIQ=
=IVUR
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Mike Frysinger]

On Tuesday 13 September 2005 10:21 pm, Nathan L. Adams wrote:
> Mike Frysinger wrote:
> > if you read this whole thread you'll find that it is a grey area with
> > different devrel people saying/thinking different things in terms of what
> > devrel's responsibilities are
>
> It sounds like somebody needs to take a look at all of the existing
> documentation for this topic, write a GLEP that clarifies the matter,
> and present it to the council for a vote.

GLEP's are developed after the details are ironed out in public developer 
forums ... their purpose isnt to fast track changes through the Gentoo 
council to kill long threads

not saying that is what you meant, just making sure everyone is on the same 
track ;)
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Nathan L. Adams]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mike Frysinger wrote:
> if you read this whole thread you'll find that it is a grey area with 
> different devrel people saying/thinking different things in terms of what 
> devrel's responsibilities are

It sounds like somebody needs to take a look at all of the existing
documentation for this topic, write a GLEP that clarifies the matter,
and present it to the council for a vote.

- - who should enforce Gentoo policy (technical or otherwise)?
- - what are the procedures for getting the enforcement done?
- - what checks and balances are in place (and are more/clarification
needed)?
- - etc.

Nathan

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDJ4k22QTTR4CNEQARAvbbAJwNtqXM9L9ycyCqmQoJrelYeNnE0wCgoRit
4mUsp/yONu4TfTAV5GVxSKk=
=Mflu
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Mike Frysinger]

On Tuesday 13 September 2005 08:22 pm, Lance Albertson wrote:
> Mike Frysinger wrote:
> >>It certainly says they're responsible for adding and removing
> >>developers, but I don't see anything about them being solely responsible
> >>for revoking access.
> >
> > no, nowhere does it say 'devrel is the only team which may revoke
> > access', but it is the only team which says they can and i'd prefer it
> > stay that way
>
> I would like there to be a clause that infra has the ability to at least
> temporarily revoke access to have the ability to protect our servers if
> something came up quickly. I've always made sure any permanent removals
> go through devrel first.

that would make a lot of sense
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Lance Albertson]

Mike Frysinger wrote:

>>It certainly says they're responsible for adding and removing
>>developers, but I don't see anything about them being solely responsible
>>for revoking access.
> 
> 
> no, nowhere does it say 'devrel is the only team which may revoke access', 
> but 
> it is the only team which says they can and i'd prefer it stay that way
> -mike

I would like there to be a clause that infra has the ability to at least
temporarily revoke access to have the ability to protect our servers if
something came up quickly. I've always made sure any permanent removals
go through devrel first.

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Mike Frysinger]

On Tuesday 13 September 2005 07:59 pm, Donnie Berkholz wrote:
> Mike Frysinger wrote:
> > as avenj pointed out, current 'mission statement' of devrel says that
> > they handle the issue of actually revoking a dev's access
>
> I thought this was written somewhere too, but I can't seem to find it
> anywhere. Do you know where it says this?

main project page for devrel
http://www.gentoo.org/proj/en/devrel/index.xml

> It certainly says they're responsible for adding and removing
> developers, but I don't see anything about them being solely responsible
> for revoking access.

no, nowhere does it say 'devrel is the only team which may revoke access', but 
it is the only team which says they can and i'd prefer it stay that way
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Donnie Berkholz]

Mike Frysinger wrote:
as avenj pointed out, current 'mission statement' of devrel says that they 
handle the issue of actually revoking a dev's access


I thought this was written somewhere too, but I can't seem to find it 
anywhere. Do you know where it says this?


It certainly says they're responsible for adding and removing 
developers, but I don't see anything about them being solely responsible 
for revoking access.


Thanks,
Donnie
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Mike Frysinger]

On Tuesday 13 September 2005 07:46 pm, Lance Albertson wrote:
> Donnie Berkholz wrote:
> > Not really, because my opinion that devrel shouldn't be involved is not
> > automatically turned into reality (much to my regret). I'm trying to
> > supply evidence why this should stay between QA and infra.
> >
> >> at any rate, you're proposing giving the control to the QA team which
> >> has no guidelines or processes outlined, let alone the manpower.
> >> devrel has all of these.
> >
> > And devrel is the wrong group to handle it, so QA needs to come up with
> > some guidelines.
>
> I tend to agree with Donnie on this partially. Devrel's main focus isn't
> the QA of the tree, its dealing with developers.

exactly, which is what i said originally

QA flags developers as bad apples and tells devrel to punish them

> If QA has done all it can to help improve someone or deal with their
> problems, then devrel can take over it. Give the power to the right
> people so they can do the right kind of work and decisions.

i also noted this originally ... QA team tells dev what they've done wrong and 
to plzfixkthx.  if dev is unresponsive/continues to produce garbage, then QA 
team informs devrel to clean up said dev.
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Mike Frysinger]

On Tuesday 13 September 2005 07:31 pm, Donnie Berkholz wrote:
> Mike Frysinger wrote:
> > at any rate, you're proposing giving the control to the QA team which has
> > no guidelines or processes outlined, let alone the manpower.  devrel has
> > all of these.
>
> And devrel is the wrong group to handle it, so QA needs to come up with
> some guidelines.

as avenj pointed out, current 'mission statement' of devrel says that they 
handle the issue of actually revoking a dev's access

so if you wish to change that, feel free to start up a new thread
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Lance Albertson]

Donnie Berkholz wrote:

> Not really, because my opinion that devrel shouldn't be involved is not
> automatically turned into reality (much to my regret). I'm trying to
> supply evidence why this should stay between QA and infra.
> 
>> at any rate, you're proposing giving the control to the QA team which
>> has no guidelines or processes outlined, let alone the manpower. 
>> devrel has all of these.
> 
> 
> And devrel is the wrong group to handle it, so QA needs to come up with
> some guidelines.

I tend to agree with Donnie on this partially. Devrel's main focus isn't
the QA of the tree, its dealing with developers. QA should have the
authority to limit access to the tree if someone isn't following the
guidelines properly. They are the ones with the technical know how to
make the judgment on that. Obviously, they will need to come up with
guidelines if someone does make a goof up. Give them some probationary
time, maybe make them take the quiz again to improve their ebuild
skills. I just don't think devrel is the right place for that kind of
authority.

I kind of see devrel as the last resort for resolving developer issues.
If QA has done all it can to help improve someone or deal with their
problems, then devrel can take over it. Give the power to the right
people so they can do the right kind of work and decisions.

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Donnie Berkholz]

Jason Stubbs wrote:

On Wednesday 14 September 2005 05:43, Donnie Berkholz wrote:

QA can work faster since it's less objected do and doesn't need endless 
committees and documentation -- the documentation is the broken code. 



That's not true. The documentation is the developer guide, the ebuild faq, 
pertinent GLEPs that haven't made their way into other documentation yet, 
etc. There is _plenty_ of documentation.


I'm saying the documentation that somebody's doing something wrong. I 
guess "evidence" would be a better word.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Donnie Berkholz]

Mike Frysinger wrote:
so your previous off-topic comment about redtape in devrel processes was 
irrelevant :P


Not really, because my opinion that devrel shouldn't be involved is not 
automatically turned into reality (much to my regret). I'm trying to 
supply evidence why this should stay between QA and infra.


at any rate, you're proposing giving the control to the QA team which has no 
guidelines or processes outlined, let alone the manpower.  devrel has all of 
these.


And devrel is the wrong group to handle it, so QA needs to come up with 
some guidelines.


Thanks,
Donnie
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Jason Stubbs]

On Wednesday 14 September 2005 05:43, Donnie Berkholz wrote:
> QA can work faster since it's less objected do and doesn't need endless 
> committees and documentation -- the documentation is the broken code. 

That's not true. The documentation is the developer guide, the ebuild faq, 
pertinent GLEPs that haven't made their way into other documentation yet, 
etc. There is _plenty_ of documentation.

-- 
Jason Stubbs


pgpxxJvlJibT2.pgp
Description: PGP signature

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Mike Frysinger]

On Tuesday 13 September 2005 12:22 pm, Jon Portnoy wrote:
> On Tue, Sep 13, 2005 at 07:33:59AM -0500, Lance Albertson wrote:
> > The actual powers/role of devrel has always been a grey area.
>
> No it hasn't, unless by 'gray area' you mean 'a few people who don't
> like devrel claim it shouldn't be able to do anything because drobbins
> set it up'

if you read this whole thread you'll find that it is a grey area with 
different devrel people saying/thinking different things in terms of what 
devrel's responsibilities are

also, can we drop the gay conspiracy / anti-conspiracy e-mails, they're just 
wasting time

> Recruitment, conflict resolution, disciplinary issues. I.e., 'managing
> developers.'

sounds good to me
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Mike Frysinger]

On Tuesday 13 September 2005 06:43 pm, Donnie Berkholz wrote:
> Mike Frysinger wrote:
> > QA team identifies a misbehaving dev who refuses to change and then hands
> > off the name/relevant data to devrel ... QA team then is pretty much done
> > with the issue and the rest is up to devrel to resolve
>
> I disagree that devrel should be involved. I think QA should hand off
> directly to infra, who can deactivate accounts.

so your previous off-topic comment about redtape in devrel processes was 
irrelevant :P

at any rate, you're proposing giving the control to the QA team which has no 
guidelines or processes outlined, let alone the manpower.  devrel has all of 
these.
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Donnie Berkholz]

Mike Frysinger wrote:
QA team identifies a misbehaving dev who refuses to change and then hands off 
the name/relevant data to devrel ... QA team then is pretty much done with 
the issue and the rest is up to devrel to resolve


I disagree that devrel should be involved. I think QA should hand off 
directly to infra, who can deactivate accounts.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Brian Harring]

On Tue, Sep 13, 2005 at 05:02:45PM -0400, Mike Frysinger wrote:
> On Tuesday 13 September 2005 04:43 pm, Donnie Berkholz wrote:
> > Mike Frysinger wrote:
> > > this side note is unrelated to the point being made and really belongs in
> > > the previous discussions on the devrel list
> > >
> > > besides, is this a bad thing ?  i'd prefer to have devs settle crap
> > > themselves than ever contacting devrel :P
> >
> > It's very relevant, because it supports the idea of QA taking care of
> > technical issues on its own. QA can work faster since it's less objected
> > do and doesn't need endless committees and documentation -- the
> > documentation is the broken code.
> 
> QA team does not care at all about inner workings of devrel
> 
> QA team identifies a misbehaving dev who refuses to change and then hands off 
> the name/relevant data to devrel ... QA team then is pretty much done with 
> the issue and the rest is up to devrel to resolve

Pretty much is what I'm after; just want to ensure no more scenarios
where stuff gets left broken for 18 months (actual example) due to QA 
having no means to force people to fix their cruft.

This need a proposal, or can the council just do a "make it so" ?
~harring


pgpNdXWnwxORt.pgp
Description: PGP signature

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Mike Frysinger]

On Tuesday 13 September 2005 04:43 pm, Donnie Berkholz wrote:
> Mike Frysinger wrote:
> > this side note is unrelated to the point being made and really belongs in
> > the previous discussions on the devrel list
> >
> > besides, is this a bad thing ?  i'd prefer to have devs settle crap
> > themselves than ever contacting devrel :P
>
> It's very relevant, because it supports the idea of QA taking care of
> technical issues on its own. QA can work faster since it's less objected
> do and doesn't need endless committees and documentation -- the
> documentation is the broken code.

QA team does not care at all about inner workings of devrel

QA team identifies a misbehaving dev who refuses to change and then hands off 
the name/relevant data to devrel ... QA team then is pretty much done with 
the issue and the rest is up to devrel to resolve
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Donnie Berkholz]

Mike Frysinger wrote:
this side note is unrelated to the point being made and really belongs in the 
previous discussions on the devrel list


besides, is this a bad thing ?  i'd prefer to have devs settle crap themselves 
than ever contacting devrel :P


It's very relevant, because it supports the idea of QA taking care of 
technical issues on its own. QA can work faster since it's less objected 
do and doesn't need endless committees and documentation -- the 
documentation is the broken code.


Thanks,
Donnie
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Mike Frysinger]

On Tuesday 13 September 2005 02:04 pm, Donnie Berkholz wrote:
> Mike Frysinger wrote:
> > - in the case of developers who do not wish to follow accepted
> > policies/guidelines/etc even after being enlightened, devrel is notified
> > and takes appropriate corrective action
>
> - in the case of a need to take appropriate corrective action, devrel
> gets tied up in investigative and judgment subcommittees that take so
> long to get anything done, by the time they finally manage to agree on
> it (twice), the issue has already been resolved.

this side note is unrelated to the point being made and really belongs in the 
previous discussions on the devrel list

besides, is this a bad thing ?  i'd prefer to have devs settle crap themselves 
than ever contacting devrel :P
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] maintainer-wanted ebuilds which are tagged REVIEWED

[Ciaran McCreesh]

On Tue, 13 Sep 2005 15:50:50 -0400 Chris Gianelloni
<[EMAIL PROTECTED]> wrote:
| On Tue, 2005-09-13 at 20:08 +0100, Ciaran McCreesh wrote:
| > * Keywords field changes
| 
| Wouldn't you *want* to see these?

Mmm, I suppose maybe someone might try to sneak a REVIEWED add past us.
I've switched the other three off but left keyword changes on.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgp8ds9YgQvdn.pgp
Description: PGP signature

Re: [gentoo-dev] maintainer-wanted ebuilds which are tagged REVIEWED

[Chris Gianelloni]

On Tue, 2005-09-13 at 20:08 +0100, Ciaran McCreesh wrote:
> * Keywords field changes

Wouldn't you *want* to see these?

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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] maintainer-wanted ebuilds which are tagged REVIEWED

[Chris Gianelloni]

On Tue, 2005-09-13 at 19:53 +0100, Ciaran McCreesh wrote:
> Okay, I've gone through and added in approximate categories to the
> subjects where possible. A few I'm really not sure about, if anyone
> wants to tinker feel free.

Excellent!

This is definitely appreciated.  Thanks.

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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] maintainer-wanted ebuilds which are tagged REVIEWED

[Chris Gianelloni]

On Tue, 2005-09-13 at 19:31 +0100, Ciaran McCreesh wrote:
> On Tue, 13 Sep 2005 10:52:33 -0400 Chris Gianelloni
> <[EMAIL PROTECTED]> wrote:
> | > Uhm, if the ebuild submitter does not choose a category, then we'd
> | > have to change the subject ourselves (and sometimes I'm not even
> | > remotely sure into which category would the particular ebuild fit).
> | 
> | Try asking the submitter? *grin*
> 
> Yeah, I reckon we could stick a rough category in the title before we
> tag stuff as REVIEWED. Sometimes it might end up as games-?/whatever
> rather than a full category though.

That would be fine.  In fact, it would be fine if it were just
*somewhere* in the bug report, except for the automated message you're
going to be sending out would be much more useful if it were in the
summary, even if it is just a rough idea.  Remember that not
*everything* will need the summary there right away, since not every
request for clarification will be immediately answered, but increasing
the likelihood of the category being there increases the likelihood of
the package being picked up.

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


signature.asc
Description: This is a digitally signed message part

Re[2]: [gentoo-dev] maintainer-wanted ebuilds which are tagged REVIEWED

[Jakub Moc]

13.9.2005, 21:08:43, Ciaran McCreesh wrote:

> On Tue, 13 Sep 2005 20:57:24 +0200 Jakub Moc <[EMAIL PROTECTED]> wrote:
> | Sure, I've already managed to delete all the bugspam this caused...
> | *g*

> Yeah, maintainer-wanted bug emails are a pain in the ass. How about we
> turn off email sending for:

> * I'm added to or removed from this capacity
> * Priority, status, severity, and/or milestone changes
> * Keywords field changes
> * CC field changes

> Anyone know the maintainer-wanted bugzilla password? :)

Not entirely sure about the keywords thing, other than that - kplznowtnx ;)
Someone who has the privs to do it?

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgp7GhHD4DVWf.pgp
Description: PGP signature

Re: [gentoo-dev] maintainer-wanted ebuilds which are tagged REVIEWED

[Ciaran McCreesh]

On Tue, 13 Sep 2005 20:57:24 +0200 Jakub Moc <[EMAIL PROTECTED]> wrote:
| Sure, I've already managed to delete all the bugspam this caused...
| *g*

Yeah, maintainer-wanted bug emails are a pain in the ass. How about we
turn off email sending for:

* I'm added to or removed from this capacity
* Priority, status, severity, and/or milestone changes
* Keywords field changes
* CC field changes

Anyone know the maintainer-wanted bugzilla password? :)

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgpJhRDMFZTS1.pgp
Description: PGP signature

Re[2]: [gentoo-dev] maintainer-wanted ebuilds which are tagged REVIEWED

[Jakub Moc]

13.9.2005, 20:31:30, Ciaran McCreesh wrote:

> On Tue, 13 Sep 2005 10:52:33 -0400 Chris Gianelloni
> <[EMAIL PROTECTED]> wrote:
| >> Uhm, if the ebuild submitter does not choose a category, then we'd
| >> have to change the subject ourselves (and sometimes I'm not even
| >> remotely sure into which category would the particular ebuild fit).
> | 
> | Try asking the submitter? *grin*

> Yeah, I reckon we could stick a rough category in the title before we
> tag stuff as REVIEWED. Sometimes it might end up as games-?/whatever
> rather than a full category though.

> Jakub -- this okay with you?

Sure, I've already managed to delete all the bugspam this caused... *g*

But yeah, it's good for some rough orientation, at least blah-?/ebuild if
unsure.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgpVH6QNbkLgR.pgp
Description: PGP signature

Re: [gentoo-dev] maintainer-wanted ebuilds which are tagged REVIEWED

[Ciaran McCreesh]

On Tue, 13 Sep 2005 07:39:10 -0400 Chris Gianelloni
<[EMAIL PROTECTED]> wrote:
| I know that this is automatically generated, but can we either change
| the bug subjects or figure out some way to add proposed categories to
| these?  I think changing the summary should suffice.  For the ones
| with categories, I can pretty much figure out what they are.  For the
| ones without, I have no clue and have to look at the bug to determine
| if I would even be interested in it.

Okay, I've gone through and added in approximate categories to the
subjects where possible. A few I'm really not sure about, if anyone
wants to tinker feel free.

This is a summary of maintainer-wanted packages which are tagged as
REVIEWED.  Please take a few moments to glance over this list and see
if there are any packages which your herd would like.

The REVIEWED tag is used for ebuilds which have been checked for basic
syntax and style issues. It does NOT mean that the ebuild actually works
(although it might), merely that you probably won't have to spend too
long fixing basic stuff.

This list is automagically generated. It will be sent to the gentoo-dev
mailing list at irregular intervals until someone asks me to stop.

 42572: kde-misc/kxdocker ebuild - 
 74713: app-text/pdx-1.6.1 (new package)
 81172: media-?/mp3report (new package)
 81622: app-misc/fileschanged-0.6.1 (new package)
 81641: app-misc/cfilesplit-0.2 (new package)
 93711: media-?/avi2mpeg-1.0 (new package)
 96793: media-gfx/gimp-stitch-0.9.6 (New Package)
 99009: media-sound/cowbell (new package)
 99248: kde-?/kps-0.2.ebuild (New Package)
 9: sci-?/faumachine-20050720.ebuild (new package)
100043: app-admin/DenyHosts-0.9.0.ebuild (New Package)
100108: net-misc/yacy-0.39.20050722.425 (New Package)
101523: New ebuild: sys-apps/rrdcollect
101541: x11-plugins/gkfreq - gkrellm plugin (new ebuild).
101751: games-misc/gbo-1.0.ebuild (New Package)
102187: app-text/unicode-0.4.7.ebuild (New Package)
102323: sci-geosciences/gerris-0.6.0.ebuild (new package)
102449: app-misc/megatunix-0.7.9.ebuild (New Package)
102928: ebuild for media-sound/lltag
102931: Ebuild for media-gfx/llgal
102996: net-libs/gloox-0.6 (new package)
104011: net-misc/ncp (new package)
104018: net-ftp/cmdftp (new package)
104024: net-misc/nat-traverse (new package)
104027: app-crypt/tthsum (new package)
104032: dev-lang/srf (new package)
104219: app-office/jgnash-1.9.2.ebuild (New Package)
104628: media-?/japa ebuild
105137: net-libs/libntlm-0.3.7.ebuild (New Package)
105227: net-zope/Kupu 1.3 (new ebuild)
105253: dev-db/pxlib
105438: earth3d-1.0.3.ebuild (New Package)
105482: sci-?/basemap-0.6.2 (new ebuild)
105671: media-?/mpck-0.10.ebuild (New Package)

This is a total of 34 bugs.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgp5afbvZyuUx.pgp
Description: PGP signature

Re: [gentoo-dev] maintainer-wanted ebuilds which are tagged REVIEWED

[Ciaran McCreesh]

On Tue, 13 Sep 2005 10:52:33 -0400 Chris Gianelloni
<[EMAIL PROTECTED]> wrote:
| > Uhm, if the ebuild submitter does not choose a category, then we'd
| > have to change the subject ourselves (and sometimes I'm not even
| > remotely sure into which category would the particular ebuild fit).
| 
| Try asking the submitter? *grin*

Yeah, I reckon we could stick a rough category in the title before we
tag stuff as REVIEWED. Sometimes it might end up as games-?/whatever
rather than a full category though.

Jakub -- this okay with you?

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgpgkKkGabmI4.pgp
Description: PGP signature

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Donnie Berkholz]

Mike Frysinger wrote:
- in the case of developers who do not wish to follow accepted 
policies/guidelines/etc even after being enlightened, devrel is notified and 
takes appropriate corrective action


- in the case of a need to take appropriate corrective action, devrel 
gets tied up in investigative and judgment subcommittees that take so 
long to get anything done, by the time they finally manage to agree on 
it (twice), the issue has already been resolved.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Mike Frysinger]

On Tuesday 13 September 2005 01:50 pm, Brian Harring wrote:
> On Tue, Sep 13, 2005 at 11:51:18AM -0500, Grant Goodyear wrote:
> > Grant Goodyear wrote: [Tue Sep 13 2005, 11:40:43AM CDT]
> >
> > > I'm not sure that's entirely correct.  I seem to remember at least one
> > > devrel dev stating that when it comes to devs who violate technical
> > > policies (not using repoman, repeatedly breaking sections of the tree,
> > > etcetera) that enforcement should be left up to the appropriate
> > > managers, not devrel.  The argument was that devrel devs are often not
> > > experts in the technical aspects, so it's hard for them to adjudicate
> > > effectively.
> >
> > I should also mention that I'm not advocating this interpretation.  I'd
> > much prefer that devrel's scope encompass such technical issues.
>
> I'd prefer the QA project/herd handle this.

the QA team tracks when something goes wrong and makes sure that people are 
educated on what they did wrong ... so in that aspect they are enforcing 
policy by telling the dev to stop screwing up

> They deal in hauling in devs, dealing with idiot
> devs, and chucking awol devs; I really don't see how QA falls under
> them beyond potentially the punitive aspect of QA having someone's cvs
> turned off for continually screwing up (willingly or otherwise).

devrel is introduced as a last resort if the dev ignores the QA team
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Mike Frysinger]

On Tuesday 13 September 2005 01:09 pm, Ciaran McCreesh wrote:
> On Tue, 13 Sep 2005 12:22:32 -0400 Jon Portnoy <[EMAIL PROTECTED]> wrote:
> | On Tue, Sep 13, 2005 at 07:33:59AM -0500, Lance Albertson wrote:
> | > The actual powers/role of devrel has always been a grey area.
> |
> | No it hasn't, unless by 'gray area' you mean 'a few people who don't
> | like devrel claim it shouldn't be able to do anything because
> | drobbins set it up'
> |
> | Recruitment, conflict resolution, disciplinary issues. I.e.,
> | 'managing developers.'
>
> * devrel doesn't do "broke the tree" enforcement, that's QA's job
> * devrel doesn't do "broke the tree" enforcement, that's the council's
> job
> * devrel doesn't do "broke the tree" enforcement, that's the
> management's job
> * devrel are the only people who do enforcement, and that they decide
> when they do it
> * devrel are the only people who do enforcement, and that they need to
> be told by QA when they need to do something
> * devrel are the only people who do enforcement, and that they need to
> be told by a manager when they need to do something

ive heard some of these ... personally i see it as:
- the council puts policies/guidelines/etc into effect based on developer 
community
- QA team uses these policies/guidelines/etc to validate Gentoo and makes 
other developers aware of their mistakes in a friendly manner
- in the case of developers who do not wish to follow accepted 
policies/guidelines/etc even after being enlightened, devrel is notified and 
takes appropriate corrective action

the idea of course is that policies/guidelines/etc dont come out of nowhere as 
they should be generally accepted before they are instituted
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Rob Cakebread]

Lance Albertson wrote:


Ah, I see.  To the best of my knowledge that just needs to be worked out
w/ the GLEP 15 people and infra.  I dropped into -infra and they said
that there's space for it, but that bug # 98282 lists a couple of
contentious points.  (Also, the gentooexperimental scripts "about" page
seems to suggest that their framework differs from the "official"
version.)




I did the temporary site on gentooexperimental. It'll happily die after
port001 and his crew finish the official one.


--
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] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Brian Harring]

On Tue, Sep 13, 2005 at 11:51:18AM -0500, Grant Goodyear wrote:
> Grant Goodyear wrote: [Tue Sep 13 2005, 11:40:43AM CDT]
> > I'm not sure that's entirely correct.  I seem to remember at least one
> > devrel dev stating that when it comes to devs who violate technical
> > policies (not using repoman, repeatedly breaking sections of the tree,
> > etcetera) that enforcement should be left up to the appropriate
> > managers, not devrel.  The argument was that devrel devs are often not
> > experts in the technical aspects, so it's hard for them to adjudicate
> > effectively.  
> 
> I should also mention that I'm not advocating this interpretation.  I'd
> much prefer that devrel's scope encompass such technical issues.

I'd prefer the QA project/herd handle this.

In my opinion, devrel should deal in developer pissing matches 
(preferably kicking both parties in the head for fighting), incoming 
devs, outgoing devs, and carrying out punitive measures.

QA involves a helluva lot more then just reacting when people complain 
that XYZ is screwing up the tree; proper QA involves actually 
identifying xyz is screwing up the tree rather then a reactive 
approach.

Essentially, QA requires people actively auditing the tree, deps, and 
nudging devs to stop screwing things up, preferably with advice on how 
to avoid screwing up.  This involves a good chunk of work, and for the 
work to actually go anywhere, there needs to be backing of some sort.

QA has never had true backing beyond (essentially) whining to devrel 
that xyz is breaking stuff.  It's not particularly surprising that 
they haven't been incredibly effective, considering that fact.

Yes, Mr_bones_ will rightfully tear your ass if you keep breaking 
things, but ultimately it's just nagging, if he wants anything done he 
has to present the case to devrel, who may or may not do something.

This setup I view as (bluntly) broke; devrel isn't tracking what's 
going on in the tree, Michael is, further he's tracking who screws 
up and who doesn't on a regular basis due to his scans.  He knows who 
has been naughty or nice, essentially :)

Dunno, my two cents.  Not much for QA being under the auspices of 
devrel for the reasons above, but also keeping things seperated, and 
avoiding more cabal bitching.

Not meaning this to be a slap in devrel's direction mind you; question 
of area of focus.  They deal in hauling in devs, dealing with idiot 
devs, and chucking awol devs; I really don't see how QA falls under 
them beyond potentially the punitive aspect of QA having someone's cvs 
turned off for continually screwing up (willingly or otherwise).
~harring


pgpl2yafzQUxY.pgp
Description: PGP signature

Re: [gentoo-dev] Zend Company Products

[Sebastian Bergmann]

Paweł Madej schrieb:
> Zend Studio
> Zend Studio Server
> Zend Optimizer

 The PHP Herd has the Zend products on their TODO [1].

 --
 [1] http://svn.gnqs.org/projects/gentoo-php-overlay/wiki/TodoList

-- 
Sebastian Bergmann  http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Ciaran McCreesh]

On Tue, 13 Sep 2005 12:22:32 -0400 Jon Portnoy <[EMAIL PROTECTED]> wrote:
| On Tue, Sep 13, 2005 at 07:33:59AM -0500, Lance Albertson wrote:
| > 
| > The actual powers/role of devrel has always been a grey area.
| 
| No it hasn't, unless by 'gray area' you mean 'a few people who don't 
| like devrel claim it shouldn't be able to do anything because
| drobbins set it up'
| 
| Recruitment, conflict resolution, disciplinary issues. I.e.,
| 'managing developers.'

Well, here's the thing... I've been told by various devrel members that:

* devrel doesn't do "broke the tree" enforcement, that's QA's job
* devrel doesn't do "broke the tree" enforcement, that's the council's
job
* devrel doesn't do "broke the tree" enforcement, that's the
management's job
* devrel are the only people who do enforcement, and that they decide
when they do it
* devrel are the only people who do enforcement, and that they need to
be told by QA when they need to do something
* devrel are the only people who do enforcement, and that they need to
be told by a manager when they need to do something

When you add in things that drobbins, the council and various managers
have said it becomes even more contradictory. So I'd say it's not a
very clear area at all...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgpabyVlaSXKM.pgp
Description: PGP signature

[gentoo-dev] Zend Company Products

[Paweł Madej]

Hello,

I'm PHP developer using commercial Zend Studio installed out of portage 
and I try to investigate if it is possible to get it to portage tree 
(i'll try to do an ebuild)


but my question if there is a need for that applications?

I mean
Zend Studio
Zend Studio Server
Zend Optimizer

More info about those apps: http://www.zend.com

If there will be an interest to do those ebuilds, please give me some 
links where I could find any info how to maintain ebuilds and general 
portage developement which you think i should read before getting to work.


Greets
Paul
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Grant Goodyear]

Grant Goodyear wrote: [Tue Sep 13 2005, 11:40:43AM CDT]
> I'm not sure that's entirely correct.  I seem to remember at least one
> devrel dev stating that when it comes to devs who violate technical
> policies (not using repoman, repeatedly breaking sections of the tree,
> etcetera) that enforcement should be left up to the appropriate
> managers, not devrel.  The argument was that devrel devs are often not
> experts in the technical aspects, so it's hard for them to adjudicate
> effectively.  

I should also mention that I'm not advocating this interpretation.  I'd
much prefer that devrel's scope encompass such technical issues.

-g2boojum-
-- 
Grant Goodyear  
Gentoo Developer
[EMAIL PROTECTED]
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76


pgpwoInQxQ6Mo.pgp
Description: PGP signature

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Grant Goodyear]

Jon Portnoy wrote: [Tue Sep 13 2005, 11:22:32AM CDT]
> > 
> > The actual powers/role of devrel has always been a grey area.
> 
> No it hasn't, unless by 'gray area' you mean 'a few people who don't 
> like devrel claim it shouldn't be able to do anything because drobbins 
> set it up'
> 
> Recruitment, conflict resolution, disciplinary issues. I.e., 'managing 
> developers.'

I'm not sure that's entirely correct.  I seem to remember at least one
devrel dev stating that when it comes to devs who violate technical
policies (not using repoman, repeatedly breaking sections of the tree,
etcetera) that enforcement should be left up to the appropriate
managers, not devrel.  The argument was that devrel devs are often not
experts in the technical aspects, so it's hard for them to adjudicate
effectively.  

Of course, I could be entirely mistaken, but I know that I'm not the
only person who has this impression.

-g2boojum-
-- 
Grant Goodyear  
Gentoo Developer
[EMAIL PROTECTED]
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76


pgpjgJI8L4tcI.pgp
Description: PGP signature

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Lance Albertson]

Jon Portnoy wrote:
> On Tue, Sep 13, 2005 at 07:33:59AM -0500, Lance Albertson wrote:
> 
>>The actual powers/role of devrel has always been a grey area.
> 
> 
> No it hasn't, unless by 'gray area' you mean 'a few people who don't 
> like devrel claim it shouldn't be able to do anything because drobbins 
> set it up'
> 
> Recruitment, conflict resolution, disciplinary issues. I.e., 'managing 
> developers.'

Right, thats what I'm saying. If the council says its approved and thats
what they do, they can't complain/bitch about it because drobbins set it
up unless they want the council to charge them to change it.

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Jon Portnoy]

On Tue, Sep 13, 2005 at 07:33:59AM -0500, Lance Albertson wrote:
> 
> The actual powers/role of devrel has always been a grey area.

No it hasn't, unless by 'gray area' you mean 'a few people who don't 
like devrel claim it shouldn't be able to do anything because drobbins 
set it up'

Recruitment, conflict resolution, disciplinary issues. I.e., 'managing 
developers.'

-- 
Jon Portnoy
avenj/irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff

[Ciaran McCreesh]

On Tue, 13 Sep 2005 00:39:31 -0500 Brian Harring <[EMAIL PROTECTED]>
wrote:
| Each has a role, don't blur the AT definition into ebuild devs unless 
| you've after eliminating AT positions (something I doubt going by
| your previous QA threads); if you're after that, state so please.

Not at all. I'd like it much more if every new potential tree developer
had to go through a phase of being an AT (or an equivalent role for
doing ebuild development). It's a great way to find out whether people
are *really* going to be good as a developer.

| Your metric frankly is rather vague.  Come up with one applicable to 
| AT's rather then vague terms impying AT's are not of the 'elite' 
| ebuild dev standard please.

Bah, it's not elitism. It's a matter of experience.

| IOW, nail down your metric, then apply it to the existing AT's (since 
| they are what we have to work with), and then re-raise your views
| that they "don't know what they're doing".

Uh, that isn't my view. My view is that if they aren't yet experienced
enough to have tree commit access then they're not yet experienced
enough to vote.

This is entirely separate from other developer roles. There's more than
one way to become an experienced developer, some of which don't involve
touching the tree.

| > An arch tester has not committed himself to the project for the same
| > length of time as a full developer.
| 
| This is mild BS, since it's a common issue to all classes of gentoo 
| volunteers.  Further, stats provided (as were requested) I'd posit
| are actually better then ebuild dev stats, although worth noting the 
| sampling period differs.

Try comparing it against the stats for the first month or two of every
ebuild dev.

| > Uhm... Different people have different skill levels. Some of this is
| > down to natural ability, some of it is down to experience. Arch
| > testers have not yet proven themselves. Full developers have (at
| > least in theory...).
| 
| Not much for the natural ability bit/elitist stuff; the question is 
| what they've demonstrated, the work done.  Doesn't matter if it 
| takes a person 20 hours, or 1, it's the end product people see, 
| and what ultimately matters (as you've pointed out in re: to QA).

There are times when being able to get something right *quickly* is
extremely important. Sometimes it makes no difference, sometimes it
does.

| Beyond that, I don't agreew with the "Arch testers haven't proven
| themselves". They wouldn't be marked as AT's by the arch if they
| hadn't demonstrated some form of worth, just the same as ebuild devs
| aren't recruited if they haven't shown some form of worth (this
| includes ability to stick around for more then a month).  Screwups
| happen, but the stats offered are a pretty good indication they've
| got that angle addressed imo.

The whole point of the AT role is that it's used as a kind of testing
ground for potential full developers. It's a way to get the benefit of
extra testers without having to commit to giving them tree access
straight away.

| Treating contributors as second class citizens (in terms of cvs ro 
| access and email) is a really great way to piss on people who are 
| doing a good chunk of work for gentoo.

Bah. By the same argument, why don't we give out @gentoo.org addresses
to anyone who ever files a bug report? Otherwise we're treating our
users as second class citizens!

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgpLCxlyyovsO.pgp
Description: PGP signature

Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff

[Ciaran McCreesh]

On Tue, 13 Sep 2005 13:21:22 +0200 Simon Stelling <[EMAIL PROTECTED]>
wrote:
| > Uhm... Different people have different skill levels. Some of this is
| > down to natural ability, some of it is down to experience. Arch
| > testers have not yet proven themselves. Full developers have (at
| > least in theory...).
| 
| Yes, in theory. Too bad reality doesn't match with theory far too
| often. I for example became dev after just submitting a few
| "app-foo/bar works on amd64" bugs and moaning because it took too
| long to get them fixed. Of course i knew portage, but I really can't
| say that I have proven myself to be useful to the project when I
| joined it. BUT, this was before the idea of an AT existed. Today,
| every user who wants to become a amd64 developer, has to become AT
| first, to prove himself, so the problem you're speaking of was fixed,
| not caused by ATs.

Which is exactly why I like the idea of ATs, and exactly why I'm
against giving them in effect 'full dev minus cvs write' powers. That
can wait until they reach full dev status.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgpNdgBxg9TT5.pgp
Description: PGP signature

Re: Re[2]: [gentoo-dev] maintainer-wanted ebuilds which are tagged REVIEWED

[Chris Gianelloni]

On Tue, 2005-09-13 at 14:08 +0200, Jakub Moc wrote:
> 13.9.2005, 13:39:10, Chris Gianelloni wrote:
> 
> 
> > I know that this is automatically generated, but can we either change
> > the bug subjects or figure out some way to add proposed categories to
> > these?  I think changing the summary should suffice.  For the ones with
> > categories, I can pretty much figure out what they are.  For the ones
> > without, I have no clue and have to look at the bug to determine if I
> > would even be interested in it.
> 
> Uhm, if the ebuild submitter does not choose a category, then we'd have to
> change the subject ourselves (and sometimes I'm not even remotely sure into
> which category would the particular ebuild fit).

Try asking the submitter? *grin*

Here's a good example.  If I submitted an ebuild for "nwn" what would
you think it might be?  What if I submitted it as "games-rpg/nwn"
instead?  Now, a category isn't *required* of there's a decent
description (such as the "gkrellm plugin" description shown as an
example).  The point being that nobody is going to be able to determine
what some of these packages are without some serious investigation, as
they tend to have cryptic names.

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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Bug 80905

[Frank Schafer]

On Tue, 2005-09-13 at 15:14 +0100, Daniel Drake wrote:
> Ivan Yosifov wrote:
> > On Tue, 2005-09-13 at 14:52 +0100, Daniel Drake wrote:
> > 
> >>are running vesafb-tng and have >=1GB RAM then try 
> >>turning off vesafb-tng 
> > 
> > 
> > Why ?
> > 
> 
> Actually, this shouldn't matter, as this only occurs with 64gb highmem. I 
> only 
> mentioned it as this is the only "random crasher" Gentoo kernel bug that 
> we've 
> had recently:
> 
> http://bugs.gentoo.org/show_bug.cgi?id=101359
> 
> Actually, there are also some upstream x86_64 issues. Frank, are you on amd64?
> 
> Daniel

I'm still on the kernel from the life-cd. The self compiled kernel has
the highmem option set to off (I have only 1GB). I'm on x86 Intel
Celeron M and have CHOST set to i686-pc-linux-gnu and CFLAGS="-O2
-march=pentium2"

I've unset nearly everything in USE to get a running minimal system (91
packages). Let's see first if X builds without any acceleration, DRI,
GLX and so on.

I'll let you know all and every of my results. Be patient, my time is
limited so I can't deliver a result every day.

Regards
Frank

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug 80905

[Patrick Lauer]

On Tue, 2005-09-13 at 17:01 +0300, Ivan Yosifov wrote:
> On Tue, 2005-09-13 at 14:52 +0100, Daniel Drake wrote:
> > are running vesafb-tng and have >=1GB RAM then try 
> > turning off vesafb-tng 
> 
> Why ?
Because of known bugs I'd guess?
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Bug 80905

[Daniel Drake]

Ivan Yosifov wrote:

On Tue, 2005-09-13 at 14:52 +0100, Daniel Drake wrote:

are running vesafb-tng and have >=1GB RAM then try 
turning off vesafb-tng 



Why ?



Actually, this shouldn't matter, as this only occurs with 64gb highmem. I only 
mentioned it as this is the only "random crasher" Gentoo kernel bug that we've 
had recently:


http://bugs.gentoo.org/show_bug.cgi?id=101359

Actually, there are also some upstream x86_64 issues. Frank, are you on amd64?

Daniel
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug 80905

[Ivan Yosifov]

On Tue, 2005-09-13 at 14:52 +0100, Daniel Drake wrote:
> are running vesafb-tng and have >=1GB RAM then try 
> turning off vesafb-tng 

Why ?

-- 
Cheers,
Ivan Yosifov.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug 80905

[Daniel Drake]

Frank Schafer wrote:

Does someone know if it's worth a try with the vanilla and if vanilla
here means a really vanilla from kernel.org or if it's sufficient to get
the (too patched and thus not so vanilla) vanilla-sources.


vanilla-sources is not patched.


Please be kind with me regarding to the fact that I'm posting here. On
the gentoo mailing list I get only replies like: "You probably have
faulty memory." If THIS would be the fact the bug would show up randomly
in different ebuilds or at least at different lines of code.


Faulty hardware can cause all kinds of unexplainable behaviour. Don't base 
your judgement on this.


One final point, if you are running vesafb-tng and have >=1GB RAM then try 
turning off vesafb-tng for now.


Daniel
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff

[Wernfried Haas]

On Tue, Sep 13, 2005 at 08:08:41AM -0500, Mike Doty wrote:
> No, you're confusing the different definitions of developers.  In the
> gentoo sense of everyone is a developer(ebuild, infra, devrel, even
> forums), then yes, you would have to consider the AT as a "developer."
Uuuuh, watch your language. This was a hot topic before ;-)

> Due to the fact that it hasn't been official, providing them with the
> tools to get their job done has been a challenge.  I don't think it's
> right to ask for read-only CVS without them being official for example.
Makes sense. They need official tools to do official work, so make
them official.

> While most developers have accepted them and use them, there are still
> those that look down on them.  What can I say, other than a distro like
> gentoo inherently breeds a certain level of 31337ism, however misplaced
> or inappropriate it is.
At least the fact that some people cry out loud as soon someone talks
about people who don't mess up ebuilds as developers is a bit strange.

> So, the choice for an AT to not pursue becoming a ebuild/arch dev is
> theirs to make, with a wide variety of reasons.  It's not that they lack
> in any one skill that would otherwise make them a developer.
They may know even more than people commited to doing infra, devrel or
forums work who are full members as well. Gentoo is more than a bunch
of developers and there are also a lot of folks filling different
positions (e.g. developer and infra).
In fact current ATs are already doing the ebuild quiz, which is
"harder" than the staff quiz others do. They do important work even
though it's not _that_ 13117 as writing ebuilds. I really don't see a
reason why they should not get full staff priviledges.
After all Gentoo is the result of our united efforts. We need people
writing code as well as docs team, infra, forums, devrel, AT and all 
the other folks i forgot now.

cheers,
Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug 80905

[Brian Harring]

On Tue, Sep 13, 2005 at 03:24:38PM +0200, Frank Schafer wrote:
> Hello,
> 
> this bug is from 2005-02-05. It was reported again (in this thread)
> 2005-02-10. I hit the same behavior 2005-09-08.
> 
> internal compiler error: segmentation fault during emerge Xorg
> 
> The bug is simply reproducible (emerge Xorg) at the same line of code.
> 
> The bug is still marked as NEW. Donnie Berkholz replied 2005-02-10 with:
> "Could you humor me and try with a vanilla kernel?"
> 
> My questions here: Does someone have a look at this? I think a not
> installable Xorg is severe enough to mark it as CRITICAL.
> 
> Does someone know if it's worth a try with the vanilla and if vanilla
> here means a really vanilla from kernel.org or if it's sufficient to get
> the (too patched and thus not so vanilla) vanilla-sources.
> 
> Please be kind with me regarding to the fact that I'm posting here. On
> the gentoo mailing list I get only replies like: "You probably have
> faulty memory." If THIS would be the fact the bug would show up randomly
> in different ebuilds or at least at different lines of code.

Granted Donnie is a miserable so and so, but his advice is 
accurate.

To get an ICE (what you're getting) requires either
1) faulty hardware.  proc going nuts, mem going nuts
2) faulty kernel
3) faulty toolchain

Reproducability of a failure across reboots kind of indicates 1 as not 
being the case, leaving 2, and 3.

ICE's are pretty much *never* the fault of the source; the source may 
expose a toolchain bug, but it's not the sources fault.  

You don't blame an email for crashing your email client, you blame your 
email client for horking up and segfaulting, instead of gracefully 
failing in the face of potentially wrong input.

Note I'm not stating the source is the fault here, just trying to 
clarify that ICE's pretty much are indicative of 
hardware/kernel/toolchain being nuts, not the source that's being 
compiled.

So... try his suggestion.  Yes it's annoying, but frankly addressing 
your issues here pretty much requires poking at the options above, 
seeing if one of them makes compilation stop ICE'ing.  If it does, 
then you back track and figure out what changed... etc.
~harring


pgpyVFvvjd4As.pgp
Description: PGP signature

[gentoo-dev] Bug 80905

[Frank Schafer]

Hello,

this bug is from 2005-02-05. It was reported again (in this thread)
2005-02-10. I hit the same behavior 2005-09-08.

internal compiler error: segmentation fault during emerge Xorg

The bug is simply reproducible (emerge Xorg) at the same line of code.

The bug is still marked as NEW. Donnie Berkholz replied 2005-02-10 with:
"Could you humor me and try with a vanilla kernel?"

My questions here: Does someone have a look at this? I think a not
installable Xorg is severe enough to mark it as CRITICAL.

Does someone know if it's worth a try with the vanilla and if vanilla
here means a really vanilla from kernel.org or if it's sufficient to get
the (too patched and thus not so vanilla) vanilla-sources.

Please be kind with me regarding to the fact that I'm posting here. On
the gentoo mailing list I get only replies like: "You probably have
faulty memory." If THIS would be the fact the bug would show up randomly
in different ebuilds or at least at different lines of code.

Thanks in advance for every hint
Frank

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff

[Mike Doty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Luca Barbato wrote:
| Simon Stelling wrote:
|
|> Ciaran McCreesh wrote:
|>
|>> On Mon, 12 Sep 2005 22:51:38 -0500 Brian Harring <[EMAIL PROTECTED]>
|>> wrote:
|>> | define exactly how one proves themself, and in what context.
|>>
|>> Repeated good contributions.
|>
|>
|>
|> Just to clarify: We're not going around giving everybody AT-status who
|> just asked for it. Normally, we note certain users filing many bugs
|> (=useful contributions) and then we're going toward them to ask them
|> whether they want to become ATs. Also, they have to pass the current
|> dev quizzes before they become ATs, so the required knowledge *is* there.
|>
|> So, basically, ATs already HAVE proven themselves to be useful.
|>
|
| Basically you are saying that they have the skill to be developers, they
| prove them, but they don't have enough time to become full developers?
|
| lu
No, you're confusing the different definitions of developers.  In the
gentoo sense of everyone is a developer(ebuild, infra, devrel, even
forums), then yes, you would have to consider the AT as a "developer."
If you take a more classical view, or at least acknowledge the fact that
everyone has the term "developer" in their title and discount this fact,
then no, they are no more "developers" than infra or docs or devrel.

When I started this project, I had in mind that all ATs would eventually
become devs, but it's never been a requirement.  Being an AT has many
advantages over being a dev in some peoples eyes.

Pros:
As it's not official, you don't need to go through devrel(which at the
time of inception was very slow)

You are sheltered from a lot of the political bullshit that "developers"
have to deal with.

The commitment isn't nearly as large in terms of time.  We mostly
recruit ATs from those active on IRC.  They already spend the time
testing and filing bugs, helping user, and so on.  It doesn't require a
great change in time to move from helpful user to AT.

It's a great training and recruiting tool.  A number of ATs have stated
that they don't feel they have the skills to be a developer.  This is a
statement that I would dispute in a number of cases.  However, after
being an active AT, you can't help but to learn how things work.  ATs
are encouraged to submit patches and solve problems.  The transition
from AT to dev is much less painful then if it was skipped.  ATs come
out of the program as knowledgeable people with a focus on testing.
Gentoo /needs/ more of these people.

And, most importantly, they get the feeling of satisfaction that comes
with learning and the knowledge that they have contributed.

Cons:
Due to the fact that it hasn't been official, providing them with the
tools to get their job done has been a challenge.  I don't think it's
right to ask for read-only CVS without them being official for example.

While most developers have accepted them and use them, there are still
those that look down on them.  What can I say, other than a distro like
gentoo inherently breeds a certain level of 31337ism, however misplaced
or inappropriate it is.

So, the choice for an AT to not pursue becoming a ebuild/arch dev is
theirs to make, with a wide variety of reasons.  It's not that they lack
in any one skill that would otherwise make them a developer.

Off topic, AMD64 requires that all new potential devs work as an AT for
the reasons stated above.  When they do make dev, they "hit the ground
running," and we don't need to invest anywhere near as much time as we
would without the program, nor are there any misconceptions about how we
operate.

- --
===
Mike Doty   [EMAIL PROTECTED]
Gentoo/AMD64 Strategic Lead PGP Key: 0xA797C7A7
Gentoo Developer Relations
~ ===GPG Fingerprint===
~   0094 7F06 913E 78D6 F1BB  06BA D0AD D125 A797 C7A7
===
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDJs9Z0K3RJaeXx6cRAj/XAKDJXKTeb4DsELKqC+EoOeLny1uRtQCfYx11
9a1/mby281fO6/0E6iTQAu0=
=/S6n
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Lance Albertson]

Thierry Carrez wrote:
> Nathan L. Adams wrote:
> 
>>Mike Frysinger wrote:
>>
>>
right ... once a GLEP has been hammered out and approved, there isnt really 
anything left for managers/council to do ... it's then up to whoever to get 
it done ;)
>>
>>They *could* do some 'creative re-org' a.k.a. remove some folks from
>>their current roles if they are willfully breaking the rules...
> 
> 
> This is the role of devrel enforcement arm. The complaint /
> investigation / judgement / appeal process is already defined. The
> council enters the stage only at the appeals step to limit abuse of
> power situations (and of course to define what policy really is).
> 
> I for one am committed to help in enforcement of any policy that has
> been decided, but only in the limits of what we were elected for (we
> won't replace project leads or devrel).

The actual powers/role of devrel has always been a grey area. Perhaps it
is time that the Council formalize their position so people know exactly
what they can/can't do.

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


signature.asc
Description: OpenPGP digital signature

Re[2]: [gentoo-dev] maintainer-wanted ebuilds which are tagged REVIEWED

[Jakub Moc]

13.9.2005, 13:39:10, Chris Gianelloni wrote:


> I know that this is automatically generated, but can we either change
> the bug subjects or figure out some way to add proposed categories to
> these?  I think changing the summary should suffice.  For the ones with
> categories, I can pretty much figure out what they are.  For the ones
> without, I have no clue and have to look at the bug to determine if I
> would even be interested in it.

Uhm, if the ebuild submitter does not choose a category, then we'd have to
change the subject ourselves (and sometimes I'm not even remotely sure into
which category would the particular ebuild fit).

*shrug*

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

pgp0H6YHz6s0M.pgp
Description: PGP signature

Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff

[Luca Barbato]

Simon Stelling wrote:

Ciaran McCreesh wrote:


On Mon, 12 Sep 2005 22:51:38 -0500 Brian Harring <[EMAIL PROTECTED]>
wrote:
| define exactly how one proves themself, and in what context.

Repeated good contributions.



Just to clarify: We're not going around giving everybody AT-status who 
just asked for it. Normally, we note certain users filing many bugs 
(=useful contributions) and then we're going toward them to ask them 
whether they want to become ATs. Also, they have to pass the current dev 
quizzes before they become ATs, so the required knowledge *is* there.


So, basically, ATs already HAVE proven themselves to be useful.



Basically you are saying that they have the skill to be developers, they 
prove them, but they don't have enough time to become full developers?


lu
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] maintainer-wanted ebuilds which are tagged REVIEWED

[Chris Gianelloni]

On Tue, 2005-09-13 at 01:13 +0100, Ciaran McCreesh wrote:
> This list is automagically generated. It will be sent to the gentoo-dev
> mailing list at irregular intervals until someone asks me to stop.

I know that this is automatically generated, but can we either change
the bug subjects or figure out some way to add proposed categories to
these?  I think changing the summary should suffice.  For the ones with
categories, I can pretty much figure out what they are.  For the ones
without, I have no clue and have to look at the bug to determine if I
would even be interested in it.

>  74713: pdx-1.6.1 (new package)

Bad.

> 101541: gkfreq - gkrellm plugin (new ebuild).

Good (even without category)

> 102928: ebuild for media-sound/lltag

Good.  While I don't know what it is exactly, I at least have an idea
that it is sound-related.

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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff

[Simon Stelling]

Ciaran McCreesh wrote:

On Mon, 12 Sep 2005 22:51:38 -0500 Brian Harring <[EMAIL PROTECTED]>
wrote:
| define exactly how one proves themself, and in what context.

Repeated good contributions.


Just to clarify: We're not going around giving everybody AT-status who just 
asked for it. Normally, we note certain users filing many bugs (=useful 
contributions) and then we're going toward them to ask them whether they want to 
become ATs. Also, they have to pass the current dev quizzes before they become 
ATs, so the required knowledge *is* there.


So, basically, ATs already HAVE proven themselves to be useful.

--
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff

[Simon Stelling]

Homer Parker wrote:

On Tue, 2005-09-13 at 04:14 +0100, Ciaran McCreesh wrote:


| voting previleges

Again, why? They have not yet demonstrated their understanding of
complex technical issues. Voting should be restricted to people who
know what they're doing. Arch testers have not yet proven themselves.



I don't remember that being asked for...


As the GLEP asks to make the ATs staff, it'd imply giving them voting 
privileges.

--
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff

[Simon Stelling]

Ciaran McCreesh wrote:

| voting previleges

Again, why? They have not yet demonstrated their understanding of
complex technical issues. Voting should be restricted to people who
know what they're doing. Arch testers have not yet proven themselves.


Does that mean that all the Gentoo people who didn't take the ebuild quiz (which 
doesn't proove the understanding of complex technical issues very good anyway 
IMHO, but that's another issue) should not be allowed to vote?



| > Assuming by "arch dev" you mean "arch tester", then:
| >
| > Experience, commitment and (at least in theory) recruitment
| > standards.
| 
| Commitment first:

| IMNSHO, it is rude to assume that an Arch Tester is less commited to
| their work than an Arch Team member.  All developers should be doing
| their part and should hopefully ( we don't live in an ideal world here
| after all ) be commited to doing their work well.  A lack of
| commitment that results in shoddy work should get them removed from
| any developer role, Arch Team member or otherwise.

An arch tester has not committed himself to the project for the same
length of time as a full developer.


That's not true. The whole point is that our current ATs *don't want* to be 
developers but are willing to help us and are a great help to keep the tree up 
to date, and we think it's unfair to honor a dev who doesn't much but sending 
emails with a nice signature but treating the ATs as users where they do far 
more than said dev.



Uhm... Different people have different skill levels. Some of this is
down to natural ability, some of it is down to experience. Arch testers
have not yet proven themselves. Full developers have (at least in
theory...).


Yes, in theory. Too bad reality doesn't match with theory far too often. I for 
example became dev after just submitting a few "app-foo/bar works on amd64" bugs 
and moaning because it took too long to get them fixed. Of course i knew 
portage, but I really can't say that I have proven myself to be useful to the 
project when I joined it. BUT, this was before the idea of an AT existed. Today, 
every user who wants to become a amd64 developer, has to become AT first, to 
prove himself, so the problem you're speaking of was fixed, not caused by ATs.


Regards,
--
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] cjk-latex-4.6 ??

[Stuart Longland]

Yuan MEI wrote:
> Alec Warner <[EMAIL PROTECTED]> writes:
> 
> 
>>Yuan MEI wrote:
>>
>>>I noticed that cjk-latex-4.6(http://cjk.ffii.org/) has been out for a
>>>long, but no ebuild is in the portage.  So, who'd like to handle this?
>>
>>Usually you will want to check bugs.gentoo.org before querying on this
>>list. -> http://bugs.gentoo.org/show_bug.cgi?id=103309
> 
> 
> Sorry, but I cannot treat this as a `bug'.  Anyway, now, I know :-)

Hey, I don't exactly consider myself a bug either... but I'm in there.
(and so are a lot of others... just go poking around the devrel bugs) ;-)

Just about anything and everything is considered a bug here -- be it an
enhancement (such as a new ebuild or Developer) or a defect.
-- 
    _ Stuart Longland (a.k.a Redhatter)
/  _ \   ______  __| |__  __   __ Gentoo Linux/MIPS Cobalt and Docs
- (_) \ /   \  ;   \(__   __)/  \ /  \Developer
 \//  O _| / /\ \  | |  | /\ | /\ |
 /   / \   /__| /  \ \ | |  | \/ | \/ |
(___/   \/|_;  |_| \_/   \__/ \__/ http://dev.gentoo.org/~redhatter


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

[Thierry Carrez]

Nathan L. Adams wrote:
> Mike Frysinger wrote:
> 
>>>right ... once a GLEP has been hammered out and approved, there isnt really 
>>>anything left for managers/council to do ... it's then up to whoever to get 
>>>it done ;)
> 
> They *could* do some 'creative re-org' a.k.a. remove some folks from
> their current roles if they are willfully breaking the rules...

This is the role of devrel enforcement arm. The complaint /
investigation / judgement / appeal process is already defined. The
council enters the stage only at the appeals step to limit abuse of
power situations (and of course to define what policy really is).

I for one am committed to help in enforcement of any policy that has
been decided, but only in the limits of what we were elected for (we
won't replace project leads or devrel).

-- 
Koon
-- 
gentoo-dev@gentoo.org mailing list