Re: [BuildStream] Proposal: spreading responsibility and maintainership [Was: 1.4 Release timeline]

[Laurence Urhegyi <laurence urhegyi codethink co uk>]

On 2018-12-12 06:20, Tristan Van Berkom wrote:
> > In principle I agree, as this will hugely decrease notifications, but 
> > I 
> > know how useful the comments/discussions on a WIP MR can be for 
> > developers. Will leave it up to others to comment though.
>
> I don't disagree at all with that, but gitlab doesn't have a feature
> for it, it doesn't even have a feature to look at the merge requests UI
> and exclude the WIP merge requests.

No, it doesn't, sadly. I looked into 'locking' an MR when I composed 
this email, but that just means that only project members can comment 
and it won't affect notifications.

> While people can discuss their branches outside of gitlab, we cannot
> produce a clean feedback loop which excludes WIP stuff with the current
> gitlab limitations, and I strongly believe that including developers in
> the feedback loop is a necessary step towards empowering developers and
> putting the developers in the driver seat.

I wonder how other projects get around this?

I don't think it is too much to ask to ask those people who are doing 
full notification subscription to filter emails to avoid WIP MRs.

> [...]
> I don't like being the only one who has to say "no", any more than
> anyone else likes it. It takes its toll and results in some outbursts
> on my part, I apologize for that, and the very intent of this proposal
> is to try to create an atmosphere where that doesn't happen.

I understand. I think we can maintain high quality whilst being cordial. 
We can probably all do better at that sometimes :)

<snip>
> > For 'breaking changes' or seriously complex features, we need to 
> > encourage the contributors who will be developing the feature to be 
> > involved in the 'hard discussions' from the start of them (even if 
> > only 
> > a little, keeping abreast of them and providing a summary email that 
> > gets verified by the stakeholders, as happened with the workspace UX 
> > changes) or to provide a full breakdown of their understanding of the 
> > work to be undertaken before they start developing. This can then be 
> > referenced by reviewers at review time, instead of bottle-necking on 
> > the 
> > expertise of yourself and Juerg.
>
> Definitely this, and I would say it is an understatement.
>
> The individual who is going to implement a complex feature should be
> the individual who made the proposal on the mailing list, and it should
> be the same person representing the feature throughout the entire
> process.

+1

We've certainly seen this work well.

> Now, when you say that a developer should provide a full breakdown of
> the work to be undertaken, I think this goes beyond what individual
> changes need to be done, and extends to how the developer will approach
> the work, and what will be done in what order, and what will be tested
> and known to work before proceeding to the next step.
<snip>
> Does this distinction make sense to you ?

It does.

The important thing for the public proposal is to get to a full picture 
of the feature as a 'finished product', including overall architecture 
review and implications on elsewhere in the code.

> > Also, in lieu of not having the auotmated testing in place to be able 
> > to 
> > have a merge-bot, I am I strong advocate of the 'approval' feature in 
> > gitlab. I've seen it work well on Freedesktop-SDK (prior to the bot) 
> > and 
> > then on the BuildGrid project, where we set the policy to be 'one 
> > approval is needed on your MR before merge, by someone from the 
> > specified list'. This empowers people and they take it seriously, in 
> > my 
> > experience.
>
> I am more and more ambivalent about the approvers; especially if there
> is only one required approver and that those who have sufficient
> permissions can self approve.

I really like it. Again, comments from others are welcome.

One thing to consider is whether we try to categorise the codebase (as I 
started on the wiki and we could do with CODEOWNERS) and assign relevant 
approvers per area, or just give blanket access. I think the codebase is 
probably large enough to warrant the former.

> My main worry with approvers comes from my experience with gerrit's
> voting system, which I believe allows people to "pass the buck" when it
> comes to reviews, at least in the settings where I've used gerrit.

I don't know about gerrit's voting system but it sounds like a different 
thing to me.

Thanks,
Laurence