On Sat, Mar 03, 2018 at 05:13:25PM -0800, Andres Freund wrote:
> Reviewing whether the implementation is good enough *does* use
> resources. Our scarcest resource isn't patch contributions, it's
> dealing with review and maintenance.
This is true. One thing that patch authors tend to easily forget is
that a patch merged into the development branch means in no way that the
work is done, it is only the beginning. Even if it is the committer's
responsibility to maintain a feature because by committing he accepts to
take the maintenance load, the author should also help with things as
the person who knows the pushed code as much as the committer himself.
The more patches pushed, the more maintenance load. Careful peer review
is critical in being able to measure if a feature is going to cost much
in maintenance or not in the years following its commit.
> A lot of contributors, including serial ones, don't even remotely put in
> as much resources reviewing other people's patches as they use up in
> reviewer and committer bandwidth. You certainly have contributed more
> patches than you've reviewed for example. That fundamentally can't
> scale, unless some individual contribute way more review resources than
> they use up, and that's not something many people afford nor want.
This problem has existed for years, and has existed since I managed my
first commit fest. In my opinion, it is easier to give value in a
company to new and shiny features than to bug tasks, so people tend to
give priority to features over maintenance, because they give more value
to their own career as new features are mainly seen as individual
achievements, while maintenance is a collective achievement, as this
involves most of the time fixing a problem that somebody else
introduced. That's sad I think, maintenance should be given more value
as this is in the area of teamwork-related metrics.
--
Michael
