simplistic questions about core/extras merge

[Bill Nottingham]

Max Spevack (mspevack at 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