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