Hi Patrick, Thanks for starting this discussion.
On Thu Nov 06 2014 at 11:58:03 AM Patrick Georgi <[email protected]> wrote: > Hi all, > > those walls of text recently certainly gave a lot of information to > digest. I'd like to discuss one aspect that got indirect coverage only, > which is the desire to have some boards be "stable" (for some definition of > stable). It comes up every now and then and this time it was in the form of > "please leave boards X, Y, Z alone". > > We have a pretty chaotic development process that allows for lots of > velocity all over the place. Unfortunately that makes the only useful > stable name in our repository ("master") quite unreliable for users. The > board-status script and wiki page is a nice approach, but given that every > board is tested on a different commit id, I wouldn't trust a "green" box > there to say anything more than that _exactly_ the tester's configuration > is going to work. For all I know, a theoretically suspend-capable board > tested without that feature enabled (never-mind that board-status doesn't > say anything about wake-up in the first place), may not even build with > suspend enabled because that part of the tree was broken in just that > revision. > > > With that in mind, I want to throw out some ideas: > > * Let's have regular release cycles. maybe quarterly, eg in the middle of > each quarter (that is, feb 15, may 15, aug 15, nov 15) to avoid certain > vacation-heavy periods. > > I suspect that quarterly might be too frequent. May 2 or 3 times a year. That would give more time to test and stabilize. > * A number of weeks (2? 4?) before the official release date, we branch > and only accept bug fixes into the branches. > > I am concerned about branching too soon and trying to maintain both master and branch. Personally, I would like to see master go through a bugfix period before branching. I think it would keep master healthier and minimize the merge back effort after release. > * for each release, we tag from the branch (so we have a _single_ commit > id for everything), do a nice write-up on which boards we know are > functional, known issues, and what notable changes there are compared to > the previous release. > > We could update the coreboot KERNELVERSION as part of the branch process. That will be helpful for for derivative works. * board-status gets extended to track branches and tags properly (we need > that for the classic branch already, since some boards are on the way out > on master) > IMHO this gives us a couple of advantages over the current non-process: > It gives us the opportunity for exposure to the world since releases tend > to draw some media attention. > And it may encourage some more focussed testing (on board-status) than the > current approach, which may increase participation - having your port > listed as working on the 2015.08 release notes is a bigger incentive than > some green box on some obscure wiki-page. > We can point people to certain revisions with more confidence (and with a > nicer name than a SHA1 of a random tree), which will make vendors' lives > easier (and in combination with that media exposure, also community support > on #coreboot and the list when people ask what revision to use). > > > These are all very valid reasons and I support any improvement was can make in releasing coreboot source. Thanks for Starting the discussion Marc This is definitely written for discussion, not a blueprint I intend to > implement ASAP. > I'm not even sure if I still like the proposal tomorrow. > Any specifics are just there to give the concept more meat, I have no idea > if they work out. > Maybe we don't even need anything like this? > Consider it a conversation starter and add your comments :-) > > > Thanks, > Patrick > > -- > coreboot mailing list: [email protected] > http://www.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
