>>>>> "Sean" == Sean Whitton <spwhit...@spwhitton.name> writes:
Sean> ===== BEGIN FORMAL RESOLUTION TEXT
Sean> tag2upload allows DDs and DMs to upload simply by using the
Sean> git-debpush(1) script to push a signed git tag.
Sean> 1. tag2upload, in the form designed and implemented by Sean
Sean> Whitton and Ian Jackson, and design reviewed by Jonathan
Sean> McDowell and Russ Allbery, should be deployed to official
Sean> Debian infrastructure.
Sean> 2. Under Constitution §4.1(3), we overrule the ftpmaster
Sean> delegate's decision: the Debian Archive should be configured
Sean> to accept and trust uploads from the tag2upload service.
Sean> 3. Future changes to tag2upload should follow normal Debian
Sean> processes.
Sean> 4. Nothing in this resolution should be taken as requiring
Sean> maintainers to use any particular git or salsa workflows.
Sean> END FORMAL RESOLUTION TEXT =====
Seconded.
I realize I asked you to wait, but Russ's message
8734oytl8l....@hope.eyrie.org has convinced me I was wrong.
In addition, I would like to respond to those who claim that a GR is
inappropriate, or that ftpmaster should be given more time.
Back in 2019, you and Ian approached ftpmaster asking for tag2upload
support. There was an extensive debian-devel thread, and there was a fair
bit of private discussion.
At that time, I was DPL. You followed a reasonable process. You tried
to understand their requirements. It became clear to you and to me [1]
as a neutral party that your design was not going to be able to meet
their requirements.
[1]: I did support the idea of replacing Debian source packages with
git in my DPL platform. Amusingly that was in response to a proposal
Joerg made. I was not a specific proponent of either tag2upload or
ftpmaster's concerns. I did support exploring tag2upload as a promising
option.
Ftpmaster did decide. No, perhaps it was not a formally announced
decision. Perhaps it was only a blocking decision of multiple individual
members rather than a team. No one proposed an option for how you could
ask for a formal decision. Other members of ftpmaster could have
indicated how you could ask for a collaborative design. They could have
proposed ways to have collaborative design. They could have, but did not.
They blocked your work.
My take away was that they believed that essential security properties
they cared about were incompatible with your design and there was no way
forward. Even getting requirements out of ftpmaster was difficult. I had
to intervene as DPL and talk about the importance of delegated teams
working with the project as a whole. (It is not the DPL’s job to second
guess a team’s decision, but it is the DPL’s job to prod teams when balls
are getting dropped or when teams aren’t working to resolve cross-team
issues.)
Let’s be honest, personalities were involved. It looked fairly clearly
like there were people on ftpmaster who didn’t want to work with Ian on
this issue. I get that: I’ve been frustrated working with Ian before, and
I know he’s been frustrated with me.
There are solutions to allow things to move forward even when
personality conflicts get in the way. could have worked with you. They could
have even insisted that if tag2upload was going to move forward, you
needed to get someone else involved to work on the design with them. (You
might not have liked that, but tag2upload has enough support that if
getting another designer involved was what it took to make progress, that
could have happened.)
Instead, there was silence. You worked with ftpmaster. They said no. That’s
fine. There’s nothing wrong with that. These things are always
complicated. It was probably a combination of believing that the
security concerns they had were paramount, insufficient hours in the
day, and emotionally draining discussions. All that is part of life in
Debian. What should not be part of life in Debian is those combinations
blocking work with no recourse to get a broader opinion.
The project needs to be able to balance the decisions of teams
against other competing interests. We delegate responsibility to our
teams to move forward based on the overall needs of the project, not on
the needs and desires of the delegates. Yes, delegates get a lot of
discretion because they are doing the work, because we value being a
do-ocracy, and because volunteer work is fun when we have the flexibility
to do our jobs in a manner that appeals to us.
For Debian to remain vibrant and fun, we need to have ways to resolve
conflicts when one person’s doing crosses ways with another person’s
doing. We need to have ways to ask a broader group when ftpmaster’s
concerns about archive signatures run against your desire to make Debian easier
to contribute to and to provide better traceability of our source
packages.
It turns out we do have ways of addressing that. They include GRs, the
technical committee setting policy (such as policy on archive security
requirements), and the DPL making delegations. We also have other less
formal approaches.
At any point, ftpmaster could have proposed a time-bounded decision
strategy for resolving the conflict they were more comfortable with. You
chose GR.
Back in 2019, I told Ian there was not sufficient support for a formal
process to break the conflict. In the debian-devel threads, it looked
like not enough people understood the issues. Also, we’d had a lot of
formal discussion already in 2019, and there’s only so much change that
is good for the project in a year.
I recommended working to increase the number of people who were familiar
with tag2upload and the issues involved.
That has clearly happened. Many people have participated in the discussion
displaying a informed understanding of the issues. Today, we are ready to
make an informed decision about the issues involved.
Also, in the five years, someone else who wanted a different git-based
solution could have worked on it and proposed a prototype. Heck, they
could have even taken your code as a starting point: it’s free software
after all.
That can still happen. If a year from now, we have a different way to do
git pushes into the archive, we can revisit whether trusting tag2upload
makes sense.
For all these reasons and more, I think now is the time to make this
decision, and I think a GR is an appropriate mechanism to do so.
signature.asc
Description: PGP signature
