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

Re: Workflow changes proposal for 2025



Hi,

Thanks everyone for the feedback, I have updated
https://salsa.debian.org/go-team/go-team.pages.debian.net/-/merge_requests/7
Direct link to artifact:
https://otto.pages.debian.net/-/go-team.pages.debian.net/-/jobs/6923949/artifacts/build/workflow-changes.html

On Tue, 14 Jan 2025 at 12:45, Nilesh Patra <nilesh@riseup.net> wrote:
>
> > Seems you think code reviews are a time waste?
>
> Wow. That's a strong statement and assumption.
>
> To be clear, I never said that. Please take my statements at face-value.
> Just that I personally would not have time for reviewing other's MR/PRs.

Sorry, that was maybe too blunt. What I intended to ask was, that
given all of us have limited time to work on Debian, and we have to
make decision on how to use that time, why do you allocate 0% on Merge
Request reviews?

> > You catch issues earlier and avoid extra work that you might have
> otherwise, and the collaboration helps
> grow the team and new contributors [...]
>
> JFYI, I am a DD as well. Almost all my packages are team maintained.
>
> 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.

Personally I am a big proponent of having code reviews and running CI
*even in the absence of any particular doubt* that something might be
broken or incorrect. People almost never upload packages that are
broken intentionally. It is always a surprise to them when they get a
bug report.

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. Better quality also makes me more
proud and motivated to continue contributing. Code reviews also help
to disseminate best practices as different people get exposure to how
others do things. Participating in code reviews is also social, and
makes Debian feel more meaningful than grinding away on bugs and doing
uploads alone.

Based on the very first goal statement at
https://go-team.pages.debian.net/ I assumed I would find like-minded
people in the Go team, but now at least three people have said they
don't want to do code reviews, and two people have said they don't
want to use CI.


Reply to: