On Sun, 25 Feb 2007 11:21:33 -0700, Kevin Fenzi wrote:
> > > > - 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.
>
> Now it's getting interesting. Being a sponsor has never before implied
> that you have to fix orphans or take over packages when a sponsored
> person leaves the project or is AWOL. With such a requirement, the
> sponsorship system would be too burdensome and too much of a risk.
ok. So, who should handle those things? FESCo?
No one?
Quite obviously, those are not the only two options. And hence the answer
to the latter two questions is "no".
Would you like to update that wiki page with your thoughts on it?
Such thoughts ought to come from the governing body of the project, since
1) the CLA and the contributor sponsorship system is their sphere of
responsibility, 2) a successful sponsorship system makes it possible to
scale, and 3) it can also happen that sponsors leave the project.
> > What do you see such a roadmap containing?
>
> Points that give the impression that there is the desire to have a
> product ready when Fedora 7 will be released. When to have packages
> rebuilt and ready, whether and when there will be any sort of freeze
> (especially with regard to ABI and API breakage), "last
resort"/"last
> minutes" procedures for fixing packages where package owners have not
> met the deadline. I see Matt Domsch' build failure report, I see the
> complicated and lengthy AWOL procedure, I see that test2 is close,
> but Extras 7 is broken in many areas, I see ACLs which lock down
> packages in CVS, and all that would benefit from plans on how to
> bring Extras 7 in shape in time.
For much of this with the merged tree, we will be using the procedure
that former Core used to use?
Is that a question?
Apart from that, we don't have "the merged tree" yet, so it is more
interesting how to proceed until test3 and beyond.
http://www.fedoraproject.org/wiki/JesseKeating/RelEng
Perhaps Jesse could comment and put up a more exacting page with dates
where broken packages must be fixed, procedures for freeze, etc?
I agree it would be good to have a schedule with dates for each step,
when freezes are, what to do about packages that are still broken by
freeze, etc.
Some of the E-V-R and broken deps problems have been fixed, but not
pushed out in devel since we are in test2 freeze, it looks like?
Well, Core is frozen, Extras doesn't have any schedule ;-), but right,
after the topic had come up on maintainers-list, Extras devel is sort of
in a freeze, too, and pushed to only on demand.
Also, it doesn't look like the broken EVR report mails anyone,
just
goes to the list. Could you change it to mail owners? I think some
people might be missing the problem.
The code that would do that [without creating too much spam] is missing.
I think we could also figure out
the core owners for the core packages that have broken EVR, and mail
them too... or I can do so manually.
What is needed is a clear word that those issues are considered bugs that
need addressing and will be fixed. It is an unthankful task for any
contributor to spend time on filing such issues, if the tickets stay open
for a very long time (e.g. until the affected dist will see EOL).
On the subject of broken deps, I can look at assisting people with
those. Will go file bugs and see if there are any that are easy to
fix. Does the script just run 'repoclosure' ?
A modified version, but running the original repoclosure from yum-utils
should work to check packages and local builds, too.