Gentoo Archives: gentoo-osx

From: Kito <kito@g.o>
To: gentoo-osx@l.g.o
Subject: Re: [gentoo-osx] Arch Testing Policy and Procedures
Date: Mon, 05 Sep 2005 03:42:42
In Reply to: Re: [gentoo-osx] Arch Testing Policy and Procedures by Lina Pezzella
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)<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, 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@g.o mailing list


Subject Author
Re: [gentoo-osx] Arch Testing Policy and Procedures Grobian <grobian@g.o>