Mailing List Archive

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

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

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

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

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

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

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

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

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

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

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