Re: [coreboot] How is depreciating 95% of coreboot boards worth it for such minor improvements?

[ron minnich]

I am always sad to see boards go away, especially since it means that the
amount of coreboot I still have code in is smaller by the month, but ...
there's a real opportunity cost to keeping old boards in. We've had cases
where a new, useful feature has to be implemented as a config variable
since not all boards can support it. Frequently these are old boards and
there's nobody around to add it. Further, experience has shown us that over
time, even if nothing else changes, older boards just stop working due to
toolchain changes or even bug fixes. I've had this happen to me several
times, where I can't build a new image for a board that is "known good."
I'm not the only one.

It's a lot of work to keep a board current. We don't want coreboot to
become a repo of broken boards. If nobody can stand up and state they are
supporting a board, then it's time to end that board. And, as pointed out,
this is git, there are branches, so no board is ever really gone.

I think that for every board in the tip of tree, we should always have an
active maintainer. It's just too easy for them to break otherwise.

On Wed, Aug 23, 2017 at 1:13 PM Aaron Durbin via coreboot <
[e-mail]> wrote:
> On Wed, Aug 23, 2017 at 2:06 PM, Felipe Sanches 
> wrote:
> > Is there an index of which was the latest git commit for each removed
>
> board
> > ?
> > That would help anyone interested in working on them in the future. It is
> > not strictly necessary, but would certainly make life easier. And it
>
> can't
> > be that hard to update a wiki page (or something equivalent) any time
> > there's a new board deprecation.
>
> Keep in mind that branches exist for each release which inherently has
> the full history at time of release:
>
> $ git ls-remote upstream refs/heads/*
> 6cb3a59fd5e754c3627b79db21c5bcc284bfd721        refs/heads/4.1
> ad342a4589df6c51c96c1e9110979964b244fec3        refs/heads/4.2
> 1bf5e6409678d04fd15f9625460078853118521c        refs/heads/4.3
> 588ccaa9a7d94da4f5a5b3579eb9e3d06c9f4a51        refs/heads/4.4
> c21e07385f9b4048d6ddb67989b23999f566951d        refs/heads/classic-2014.10
> e9418b454f6d2734360ca4e3c017f59904490d9f        refs/heads/coreboot-v1
> 25d77ad675f8bac8fd7e038801c72797ea8dc7d6        refs/heads/coreboot-v3
> 4fcce9da0a1b62b46ed78c522f6fcbf51ff5974e        refs/heads/foo2
> f5fe3590af9a67f9fd3adaee85168d3cac0d84d0        refs/heads/master
> > 2017-08-23 16:53 GMT-03:00 Nico Huber :
> > > Hi,
> > >
> > > On 23.08.2017 06:00, [e-mail] wrote:
> > > > Just because a board lacks active developers doesn't mean that no one
>
> is
> > > > using it.
> > >
> > > right, and we won't stop anybody from using them in the future. Please
> > > keep in mind, when a board is removed from the tree that only means that
> > > the people working on newer boards don't maintain the old ones any more.
> > > You can still check out the parent of the removal commit and build these
> > > boards. I don't know which boards exactly are in question, but older
> > > board ports are often broken anyway. So you can't argue that keeping
> > > them in the tree would magically make them work.
> > > > As a layman I simply can't understand as to how all these seemingly
> > > > insignificant improvements such as CBMEM in ramstage make it worth
> > > > removing almost every compatible board from the source,
> > >
> > > I agree that these improvements would be insignificant to the boards in
> > > question. Though, making improvements at all for newer platforms is much
> > > harder if you have to take care of the old platforms (with incompatible
> > > code) too.
> > > > including nearly
> > > > all the models that still have an open source init.
> > >
> > > Can I see numbers please? I count about 50 Intel based boards (not
> > > counting variants) with free init code which is actively developed.
> > > There are more on the ARM front and probably some AMD based too. They'll
> > > all stay. How many are we going to remove?
> > > > To me it seems at the rate this is going soon all that will be left
>
> is a
> > > > few blobbed and NDA'ed development boards unavailable to the general
> > > > public.
> > >
> > > What rate? how many have we removed already? 2? If you estimate from
> > > that and the prospect that we'll remove 50+ one year later, well, then
> > > we'd remove 1,000+ boards next year. That would indeed be a problem...
> > > > Am I mistaken?
> > >
> > > Yes, I guess.
> > >
> > > Nico