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