[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Slightly OT: bad rap for Fedora, and realistic effects

On Fri, 23 Feb 2007 13:35:17 +0100
mschwendt tmp0701 nospam arcor de (Michael Schwendt) wrote:

> Still, the merge of Core+Extras will put the Fedora Project at a test.
> There are several issues I still don't understand and which sometimes
> make me shake my head in disbelief. For instance, but not limited to:

Yeah, It's a big task, and there will be mis-steps I am sure, but we do
the best we can and press on. ;) 
> * heavy use of Red Hat internal mailing-lists for Fedora related
> matters,

I don't know off hand of anything like that. I think there has been a
effort to make sure RedHat internal people know that they have to
follow the package guidelines, etc. 
> * weird procedures by which Red Hat's Fedora Core package owners need
> sponsorship for cvs_extras and either get blanket approval or are
> really "sponsored" by community contributors without that the
> sponsors' responsibilities and duties are documented,

Well, the problem is that all the current RedHat internal maintainers
of packages formerly in "core" need access to CVS to maintain their

In the last FESCO meeting (see the wiki for meeting minutes), Warren
talked about having a Redhat sponsor available at each physical RedHat
site that would be able to help other maintainers there with guidelines
and process questions and be able to sponsor them. I think thats a
great idea. 

I think the responsibilities of sponsors are the same as they have
always been (although no where written down), namely: 
- Make sure the people you sponsor try and follow the guidelines. 
- Help answer questions they may have. 
- Fix problems that they cause if mistakes are made and they can't
figure out how to fix them. 
- Revoke sponsorship in the event that the person refuses to follow
rules, and deal with that persons leftover packages. 

> * more closed circles, in which decisions are made -- including
> mysteries like brew, koji, and code transfer for the new Updates
> System,

Yeah, but the problem here is that much of that is still in flux. 
From what I know: 

- brew = internal redhat build system. We don't need to care about it

- koji = fork of brew blessed by the lawyers and available for Fedora
use. This will be our new build system hopefully if it can all be made
to work.

- Updates system - No idea where that is... it is still not finished
from what I know. Perhaps someone else could fill this in? 
> * unclear role of FESCo, not enough steering -- instead: the drive
> that "you don't need to be in FESCo to get something done",

What items do you think need addressing? 
The problem is that there is all kinds of change right now. I suspect
once the buildsystem is figured and the merge is figured we can look at
more longer term issues. Please do bring up on the lists or if you
prefer personal email to me any issues you want to have addressed. 

> * the community used to have full control over Extras -- this control
> is lost, instead: even sponsors would need to ask their sponsorees
> for permission before they could fix or veto anything in CVS,

Yeah, I think that should be changed. I think either sponsors should be
able to access any package at all, or any package that has a maintainer
they sponsored at the least. 

> * changes to infrastructure and policies/guidelines, respectively,
> without prior communication,

Such as? The package review guidelines have been a big source of
confusion lately, but nothing was changed until it was pretty well
agreed on in maintainers, then approved by FESCO. 

I agree that the wiki should be updated to reflect this. I will see if
I can get someone to do that or do it myself today. 

> * annoying cross-posts due to an overly complex and unclear
> choice of mailing-lists -- still: the feeling that some lists are
> missing, because vital communication and coordination (e.g. about
> things done in Core) is missing.

Agreed. I wish we would just move all the mailing lists per thl's last
suggestion. It would be pain and another bit of chaos, but I think we
should just bite the bullet and do it. 


Attachment: signature.asc
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]