Re: simplistic questions about core/extras merge
Max Spevack (mspevack(a)redhat.com) said:
So let's look at the process for a single package, making its way
from
"Core" to "New World":
1) Package is reviewed under the current Fedora guidelines. As these
reviews happen, the guidelines that we have are always up for intelligent
discussion.
2) Once a package passes review, a couple of things have to happen
a) Current maintainer (someone who is @redhat.com) needs to agree
to a freeze.
b) Current maintaner needs to get a Fedora account.
c) Package's "upstream" is moved from internal CVS and build
system to external CVS and build system (basically Extras)
d) Current maintainer decides if anyone else should have
"maintainer" ACLs at this time
e) Development resumes
Is that basically the right model? Am I forgetting any major concerns
that have previously been voiced? What steps am I missing?
Well, there has been plans of a two-stage merge. For anything that's
reasonably on the edges of Fedora (i.e., isn't a dependency of the world),
we could do moves before 'the big switch', which would be done in a one-off
basis as stated above.
However, for the vast majority of packages, there will be a simple
drop-dead date where they are moved en-masse. The Fedora account
requirements, etc. will all still be there, but it will be a period
where we shut down all CVS for a few hours to do this.
I have a few other questions too:
1) What is the process for new folks being given "maintainer" access to a
package that is in the New World? I think it's simply a matter of the
current maintainer saying so, and the proper access being given in CVS?
But *who* is the person/persons who actually makes that happen?
The maintainer (or a CVS administrator) does that by editing the ACL.
2) What are we going to call the new repo, from the /etc/yum.repos.d/
perspective? In fact, my larger question is "what will f7's
fedora-release package look like?
One repo to rule... <WHACK>. Sorry about that.
Right now we have core, extras, devel, extras-devel, updates, and updates-testing.
This would be trimmed to simply release, development, updates, and updates-testing.
3) How are we going to deal with the worst case scenario, which is
packages that fail review, or for which the current @redhat.com maintainer
doesn't do anything to help prepare for the merge?
Pointy sticks, pitchforks, managers?
Bill