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@xxxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
