On Fri, 23 Feb 2007 19:05:24 +0100
mschwendt.tmp0701.nospam(a)arcor.de (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:
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.
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.
> - Revoke sponsorship in the event that the person refuses to
> 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.
> - 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
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:
> > 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
What do you see such a roadmap containing?