[gentoo-osx] Arch Testing Policy and Procedures

[gentoo-osx] Arch Testing Policy and Procedures

[Lina Pezzella]

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

Our apologies for the tardiness of this e-mail; we have been  
preoccupied with moving back to college this last week.

We have thrown together some draft documentation[1] regarding our  
expectations for ppc-macos arch testers. We have purposely neglected  
to include policy and procedures for dealing with stable keywords  
pending the current reevaluation of our decision to maintain them.  
For all interested, please review the document and tell us what you  
think. The faster we can all agree on policy and procedures, the  
faster we can get arch testers on board.

For those that missed the initial arch tester discussion, the hope is  
that having a dedicated group of arch testers will improve QA as well  
as free up developers to solve design and porting issues rather than  
keyword requests and package testing. It is also a great place for  
potential new developers to gain experience with the project.

More policy and procedure documentation to come.

- --Lina Pezzella && Hasan Khalil
Ebuild & Porting Co-Leads
Gentoo for OS X

[1] http://dev.gentoo.org/~gongloo/macos/doc/at-procedures.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFDGlv7NJ9STR9DbYERAqJ1AKCgQ73vaFfulp1tvXt3FhMOAckZvgCgqO9t
+xaXd/DKXUW0ZmJxomn8vYw=
=GZ6D
-----END PGP SIGNATURE-----
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] Arch Testing Policy and Procedures

[Grobian]

Although I like the arch testers (ATs) idea pretty much, I have some 
questions:

- Why have the 'low hanging fruit' bugs from before 2005 not been
   resolved till I run through them a few weeks ago?.  Most of them were
   small and had no USE flags.  I expect the devs that had no time to do
   this in the past won't have time to do it when an AT has run over it.
   In the end, the dev is responsible for the commit, not the AT, hence I
   would not be surprised if the dev does a (non USE flag extensive)
   compilation on his own machine before committing to CVS.  A trust
   relationship between dev and AT is neccessary too and needs to be
   built.
- Maybe AT's should be 'assigned' to one or two devs who are
   responsible for committing the AT's work.  This is a natural mentor
   relationship as well as QA wise, it is obvious who is going to punish
   you if your work is not correct ;)
- This proposal assumes ATs have time, which devs apparently have not.
   I agree that the AT work is simple, but boring.  Though I still like
   to know why it hasn't been done in the past.
- Assuming I'd have an AT or two assigned to me, I'd like to have the
   freedom to give them more flesh if they are hungry for it, i.e. dive
   into why something doesn't configure/build/compile/install and try to
   come up with a patch.  Maybe this is dev dependant, but I think for an
   AT it would be nice to know there is a road upstairs: if they're good,
   and do what they do very well, it would be nice if I wouldn't have to
   commit their work.  (in other words: promote such AT to a dev)  On the
   other hand, you still need the AT work to be done.

I think the draft is a good piece of work.  I'm almost eager to have 
one, like a PhD who gets an MSc assigned to him.  My experiences with 
some bug reporters who were also in IRC to fix bugs using direct 
feedback from them is very productive, however if I slam myself in the 
face and throw some cold water over my head I feel myself forced to look 
at the issue from a much more pessimistic point of view considering this 
team and the current 'productiveness'.

Currently, we only discuss the way 'up', but maybe the way 'down' should 
be in the picture too.  An AT should be considered to be 'active'. 
Where active means that such AT can do some useful work on a regular 
base.  (Note: this implicitly requires devs to be at least as active as 
the AT.)  If not, while there is work enough, such AT should be removed. 
  Might sound obvious, but if there are no hard rules for it, noone will 
get removed.

Ok, I better stop this lengthy email right here.  Considering the 
statistics, it's way to long to be entirely read by most people anyway 
;)  For those that skipped the middle part, a short recap:

Yes, nice idea, but I think we should look at the problem from inside 
this very team first.  I would consider the average participation level 
very unhealthy.  This team is also very opaque, it's almost impossible 
to know what someone is working on.


Lina Pezzella wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Our apologies for the tardiness of this e-mail; we have been preoccupied 
> with moving back to college this last week.
> 
> We have thrown together some draft documentation[1] regarding our 
> expectations for ppc-macos arch testers. We have purposely neglected to 
> include policy and procedures for dealing with stable keywords pending 
> the current reevaluation of our decision to maintain them. For all 
> interested, please review the document and tell us what you think. The 
> faster we can all agree on policy and procedures, the faster we can get 
> arch testers on board.
> 
> For those that missed the initial arch tester discussion, the hope is 
> that having a dedicated group of arch testers will improve QA as well as 
> free up developers to solve design and porting issues rather than 
> keyword requests and package testing. It is also a great place for 
> potential new developers to gain experience with the project.
> 
> More policy and procedure documentation to come.
> 
> - --Lina Pezzella && Hasan Khalil
> Ebuild & Porting Co-Leads
> Gentoo for OS X
> 
> [1] http://dev.gentoo.org/~gongloo/macos/doc/at-procedures.html
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (Darwin)
> 
> iD8DBQFDGlv7NJ9STR9DbYERAqJ1AKCgQ73vaFfulp1tvXt3FhMOAckZvgCgqO9t
> +xaXd/DKXUW0ZmJxomn8vYw=
> =GZ6D
> -----END PGP SIGNATURE-----
> --gentoo-osx@gentoo.org mailing list
> 

-- 
Fabian Groffen
Gentoo for Mac OS X
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] Arch Testing Policy and Procedures

[Lina Pezzella]

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


On Sep 4, 2005, at 6:57 AM, Grobian wrote:

> Although I like the arch testers (ATs) idea pretty much, I have  
> some questions:
>
> - Why have the 'low hanging fruit' bugs from before 2005 not been
>   resolved till I run through them a few weeks ago?.  Most of them  
> were
>   small and had no USE flags.  I expect the devs that had no time  
> to do
>   this in the past won't have time to do it when an AT has run over it

This is exactly the point of arch testers. The idea is that AT's will  
evaluate those bugs and the developer will trust the AT's opinion and  
commit without redoing their work. It does not take much time to  
keyword and commit a package. The time drain is in compiling and  
testing the package.

>   In the end, the dev is responsible for the commit, not the AT,  
> hence I
>   would not be surprised if the dev does a (non USE flag extensive)
>   compilation on his own machine before committing to CVS.

This is probably a good idea until a trust relationship between the  
dev and AT is established. For example, I rechecked most of your work  
as a developer candidate in the beginning, but after a week or so I  
stopped checking and committed what you indicated on trust. I would  
expect the same to happen with the new AT team.

> A trust relationship between dev and AT is neccessary too and needs  
> to be
>   built.

Absolutely. This will come from the AT doing good work and devs being  
prompt about responding to an AT's work. If each developer dedicated  
just an hour each week to going through AT work and committing what  
was indicated, I think it would be fairly easy to keep up with the  
load. You can do a large number of commits in an hour.

> - Maybe AT's should be 'assigned' to one or two devs who are
>   responsible for committing the AT's work.  This is a natural mentor
>   relationship as well as QA wise, it is obvious who is going to  
> punish
>   you if your work is not correct ;)

I agree that we should have some sort of probation set up for AT's  
that do not do good work. I don't want to 'assign' AT's to devs as  
that implies that a dev is overseeing the AT's work. In order for  
AT's to help reduce our workload as devs they need to be a trusted/ 
independent group. Developers are not babysitters.

> - This proposal assumes ATs have time, which devs apparently have not.

Not true. If I didn't have time, I wouldn't be doing Gentoo. I choose  
to spend my time as a developer on larger projects then simply  
testing and keywording ebuilds.

>   I agree that the AT work is simple, but boring.  Though I still like
>   to know why it hasn't been done in the past.

It has been done by other archs and is recently becoming more  
mainstream within Gentoo.

> - Assuming I'd have an AT or two assigned to me,

That's not the way I'd like this to work.

> I'd like to have the
>   freedom to give them more flesh if they are hungry for it, i.e. dive
>   into why something doesn't configure/build/compile/install and  
> try to
>   come up with a patch.

Having AT's gives us a good way to evaluate potential new developers.  
My hope is that if an AT does good work and is interested in becoming  
a Gentoo developer, we can give them "more flesh", as you put it. It  
should be clear though that "more flesh" is not the responsibility of  
an AT.

> Maybe this is dev dependant, but I think for an
>   AT it would be nice to know there is a road upstairs: if they're  
> good,
>   and do what they do very well, it would be nice if I wouldn't  
> have to
>   commit their work.  (in other words: promote such AT to a dev)   
> On the
>   other hand, you still need the AT work to be done.

Yes, promote the existing AT to a developer and get a new AT. Perhaps  
have the old AT mentor the new AT. These are all things to be decided  
upon as part of our policy on becoming a Gentoo for Mac OS X  
developer (which I think should also be written out instead of being  
unspoken). I feel that this is a subject for another policy page and  
another e-mail. For now, I'd like to focus on getting a group of AT's  
in place.

> I think the draft is a good piece of work.  I'm almost eager to  
> have one, like a PhD who gets an MSc assigned to him.  My  
> experiences with some bug reporters who were also in IRC to fix  
> bugs using direct feedback from them is very productive, however if  
> I slam myself in the face and throw some cold water over my head I  
> feel myself forced to look at the issue from a much more  
> pessimistic point of view considering this team and the current  
> 'productiveness'.

Don't assume that not seeing work from a developer means they're not  
working. For instance, as a result of recent emails on this list,  
Hasan and I have moved a large chunk of our time that was previously  
spent on porting/keywording e-mails to drafting documentation.  
Additionally, a lot of developers choose to work on long-term  
projects in an overlay and thus don't necessarily commit things to  
the portage tree proper on a regular basis.

This being said, there are a good number of inactive developers. In a  
previous e-mail on this thread, Hasan and I explained our inability  
to take care of this problem without assuming the "Lead" position.  
Since there were no direct objections to our taking this position, we  
will make the appropriate changes to the project page[1] and begin  
conversation with devrel regarding our inactive developers. Hopefully  
this is still okay with everyone. More to follow regarding this in a  
new thread once we have more information.

> Currently, we only discuss the way 'up', but maybe the way 'down'  
> should be in the picture too.  An AT should be considered to be  
> 'active'. Where active means that such AT can do some useful work  
> on a regular base.  (Note: this implicitly requires devs to be at  
> least as active as the AT.)  If not, while there is work enough,  
> such AT should be removed.  Might sound obvious, but if there are  
> no hard rules for it, noone will get removed.

Agreed. So far, then, we need documentation/policy on the following:

1) Inactivity (Developers and ATs)
2) Probation for ATs (Probation for Devs is covered by devrel)
3) Selection of New Developers / New ATs
4) What each developer is working on (10,000ft overview)
5) Specific/Misc Policy such as where to install python modules,  
package.mask usage, Unstable/Stable Keywording, etc

All of this will be in the form of a Gentoo for Mac OS X policy  
handbook, which will take time (specifically (5) above). Suggestions  
for what should go in here would be highly valued.

> Yes, nice idea, but I think we should look at the problem from  
> inside this very team first.  I would consider the average  
> participation level very unhealthy.

Again, please don't confuse lack of commits with lack of  
participation. Also note that we have only a handful of active  
developers. Once we agree upon policy for inactivity, we can make  
some progress with weeding out those that are not contributing.

> This team is also very opaque, it's almost impossible to know what  
> someone is working on.

Like we said, we'll address this shortly. We felt that AT's are more  
important than this right now. To give an idea:

Kito is working on Darwin stuff. I'm sure he can elaborate if he  
cares to.
Hasan is working on autotools and baselayout design issues for the  
collision-protect
profiles as well as ipv6 support for qt.
I am just completing my work with adding dylib support to ffmpeg. I  
also take care of sci-biology for ppc-macos. Next project is fixing  
esound.

And of course, Hasan and I are both working on drafting documentation/ 
policy such as the AT Policy/Procedures draft we just sent out. If  
there is more documentation/policy that you feel is necessary, please  
start another thread and let all of us know. It's hard for us to tell  
what is needed since we've been here a while.

Before discussing these other issues, however, can we all agree upon  
what is necessary to bring ATs on board? Is the documentation we have  
sufficient for that purpose, or is there more that needs to be added?  
(Note: policy on converting ATs to Devs is not needed yet.)

- --Lina Pezzella
Ebuild & Porting Co-Lead
Gentoo for OS X

[1] http://www.gentoo.org/proj/en/gentoo-alt/macos/index.xml

>
> Lina Pezzella wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> Our apologies for the tardiness of this e-mail; we have been  
>> preoccupied with moving back to college this last week.
>> We have thrown together some draft documentation[1] regarding our  
>> expectations for ppc-macos arch testers. We have purposely  
>> neglected to include policy and procedures for dealing with stable  
>> keywords pending the current reevaluation of our decision to  
>> maintain them. For all interested, please review the document and  
>> tell us what you think. The faster we can all agree on policy and  
>> procedures, the faster we can get arch testers on board.
>> For those that missed the initial arch tester discussion, the hope  
>> is that having a dedicated group of arch testers will improve QA  
>> as well as free up developers to solve design and porting issues  
>> rather than keyword requests and package testing. It is also a  
>> great place for potential new developers to gain experience with  
>> the project.
>> More policy and procedure documentation to come.
>> - --Lina Pezzella && Hasan Khalil
>> Ebuild & Porting Co-Leads
>> Gentoo for OS X
>> [1] http://dev.gentoo.org/~gongloo/macos/doc/at-procedures.html
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.2 (Darwin)
>> iD8DBQFDGlv7NJ9STR9DbYERAqJ1AKCgQ73vaFfulp1tvXt3FhMOAckZvgCgqO9t
>> +xaXd/DKXUW0ZmJxomn8vYw=
>> =GZ6D
>> -----END PGP SIGNATURE-----
>> --gentoo-osx@gentoo.org mailing list
>>
>
> -- 
> Fabian Groffen
> Gentoo for Mac OS X
> -- 
> gentoo-osx@gentoo.org mailing list
>
>


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFDG0lZNJ9STR9DbYERAh9XAKDgy4xA270naCwyzOnDOC8a/5cC2ACbBHnx
FyQ6uGgz2kUN21unshZFxyM=
=YPW3
-----END PGP SIGNATURE-----
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] Arch Testing Policy and Procedures

[Grobian]

Just to be a pain in the place where the sun don't shine (but I seem to 
be destined to be), I really don't think we need ATs.

Really, I can easily cope with the bugs that are being reported.  In 
fact, I *am* some sort of the AT, and once I have gone through the whole 
list of bugs, there will be not enough work to keep my AT-work going. 
Ok, I'm on hold here at the very moment, but like I used to work here, I 
don't really see the need for some ATs.

The idea is fantastic, but we don't have enough work.  We just don't 
have people that like doing the AT work.  I have been doing it for a few 
weeks now I think, and don't care about it much.  It's ok with me.

Once I'm finished with it, I'll have to resort in doing something else 
for the project that is eligable to be 'fixable'.  At least if you let 
me, of course.

With respect to your further announcements, in the last few weeks my 
opinion on anything Gentoo/OSX related has changed, so don't expect my 
opinion to be the same.  One could say, my vision 'grows'.


Lina Pezzella wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> On Sep 4, 2005, at 6:57 AM, Grobian wrote:
> 

>>> - --Lina Pezzella && Hasan Khalil
>>> Ebuild & Porting Co-Leads
>>> Gentoo for OS X
>>> [1] http://dev.gentoo.org/~gongloo/macos/doc/at-procedures.html
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.2 (Darwin)
>>> iD8DBQFDGlv7NJ9STR9DbYERAqJ1AKCgQ73vaFfulp1tvXt3FhMOAckZvgCgqO9t
>>> +xaXd/DKXUW0ZmJxomn8vYw=
>>> =GZ6D
>>> -----END PGP SIGNATURE-----
>>> --gentoo-osx@gentoo.org mailing list

-- 
Fabian Groffen
Gentoo for Mac OS X
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] Arch Testing Policy and Procedures

[Kito]

On Sep 4, 2005, at 2:22 PM, Lina Pezzella wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Sep 4, 2005, at 6:57 AM, Grobian wrote:
>
> Don't assume that not seeing work from a developer means they're  
> not working. For instance, as a result of recent emails on this  
> list, Hasan and I have moved a large chunk of our time that was  
> previously spent on porting/keywording e-mails to drafting  
> documentation.

Have you joined the docs team yet?

> Additionally, a lot of developers choose to work on long-term  
> projects in an overlay and thus don't necessarily commit things to  
> the portage tree proper on a regular basis.

Who is working on what where when?

>
> This being said, there are a good number of inactive developers. In  
> a previous e-mail on this thread, Hasan and I explained our  
> inability to take care of this problem without assuming the "Lead"  
> position. Since there were no direct objections to our taking this  
> position

I think I have to object.

The current direction is not ever going to be good for anyone, users  
or developers, and if it continues in the current direction it runs a  
high risk of being booted from Gentoo proper IMHO. I don't think any  
amount of policy, PR, elections, hand-waving, documentation, whatever  
is going to solve the problem. The best ideas I've seen proposed on  
this list have gotten little, if any, response from either of you. It  
seems apparent you think writing a bunch of policy and shuffling some  
names around on a webpage is going accomplish something.

The macos project had docs, webpages, strategical operational  
structural senior team lead documentation managers and co-presidents,  
and /. announcements before the alpha version was even finished.  
There has been little progress made since a year ago, other than more  
ebuilds that install to / that no users want anyway (can you blame  
them?)...

The g/fbsd team is waaaaaaay farther along than we are, and they  
still have 0 official docs/policies/etc. I don't believe that to be a  
coincidence.

> , we will make the appropriate changes to the project page[1] and  
> begin conversation with devrel regarding our inactive developers.

Let the council deal with inactive developers, IIRC there are  
provisions for exactly this problem.

> Hopefully this is still okay with everyone. More to follow  
> regarding this in a new thread once we have more information.
>
>> Currently, we only discuss the way 'up', but maybe the way 'down'  
>> should be in the picture too.  An AT should be considered to be  
>> 'active'. Where active means that such AT can do some useful work  
>> on a regular base.  (Note: this implicitly requires devs to be at  
>> least as active as the AT.)  If not, while there is work enough,  
>> such AT should be removed.  Might sound obvious, but if there are  
>> no hard rules for it, noone will get removed.
>
> Agreed. So far, then, we need documentation/policy on the following:
>
> 1) Inactivity (Developers and ATs)

This should be dealt with by the new council and/or devrel, but, how  
is anyones inactivity a problem (other than the obvious lack of  
manpower) ? Yes its annoying, but out of all the problems that need  
to be solved and work to be done, this seems like an odd thing to  
focus on.

> 2) Probation for ATs (Probation for Devs is covered by devrel)

I think there shouldn't be a separate set of rules for macos ATs, you  
should work with the other arch teams and establish something project  
wide. We are already in the corner, no reason to make macos even more  
of a corner case.

> 3) Selection of New Developers / New ATs

What needs to be documented that isn't already handled by devrel?

> 4) What each developer is working on (10,000ft overview)

http://cia.navi.cx/stats/author/<nick> and bugs.g.o are fairly  
telling...

> 5) Specific/Misc Policy such as where to install python modules,  
> package.mask usage, Unstable/Stable Keywording, etc

These things should be established before they are documented. Design  
by declaration is not a good idea.

>
> All of this will be in the form of a Gentoo for Mac OS X policy  
> handbook, which will take time (specifically (5) above).  
> Suggestions for what should go in here would be highly valued.

I think the wiki is better suited for us at this point, as everything  
is in a fairly heavy state of flux. This also allows users to  
participate.

>
>> Yes, nice idea, but I think we should look at the problem from  
>> inside this very team first.  I would consider the average  
>> participation level very unhealthy.
>
> Again, please don't confuse lack of commits with lack of  
> participation. Also note that we have only a handful of active  
> developers. Once we agree upon policy for inactivity, we can make  
> some progress with weeding out those that are not contributing.

I haven't been too active in commits lately myself...RL,work and  
trouble with the 'big picture' of the project has slowed me down...

>
>> This team is also very opaque, it's almost impossible to know what  
>> someone is working on.
>
> Like we said, we'll address this shortly. We felt that AT's are  
> more important than this right now. To give an idea:
>
> Kito is working on Darwin stuff. I'm sure he can elaborate if he  
> cares to.

I guess I don't work on macos stuff? I feel like I've been fairly  
vocal as to what I am / will be working on. Yes Darwin, but more-so  
macos as you can't have one without the other. For the past week,  
I've been getting familiar with the portage rewrite as much as  
possible.I'm also in the ppc and sound herds and maintain several  
sound packages, also working on a Darwin port for the pegasos and a  
LiveDVD designed for audio production. I try to keep my devaway  
current, there are times when I get too busy with work and life that  
will keep me away from gentoo for days at a time. I'm not really sure  
how I can be any more transparent...no, I won't blog :p

>
> Before discussing these other issues, however, can we all agree  
> upon what is necessary to bring ATs on board? Is the documentation  
> we have sufficient for that purpose, or is there more that needs to  
> be added? (Note: policy on converting ATs to Devs is not needed yet.)

I think ATs are a great idea, but work better with a larger dev/user  
base. We couldn't even keep up with the bugs/patches/requests/reports  
submitted by our existing small base of users. The notion of 'not  
checking the ATs work' seems very odd, if an active dev is merely a  
proxy for a users work, that user should just be mentored and become  
an official dev.

--Kito
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] Arch Testing Policy and Procedures

[Grobian]

Kito wrote:
>> Additionally, a lot of developers choose to work on long-term projects 
>> in an overlay and thus don't necessarily commit things to the portage 
>> tree proper on a regular basis.
> 
> Who is working on what where when?

funny you ask
> 
>>
>> This being said, there are a good number of inactive developers. In a 
>> previous e-mail on this thread, Hasan and I explained our inability to 
>> take care of this problem without assuming the "Lead" position. Since 
>> there were no direct objections to our taking this position
> 
> I think I have to object.

Kito has it's own concerns, I like to focus on another side of this 
issue.  Besides that I think a dual headed lead is retarded, I like to 
point at the literature.  Think of some big management gurus, like 
Mintzberg (could I mention another name instantly?), Davenport, etc. 
they all say the same: a lead (or manager) is assingned from above, and 
comes from a herd the to be lead herd is not familiar with.  In other 
words: yes, we are in need of a lead, but he or she will come from 
another team.  For example a senior dev from the mips or whatever herd.

Ok, why you say, simple.  Noone will accept a lead from his/hers own 
team.  Simple as that.  It works like that in the real world.  It's hard 
for the lead and hard for the people to be lead.  Hard because you used 
to be on the same level, and had chats/whatever on the works as being a 
'worker', now suddenly that co-worker is going to tell you what to do. 
And maybe you don't like it.  You used to be able to have arguments, now 
you're just supposed to cooperate.

You can throw up the "this is voluntary work" and stuff, but that's the 
whole reason why it doesn't work, IMHO.  People are too free.  Charity 
work is being directed too.  "You are free to do as we tell you", [1] 
and if you don't want that, go look for some other charity work.  Of 
course, it would be nice if a discussion with the lead is allowed.

If Mike Frysinger would jump in today or tomorrow, here in this team, 
we'd have to listen to "OSX sucks" all day long, but also "if we do it 
like this, then it works, even on osx".  IMHO, this is the danger, and 
progress that's not here.  The guy is great in making decisions on his 
own.  Out of scope for the discussion whether those decisions are 
correct.  He makes Gentoo (as a whole) move.

> The g/fbsd team is waaaaaaay farther along than we are, and they still 
> have 0 official docs/policies/etc. I don't believe that to be a 
> coincidence.

Maybe we should as a team be more than 'interested' in what Diegò does...

> http://cia.navi.cx/stats/author/<nick> and bugs.g.o are fairly telling...

Thanks, I didn't know of that one.  Most useful.

>> Again, please don't confuse lack of commits with lack of 
>> participation. Also note that we have only a handful of active 
>> developers. Once we agree upon policy for inactivity, we can make some 
>> progress with weeding out those that are not contributing.
> 
> I haven't been too active in commits lately myself...RL,work and trouble 
> with the 'big picture' of the project has slowed me down...

Somehow, the point of my comment is completely missed.  I don't know 
exactly what Kito is working on at the moment, and I don't know at all 
what Hasan and Lina are working on, but I know they are doing 
'something', and every once in a while they show some sign of life. 
There are around 15 (fifteen!) people associated to the ppc-macos team, 
it seems.  Then from those 15, are only mentioned 3 plus myself active? 
  That is the question I put on the table.  People that once signed up 
or where dragged into this project.  Where are they, do they even think 
of ppc-macos, or can we just clear them out (with devrel help?) and make 
clear what the team consist of?

> I guess I don't work on macos stuff? I feel like I've been fairly vocal 
> as to what I am / will be working on.

Again, I was not after you, or Hasan, or Lina.  Though, I think I know a 
little bit what's your road, as we discussed it a few times.

> I think ATs are a great idea, but work better with a larger dev/user 
> base. We couldn't even keep up with the bugs/patches/requests/reports 
> submitted by our existing small base of users. The notion of 'not 
> checking the ATs work' seems very odd, if an active dev is merely a 
> proxy for a users work, that user should just be mentored and become an 
> official dev.

In the light of GLEP 40, I think we should come up with a different name 
for our AT, because it doesn't match what the GLEP 40 AT means.  If we 
ever happen to GLEP our AT, we will have a number > 40, hence we need 
another term.

I think the difference can be said to be that the AT proposal here 
assumes an AT to work on ~arch, while the GLEP assumes an AT to work on 
arch.  The GLEP proposal is interesting for us, because it discusses our 
'stabling' problems from an x86 world.


[1] Adam Freeland - We Want Your Soul - Freeland Records


-- 
Fabian Groffen
Gentoo for Mac OS X
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] Arch Testing Policy and Procedures

[Nathan]

I'm not a _gentoo_ dev, so I'm not sure if my input here is welcome. 
If it's not, feel free to stop reading now  :-)

> ...I like to
> point at the literature.  Think of some big management gurus, like
> Mintzberg (could I mention another name instantly?), Davenport, etc.
> they all say the same: a lead (or manager) is assingned from above, and
> comes from a herd the to be lead herd is not familiar with.  In other
> words: yes, we are in need of a lead, but he or she will come from
> another team.  For example a senior dev from the mips or whatever herd.

This may be true in the short run for large corporations in an
unfeeling 'command and control' structure.  In the long run, I don't
believe it's better for anyone.  I've never been one to be influenced
by Big Management Gurus(TM) or their short-sighted, self-serving
doctrines.  (Their visionary, selfless doctrines are okay though)

Lets run through your logic:

> Ok, why you say, simple.  Noone will accept a lead from his/hers own
> team.  

Proof to the contrary:  I've been on several small volunteer teams. 
In my experience, a lead selected by general consensus (or elections)
is accepted by all except the most immature people who tend to have
pre-existing personal grudges against the lead.

> Simple as that.  It works like that in the real world.

Perhaps with nasty corporate cultures and/or immature people.  In my
experience, gentoo devs seem to be rather mature, and I've not felt
oppressed by the gentoo culture yet.

>  It's hard
> for the lead and hard for the people to be lead.  

The best followers lead the leader with the best suggestions.  The
best leader follows the best suggestions of his followers.  I work
where I do now because I CHOSE my boss.  If some jerk were appointed
in his place (project manager over development), I would be outta
there quicker than a flash.  I would be ok promoting someone from
within the team, or hiring an outsider that we all like (non-jerk
variety).

> Hard because you used
> to be on the same level, and had chats/whatever on the works as being a
> 'worker', now suddenly that co-worker is going to tell you what to do.
> And maybe you don't like it.  

 _Assuming_ the lead has no tyrannical powers to force everyone to
obey their every whim (I looked for Gentoo documentation on team
organization and responsibilities, but couldn't find it.), there
shouldn't be much to worry about.  Assuming (again-sorry, where are
those docs?) that a Gentoo lead consists of mostly extra
responsibilities, and not of extra sticks to beat people with, being a
lead tends to be more of a 'character building chore' for the lead
than anything else.

> You used to be able to have arguments, now
> you're just supposed to cooperate.

If Gentoo policies _really_ say that you have to Unquestioningly Obey
The Lead In All Things(TM), then I will swiftly disassociate myself
with all things Gentoo.  Do you really think Hasan and/or Lina are
going to turn into earless monsters if they jointly become 'the lead'?

None of the above is intended to be rude or offensive--so please don't
take it that way!

~ Nathan S.
(An almost-user waiting for non-root installs before taking the plunge)

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] Arch Testing Policy and Procedures

[Grobian]

Nathan wrote:
> I'm not a _gentoo_ dev, so I'm not sure if my input here is welcome. 
> If it's not, feel free to stop reading now  :-)

I consider it welcome.

>> ...I like to
>> point at the literature.  Think of some big management gurus, like
>> Mintzberg (could I mention another name instantly?), Davenport, etc.
[snip]
> 
> This may be true in the short run for large corporations in an
> unfeeling 'command and control' structure.  In the long run, I don't
> believe it's better for anyone.  I've never been one to be influenced
> by Big Management Gurus(TM) or their short-sighted, self-serving
> doctrines.  (Their visionary, selfless doctrines are okay though)

On the contrary, their logic is used on the long run.  Though I can 
agree with you that their methodology might seem a bit overdone here. 
I'll explain lateron why I brought it up.

> Lets run through your logic:
> 
>> Ok, why you say, simple.  Noone will accept a lead from his/hers own
>> team.  
> 
> Proof to the contrary:  I've been on several small volunteer teams. 
> In my experience, a lead selected by general consensus (or elections)
> is accepted by all except the most immature people who tend to have
> pre-existing personal grudges against the lead.

yes, correct*.

> 
>> Simple as that.  It works like that in the real world.
> 
> Perhaps with nasty corporate cultures and/or immature people.  In my
> experience, gentoo devs seem to be rather mature, and I've not felt
> oppressed by the gentoo culture yet.

Yes, correct*.

>>  It's hard
>> for the lead and hard for the people to be lead.  
> 
> The best followers lead the leader with the best suggestions.  The
> best leader follows the best suggestions of his followers.  I work
> where I do now because I CHOSE my boss.  If some jerk were appointed
> in his place (project manager over development), I would be outta
> there quicker than a flash.  I would be ok promoting someone from
> within the team, or hiring an outsider that we all like (non-jerk
> variety).

Yes, correct*.

>> Hard because you used
>> to be on the same level, and had chats/whatever on the works as being a
>> 'worker', now suddenly that co-worker is going to tell you what to do.
>> And maybe you don't like it.  
> 
>  _Assuming_ the lead has no tyrannical powers to force everyone to
> obey their every whim (I looked for Gentoo documentation on team
> organization and responsibilities, but couldn't find it.), there
> shouldn't be much to worry about.  Assuming (again-sorry, where are
> those docs?) that a Gentoo lead consists of mostly extra
> responsibilities, and not of extra sticks to beat people with, being a
> lead tends to be more of a 'character building chore' for the lead
> than anything else.

Yes, correct*.

>> You used to be able to have arguments, now
>> you're just supposed to cooperate.
> 
> If Gentoo policies _really_ say that you have to Unquestioningly Obey
> The Lead In All Things(TM), then I will swiftly disassociate myself
> with all things Gentoo.  Do you really think Hasan and/or Lina are
> going to turn into earless monsters if they jointly become 'the lead'?

I hope, but I think you are correct*.

*) provided in the case that all is well and there just need to be some 
structure.

I have the impression that a few major things *have* to be done.  This 
requires 'action' and taking discisions that probably not everyone is 
going to be happy with.  I feel especially the last one is required to 
bring this project *any* further, because it appears to be stuck on 
little details, while the big lines aren't even properly drawn.  Hence 
my rather business-like approach, which may be the horror vision for 
anyone.  Of course I do *not* prefer a situation where people can't be 
free in what they want to do for the project.  However, you cannot have 
everybody doing not so much (or almost nothing) too.  I don't think open 
source and volunatary work means: "do whenever you feel like it".  If 
that would be the base, many things would not have been here around now. 
  You need people that are passionate, and devote some time to a project.
I don't want people to relate this sentence above to this team directly, 
for I'm having a more general talk here.

If I read carefully between the lines of some very active (and sometimes 
counsil) members, I hear this complaint.  We see this complaint when 
people leave the project with furious last words on about 300 devs and 
noone testing package X.

In my opinion open source needs to be managed too, because if it isn't, 
it doesn't move or innovate.  The Gentoo counsil isn't just put there 
for fun, they are clearly chosen to get Gentoo move again at certain 
points.  They will provide some management, to serve a higher purpose, 
which is a long term one.


-- 
Fabian Groffen
Gentoo for Mac OS X
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] Arch Testing Policy and Procedures

[Finn Thain]

On Tue, 6 Sep 2005, Grobian wrote:

> I have the impression that a few major things *have* to be done.  This 
> requires 'action' and taking discisions that probably not everyone is 
> going to be happy with.

Yes. You also made this point earlier in the thread, but it got snipped 
(I'll repeat it here:)

> > > If Mike Frysinger would jump in today or tomorrow, here in this 
> > > team, we'd have to listen to "OSX sucks" all day long, but also "if 
> > > we do it like this, then it works, even on osx".

And that is one of the main reasons why, in big business, an executive or 
team of executives from outside the organisation (often from overseas) 
might be installed by a board to do a particular job (e.g. a 
reorganisation).

This is not always because the vision or ability is lacking in-house, it 
is because no-one in-house wants the job (makes to many enemies to say 
"gentoo-macos sucks"), or because noone in-house will be given sufficient 
respect ("he is just one of us, and we don't see a problem") or because 
noone in-house can be trusted to do it (doesn't really apply here, since 
nepotism and corruption aren't the issue).

-f
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] Arch Testing Policy and Procedures

[Finn Thain]

On Tue, 6 Sep 2005, Nathan wrote:

[snip]
> Assuming (again-sorry, where are those docs?) that a Gentoo lead 
> consists of mostly extra responsibilities, and not of extra sticks to 
> beat people with, being a lead tends to be more of a 'character building 
> chore' for the lead than anything else.

Yes, in an ideal world, a lead would not have to exercise powers that 
no-one else in the team posessed. But in reality, one doesn't elect leads 
by drawing straws to pick a random unfortunate who will merely carry the 
burden of extra responsibilities. So why elect a lead?

In my opinion, the most effective (and innovative) open source projects 
are run by an (inspired) dictator, and the least effective are run by 
committee or by a loose group of random volunteers, each one with a 
different "itch to scratch".

[snip]
> Do you really think Hasan and/or Lina are going to turn into earless 
> monsters if they jointly become 'the lead'?
  
The problem here is that gentoo-osx lacks a coherent shared goal*, and 
electing a lead isn't going to help much unless it can provide that. 
Electing two leads is, in general, worse than electing one when it is a 
coherent vision that is missing. It is like having a committee of 2.

-f

* And I confess that I have helped muddy the water on that score.
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] Arch Testing Policy and Procedures

[Grobian]

On Wed, September 7, 2005 06:57, Finn Thain wrote:
> Yes, in an ideal world, a lead would not have to exercise powers that
> no-one else in the team posessed. But in reality, one doesn't elect leads
> by drawing straws to pick a random unfortunate who will merely carry the
> burden of extra responsibilities. So why elect a lead?
>
> In my opinion, the most effective (and innovative) open source projects
> are run by an (inspired) dictator, and the least effective are run by
> committee or by a loose group of random volunteers, each one with a
> different "itch to scratch".

To stay close with our home, Apple wouldn't be whatever it is today, if it
hadn't such a (almost notorious) key figure called Steve Jobs.  Many,
many, many people have declared that it is *impossible* to work with him,
though the man has a vision, and makes that vision happen.  So far, he has
had luck and bad luck, where the luck outweights the last years.

I completely agree that there wouldn't be a GNU (which is not Linux) if
there wasn't an ultra arrogant Richard Stallman who even insults his own
"user base", if they don't think like he wants to.

Last FOSDEM, I met Gerv, the Bugzilla guy from Mozilla.  He's a real
*******, and I can say so, because he didn't hestitate to cut my question
and put it in the corner as "useless".  It simply didn't match his vision,
and so it was crap.  In the end, he *did* produce a fairly well bug
tracking system, but don't you dare to suggest something he doesn't like,
or your bug will disappear or get REJECT/WONTFIX etc.  If you really want
to change something in that thing, your one and only resort is the 'fork'.
 And I assume you all know what 'forks' have happened in the past an what
it finally ends up with.

I think there are plenty of (open source) projects to be identified that
all got stuck after there was released some initial code (in the best
case).  Or just code that doesn't innovate and only gets bugfixed and in
the end get overruled by a fork or redo.  (See -dev on torsmo, which is
such case.)

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] Arch Testing Policy and Procedures

[Grobian]

Thanks for saying what I wanted to say in human readable English.  You
have exactly pointed out what I wanted to point out in considerably less
'code'.

On Wed, September 7, 2005 06:39, Finn Thain wrote:
>
>
> On Tue, 6 Sep 2005, Grobian wrote:
>
>> I have the impression that a few major things *have* to be done.  This
>> requires 'action' and taking discisions that probably not everyone is
>> going to be happy with.
>
> Yes. You also made this point earlier in the thread, but it got snipped
> (I'll repeat it here:)
>
>> > > If Mike Frysinger would jump in today or tomorrow, here in this
>> > > team, we'd have to listen to "OSX sucks" all day long, but also "if
>> > > we do it like this, then it works, even on osx".
>
> And that is one of the main reasons why, in big business, an executive or
> team of executives from outside the organisation (often from overseas)
> might be installed by a board to do a particular job (e.g. a
> reorganisation).
>
> This is not always because the vision or ability is lacking in-house, it
> is because no-one in-house wants the job (makes to many enemies to say
> "gentoo-macos sucks"), or because noone in-house will be given sufficient
> respect ("he is just one of us, and we don't see a problem") or because
> noone in-house can be trusted to do it (doesn't really apply here, since
> nepotism and corruption aren't the issue).

-- 
gentoo-osx@gentoo.org mailing list