[coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release

[Peter Stuge]

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