[coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
mr.nuke.me at gmail.com
Wed Oct 28 16:43:37 CET 2015
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.
More information about the coreboot