----- Original Message -----
From: "Julius Werner"
To: "Timothy Pearson" <tpearson(a)raptorengineering.com>
Cc: "Martin Roth" <gaumless(a)gmail.com>om>, "Peter Stuge"
<peter(a)stuge.se>se>, "coreboot" <coreboot(a)coreboot.org>
Sent: Thursday, May 2, 2019 5:23:58 PM
Subject: Re: [coreboot] Re: What maintenance is expected from coreboot developers &
I don't think as an open-source project we can
really set hard
expectations of what a contributor does after their patch is landed,
regardless of whether it's an individual or a company. We don't make
our contributors sign contracts, after all. Any work on coreboot by
anyone is best effort, and anyone's priorities may change. I don't
think this is any different in other projects (e.g. Linux) either.
True, however we can still set expectation even if there is no way to enforce it. This
would be more of a social norm than a hard requirement, but it does help to know that if
you are e.g. pushing an entire board into coreboot, that to keep it in tree you are
expected to do <x> amount of work over the coming years. That in turn may (or may
not) influence the decisions to try to do a port / push the board upstream in the first
place, or in a corporate setting potentially get the additional resources allocated to
avoid merge / remove / merge cycles that are more expensive than merge / maintain.
> I think the only thing that matters in terms of "is being maintained"
> or not is at what point we remove code from the tree. To a certain
> extent, every committer has an obligation to make sure that new
> patches they add don't break existing platforms but of course there is
> a limit to how much a single person can test and how deep they can dig
> into unfamiliar code. A maintainer is mostly a person that can help
> committers make these kinds of changes in a way that won't break their
> platform (through reviews), can regularly test their platforms to make
> sure no silent breakages crept in (and fix those that did), and can
> work on supporting larger API changes that we decide as a community in
> their platform (e.g. something like dropping LATE_CBMEM_INIT).
> Whenever we have code somewhere that's clearly in need of someone like
> that but has nobody stepping up, we should consider removing it (which
> should be a case by case decision based on how much trouble it causes
> and how valuable it still is).
> On Thu, May 2, 2019 at 2:48 PM Timothy Pearson
> <tpearson(a)raptorengineering.com> wrote:
>> I would suggest the same industry standard maintenance period that would
>> normally apply to a commercial, closed source product. For instance, consumer
>> hardware might only receive a year or two of support from initial release, but
>> an embedded system might be more typically see 3-5 years or more. Especially
>> with the focus on using binary-only libraries with newer e.g. Intel platforms,
>> I don't see how maintenance of the coreboot portions can reasonably be
>> beyond the support period of the upstream software vendor. At the same time,
>> if a commercial product would see some degree of maintenance, we should expect
>> the same level of maintenance in the open product (coreboot) where feasible.
>> One interesting issue brought up is whether we should be expecting maintainers
>> to rewrite large chunks of code as the underlying coreboot APIs change. This
>> is where things differ from a normal closed source lifecycle, in that in the
>> closed source world "maintenance" can be as simple as applying small
>> a mothballed, static codebase and recompiling. In the open source world,
>> maintenance normally involves a continual treadmill of making sure the board
>> support is kept up to date as the underlying codebase continually changes.
>> While I am not advocating for the static approach, it should be recognized
>> that continual changes do cost something, and perhaps there should be more
>> emphasis on developers that are pushing widespread changes also ensuring that
>> all officially supported boards / chipsets / etc. are fixed up at the same
>> Just my $0.02, as a somewhat time strapped and not very good de facto maintainer
>> of parts of the legacy AMD codebase. :)
>> ----- Original Message -----
>> > From: "Martin Roth" <gaumless(a)gmail.com>
>> > To: "Peter Stuge" <peter(a)stuge.se>
>> > Cc: "coreboot" <coreboot(a)coreboot.org>
>> > Sent: Thursday, May 2, 2019 4:16:41 PM
>> > Subject: [coreboot] Re: What maintenance is expected from coreboot
>> > companies
>> > Thanks Peter,
>> > Is there a time limit that you think is appropriate to request
>> > maintenance for?
>> > Obviously it's not reasonable to request that they maintain it
>> > forever, but is 2 years after the initial push reasonable? 3 years?
>> > What level of maintenance would be expected? Would we just require
>> > bugfixes, or would adding new features to the chip be expected? Or
>> > even just reviews of code affecting their chip?
>> > Martin
>> > On Wed, May 1, 2019 at 10:01 AM Peter Stuge <peter(a)stuge.se> wrote:
>> >> Martin Roth wrote:
>> >> > I'd like to discuss the issue of what's expected from
>> >> > code is added to the coreboot tree.
>> >> Thanks for bringing this up.
>> >> > It seems like there's a feeling
>> >> > that if a company pushes code to coreboot, or hires someone to
>> >> > code to coreboot that there's an obligation to help maintain
>> >> > going forward. This seems to be different than if an individual
>> >> > code, but maybe I'm wrong.
>> >> That's about right, at least for me.
>> >> I assume that no company contributes to coreboot purely out of
>> >> in fact I believe that doing so could violate tax code in some
>> >> Given that companies engage in coreboot development with a resource
>> >> profit motive I find it fair and just to expect that some of that
>> >> will be contributed back into the project, through "public
>> >> contributions, which can include janitorial maintenance work as well as
>> >> much-requested feature development that noone else is working on.
>> >> Nobody wants to receive a code dump.
>> >> Volunteer contributors tend to not have resources comparable to
>> >> And volunteers inherently tend to focus on "public good"
>> >> I believe that everyone who sees the project activity maintains a
>> >> balance sheet of who has taken how much and who has given how much. At
>> >> least I do this. I think it's human nature.
>> >> My expectations derive from that (unspoken, subjective) balance sheet.
>> >> My experience is, however, another axis. In my experience, some
>> >> give more "public good" back than they take, other companies
>> >> take and never give anything at all back, and other companies still
>> >> will take, and try to give back, but fail to give back anything useful
>> >> out of ignorance in the best case, and give back something harmful on
>> >> purpose in the worst.
>> >> The maintenance story in coreboot has been a topic before, and
>> >> everyone (also every individual developer working for companies)
>> >> knows that a maintenance investment is required for the code not to
>> >> become perverted over time.
>> >> But someone has to spend money on that, and noone really wants to.
>> >> The Linux Foundation employs maintainers for this purpose. It might be
>> >> useful for coreboot to also employ maintainers, but I'd vehemently
>> >> argue *against* copying or joining the Linux Foundation, because it
>> >> continually make things worse rather than better.
>> >> One of the fundamental problems is the expectations its members have,
>> >> another is the (legal) culture in its jurisdiction.
>> >> //Peter
>> >> _______________________________________________
>> >> coreboot mailing list -- coreboot(a)coreboot.org
>> >> To unsubscribe send an email to coreboot-leave(a)coreboot.org
>> > _______________________________________________
>> > coreboot mailing list -- coreboot(a)coreboot.org
>> > To unsubscribe send an email to coreboot-leave(a)coreboot.org
>> coreboot mailing list -- coreboot(a)coreboot.org
> > To unsubscribe send an email to coreboot-leave(a)coreboot.org