RFC: Procedure for changing packaging workflow (was Re: Announcement: packaging workflow changes)
Thank you all for your comments. I opened a draft merge request
proposing a procedure for workflow changes:
https://salsa.debian.org/go-team/go-team.pages.debian.net/-/merge_requests/19
Feedback would be appreciated. I'm not at all attached to that specific
procedure or even the general approach; I just wanted to write something
down to bootstrap the discussion. Ideas for completely different
approaches would be nice to hear. Feel free to push your own changes
directly to the MR branch.
Additional replies in-line below:
On 3/26/26 10:55, Nilesh Patra wrote:
On 26/03/26 6:51 pm, Otto Kekäläinen wrote:
What? You merged all of them in a few hours
It might be sensible to restrict access to the policy repo to only owners
to prevent this in the future.
I'd prefer not to. We can revert changes if needed, but more
importantly we need people to be active - removing permissions from
people who try to be active is the wrong signal and does not help
build a team.
The biggest miscommunication here was that Richard did a couple tweak
MRs and merged them in one hour, for which I already expressed my
critique. But he did not do the thing Andrew stated above. The
majority of Richard's changes have been pending as open MRs for many
weeks in multiple repositories.
I've encouraged team members to go and review all open MRs and PRs
across all team assets and team packages in e.g.
https://lists.debian.org/debian-go/2026/02/msg00097.html
I'd like to encourage people again to spend time reviewing what is
currently open. That is the best way to drive progress.
I reviewed them and left some comments after sending my last e-mail.
Thanks for commenting. I'll open some new MRs to address the comments
and CC you.
The last wave of policy changes actually took 2 years including an in-person debconf
to finalize things.
Actually, the changes that started in 2017 are still not done, and the
main person driving them quit Debian years ago because so many
holdouts was stopping him from doing clearly beneficial work, and
those holdouts didn't do the work either, nor did any of them finalize
the policy changes - neither the policy text itself, nor the tooling
to do it.
I think this is an important observation. If a contributor doesn't feel
like they can make significant progress, they'll move on to a different
project. At least I'm that way; I have bailed on projects because there
were too many hurdles. The best way to keep useful contributions coming
is to make it as easy as possible to contribute. This means either
timely reviews or allowance of self-merging when there is no timely
feedback. (If you don't think my contributions are helpful, please let
me know.)
For my part, I will:
* take any well-intentioned criticism seriously (all of the criticism
so far has been well-intentioned, which is nice)
* not be offended if anyone wants to revert one of my changes
* review others' MRs in a timely manner
* be more vocal on the mailing list
I wasn't a part of this team or even the project back in the day. But if in case you
are calling me a holdout, I want to express that it's very discouraging to hear for
me. I'm quite sure that I do actual work in multiple areas/teams.
(all of this is unpaid, volunteer free time/hours)
If you don't get enough reviews, you should consider to nudge on this list.
Yes. Richard should have done more of that.
At the same time, anyone can right now go and review and comment
whatever MRs are open. We also have people who push directly to git
HEAD or even upload without any room for feedback or discussions.
Richard wasn't behaving ike that, just a little too impatient and fast
to the volunteer cadence typical in Debian.
And that's actually fine - and I understand the eagerness to get things merged
when you have spent cycles on it. What is not fine is not acknowledging that this
was problematic, which I did not find in Richard's last email and prompted
me to respond.
The reply from Andrew made it clear that a review window lasting a few
hours is too short, which I completely agree with. But that's not what
happened -- the substantive MRs were open for weeks or months, not
hours, and I sent multiple emails to the list.
How many team members should approve changes? I think it's
counterproductive to wait several days/weeks/months for approvals when
it's easy to just revert a change and try again if someone has an objection.
No. It wastes more time and cycles, really. This happened last year in
https://salsa.debian.org/go-team/go-team.pages.debian.net/-/merge_requests/9
https://lists.debian.org/debian-devel/2024/08/msg00299.html
What happened last year is also an example that if you don't get any
feedback in a couple of weeks, you don't get much more in a year (some
of my MR/PRs have been open now well over a year).
I think some of your MRs were reverted after more than 5 months of being proposed
so I'm unsure if I agree fully concur. But I agree that things can keep piling
up for long if no-one attends to it.
The Go team policy does not have any description or agree process on
how to do decisions. The best we in practice have so far is that
people post MRs/PRs and others post there thumbs up or down.
I am happy to brainstorm and agree upon some decision structure beyond
that, but we should not be to hard on new contributors of trying to do
something and not following some unwritten rules.
That'd be good. But I also think that this is not specific to the go team.
I've not seen documented procedures for policy changes in a large majority
of the teams that I have come across thus far; so I reckon this problem
exists debian-wide.
Maybe we can be trailblazers -- an inspiration to all other Debian teams. :)
I don't even notice your merge requests exist.
Can we configure Salsa to email debian-go whenever a MR is opened for
the go-team.pages.debian.net project? Should we?
Unsure if configuring this is an option. But you could tag @go-team -- all go-team members
on salsa would get a notification that way and would probably lead to more reviews.
Please no, that would spam 320+ people who might start turn off their
Salsa notifications completely.
I think the best outcome stems from nudging this list with email (e.g.
https://lists.debian.org/debian-go/2026/02/msg00097.html).
Please know that emailing the list every time an MR is opened, and
emailing when no feedback is received, are additional obstacles to
contributing. They discourage contributions. It would be better if
more team members subscribed to Salsa notifications, or if the list was
automatically notified for every new MR, or something. Maybe an IRC bot?
If there are people who have the interest and bandwidth to actively
comment on all PRs, they should subscribe to the repositories they are
interested in. Instructions at https://wiki2025.debian.org/wiki/Salsa.
I don't have instructions at hand for GitHub, but same 'watch'
principles apply to https://github.com/Debian/dh-make-golang as well.
When you say "all PRs", do you mean all MRs across all projects in the go-team?
I suspect there aren't many MRs across all of go-team, but I don't know
for sure. I'm guessing that MRs are opened either because a go-team
member would like someone to double-check something, or because the
change is from someone outside of go-team. Either way, it would be nice
if someone was around to provide some timely feedback.
-Richard
Reply to: