[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Workflow changes proposal for 2025



Thanks everybody for feedback!

Nice to see a lot of people participated in the discussion this week.

Based on the and some people being against having merge requests as
part of the recommended workflow, and some also objected having Salsa
CI as part of the team workflow, I decided to split that now out into
https://salsa.debian.org/go-team/go-team.pages.debian.net/-/merge_requests/8.
We might revisit that some other day.

I will now merge this part of the proposal that seemed to be supported
by the overwhelming majority via
https://salsa.debian.org/go-team/go-team.pages.debian.net/-/merge_requests/7

Two small comments:

> That said, I do not have strong opinions at all. You have somewhat
> convinced me to spend some time on code reviews. If someone pings me for
> a review, I would not mind spending sometime there, but I don't think I
> would do drive-by reviews regularly.

Thanks for at least spending some time on reviews. Perhaps your
opinion of their usefulness may change over time if we have get to
have a fast and smoot review workflow.

> > > Even the NM step ensures that a DD knows when to ask for help, and I
> > > will seek help when I need it, just like I have in the past.
> >
> > This seems to indicate that you don't want to have feedback, nor want
> > to give feedback, but rather only reach out to other team members *if*
> > you have a specific question, and probably assume other team members
> > would engage only if they have questions or if they need help.
>
> Don't you think Debian operates a lot like that in general? IRC, mailing
> lists, and other communication channels are often used when someone
> needs help or feedback on something, rather than for reviews on every
> small change, right?

IRC and mailing lists are very bad for code reviews, so no, they don't
happen much and I hope they don't happen at all now that we have
proper code review tooling and UIs to be way more efficient in
reviewing and re-reviewing changes.

That reference to "every small change" is a common attitude and
sometimes reviews can be skipped (no matter if the changes are large
or small) but in my view the code review process is done with tools
that are quick and efficient to use, so even small code reviews don't
take more than a couple of minutes, and we can have them too.

Sometimes very small changes lead to bugs, so personally I like a
working culture where everything is categorically reviewed and CI
tested no matter if the author considers the change "safe" or not. The
upstide with small changes is that they are very fast to review, so
the cost of reviewing small things is low.

> > By practicing both code reviews and CI we can catch things that people
> > didn't think about in advance. This increases quality, which saves
> > time in the long run, both for the maintainer themselves and for the
> > people who are affected by bugs. [...]
>
> Reading all of this makes me imagine that you probably work or have
> worked for a big tech company. The workflow there is quite similar to
> what you describe. That works really good when you have a team of paid
> software developers working 8h/day but that's not true for a lot of
> Debian world. I am not sure if such an approach would scale well in this
> context, but I defer that judgement to you.

Yes, I do work for a large company, but before it I worked for a small
company, and both of them have exactly the same CI and code review
culture. It is not that much about the size of the company, but that
the enities having the same manager responsible for production systems
humming smoothly 24/7 and that manager having the same philosophy
about reviews and CI.

I also participate in multiple open source projects that quite
successfully have a policy of having every code change CI tested and
reviewed by at least one person. In Debian the Salsa CI team works
like this, but that of course is an outlier because people who want to
develop Salsa CI are naturally drawn to same engineering culture.

> None of this is meant to denigrate your work, and I am terribly sorry if
> I am giving that impression in the slightest. Thank you very much for
> taking out your time to draft a new policy, very much appreciated!

Thanks!

I think we ultimately want the same thing. I just need to update the
tooling to do all of this as automatically as possible so that you
will also feel that doing this "extra" stuff is not a burden, but easy
and fast.


Reply to: