Patrick Georgi wrote:
branches are where commits are pushed to die.
Yes, this is a very important point, and is why I don't support Alex' proposal of moving some things to live only on a branch, and not on master.
Branches *can* work really well, but only when there is a person and/or team actively maintaining that branch, and for that to work well, the branch needs to have a fairly clear policy. The best example of this is the Linux kernel.
We don't have the manpower of the Linux kernel however. And I don't that you're volunteering to maintain the branch, Alex?
I'd like to propose that without a designated maintainer stepping up we don't create branches other than per the release process that we're starting to get into.
The AGESA code and older FSP and the other things you list are yes older and less shiny than the new native code, but also more proven.
It's not a good idea to sweep older code under a branchy carpet until newer code is generally felt to be equal or better. I don't think that's the case yet, it's just too early.
//Peter
On 10/28/2015 07:00 AM, Peter Stuge wrote:
Patrick Georgi wrote:
branches are where commits are pushed to die.
Yes, this is a very important point, and is why I don't support Alex' proposal of moving some things to live only on a branch, and not on master.
So, tagging and removing is better than a branch where people can continue to work, and submit patches via coreboot.org? I guess we'd much rather just remove stuff than allow people to continue using it, right? I guess we want to disallow people the ability to backport features to their hardware, and just remove it instead.
Branches *can* work really well, but only when there is a person and/or team actively maintaining that branch, and for that to work well, the branch needs to have a fairly clear policy. The best example of this is the Linux kernel.
If branches die out they die out. That means there isn't interest in that hardware. Big deal.
We don't have the manpower of the Linux kernel however. And I don't that you're volunteering to maintain the branch, Alex?
Do you offer to maintain the problematic code going forward?
I'd like to propose that without a designated maintainer stepping up we don't create branches other than per the release process that we're starting to get into.
I'd like to propose that without a designated maintainer stepping up, we just remove the code. Experience tells us that people are silent until their (broken) toys are taken away, and only then start crying. Just look at the fiasco (in no particular order) Marc, Martin, and Ron caused after sandybrdge fsp got removed. Branches might prevent that.
The AGESA code and older FSP and the other things you list are yes older and less shiny than the new native code, but also more proven.
The need to make changes to core code whenever a new mainboard is added is proven indeed.
Alex
Alex G. wrote:
branches are where commits are pushed to die.
Yes, this is a very important point, and is why I don't support Alex' proposal of moving some things to live only on a branch, and not on master.
So, tagging and removing is better than a branch where people can continue to work, and submit patches via coreboot.org?
I think you are confusing things. I disagree with removing the things you listed.
Here's a brief summary of the release process as I understand it:
For each release a tag and a branch are created, and on master some old things are then immediately removed. I disagree with removing the things you have listed for this release.
The community works on what interests them. Some work will go only into the post-release branch, and some work goes only into master. That's OK.
The post-release branch is second class in the sense that anything happening there does not have to fit into master. It is first class in the sense that larger changes in master do not have to be worked into code removed after the release.
However, this is not what we are discussing.
We are discussing whether the things you listed should stay on master or not, after the current release, and I strongly feel that most if not all of them should.
I do not think that there is any urgency.
Branches *can* work really well, but only when there is a person and/or team actively maintaining that branch, and for that to work well, the branch needs to have a fairly clear policy. The best example of this is the Linux kernel.
If branches die out they die out. That means there isn't interest in that hardware. Big deal.
I'm afraid it just isn't that simple.
We don't have the manpower of the Linux kernel however. And I don't that you're volunteering to maintain the branch, Alex?
Do you offer to maintain the problematic code going forward?
We are already doing all right there, and I don't see it as problematic.
I'd like to propose that without a designated maintainer stepping up we don't create branches other than per the release process that we're starting to get into.
I'd like to propose that without a designated maintainer stepping up, we just remove the code.
I think that's too large a change compared to how the community has worked before to be either practical or useful.
I don't think this is a bad end goal for us to have, but I also don't believe that we can go from A to Z in a single step.
Just look at the fiasco (in no particular order) Marc, Martin, and Ron caused after sandybrdge fsp got removed.
From what I can tell that was caused by you, but that's getting off topic.
//Peter
On Mi, 2015-10-28 at 08:43 -0700, Alex G. wrote:
On 10/28/2015 07:00 AM, Peter Stuge wrote:
Patrick Georgi wrote:
branches are where commits are pushed to die.
Yes, this is a very important point, and is why I don't support Alex' proposal of moving some things to live only on a branch, and not on master.
So, tagging and removing is better than a branch where people can continue to work, and submit patches via coreboot.org?
Typically branches are used for two purposes:
(1) stable releases. Tag v4.2, branch off, possibly tag v4.2.1 bugfix Typically no development happens here, often projects even have the policy that fixes need to land in master before they are allowed to be cherry-picked into a stable branch.
(2) development branches. New stuff, intended to be merged in master.
Have a branch to park unliked code there is just a bad excuse IMO. Don't do that.
If there is dead code, i.e. boards not being sold any more and not having seen updates (other than tree-wide cleanups) for years -- just remove them, and document the last release supporting that hardware.
For AGESA I don't think it should be removed. Even if the plan is to obsolete the code some day with native support in codeboot -- I think for the time being it is useful for developers to be able to look at the code, to be able to build agesa/native versions of a board from the same coreboot code base, for regression testing and bringing native on par with agesa ...
cheers, Gerd
-
Alex G. -
Gerd Hoffmann -
Peter Stuge