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@g.o mailing list