RFC: Package Review VCS

[Warren Togami]

Josh Boyer wrote:
> 
> The idea behind this is nice.  Using CVS to do it will suck.  

What about it exactly?
Using CVS as a tool again when we should be using a more modern VCS?

I suppose we could use a different VCS tool here in order to open up 
experimentation of new tools in a non-critical area.  This however would 
have the detriment of losing an opportunity for newbie training, for new 
contributors to become familiar with our strange CVS structure and 
"make" commands in a safe environment.

(OTOH, this would be a great opportunity to show people bzr's awesome 
checkout --lightweight feature.  bzr allows the user to use bzr as 
either a distributed VCS like git, or in the traditional 
checkin-directly-upstream mode like CVS.  bzr is very user friendly, 
fast and flexible.  But then the above detriment...)

> Also, I'm not sure it buys you a ton over keeping track of changes in the
> specfile during review, which should already be done anyway.
> 
> josh
> 

While most spec changes during a review will be boring, it is sometimes 
worthwhile to keep them in history.  A more interesting thing this 
enables may be during pre-review, where it can act as a playpen/staging 
ground for rapid packaging and testing.  Imagine this:

1) Existing Fedora packager begins work on a new package.
2) cvs-import.sh in /cvs/pkgreview, existin Fedora packager can create 
whatever they want, whenever they want.
3) They might ask other people to help in packaging.  *Real* quick 
centralized place to point other people to ask for help.
4) *Real* quick build testing on all archs directly from your 
work-in-progress.

I call that enabling.

I suppose we could make using /cvs/pkgreview optional for package 
reviews.  And Merge Review could use /cvs/pkgs instead.  But I can't 
imagine why anybody would prefer the hassle of spinning new .src.rpm's 
and uploading them to a web accessible URL several times instead of 
simply using a VCS.

Warren Togami
wtogami at redhat.com