On 6/6/07, Christopher Blizzard <blizzard@xxxxxxxxxx> 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"
