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.
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 <tpear...@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 expected 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 patches to 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 time. > > 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" <gauml...@gmail.com> > > To: "Peter Stuge" <pe...@stuge.se> > > Cc: "coreboot" <coreboot@coreboot.org> > > Sent: Thursday, May 2, 2019 4:16:41 PM > > Subject: [coreboot] Re: What maintenance is expected from coreboot > > developers & 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 <pe...@stuge.se> wrote: > >> > >> Martin Roth wrote: > >> > I'd like to discuss the issue of what's expected from developers after > >> > 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 push > >> > code to coreboot that there's an obligation to help maintain that code > >> > going forward. This seems to be different than if an individual adds > >> > 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 altruism, > >> in fact I believe that doing so could violate tax code in some > >> jursidictions. > >> > >> Given that companies engage in coreboot development with a resource (money) > >> profit motive I find it fair and just to expect that some of that profit > >> will be contributed back into the project, through "public good" > >> 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 companies. > >> And volunteers inherently tend to focus on "public good" contributions. > >> > >> I believe that everyone who sees the project activity maintains a mental > >> 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 companies > >> give more "public good" back than they take, other companies only ever > >> 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@coreboot.org > >> To unsubscribe send an email to coreboot-le...@coreboot.org > > _______________________________________________ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > _______________________________________________ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
