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

[Wim Vervoorn]

Hello Alex,

I totally agree with your mail. This certainly looks like the way to deal with 
it.

We don't loose anything but make it easier to move forward with new designs at 
the same time when using branches.

BR Wim.





-Original Message-
From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Alex G.
Sent: Wednesday, October 28, 2015 4:56 AM
To: coreboot@coreboot.org
Subject: Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets 
for 4.2 release

On 10/27/2015 01:36 PM, Vladimir wrote:
> Although I agree with you that AMD is not innocent as well, if you 
> would check a "Binary situation" page at coreboot's wiki, you would 
> see that Intel is in three times more evil

Probably "evil" is a bad term. I doubt that there's an ill intent. There are 
customer (read OEMs) who want such "features". Remember the Lenovo laptops that 
only allowed you to connect white-listed wifi cards before they would boot? [1]

The real issue is that some of those "features" cannot be disabled, but that's 
a technical argument, and has nothing to do with evil vs good.

> (still could not understand why some
> incredibly talented coreboot developers are spending so much time 
> fighting Intel's ME issues,

I can't speak for others, but that allows me to continue to work on coreboot, 
while also paying the bills. In fact, there is a significant number of 
developers who pay their bills by working on coreboot. That's progress that 
coreboot wouldn't otherwise see.

> In any case, it would be very sad to see the AMD code gone from the 
> master branch. Even the code for some unpopular boards like Intel 
> Atom-based EOL "Mohron Peak" was allowed to stay!

There are two reasons for that, one technical, and another one political. On 
the technical side, there are users, and people stepped up to maintain that 
code. That's usually sufficient to allow code back in.

On the non-technical side, one or two of the developers who originally 
committed that code got very offended, angry, and blindsighted by the fact that 
it was removed. I won't go into the details.

> Why AMD boards are considered worse? The sole idea of AMD code going 
> away,

Who said AMD is worse? And who said AMD is going away? The whole idea is to 
move it to a separate branch. This has two advantages:
 * it's only concerned with agesa boards, so it's not constrained by the needs 
of other hardware
 * the master branch is no longer held back by the integration issues of agesa

Positive side-effects:
 * No longer need to build-verify AGESA for unrelated changes (AGESA boards 
take up more than half the server time)

> which will affect many alive-and-kicking coreboot-supported AMD 
> boards,

How will moving code around affect supported boards?

> is beyond my comprehension

BRANCH NOT EQUALS REMOVAL

Does that help?

Someone in this thread (was it you Stefan?) was also suggesting we wait until 
4.3 release before we "remove" AGESA code. I know this whole discussion started 
as "removing" stuff, but nobody wants to remove anything anymore. We've gotten 
smarter. We just make the effort more distributed and less centralized. I think 
moving to branches should be done sooner rather than later.

Here's a list of things I think should be moved to branches, right after the 
4.2 release:

* AGESA
reason: integration issues

* binaryPI
reason: integration issues

* FSP 1.0
reason: integration issues

* MRC boards
reason: sandy/ivy already has native init path. Some chromebooks have already 
been converted.

See the pattern? Now remember, this assumes branches are as first class 
citizens as 'master'. Look at chromiumos coreboot: plenty of branches.
That shows it can work.

If people apply that pattern, there are a few other things that could be 
branched, but I intentionally excluded:

* ROMCC-only boards:
why not: x86 bootblock still uses ROMCC, so there's no immediate value in 
removing boards that also need ROMCC for romstage. Maybe we should think of it 
for some future release, once we get more hardware to use CAR setup in the 
bootlock.

* google FSP boards (informally, FSP 1.1) why not: the FSP spec that's used on 
those boards is subject to change (and become 1.2, 1.3, etc), and there's no 
indication that we'll see significant integration issues if that happens/after 
it goes live.

Hope this clears things up,
Alex

[1] http://www.coreboot.org/images/6/68/Network_card_bios.jpg

> 
> On 27 October 2015 at 23:15, Timothy Pearson 
>  > wrote:
> 
> On 10/27/2015 03:10 PM, Vladimir wrote:
>> It would be really wrong to remove the whole AGESA code: there are 
>> AMD-based products which are still very alive and actively sold (at 
>> the developing markets) Moving the support for these products to a 
>> separate coreboot branch, could create many inconveniences for those 
>> AMD product owners who would like to test & use the latest and 
>> greatest coreboot
>> build: they will have to backpor

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

[Patrick Georgi]

2015-10-28 4:56 GMT+01:00 Alex G. :
> Here's a list of things I think should be moved to branches, right after
> the 4.2 release:
So far the idea was to drop things in master after a release, and
create branches for releases (as I did for 4.1 yesterday, in addition
to the tag).
So, when dropping stuff after the 4.2 release, to go back to these
things, you start from the 4.2 branch.

> Now remember, this assumes branches are as first class
> citizens as 'master'. Look at chromiumos coreboot: plenty of branches.
> That shows it can work.
There's a significant difference (and a problem that we'd inherit by
adopting the chromium gerrit model):

The difference is that Chromium firmware branches are made per-board
for devices where not many changes are expected.
The items you point out are most interesting for adding new boards
(nevermind if this actually happens - but the Lenovo *60 stuff wasn't
predicted a year before it happened either, 945 was "dead" then).
If we go for branches for that, developing FSP1.0 coreboot will look
quite different from master-coreboot.

The problem we have with firmware branches over at Chromium is that,
as far non-ChromeOS development is concerned, branches are where
commits are pushed to die. They're not folded back into mainline
Chromium nor coreboot.org. We don't really have a good solution for
that.

If we spawn tons of branches every time something becomes a bit
inconvenient to deal with, we're quickly devolving into u-boot:
vendors will just start maintaining their own branches, and porting
high level features between those requires an immense amount of effort
because there are many years of divergence between them.
If you want a taste of that, try building something on Chromium's
chromeos-2013.04 branch and then port it to upstream master. And that
was just 2.5 years.

tl;dr: hiding problems in branches won't serve us long-term.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

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

[Vladimir]

On 10/28/2015 04:56 AM, Alex Gagniuc wrote:
>
> How will moving [AGESA] code [to a separate branch] affect supported
[AMD] boards?
>

The biggest problem here is:

Various improvements and important bug fixes, that will be introduced to a
master branch and affect all the coreboot boards, will not be automatically
applied to that separate AMD branch. Those coreboot developers which have
AMD boards and want to constantly use and test latest and greatest coreboot
builds, they will have to constantly check the coreboot commit log and
backport all these improvements and fixes to their separate (and soon to be
abandoned) AMD branch. That will be adding lots of unnecessary manual work
and draining lots of workhours, which otherwise could have been spent on
writing the bug reports or improving a coreboot code which is common for
all the coreboot-supported boards.

As result, moving AGESA code will affect - and not only AMD boards: all the
coreboot supported boards will be indirectly negatively affected by that
change...

Luckily Timothy Pearson has advised a perfect solution for this issue:

On 28 October 2015 at 02:23, Timothy Pearson wrote:
>
> Perhaps in the short term we can port the remaining AGESA Fam15h boards
> to native init, and look into moving Fam14h to as much native as
> possible while still keeping the PSP happy with its blobs?
>

If the AGESA boards will be ported to a native init, they will be able to
continue to be supported by a master branch! That approach will allow
coreboot developers with AMD boards to avoid spending time on backporting
the changes and concentrate on developing and testing the latest coreboot
builds from a master branch

Best regards,
Vladimir Shipovalov

On 28 October 2015 at 11:32, Patrick Georgi  wrote:

> 2015-10-28 4:56 GMT+01:00 Alex G. :
> > Here's a list of things I think should be moved to branches, right after
> > the 4.2 release:
> So far the idea was to drop things in master after a release, and
> create branches for releases (as I did for 4.1 yesterday, in addition
> to the tag).
> So, when dropping stuff after the 4.2 release, to go back to these
> things, you start from the 4.2 branch.
>
> > Now remember, this assumes branches are as first class
> > citizens as 'master'. Look at chromiumos coreboot: plenty of branches.
> > That shows it can work.
> There's a significant difference (and a problem that we'd inherit by
> adopting the chromium gerrit model):
>
> The difference is that Chromium firmware branches are made per-board
> for devices where not many changes are expected.
> The items you point out are most interesting for adding new boards
> (nevermind if this actually happens - but the Lenovo *60 stuff wasn't
> predicted a year before it happened either, 945 was "dead" then).
> If we go for branches for that, developing FSP1.0 coreboot will look
> quite different from master-coreboot.
>
> The problem we have with firmware branches over at Chromium is that,
> as far non-ChromeOS development is concerned, branches are where
> commits are pushed to die. They're not folded back into mainline
> Chromium nor coreboot.org. We don't really have a good solution for
> that.
>
> If we spawn tons of branches every time something becomes a bit
> inconvenient to deal with, we're quickly devolving into u-boot:
> vendors will just start maintaining their own branches, and porting
> high level features between those requires an immense amount of effort
> because there are many years of divergence between them.
> If you want a taste of that, try building something on Chromium's
> chromeos-2013.04 branch and then port it to upstream master. And that
> was just 2.5 years.
>
> tl;dr: hiding problems in branches won't serve us long-term.
>
>
> Patrick
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

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

[Patrick Georgi]

2015-10-28 13:59 GMT+01:00 Vladimir :
> If the AGESA boards will be ported to a native init, they will be able to
> continue to be supported by a master branch! That approach will allow
> coreboot developers with AMD boards to avoid spending time on backporting
> the changes and concentrate on developing and testing the latest coreboot
> builds from a master branch
I agree. Patches accepted.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

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

[Aaron Durbin]

On Wed, Oct 28, 2015 at 3:32 AM, Patrick Georgi  wrote:
> 2015-10-28 4:56 GMT+01:00 Alex G. :
>> Here's a list of things I think should be moved to branches, right after
>> the 4.2 release:
> So far the idea was to drop things in master after a release, and
> create branches for releases (as I did for 4.1 yesterday, in addition
> to the tag).
> So, when dropping stuff after the 4.2 release, to go back to these
> things, you start from the 4.2 branch.
>
>> Now remember, this assumes branches are as first class
>> citizens as 'master'. Look at chromiumos coreboot: plenty of branches.
>> That shows it can work.
> There's a significant difference (and a problem that we'd inherit by
> adopting the chromium gerrit model):
>
> The difference is that Chromium firmware branches are made per-board
> for devices where not many changes are expected.
> The items you point out are most interesting for adding new boards
> (nevermind if this actually happens - but the Lenovo *60 stuff wasn't
> predicted a year before it happened either, 945 was "dead" then).
> If we go for branches for that, developing FSP1.0 coreboot will look
> quite different from master-coreboot.
>
> The problem we have with firmware branches over at Chromium is that,
> as far non-ChromeOS development is concerned, branches are where
> commits are pushed to die. They're not folded back into mainline
> Chromium nor coreboot.org. We don't really have a good solution for
> that.
>
> If we spawn tons of branches every time something becomes a bit
> inconvenient to deal with, we're quickly devolving into u-boot:
> vendors will just start maintaining their own branches, and porting
> high level features between those requires an immense amount of effort
> because there are many years of divergence between them.
> If you want a taste of that, try building something on Chromium's
> chromeos-2013.04 branch and then port it to upstream master. And that
> was just 2.5 years.
>

That presupposes there is work going on in those branches that is
desired to be pushed back into another branch. Anyone can very much
port forward something if they so choose. That's the point of the
branching mechanism.

What is your proposal for dealing w/ inconvenience? I haven't seen a
modicum of change in that area. In fact, what we have seen is more
boards being added that use the constructs that are inconvenient. From
the few years that I have been involved in this project I have seen
the airplanes pile up in the graveyard. So basically, it seems like
status quo rules. Or the time horizon for change is so long (10 years)
that the result is accumulation of more cruft? To add insult to injury
there's no tenable way of making changes in these areas because the
physical resources are not readily available to test against. As such
there is no progress in fixing those inconveniences which in turn
means an ever increasing burden for making non-periphery changes.

Ignoring the #include "file.c" constructs, a large majority of the
mainboards drive romstage flow entirely within those directories. i.e.
main() starts in mainboard. There is no common/consistent flow for
romstage on x86. That requires chipset as well as mainboard changes to
rectify. How do you propose one goes about doing that? Build test it?
Then have someone come 6 months later and say "hey, this doesn't
work."

> tl;dr: hiding problems in branches won't serve us long-term.

What does serve us long-term? And what are those goals? Is it
quantifiable by the number of mainboards checked into the coreboot.org
repo that build regardless of the maintenance burden?

>
>
> Patrick
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: 
> Hamburg
> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

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

[Aaron Durbin]

On Wed, Oct 28, 2015 at 7:59 AM, Vladimir  wrote:
> On 10/28/2015 04:56 AM, Alex Gagniuc wrote:
>>
>> How will moving [AGESA] code [to a separate branch] affect supported [AMD]
>> boards?
>>
>
> The biggest problem here is:
>
> Various improvements and important bug fixes, that will be introduced to a
> master branch and affect all the coreboot boards, will not be automatically
> applied to that separate AMD branch. Those coreboot developers which have
> AMD boards and want to constantly use and test latest and greatest coreboot
> builds, they will have to constantly check the coreboot commit log and
> backport all these improvements and fixes to their separate (and soon to be
> abandoned) AMD branch. That will be adding lots of unnecessary manual work
> and draining lots of workhours, which otherwise could have been spent on
> writing the bug reports or improving a coreboot code which is common for all
> the coreboot-supported boards.

Those developers should then take a more active role in improving the
code that is applicable to them. As it stands now, I don't see any
work going in improving those code bases.

>
> As result, moving AGESA code will affect - and not only AMD boards: all the
> coreboot supported boards will be indirectly negatively affected by that
> change...
>
> Luckily Timothy Pearson has advised a perfect solution for this issue:
>
> On 28 October 2015 at 02:23, Timothy Pearson wrote:
>>
>> Perhaps in the short term we can port the remaining AGESA Fam15h boards
>> to native init, and look into moving Fam14h to as much native as
>> possible while still keeping the PSP happy with its blobs?
>>
>
> If the AGESA boards will be ported to a native init, they will be able to
> continue to be supported by a master branch! That approach will allow
> coreboot developers with AMD boards to avoid spending time on backporting
> the changes and concentrate on developing and testing the latest coreboot
> builds from a master branch

There's more to it than just moving to native init. That doesn't
remove the maintenance burden.

>
> Best regards,
> Vladimir Shipovalov
>
> On 28 October 2015 at 11:32, Patrick Georgi  wrote:
>>
>> 2015-10-28 4:56 GMT+01:00 Alex G. :
>> > Here's a list of things I think should be moved to branches, right after
>> > the 4.2 release:
>> So far the idea was to drop things in master after a release, and
>> create branches for releases (as I did for 4.1 yesterday, in addition
>> to the tag).
>> So, when dropping stuff after the 4.2 release, to go back to these
>> things, you start from the 4.2 branch.
>>
>> > Now remember, this assumes branches are as first class
>> > citizens as 'master'. Look at chromiumos coreboot: plenty of branches.
>> > That shows it can work.
>> There's a significant difference (and a problem that we'd inherit by
>> adopting the chromium gerrit model):
>>
>> The difference is that Chromium firmware branches are made per-board
>> for devices where not many changes are expected.
>> The items you point out are most interesting for adding new boards
>> (nevermind if this actually happens - but the Lenovo *60 stuff wasn't
>> predicted a year before it happened either, 945 was "dead" then).
>> If we go for branches for that, developing FSP1.0 coreboot will look
>> quite different from master-coreboot.
>>
>> The problem we have with firmware branches over at Chromium is that,
>> as far non-ChromeOS development is concerned, branches are where
>> commits are pushed to die. They're not folded back into mainline
>> Chromium nor coreboot.org. We don't really have a good solution for
>> that.
>>
>> If we spawn tons of branches every time something becomes a bit
>> inconvenient to deal with, we're quickly devolving into u-boot:
>> vendors will just start maintaining their own branches, and porting
>> high level features between those requires an immense amount of effort
>> because there are many years of divergence between them.
>> If you want a taste of that, try building something on Chromium's
>> chromeos-2013.04 branch and then port it to upstream master. And that
>> was just 2.5 years.
>>
>> tl;dr: hiding problems in branches won't serve us long-term.
>>
>>
>> Patrick
>> --
>> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
>> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
>> Hamburg
>> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

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

[Peter Stuge]

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.

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.

We don't have the manpower of the Linux kernel however. And I don't
that you're volunteering to maintain the branch, Alex?

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.

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.

It's not a good idea to sweep older code under a branchy carpet until
newer code is generally felt to be equal or better. I don't think
that's the case yet, it's just too early.


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

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

[Patrick Georgi]

2015-10-28 14:50 GMT+01:00 Aaron Durbin :
> That presupposes there is work going on in those branches that is
> desired to be pushed back into another branch. Anyone can very much
> port forward something if they so choose. That's the point of the
> branching mechanism.
>
> What is your proposal for dealing w/ inconvenience? I haven't seen a
> modicum of change in that area. In fact, what we have seen is more
> boards being added that use the constructs that are inconvenient.
For one: when things are considered too inconvenient (and used and
maintained) to be practical to keep around, remove them. For real.
Claiming that we can stuff them "in branches" is a cop-out, because
they're still dead.

That's also why I proposed to go with tags for releases: When people
are motivated enough to dig out the old stuff and make it work again,
there should be some incentive to bring them up to current standards.
Then they can get back into master.
If somebody is spearheading such an effort and provides test
resources, I think there's even some willingness to help with some of
the more mechanical tasks - like cleaning out #include "file.c" stuff,
but the motivation is rather hard to get by when it's unclear if the
code is ever used again.

People can still take any old commit (tagged, branched, or not) and do
their own thing on github - however I think we're setting standards by
what we do. Opening branches encourages to keep basing work on them,
instead of considering snapshots to be just that.

My main objection to dropping things was that the motivation by the
proponents always looked very similar to "this is inconvenient to me
right now, let's get rid of this".
If we were consequential in following up every such sentiment by
everyone, we'd probably ship a single file, COPYING.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

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

[Aaron Durbin]

On Wed, Oct 28, 2015 at 9:15 AM, Patrick Georgi  wrote:
> 2015-10-28 14:50 GMT+01:00 Aaron Durbin :
>> That presupposes there is work going on in those branches that is
>> desired to be pushed back into another branch. Anyone can very much
>> port forward something if they so choose. That's the point of the
>> branching mechanism.
>>
>> What is your proposal for dealing w/ inconvenience? I haven't seen a
>> modicum of change in that area. In fact, what we have seen is more
>> boards being added that use the constructs that are inconvenient.
> For one: when things are considered too inconvenient (and used and
> maintained) to be practical to keep around, remove them. For real.
> Claiming that we can stuff them "in branches" is a cop-out, because
> they're still dead.
>
> That's also why I proposed to go with tags for releases: When people
> are motivated enough to dig out the old stuff and make it work again,
> there should be some incentive to bring them up to current standards.
> Then they can get back into master.
> If somebody is spearheading such an effort and provides test
> resources, I think there's even some willingness to help with some of
> the more mechanical tasks - like cleaning out #include "file.c" stuff,
> but the motivation is rather hard to get by when it's unclear if the
> code is ever used again.

Where is that motivation now? There is no one providing the resources
so the answer is status quo which in turn means an insanely daunting
task in trying to clean up things that just so happen to touch 90% of
the mainboards because of the existing code flow/design. Without the
resources nothing can be done which means accumulation of cruft and no
idea if anyone uses anything. What's the end game there?

Maybe it doesn't matter because all the work required has been
completed going forward so one can just keep cranking out boards, but
I suspect that is not the case. And when another requirement surfaces
that no one was anticipating do we add yet another API/subset on how
to do things? Where's the common base to work against?

>
> People can still take any old commit (tagged, branched, or not) and do
> their own thing on github - however I think we're setting standards by
> what we do. Opening branches encourages to keep basing work on them,
> instead of considering snapshots to be just that.

What are the standards we're setting?

>
> My main objection to dropping things was that the motivation by the
> proponents always looked very similar to "this is inconvenient to me
> right now, let's get rid of this".
> If we were consequential in following up every such sentiment by
> everyone, we'd probably ship a single file, COPYING.

I think you're taking such a notion to the extreme. Probably the
superset of opinion may be that, but I don't think that's practical
nor helpful in this discussion. I've cited very specific things that I
have run into within my development, and I don't see a solution aside
from "tred lightly, hold your nose, and hope for the best". I'd be
happy to help support said improvement work, but there's no path for
such things, and the carrot of getting back into the sacred master
branch is apparently unpalatable for people.

From my vantage point it seems people want the playground they grew up
with and knew and loved. Therefore, don't ever change my playground.

>
>
> Patrick
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: 
> Hamburg
> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

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

[Alex G.]

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

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

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

[Martin Roth]

It seems that we've got more issues than we can address before the
proposed 4.2 release date within the next few days - we're trying to
get this out in October.

Maybe it's time for another 'Major' release where we can remove more
than just the few mainboards and truly obsolete code that I was
thinking of when I started this conversation.

Is there anyone against removal of any of these boards/chipsets after
the 4.2 release, or should we wait for a decision about handling all
of the current issues before we delete anything?

   mainboard/via/epia-m700 - http://review.coreboot.org/#/c/7470
   northbridge/via/vx800 - http://review.coreboot.org/#/c/7471
 * arima/hdama - CPU: _AMD_SOCKET_940 NB: AMDK8, SB: AMD8111, SB: AMD8131
 * digitallogic/adl855pc - CPU: INTEL_SOCKET_MPGA479M, NB: INTEL_I855,
SB: INTEL_I82801DX
 * ibm/e325 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * ibm/e326 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * iwill/dk8s2 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * iwill/dk8x - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * newisys/khepri  - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * tyan/s2735 - CPU: INTEL_SOCKET_MPGA604, NB: INTEL_E7501, SB:
INTEL_I82870, SB: INTEL_I82801EX
 * tyan/s2850 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111
 * tyan/s2875 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8151
 * tyan/s2880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * tyan/s2881 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * tyan/s2882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * tyan/s2885 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB:
AMD8131, SB: AMD8151
 * tyan/s2891 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131
 * tyan/s2892 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131
 * tyan/s2895 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131
 * tyan/s4880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * tyan/s4882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131


I'd vote against the removal of any of the AGESA codebases for this
release with the possible exception of the Family 12 codebase.  It's
only used in the torpedo mainboard, and even that's not well
supported.
I'd vote against the removal of any of the Intel FSP codebases for
this release.  They are recent, and they are definitely still being
used.  Even Rangeley.  Yes, they have their issues.

I could support moving platforms off to the 4.X branch if we decide to
create a 5.0 branch to move forward and get things cleaned up.  Still,
having dealt with several different forks of the coreboot code, my
opinion is that branching is basically going to end the support for
these platforms.  Of course the people that don't use those platforms
don't care whether coreboot is killed off for those platforms, so I'd
ask that these platforms that we're choosing to die be picked
carefully.



On Wed, Oct 28, 2015 at 8:30 AM, Aaron Durbin  wrote:
> On Wed, Oct 28, 2015 at 9:15 AM, Patrick Georgi  wrote:
>> 2015-10-28 14:50 GMT+01:00 Aaron Durbin :
>>> That presupposes there is work going on in those branches that is
>>> desired to be pushed back into another branch. Anyone can very much
>>> port forward something if they so choose. That's the point of the
>>> branching mechanism.
>>>
>>> What is your proposal for dealing w/ inconvenience? I haven't seen a
>>> modicum of change in that area. In fact, what we have seen is more
>>> boards being added that use the constructs that are inconvenient.
>> For one: when things are considered too inconvenient (and used and
>> maintained) to be practical to keep around, remove them. For real.
>> Claiming that we can stuff them "in branches" is a cop-out, because
>> they're still dead.
>>
>> That's also why I proposed to go with tags for releases: When people
>> are motivated enough to dig out the old stuff and make it work again,
>> there should be some incentive to bring them up to current standards.
>> Then they can get back into master.
>> If somebody is spearheading such an effort and provides test
>> resources, I think there's even some willingness to help with some of
>> the more mechanical tasks - like cleaning out #include "file.c" stuff,
>> but the motivation is rather hard to get by when it's unclear if the
>> code is ever used again.
>
> Where is that motivation now? There is no one providing the resources
> so the answer is status quo which in turn means an insanely daunting
> task in trying to clean up things that just so happen to touch 90% of
> the mainboards because of the existing code flow/design. Without the
> resources nothing can be done which means accumulation of cruft and no
> idea if anyone uses anything. What's the end game there?
>
> Maybe it doesn't matter because all the work required has been
> completed going forward so one can just keep cranking out boards, but
> I suspect that is not th

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

[ron minnich]

IIRC I did the IBM e325/6 back in the day and I'm happy to see it die.

ron

On Wed, Oct 28, 2015 at 8:49 AM Martin Roth  wrote:

> It seems that we've got more issues than we can address before the
> proposed 4.2 release date within the next few days - we're trying to
> get this out in October.
>
> Maybe it's time for another 'Major' release where we can remove more
> than just the few mainboards and truly obsolete code that I was
> thinking of when I started this conversation.
>
> Is there anyone against removal of any of these boards/chipsets after
> the 4.2 release, or should we wait for a decision about handling all
> of the current issues before we delete anything?
>
>mainboard/via/epia-m700 - http://review.coreboot.org/#/c/7470
>northbridge/via/vx800 - http://review.coreboot.org/#/c/7471
>  * arima/hdama - CPU: _AMD_SOCKET_940 NB: AMDK8, SB: AMD8111, SB: AMD8131
>  * digitallogic/adl855pc - CPU: INTEL_SOCKET_MPGA479M, NB: INTEL_I855,
> SB: INTEL_I82801DX
>  * ibm/e325 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
>  * ibm/e326 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
>  * iwill/dk8s2 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
>  * iwill/dk8x - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
>  * newisys/khepri  - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB:
> AMD8131
>  * tyan/s2735 - CPU: INTEL_SOCKET_MPGA604, NB: INTEL_E7501, SB:
> INTEL_I82870, SB: INTEL_I82801EX
>  * tyan/s2850 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111
>  * tyan/s2875 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8151
>  * tyan/s2880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
>  * tyan/s2881 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
>  * tyan/s2882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
>  * tyan/s2885 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB:
> AMD8131, SB: AMD8151
>  * tyan/s2891 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB:
> AMD8131
>  * tyan/s2892 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB:
> AMD8131
>  * tyan/s2895 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB:
> AMD8131
>  * tyan/s4880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
>  * tyan/s4882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
>
>
> I'd vote against the removal of any of the AGESA codebases for this
> release with the possible exception of the Family 12 codebase.  It's
> only used in the torpedo mainboard, and even that's not well
> supported.
> I'd vote against the removal of any of the Intel FSP codebases for
> this release.  They are recent, and they are definitely still being
> used.  Even Rangeley.  Yes, they have their issues.
>
> I could support moving platforms off to the 4.X branch if we decide to
> create a 5.0 branch to move forward and get things cleaned up.  Still,
> having dealt with several different forks of the coreboot code, my
> opinion is that branching is basically going to end the support for
> these platforms.  Of course the people that don't use those platforms
> don't care whether coreboot is killed off for those platforms, so I'd
> ask that these platforms that we're choosing to die be picked
> carefully.
>
>
>
> On Wed, Oct 28, 2015 at 8:30 AM, Aaron Durbin  wrote:
> > On Wed, Oct 28, 2015 at 9:15 AM, Patrick Georgi 
> wrote:
> >> 2015-10-28 14:50 GMT+01:00 Aaron Durbin :
> >>> That presupposes there is work going on in those branches that is
> >>> desired to be pushed back into another branch. Anyone can very much
> >>> port forward something if they so choose. That's the point of the
> >>> branching mechanism.
> >>>
> >>> What is your proposal for dealing w/ inconvenience? I haven't seen a
> >>> modicum of change in that area. In fact, what we have seen is more
> >>> boards being added that use the constructs that are inconvenient.
> >> For one: when things are considered too inconvenient (and used and
> >> maintained) to be practical to keep around, remove them. For real.
> >> Claiming that we can stuff them "in branches" is a cop-out, because
> >> they're still dead.
> >>
> >> That's also why I proposed to go with tags for releases: When people
> >> are motivated enough to dig out the old stuff and make it work again,
> >> there should be some incentive to bring them up to current standards.
> >> Then they can get back into master.
> >> If somebody is spearheading such an effort and provides test
> >> resources, I think there's even some willingness to help with some of
> >> the more mechanical tasks - like cleaning out #include "file.c" stuff,
> >> but the motivation is rather hard to get by when it's unclear if the
> >> code is ever used again.
> >
> > Where is that motivation now? There is no one providing the resources
> > so the answer is status quo which in turn means an insanely daunting
> > task in trying to clean up things that just so happen to touch 90% of
> > the mainboards because of the existing code flow/design. With

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

[Stefan Reinauer]

* Aaron Durbin  [151028 14:52]:
> > Various improvements and important bug fixes, that will be introduced to a
> > master branch and affect all the coreboot boards, will not be automatically
> > applied to that separate AMD branch. Those coreboot developers which have
> > AMD boards and want to constantly use and test latest and greatest coreboot
> > builds, they will have to constantly check the coreboot commit log and
> > backport all these improvements and fixes to their separate (and soon to be
> > abandoned) AMD branch. That will be adding lots of unnecessary manual work
> > and draining lots of workhours, which otherwise could have been spent on
> > writing the bug reports or improving a coreboot code which is common for all
> > the coreboot-supported boards.
> 
> Those developers should then take a more active role in improving the
> code that is applicable to them. As it stands now, I don't see any
> work going in improving those code bases.

And there I am, waiting for people to review my AMD64 cleanup patches
since July ;-) hint hint. 

Stefan


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [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

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot