Log in

Summit day 2, the reckoning...

« previous entry | next entry »
Nov. 14th, 2006 | 10:44 pm

well, lots was talked about, there were raised voices, there were wild arm gestures, there was lots of silliness as fatigue set in.

OpenID and its potential was talked about, but I'll let somebody else go into details here.

IS/IT priorities were discussed, I think we all agreed that buildsys is priority #1.

Then we got into release methodology and such. Here is where a lot of fun was had.

First we talked a bit about what we would release, and what it would look like. We mostly decided to have two or so main 'release' flavors, a Desktop and a Server set. Then we'd have some community generated spins that were either Blessed, less blessed, or sent cease and desist letters to remove the Fedora name (mostly joking here). How the blessing happens is mostly up to the Fedora board. We didn't talk too much about the content of each of these spins, will need to cover that more in detail later.

Then we talked about freezes, and what that means for Extras. This really depends on improvements to the build system, but essentially we'd have the concept of package collections that were comprised of packages "tagged" with a certain identifier, say 'dist-fc7'. When you build a package from the devel/ branch it would get tagged for 'dist-fc7'. Come freeze time (for test releases), a new tag would be created, say 'fc7-test1' and every latest 'dist-fc7' package would get this tag. Testing repos would be created from the 'fc7-test1' tag. dist-fc7 would continue rolling, but the release and qa team would cherry-pick bugfix builds from dist-fc7 and tag them for 'fc7-test1'. The composes for the test release would come from this tag. This allows devel/ to continue rolling, but the release team has a way to work with a freeze for stabilization. Final releases will be a bit different. At the date of the final freeze, we'll create the SCM branch for that release at that time. devel/ builds will start going to the NEXT release collection, while bugfixes and pre-prepared updates would be built from the say FC-7/ branch. We all agreed that this seemed mostly sane as a proposal.

Updates discussion followed. This one made my head hurt :/ Mostly this is a change in how Extras does things. Right now, one can just build a package for a release and out it goes. Now we're asking maintainers to use a tool to marshal the updates. Using a tool allows the maintainer to input some reasoning behind the update, and give the release team a chance to "veto" the update. This keeps there from being 'gratuitous' rebuilds of packages for a release. The use of updates-testing will be enforced/encouraged, and one day we'd really like there to be a simple "vote" tool that you can use to either hate or love the update. Haters would be prompted for a quick reason why they hate, and hopefully that hate would get tossed at bugzilla automagically somehow. Before moving a package from -testing to released updates, either a timeout happens and there was no input, much love was received, or a suitable excuse for ignoring the hate is given. I think changing the way we do updates will be the biggest concession Extras will have to make when merging the two worlds.

Finally we talked about Lifecycle and Legacy. Now, I got into the Fedora community mostly by taking the Legacy ball and running with it. While it was a lot of fun and I learned a lot, I think nobody will disagree that it was a very difficult task to take on and while we mostly did an admirable job, we ultimately failed to deliver what was promised. Part of this was lack of decent infrastructure early on preventing more manpower from joining, as well as perhaps really less interest in having a longer lifespan when alternatives such as CentOS emerged. Because of this, the Fedora Project would like to rethink its lifecycle and what is reasonable expectation of what the community would like to see. Mostly what we've seen is that the community would like there to be a slightly longer official support time period so that one could reasonable move from FCN to FCN+2, effectively skipping a release, and even waiting for say a month after the release for the oops bugs to get fixed. Anything beyond this really seems to be corner cases that would really be better served by something like CentOS for free, RHEL for rock solid support, or Oracle for crackmonkies. This would extend the lifespan from 9~ months to 13~ months for a release. What does this mean for the "Legacy" project? We feel that the resources currently and in the past that have contributed to the Legacy project could be better used within the Fedora project space. In both the Fedora Security team (tracking and notification of issues that need updates), and in doing package updates for released products. By moving the packages to the external world, we're giving people direct access to make an update. Does this "kill" legacy? Perhaps. I like to think of it more as absorbing the Legacy energy and reusing it elsewhere. Was Legacy a failure? I take responsibility for the failure of Legacy to delivery what was promised. There were many factors to this, and I honestly thing one of the big ones was "Is there actual interest in having a 2 year lifespan for a given Fedora release." Are we closing the door on any Legacy like project? No, I don't think so. If somebody really thinks that 13 months isn't enough, and things like CentOS or RHEL aren't right either, by all means take our bits and run with them. As for infrastructure for such a thing, that's a question for if/when somebody wants to run with it. The above will be proposed to the current Legacy leadership for their thoughts.

Finally we talked a bunch with Will Woods about the state of QA and testing. I'm sure he has some fun stuff to blog about.

And now, I think I'm going to sleep before my brain drains out my ear.

This was me telling Eamon about the Microsoft/Novell deal.

Link | Share