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

Re: F7 Release Discussion (was Re: Slightly OT: bad rap for Fedora, and realistic effects)

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.

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