On Fri, 23 Feb 2007 19:05:24 +0100 mschwendt.tmp0701.nospam@xxxxxxxx (Michael Schwendt) wrote: > On Fri, 23 Feb 2007 10:23:39 -0700, Kevin Fenzi wrote: > > > I think the responsibilities of sponsors are the same as they have > > always been (although no where written down), namely: > > The fact that they are not written down makes it useless. I think thats a bit strong, but you are right, they should be written down so everyone has the same expectations. I will try and write something up in the wiki and ask for comments, then get it approved. > > After several years of using the sponsorship system, we don't even > have a draft somewhere in the Wiki. > > Why is that? Because nobody has the time to do it? Or because nobody > knows what the sponsors' responsibilities are actually? Do we use the > terms "sponsor" and "sponsorship" just for fun or because it is a > hardcoded scheme in the FAS? Can we assume that every sponsored > contributor is observed by a sponsor during activities in cvs and > bugzilla, for example? Does that apply also to Red Hat packagers, who > should know their stuff, and blanket approvals? Is sponsorship a > *life-time* process? For example, some of the fellow contributors > I've sponsored have been the FESCo chair or still are FESCo members. > Others can be trusted, also with regard to their technical abilities. > How does that affect the person's status in the FAS and my > responsibilities as a sponsor of those people? All good questions. Would you be willing to assist me in drafting a sponsor responsibilities document? I have a rough draft here: http://www.fedoraproject.org/wiki/Extras/Schedule/SponsorResponsibilityPolicy Feel free to edit/add/comment. > > > - Fix problems that they cause if mistakes are made and they can't > > figure out how to fix them. > > You know this has become impossible with the ACLs. For now, for new packages, yes. For existing extras packages they should still be open to anyone unless the maintainer has placed a pkg.acl in place. > The original > intent of the Vacation page in the Wiki is void, too. Packagers would > need to lift the acls on all their packagers, before they could allow > trusted contributors to help out during vacation. Agreed. > > - Revoke sponsorship in the event that the person refuses to follow > > rules, and deal with that persons leftover packages. > > The second part is new to me. Leftover packages would be orphaned. Sure, but there might be open bugs to close, other packages that depend on those packages that a new maintainer should be found for, binary rpms to remove from repositories, etc. > > > - koji = fork of brew blessed by the lawyers and available for > > Fedora use > > The source code smelled like that, but relevant lists don't mention > koji with a single word. yeah. > > > - Updates system - No idea where that is... it is still not finished > > from what I know. Perhaps someone else could fill this in? > > I know where it is, I am subscribed to the Wiki page, too, but there > is some secret relationship between it and what is used at Red Hat. I think it is based off the internal tool in use for redhat, yes. > Smells a bit like another fork/semi-rewrite of an existing code base, > which creates a situation like "aha, somebody is working on > transfering more and more existant code piece by piece, so it's just > matter of time before all of it is published". I haven't looked at it, so I have no idea. > > > * 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? > > Guiding the community to prepare for Fedora 7. The contributor > community needs a roadmap. There are 1129 fc6 packages (based on > their src.rpm name) in the devel tree, while Core has reached test2 > already. The upgradecheck report lists several invalid upgrade paths. > The broken deps report lists other issues. The FE7Target tracker > lists even more issues. And I guarantee, more issues are undiscovered. Of course. I attempted to clean up the EVR and broken dependency issues a while back and made some progress on it, but I have been trying to look at core merge reviews lately instead of working more on that. I found that often you could find a solution to the issue, report a bug on it (with patch or offer to fix it) and the maintainer would happily accept it. What do you see such a roadmap containing? kevin
Attachment:
signature.asc
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
