RFR: GIT Package VCS

[Stephen John Smoogen]

On 6/6/07, Christopher Blizzard <blizzard at redhat.com> wrote:

> > > This might sound crazy (SUPPORT > 1 SYSTEM, ARE YOU CRAZY?)  Well, yes,
> > > until you realize what you need to do here.  To start with you only have
> > > to teach the rpm build side how pull a specific tag from a specific
> > > repo.  On the query side we need a browser for each kind, which is a bit
> > > of work, but something I think we need to do anyway.  (i.e. "What would
> > > git do?")
> >
> > So if I am the owner of the rpm package which has an upstream of hg and
> > want to fix, test and commit a change to say (for the sake of argument)
> > neon which is in git, I now have to know two different systems?  You're
> > crazy ;-)
>
> No.  If you happen to be a maintainer _and_ a developer and you have
> _chosen_ to use hg or git or whatever, then we make it easy for you.
> This is about adding options to bring us closer to the upstream
> developers and make their lives easier.
>

Its been a very very long day, and I am running on fumes of fumes...
but the only way I could see the workflow you are wanting to happen is
that if there are appropriate front-ends for the
'maintainer/developer/qa/nth-party' to work with. Basically the
front-end does not give a rats pee about what the backend is this week
or next week. All it does is give say the worker a set of common
commands and then interprets those for the backend systems. The tools
would be meta-meta-tools and would probably slower than an snail in a
Canadian December on some systems.. but might be possible if you
outline a simple choice selection and pluginability (you get 2 from
column A, 1 from B.. anything else you write yourself).

$ smoogeit create project kernel uses git with head git.kernel.org
# this creates both locally and say a Fedora repo and uses whatever
common lower end system. maybe some extra files to edit files.. it
then talks to the git.kernel.org in git

$ smoogeit add patch <insert file name here>
# adds the git stuff silently behind the scenes

$ smoogeit create project smooge-firewall uses sccm with head local://blah

the final workflow might be something like:

$ smoogeit publish kernel branch F7

which pushes it in a way that the Fedora build systems might be able
to handle stuff like

In this never to be written system.. the
build/errata/vcs/support/bugzilla system is semi-integrated together.
The developer can use git for his own project and then just tell the
smoogeit to publish it for SmoogeOS. The maintainer can talk to
whatever the developer has and push back or keep their own local tree
without having to know 8 systems.

Now like I said.. its shooting the moon to see this ever work.. and I
would believe that it would require you to keep the smoogeit system to
a limited number of commands and let any extras that a particular
system has extra in it be done as plugins like yum. My take on it
would be that there might be a 'hidden/common' system underneath all
this to make the buildsystem sane to debug.. so while you check out to
your laptop  using
git/cvs/mercurial/arch/svn/darcs/rcs/sccm/monotone/MicrosoftStuff and
your upstream commits are done that way.. the build system stores it
in a known format. Other people could chose to pull from either the
build system or the upstream...

wow so many fricking choices these days and I used to have to deal
with SCCM/RCS arguments.

Anyway going to sleep.

-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"