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

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

[Thierry Carrez]

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

Hello everyone,

You haven't heard much from the council members, we were busy trying to
find the best date for the first meeting...

The first Gentoo Council meeting will be held Thursday, September 15th,
at 1900 UTC.

The deadline for agenda item submission is set to tomorrow, Tuesday,
September 13th, 1900 UTC. To submit an item, you can reply here or send
an email to council@gentoo.org.

So far the following items have been put to the agenda :

Added by Grant Goodyear :
glep40: Standardizing "arch" keywording across all archs

Added by Brian Harring :
glep33: Eclass Restructure/Redesign
glep37: Virtuals Deprecation

-- 
Thierry Carrez (Koon)
Gentoo Council Member

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

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

[Donnie Berkholz]

Thierry Carrez wrote:
> The first Gentoo Council meeting will be held Thursday, September 15th,
> at 1900 UTC.

And the place?

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

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

[Ciaran McCreesh]

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

On Mon, 12 Sep 2005 21:04:10 +0200 Thierry Carrez <koon@gentoo.org>
wrote:
| The deadline for agenda item submission is set to tomorrow, Tuesday,
| September 13th, 1900 UTC. To submit an item, you can reply here or
| send an email to council@gentoo.org.

Could we get GLEP 31 (Character Sets for Portage Tree Items) added? The
only issue holding it back is that a few developers have stated
outright that they refuse to comply with it, and I don't see it as fair
to make other developers suffer nasty repoman errors because of things
a select few will end up breaking...

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


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

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

[Grant Goodyear]

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

Thierry Carrez wrote: [Mon Sep 12 2005, 02:04:10PM CDT]
> The first Gentoo Council meeting will be held Thursday, September 15th,
> at 1900 UTC.
> 
> The deadline for agenda item submission is set to tomorrow, Tuesday,
> September 13th, 1900 UTC. To submit an item, you can reply here or send
> an email to council@gentoo.org.

Yikes, that's short notice.  Of course, almost by definition the first
meeting had to have a fairly limited amount of lead time. *Shrug*  Any
chance of getting a schedule for the next couple of meetings or so?
(Actually, I'd be quite happy if the date of the next meeting could be
posted by the previous meeting, since that would generally correspond to
about a month lead.)

> Added by Grant Goodyear :
> glep40: Standardizing "arch" keywording across all archs

Please feel free to argue this GLEP in my absence.  I'm fully aware that
the council members understand the ramifications of this GLEP
substantially better than I do.

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

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

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

[Patrick Lauer]

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

On Mon, 2005-09-12 at 21:04 +0200, Thierry Carrez wrote:
> Added by Grant Goodyear :
> glep40: Standardizing "arch" keywording across all archs
> 
> Added by Brian Harring :
> glep33: Eclass Restructure/Redesign
> glep37: Virtuals Deprecation
> 
I'd like to see the following items added:
glep 15: script repository (working prototype has existed for some time)

QA: Preventing tree breakage and improving quality
GLEP31 (The UTF-8 Glep) would be dependant on a QA team that can
actually fix things and should be resurrected from its frozen state.


Patrick


-- 
Stand still, and let the rest of the universe move

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

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

[Thierry Carrez]

Grant Goodyear wrote:

> Yikes, that's short notice.  Of course, almost by definition the first
> meeting had to have a fairly limited amount of lead time. *Shrug*  Any
> chance of getting a schedule for the next couple of meetings or so?
> (Actually, I'd be quite happy if the date of the next meeting could be
> posted by the previous meeting, since that would generally correspond to
> about a month lead.)

Since we have to organize a meeting every month, we can target the
middle of each month as a general guideline. We'll also avoid Sun Mon
Fri Sat which are bad days to get most people in.

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

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

[Aron Griffis]

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

Grant Goodyear wrote:	[Mon Sep 12 2005, 03:28:58PM EDT]
> Yikes, that's short notice.  

Sorry about that, the council is moving quickly on my account.  I'll
be out of email contact for the second two weeks of September, leaving
this Saturday, so we're trying to squeeze the meeting in before then.

It's not something that I do often... in fact, I've never been out of
email contact for 2 weeks solid since I started as a dev!  It just
happens to coincide with the first month of the council's existence.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

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

[Grant Goodyear]

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

Patrick Lauer wrote: [Mon Sep 12 2005, 03:08:53PM CDT]
> I'd like to see the following items added:
> glep 15: script repository (working prototype has existed for some time)

I'm not quite sure what you're adding.  GLEP 15 was approved quite some
time ago.  "All" that remains is to finish up the implementation.

> QA: Preventing tree breakage and improving quality
> GLEP31 (The UTF-8 Glep) would be dependant on a QA team that can
> actually fix things and should be resurrected from its frozen state.

Huh?  Why should Mr_Bones_ need to go around fixing broken encodings?
He just has to break the legs of the offending devs....

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

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

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

[Patrick Lauer]

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

On Mon, 2005-09-12 at 15:53 -0500, Grant Goodyear wrote:
> Patrick Lauer wrote: [Mon Sep 12 2005, 03:08:53PM CDT]
> > I'd like to see the following items added:
> > glep 15: script repository (working prototype has existed for some time)
> I'm not quite sure what you're adding.  GLEP 15 was approved quite some
> time ago.  "All" that remains is to finish up the implementation.
or rather move it from gentooexperimental.org to "official" gentoo infrastructure (?)

> > QA: Preventing tree breakage and improving quality
> > GLEP31 (The UTF-8 Glep) would be dependant on a QA team that can
> > actually fix things and should be resurrected from its frozen state.
> Huh?  Why should Mr_Bones_ need to go around fixing broken encodings?
> He just has to break the legs of the offending devs....
Would be better if
(1) it wasn't Mr_Bones alone and
(2) there was an agreed on policy so that (if needed) repeat offenders
can be sanctioned
(e.g. by flipping their commit bit)
that of course needs some backing from the general dev population and
devrel, also the policies should be properly defined so that noone can
weasel out by invoking "it's always been like this"

I hope I'm not alone in my quest for higher QA standards :-)

wkr,
Patrick

-- 
Stand still, and let the rest of the universe move

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

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

[Grant Goodyear]

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

Patrick Lauer wrote: [Mon Sep 12 2005, 04:29:45PM CDT]
> > I'm not quite sure what you're adding.  GLEP 15 was approved quite some
> > time ago.  "All" that remains is to finish up the implementation.
> or rather move it from gentooexperimental.org to "official" gentoo
> infrastructure (?)

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.)

> > Huh?  Why should Mr_Bones_ need to go around fixing broken encodings?
> > He just has to break the legs of the offending devs....
> Would be better if
> (1) it wasn't Mr_Bones alone and
> (2) there was an agreed on policy so that (if needed) repeat offenders
> can be sanctioned
> (e.g. by flipping their commit bit)
> that of course needs some backing from the general dev population and
> devrel, also the policies should be properly defined so that noone can
> weasel out by invoking "it's always been like this"

Oh, of course.  I just don't agree that all GLEPs that involve QA should be
put on hold until we improve QA, however.

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

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

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

[Jason Stubbs]

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

On Tuesday 13 September 2005 04:04, Thierry Carrez wrote:
> glep37: Virtuals Deprecation

Need to defer this one until next time. There's a couple of small changes 
that need to be made, but enough that it'll need to go through the wringer 
again.

-- 
Jason Stubbs

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

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

[Mike Frysinger]

On Monday 12 September 2005 06:00 pm, Grant Goodyear wrote:
> Patrick Lauer wrote: [Mon Sep 12 2005, 04:29:45PM CDT]
> > > I'm not quite sure what you're adding.  GLEP 15 was approved quite some
> > > time ago.  "All" that remains is to finish up the implementation.
> >
> > or rather move it from gentooexperimental.org to "official" gentoo
> > infrastructure (?)
>
> Ah, I see.  To the best of my knowledge that just needs to be worked out
> w/ the GLEP 15 people and infra.

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 ;)
-mike
-- 
gentoo-dev@gentoo.org mailing list

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

[Mike Frysinger]

On Monday 12 September 2005 03:25 pm, Ciaran McCreesh wrote:
> On Mon, 12 Sep 2005 21:04:10 +0200 Thierry Carrez <koon@gentoo.org>
> | The deadline for agenda item submission is set to tomorrow, Tuesday,
> | September 13th, 1900 UTC. To submit an item, you can reply here or
> | send an email to council@gentoo.org.
>
> Could we get GLEP 31 (Character Sets for Portage Tree Items) added? The
> only issue holding it back is that a few developers have stated
> outright that they refuse to comply with it, and I don't see it as fair
> to make other developers suffer nasty repoman errors because of things
> a select few will end up breaking...

it was approved once already, just retracted after that fact pending further 
developments in terms of application/developer support (editors not sucking 
so much for example) ... so does it really need to be approved again ?

i'd say the work that needs to be done is documentation on how to make it 
work ... for example, i use nano and know nothing of unicode, so i really 
have no clue how to verify my work and even if i could verify it, how to 
rectify a bum editor
-mike
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Mon, 12 Sep 2005 22:03:31 -0400 Mike Frysinger <vapier@gentoo.org>
wrote:
| > Could we get GLEP 31 (Character Sets for Portage Tree Items) added?
| > The only issue holding it back is that a few developers have stated
| > outright that they refuse to comply with it, and I don't see it as
| > fair to make other developers suffer nasty repoman errors because
| > of things a select few will end up breaking...
| 
| it was approved once already, just retracted after that fact pending
| further developments in terms of application/developer support
| (editors not sucking so much for example) ... so does it really need
| to be approved again ?

What I mean is... Is the council prepared to commit itself to helping
with enforcement of the GLEP? Adding repoman enforcement would be
trivial, but repoman is circumventable -- the GLEP is withdrawn because
several developers have said that they'll do just that anyway.

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


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

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

[Mike Frysinger]

On Monday 12 September 2005 10:13 pm, Ciaran McCreesh wrote:
> On Mon, 12 Sep 2005 22:03:31 -0400 Mike Frysinger <vapier@gentoo.org>
> | > Could we get GLEP 31 (Character Sets for Portage Tree Items) added?
> | > The only issue holding it back is that a few developers have stated
> | > outright that they refuse to comply with it, and I don't see it as
> | > fair to make other developers suffer nasty repoman errors because
> | > of things a select few will end up breaking...
> |
> | it was approved once already, just retracted after that fact pending
> | further developments in terms of application/developer support
> | (editors not sucking so much for example) ... so does it really need
> | to be approved again ?
>
> What I mean is... Is the council prepared to commit itself to helping
> with enforcement of the GLEP? Adding repoman enforcement would be
> trivial, but repoman is circumventable -- the GLEP is withdrawn because
> several developers have said that they'll do just that anyway.

personally i think this is qa / devrel's area of enforcement ...

once something has been approved by the managers/council, then it's pretty 
much policy in my mind ... it just needs to trickle down into the 
documentation and tools
-mike
-- 
gentoo-dev@gentoo.org mailing list

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

[Lance Albertson]

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

Grant Goodyear wrote:
> Patrick Lauer wrote: [Mon Sep 12 2005, 04:29:45PM CDT]
> 
>>>I'm not quite sure what you're adding.  GLEP 15 was approved quite some
>>>time ago.  "All" that remains is to finish up the implementation.
>>
>>or rather move it from gentooexperimental.org to "official" gentoo
>>infrastructure (?)
> 
> 
> 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.)

A correction, the bug# is 98272.

This is correct. Last I knew port001 was working on a python based
version of this. If this has changed, we need to know about. Also,
before people go developing a new site that may potentially become an
official site, I would like to require them to submit an implementation
plan to the infra team via a bug or some other method. I don't want to
end up supporting every framework out there just because its cool. If
you're using something other than what we're currently using, I would
like to see justification for using it beyond "its a call framework".

Anyways, we have the space open for it, just haven't heard from port001
in a while about it.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

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

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

[Nathan L. Adams]

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

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

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

iD8DBQFDJltI2QTTR4CNEQARAlYeAJ4sPX/5chqU+OQ+6mRR3ttcg2KVjwCfb4Ip
RPvewdjAs7v5EjyC9GeOZGY=
=J86n
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

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

[Lance Albertson]

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

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 <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

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

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

[Lance Albertson]

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

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 <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

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

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

[Grant Goodyear]

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

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
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

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

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

[Grant Goodyear]

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

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
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

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

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

[Ciaran McCreesh]

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

On Tue, 13 Sep 2005 12:22:32 -0400 Jon Portnoy <avenj@gentoo.org> 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


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

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

[Brian Harring]

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

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

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

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

[Mike Frysinger]

On Tuesday 13 September 2005 01:09 pm, Ciaran McCreesh wrote:
> On Tue, 13 Sep 2005 12:22:32 -0400 Jon Portnoy <avenj@gentoo.org> 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

[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

[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 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] 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 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

[Brian Harring]

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

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

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

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

[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

[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

[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]

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

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

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

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

[Lance Albertson]

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

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 <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

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

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

[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

[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: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

[Lance Albertson]

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

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 <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

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

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

[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

[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

[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

[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

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

[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

[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

[Thierry Carrez]

Mike Frysinger 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

+1

Let QA handle QA and devrel handle developer relations. If devrel
processes take too much time that's something that should be improved
inside devrel, not by splitting devrel role onto multiple projects.

Before debating if the QA team should have more power to enforce, let's
just have a proper QA project. Apparently not much devs want to do QA,
not sure telling them they will do QA+police will help in motivating them.

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

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

[Ciaran McCreesh]

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

On Wed, 14 Sep 2005 09:42:43 +0200 Thierry Carrez <koon@gentoo.org>
wrote:
| Before debating if the QA team should have more power to enforce,
| let's just have a proper QA project. Apparently not much devs want to
| do QA, not sure telling them they will do QA+police will help in
| motivating them.

Part of the problem with that is that people who *would* normally do QA
think it's pretty much futile right now anyway, since the worst
offenders just carry on breaking things no matter how often they're
asked to stop...

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


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

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

[Brian Harring]

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

On Wed, Sep 14, 2005 at 04:38:04PM +0100, Ciaran McCreesh wrote:
> On Wed, 14 Sep 2005 09:42:43 +0200 Thierry Carrez <koon@gentoo.org>
> wrote:
> | Before debating if the QA team should have more power to enforce,
> | let's just have a proper QA project. Apparently not much devs want to
> | do QA, not sure telling them they will do QA+police will help in
> | motivating them.
> 
> Part of the problem with that is that people who *would* normally do QA
> think it's pretty much futile right now anyway, since the worst
> offenders just carry on breaking things no matter how often they're
> asked to stop...

I'd agree; this is the reason I stopped auditing eclasses a year back.

We've had bugs where flat out invalid deps (DEPEND dependant on 
has_version calls) sat for 2 years, *despite* QA/portage devs laying 
it on thick that this is totally invalid.

That's not even getting into user complaints.

There are people doing QA, the problem historically has been getting 
people who don't care to fix their stuff.  That's a *really* quick way 
to burn out people doing QA; the fact that there is a problem, but 
they have no means beyond nagging to get the offender to fix their 
mess.  There's only so much nagging one can do before they say "screw 
it", and wander off to do something a bit more productive.

If QA actually had some power beyond a pissed off member complaining 
to devrel, I'd expect you would see those burnt out by past attempts 
starting again.  I'd be game for resuming auditing of eclasses, 
personally.
~harring

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

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

[Curtis Napier]

Jon Portnoy wrote:
> 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)
> 

It's not about devrel taking a long time. Please don't think that I was 
bashing devrel in any way, in fact I have great respect for the devrel 
members. I know what a thankless task they have taken on and the 
bullshit they have to put up with on an almost daily basis. Kudos to you.



We all know that devrel is a team of people that have a responsibility 
to investigate any claim of wrongdoing and ensure that both sides are 
able to make their case. Afterwards, the devrel team members have to 
discuss the evidence and reach a conclusion. All of this takes time no 
matter how streamlined the process is and in the meantime the offending 
dev is allowed to continue to pollute the tree unchecked.

If QA is able to "temporarily" fix the perceived problem by removing 
ONLY write access to the portage CVS tree until devrel is able to finish 
their process, overall quality will go up. Even if it is found that no 
QA violations were made in some cases, I would rather have a few devs 
"temporarily" lose their write priveledges until devrel can pass/fail 
them than let even one bad dev through.

Personally, I think any dev that is made a member of the QA team is made 
a member because the rest of the devs trust that the person knows enough 
about Gentoo and the way it works to actually spot quality issues. I 
would trust these QA devs with this "temporary" ability wholeheartedly 
because if any of them abuse it they will be caught and removed from the 
QA team and they all know it. Plus, I think the people who are currently 
(or used to be) members of QA are respected enough for their technical 
knowledge that no one should have a problem with this *unless* they are 
one of the devs whos quality levels are in question. (personality issues 
are a different subject and have nothing to do with this discussion - 
this is a 100% technical correctness issue)

I have seen numerous debates on this list and on -core where almost 
every dev agrees that *something* must be done to ensure that all of the 
QA mistakes in the past are not repeated. All of the proposed plans 
relied on peer-review or other means that would greatly increase the 
number of devs we would need to implement it. In this case we already 
have the QA team in place and simply giving them this one ability would 
go greatly towards solving the inherent problems in the system. No new 
devs required and no new teams to create. A perfect solution to an 
endless problem.

Gentoo can't afford to peer review every single line of code but this 
small thing would greatly help in catching the largest of the mistakes 
that are made.
-- 
gentoo-dev@gentoo.org mailing list

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

[Mike Frysinger]

On Wednesday 14 September 2005 07:45 pm, Curtis Napier wrote:
> Jon Portnoy wrote:
> > 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)
>
> It's not about devrel taking a long time. Please don't think that I was
> bashing devrel in any way, in fact I have great respect for the devrel
> members. I know what a thankless task they have taken on and the
> bullshit they have to put up with on an almost daily basis. Kudos to you.

his comment wasnt directed at you in any way, it was to try and get support 
for the new proposal floating on the devrel list atm
-mike
-- 
gentoo-dev@gentoo.org mailing list

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

[Curtis Napier]

Mike Frysinger wrote:
> his comment wasnt directed at you in any way, it was to try and get support 
> for the new proposal floating on the devrel list atm
> -mike

Oh good, I wasn't sure what he meant. Thanks for clearing that up spanky.

+1 for the new proposal floating on the devrel list atm. :-)
-- 
gentoo-dev@gentoo.org mailing list

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

[Nathan L. Adams]

Jon Portnoy wrote:
> 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)

It sounds to me like those 'more familiar with the internal structure
Gentoo' haven't done so well on this issue. Maybe a little *more* peanut
gallery would do some good. 8)

Seriously, don't knock an idea simply because it doesn't come from
somebody in your chosen circle, or because it comes from somebody you
don't like personally...

> 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

What about giving QA temporary revoke powers just like infra (Curtis
Napier's idea), traditionalist? Fixing devrel's resolutions policies and
Curtis' idea don't have to be mutually-exclusive.
-- 
gentoo-dev@gentoo.org mailing list

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

[Thierry Carrez]

Nathan L. Adams wrote:

> What about giving QA temporary revoke powers just like infra (Curtis
> Napier's idea), traditionalist? Fixing devrel's resolutions policies and
> Curtis' idea don't have to be mutually-exclusive.

The idea behind -infra temporary revoke power is to react to emergency
situations (as in "we must do something *now*"). Not sure a repeated QA
violation would fall into that "emergency" category.

The solution is rather to have a devrel liaison inside the QA team (or
the other way around). These are not closed groups. We do essentially
the same with infrastructure and security, we have liaisons and people
that are members of both groups, rather than saying security should have
 wheel to do security audits and "emergency security fixes". Works a lot
better that way.

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

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

[Jon Portnoy]

On Thu, Sep 15, 2005 at 09:42:19AM +0200, Thierry Carrez wrote:
> Nathan L. Adams wrote:
> 
> > What about giving QA temporary revoke powers just like infra (Curtis
> > Napier's idea), traditionalist? Fixing devrel's resolutions policies and
> > Curtis' idea don't have to be mutually-exclusive.
> 
> The idea behind -infra temporary revoke power is to react to emergency
> situations (as in "we must do something *now*"). Not sure a repeated QA
> violation would fall into that "emergency" category.
> 
> The solution is rather to have a devrel liaison inside the QA team (or
> the other way around). These are not closed groups.

Agreed.

We don't need a second devrel, rather we need to make sure QA isn't 
ignored by devrel

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