Patch voting systems and accountability: propose only 1 approval to land patch.
by Tristan Van Berkom
Hi,
I've been wanting to spark a discussion around this but was unsure
of what venue to choose. As this fits with how we've been using gerrit
and now gitlab, I'll raise this here.
This is a proposal that we follow a more traditional maintenance style
for Baserock and also other projects we work on, specifically I would
like to see:
a.) A more limited group of maintainers / patch approvers
b.) Only one approval needed to land a patch in mainline
>From what I gather, the voting system is interesting as in it purports
to get more reviews done before landing any patches.
The is a noble idea, but I feel that the negative effects of this
outweigh the advantages these voting systems purport to achieve.
The key point here is that when somebody lands a patch on mainline in
any project, they put their reputation on the line. A patch approver
should bare the full weight of accountability for any and all side
effects which a given patch introduces to the project's user base (or
tentative user base, for projects who still have not achieved one).
The voting system is in my view condusive of an atmosphere where we, as
maintainers, externalize accountability by relying on others to
hypothetically share in the accountability for landing any given patch.
The result of such an atmosphere IMO can only be chaotic, we easliy let
bugs slip through the cracks as we become increasingly nonchalant about
pushing the "Approve" button.
This seems especially true with CI systems in which we place too much
trust. If we had to apply the patch locally and test it out using our
own reasoning and suspicions of what might break as a result (as we do
in more traditionally maintained projects), we would be more scrutinous
about landing patches and deliver a higher quality mainline.
Cheers,
-Tristan
PS:
I should add here, that it is entirely *fine* to make mistakes,
everybody makes mistakes and it's important for us to recognize them
and it's healthy to take a moment to laugh at yourself when your silly
mistake causes things to break which you did not foresee.
As individuals, we must own our mistakes in order to learn from them
and improve, assuming accountability and blame for your work is an
opportunity to own your mistakes.
Anecdote: at one R&D lab I worked with for many years, we had a monthly
"build breaker award" which I think helped to take the edge off and
encouraged a light hearted attitude towards embracing our mistakes.
6 years
Re: Patch voting systems and accountability: propose only 1 approval to land patch.
by Tristan Van Berkom
On Mon, 2017-02-27 at 09:16 +0000, Pedro Alvarez wrote:
> Hi Tristan
>
> On 27/02/2017 08:30, Tristan Van Berkom wrote:
> >
> > Hi,
> >
> > I've been wanting to spark a discussion around this but was
> > unsure
> > of what venue to choose. As this fits with how we've been using
> > gerrit
> > and now gitlab, I'll raise this here.
> >
> > This is a proposal that we follow a more traditional maintenance
> > style
> > for Baserock and also other projects we work on, specifically I
> > would
> > like to see:
> >
> > a.) A more limited group of maintainers / patch approvers
> > b.) Only one approval needed to land a patch in mainline
>
> I suggested that 2 approvals was too much a few days ago:
>
> https://irclogs.baserock.org/%23baserock.2017-02-09.log.html#t2017-
> 02-09T16:49:41
I see, this seems to be for a completely different reason, though, that
there is currently a lack of reviewers in Baserock currently. My
concern (inside and outside of Baserock) is more about when there are
plenty of reviewers.
> I think I agree, at least in (b), not sure yet in (a). How many
> maintainers would we have? Would they be allowed to merge their own
> patches? Who these maintainers would be?
I cut this part out of my original email as it's a particularly sticky
problem especially for Baserock.
I'll elaborate on my view though: There should always be one person (or
two or three) who are the ones left behind maintaining the code which
others contribute, they must be at least in agreement on the longer
term project goals and have the final word on overall project decisions
- a given project cannot survive or succeed without someone who
understands the big picture "plan" and can evaluate on a day to day
basis what criteria needs to be met for a successful outcome.
I think this just is as true for a community driven project as it is
for corporate driven work or consulting work, someone has to be in
charge of the "plan", at least for the short term milestone target, at
all times or any endeavor is almost certainly doomed to fail.
While there may be more patch reviewers in a core developer team, at
the very least this person who is left with the bits and pieces at the
end of the day, who is steering the ship, must be able to land patches
in the absence of reviewers.
Cheers,
-Tristan
>
> <snip>
>
> >
> > Anecdote: at one R&D lab I worked with for many years, we had a
> > monthly
> > "build breaker award" which I think helped to take the edge off and
> > encouraged a light hearted attitude towards embracing our mistakes.
>
> Heh, interesting idea :) we could try start getting some info for
> the
> first award.
>
> Pedro
>
6 years
Culling artifacts on a running kbas instance
by Paul Sherwood
Hi all,
currently kbas doesn't cull artifacts, so i've resorted to doing it
manually, to remove things that haven't been touched in six months.
Posting here in case it's of use to others (and so I don't forget the
runes).
find . -maxdepth 1 -mtime +180 -exec rm -fr {} \;
Obviously for folks wanting to **keep** old artifacts (eg important or
release artifacts) this would not be th right way
br
Paul
6 years, 1 month
