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