On Sun, 2007-06-10 at 13:33 -0400, seth vidal wrote: > On Sun, 2007-06-10 at 11:58 +0200, Nicolas Mailhot wrote: > > Le dimanche 10 juin 2007 à 15:23 +0530, Rahul Sundaram a écrit : > > > Nicolas Mailhot wrote: > > > > Le dimanche 10 juin 2007 à 08:44 +0530, Rahul Sundaram a écrit : > > > > > > > >> Having a web interface would allow anyone to select the package groups > > > >> and individual packages and get a ISO image for download. I posted to > > > >> fedora-infrastructure list before but we need a web app before talking > > > >> about deploying it. > > > > > > > > Yay for killing bandwidth > > > > > > Ignoring the obvious end user benefits? > > > > There are no obvious end-user benefits if an infrastructure that could > > handle lots of users melts under a few doing iso spins (I suppose you > > want dvd images in there too right?) > > I'm going to say something here which I'm sure will cause a bit of a fit > but I'll say it anyway. The bandwidth and server costs of running a > service like this would be huge. What has been discussed (briefly and > without much detail is this) > > 1. produce an open source tool to produce web-based respins of fedora > (and related) distros. > 2. release this tool so anyone could set up their own site to make > respinds > 3. setup a site so people can respin fedora with updates or with a > different set of packages. There won't be much guarantee that the distro > will work perfectly but its package set should produce dependency > closure. > 4. charge a fee for access to the site we run. That would help us offset > the costs and constrain the set of users a bit. > > That's what has been discussed and only a little bit. Right now the > important part is making a program work to do this, everything after > that is extra. > > let the angst and flames begin. > -sv I just want to step in a weigh in on this. Basically, a web based front-end has already been planned. From the beginning, we had planned on making multiple front-ends. Just because Revisor as it is seen now is a gtk desktop tool, that does not mean we are not working to make *everything* modular and allow *many* front-ends to be written. I hope I don't step on toes when outlining this but I don't want things to be over discussed. Right now what we need is coding. We know what needs to be done, we have a good model. Now it is time to do it. Basic Outline: * Front-end: This will be anything. It will continue to be the gtk client, it will be a web interface, it could be a Qt client, etc. Basically, all this component is supposed to do is poop out a Revisor "template" (as I have been calling it) that will then be moved onto the next step. * "Glue": This step is to take the Revisor "template" and go to action on it. It will setup the needed tasks and do any additional work before the actual tasks are run. * Build Server: Ok, it seems we (as a collective) have misunderstood what I would like Revisor to do at this stage. The current "Revisor", being just a Gtk application, is misleading in the way that it actually does all the work for the end-user. We tried to express our goal of being able to run the Gtk application in "client" mode and define the compose(s) and then send the definition off to a build server by including elements in the application workflow that designate when we would actually had off the process to a remote build server. From the very first day, at the Redhat Summit, we have expressed we will be working on multiple front-ends and will be designing around the fact we want to see a Revisor client and a Revisor server. The build server code will be FOSS, just like everything else has been (pungi, livecd-creator, koji, revisor, etc) and anyone will be able to set one up. As to not go into much implementation detail, *we are working on a web front-end, we are working on a client server model, we are working on allowing anyone to setup a full revisor build system*. This Revisor "build" system could be a single machine running the Revisor gtk application in standalone mode, it could be the Revisor gtk application running in client mode and sending the "template" off to another machine (server) for actually doing the build, it could be a user defining their build on the web-based front-end and then downloading the template to build it locally on their own build server or by feeding the template to the Revisor Gtk application, it could be a user building everything via a web front-end and then waiting for the notification their download is ready. To try to keep it somewhat short -> etc. etc. etc. * Archive Network: This will be like CPAN. Optionally, a user would be able to submit their "template" to the archive so others can build it later. There will be an archive network browser in all the front-ends I am going to be involved with (and at this point that is all of them.) These templates could be built by any of the methods available. A few clicks in the Revisor application, a few clicks on a website, a few clicks to submit the "template" build request off to a server. In the interest of time, there is a brief outline. There are actually 5,000^9999 more things we want to do with the concept. We also welcome ideas and additional "things" we should be doing. We are going to try to be as transparent with Revisor as possible but there are some cases where we are going to end up "just doing it". It seems we need to get more information out to everyone. I will try to get everything we displayed at the Redhat Summit onto the Revisor site. Revisor Site: http://revisor.fedoraunity.org/ Jonathan Steffan daMaestro -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
