Log in

Summit day 1 brainflush

« previous entry | next entry »
Nov. 13th, 2006 | 10:43 pm

So I'm supposed to be blogging about what we covered today. Greg helpfully documented some of the stuff related to my work here, and a more overall page here.

We did do a session on the build system, and what features of a build system we feel we need in order to sanely produce a Fedora release in the external world. Some of these features Plague already has, some of these features Brew adds to the game, and some of them neither brew nor plague do very well (and admittedly some of these may be hand wavy future things rather than blocker items...). We also set a deadline of the end of this summit to get an answer once and for all on if we can make use of the brew code for our needs. We already know that RH release engineering does not have the bandwidth for buildsystem authoring for anything other than RH's internal needs. The spare manpower for Fedora is basically me and I'm pretty wrapped up in some of the other things we need to do for this shindig. However what wasn't clear is if we could take the brew codebase and run with it. We know that many things will have to be stripped out or fixed up to work in Fedora's infrastructure rather than RHELs, and the question still remains do we add functionality on top of plague or do we replace it with brew. Tough questions that I'd rather put into the hands of a community around the build system, whatever build system it happens to be.

One of the other subjects we discussed is what to do with secondary arches. The idea of an arch maintainer (or sig) and "shadow" builds was brought up. This would mean something like our main buildsystem would have some sort of subscribeable build notification interface, that other "downstream" build systems could query to find the new builds. Then they could clone or update local source repos, or pull directly from Fedora's repo and build for that arch (or project, or whatever, see this is extendable!) Build results could be made public (we would prefer) or kept private. An arch maintainer would marshal changes in from the "downstream" into the upstream Fedora software base. These arches can be a bit more 'sloppy' in that we don't always guarantee that the software used in a buildroot to build a package for a primary arch is the same exact software set used in a buildroot to build a package for the secondary arch. I think most of us are OK with this because trying to keep things exactly the same is a game we just can't win.

Some SCM was talked about too, but it became clear that changing out the SCM really wasn't immediately necessary. Because of this, we're going to create a SCM SIG (Special Interest Group) that can and will make use of the proof of concept setups that myself and others are working to create to play with more compelling changes to the way we handle package SCM and how our work flows. I'm going to be taking a part in that as I have deep interest in being able to create a "fedora infrastructure in a box" type kit that would enable Fedora derived distribution projects to get launched very quickly and in a way that makes it easy to push their changes for their usage case back up to the upstream Fedora. I want Fedora to be the freebase from which to smoke your own flavor of crack, and share your crack with other crackheads. A distributed SCM makes this easy as you can clone a package set, and reserve that clone very easily for your project, and allow upstream Fedora maintainers to easily pull your changes back into the upstream. There are other interesting things to think about with SCM, such as patch management for the patches we apply to upstream sources (quilt comes into play here), and other goodies.

So I think that's about as much as I can flush tonight. Tomorrow we start to tackle some really important things like how the next release compose will take place, what it might look like, what we might call this new unified thing (I like Pangaea, or Pannotia, or Rodinia)

and of course....
Obligatory baby picture!

Link | Share