Hi Patrick,<div><br></div><div>Thanks for starting this discussion.<br><br><div class="gmail_quote">On Thu Nov 06 2014 at 11:58:03 AM Patrick Georgi <<a href="mailto:patrick@georgi-clan.de">patrick@georgi-clan.de</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
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".<br>
<br>
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.<br>
<br>
<br>
With that in mind, I want to throw out some ideas:<br>
<br>
* 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.<br>
<br></blockquote><div><br></div><div>I suspect that quarterly might be too frequent. May 2 or 3 times a year. That would give more time to test and stabilize. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* A number of weeks (2? 4?) before the official release date, we branch and only accept bug fixes into the branches.<br>
<br></blockquote><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* 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.<br>
<br></blockquote><div> </div><div>We could update the coreboot KERNELVERSION as part of the branch process. That will be helpful for for derivative works.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* 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) <br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
IMHO this gives us a couple of advantages over the current non-process:<br>
It gives us the opportunity for exposure to the world since releases tend to draw some media attention.<br>
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.<br>
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).<br>
<br>
<br></blockquote><div><br></div><div>These are all very valid reasons and I support any improvement was can make in releasing coreboot source.  Thanks for Starting the discussion</div><div><br></div><div>Marc</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is definitely written for discussion, not a blueprint I intend to implement ASAP.<br>
I'm not even sure if I still like the proposal tomorrow.<br>
Any specifics are just there to give the concept more meat, I have no idea if they work out.<br>
Maybe we don't even need anything like this?<br>
Consider it a conversation starter and add your comments :-)<br>
<br>
<br>
Thanks,<br>
Patrick<br>
<br>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a href="http://www.coreboot.org/mailman/listinfo/coreboot" target="_blank">http://www.coreboot.org/<u></u>mailman/listinfo/coreboot</a></blockquote></div></div>