On Thu, Jun 27, 2024 at 03:15:42PM +0800, Sean Whitton wrote:

I seek seconds for the General Resolution at the end of this e-mail.
The preceding sections are an introductory explanation and rationale.

*NOT* Seconded.

The discussion following the pre-GR has clearly shown that we need to
have further discussion. Going ahead with the GR shows disrespect for
the entirety of the discussion and the suggestions that have been made.
This makes the GR proponents look like "we want it THIS way or not at
all" to me.

That's not the way Debian works. Please consider pulling back for
Debian's sake.

Greetings
Marc

P.S.: Yes, I know how I will vote when this will go ahead

-- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le jeudi, 27 juin 2024, 09.15:42 h CEST Sean Whitton a écrit :

=====
BEGIN FORMAL RESOLUTION TEXT

tag2upload allows DDs and DMs to upload simply by using the
git-debpush(1) script to push a signed git tag.

1. tag2upload, in the form designed and implemented by Sean Whitton and
Ian Jackson, and design reviewed by Jonathan McDowell and Russ
Allbery, should be deployed to official Debian infrastructure.

2. Under Constitution §4.1(3), we overrule the ftpmaster delegate's
decision: the Debian Archive should be configured to accept and trust
uploads from the tag2upload service.

3. Future changes to tag2upload should follow normal Debian processes.

4. Nothing in this resolution should be taken as requiring maintainers
to use any particular git or salsa workflows.

END FORMAL RESOLUTION TEXT
=====

Seconded, thanks for the extensive discussion and work towards that goal.

I'm of course worried by the potential disruptions on motivation and morale for the FTP team, but I (currently) feel that the potential benefits from a working tag2upload are worth at least having that vote.

I wonder if certain amendments would make sense and better the ballot (such as weakening the "should be deployed" towards a "ftpmaster are encouraged to consider deploying", or so), but I don't have the mental space or bandwidth to think of a good one.

--
OdyX
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQTjpQ0b6NokWkvBQbzqgwvGpoTNfAUCZn0YugAKCRDqgwvGpoTN fHOtAP4mW+IYUKdb3zuKehcJ68slyLQXePCtxfUdGKMXh9666wD+M/fDjuafapRR yQrZ+2RO1a1f7MVJYlbt6vc3j5qawwc=
=ySWd
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello everyone,

I seek seconds for the General Resolution at the end of this e-mail.
The preceding sections are an introductory explanation and rationale.

We have reviewed the discussion we've already had and prepared an FAQ,
linked below.

Thank you for all the input on my previous posting, which has resulted
in a number of changes.

=====
INTRODUCTION

The tag2upload system, designed for deployment on official Debian infrastructure, allows DDs and DMs to make source-only uploads simply by pushing a signed git tag. There are two key advantages:

- it will be much quicker & easier for us to do most of our uploads

- it improves the traceability & auditability of our source-only uploads

The system works like this:

1. Maintainer types 'git debpush' to sign and push a suitable git tag.
The tag includes certain metadata that makes the maintainer's
intention to upload fully traceable, and unambiguous.

2. A robot on DSA infrastructure automatically, reliably and traceably
builds the source package, and uploads it to the Debian Archive.

tag2upload will be an additional option for your source-only uploads --
no-one will be required to use it. For more information on the details
of the system itself, I've included some links below.

The design is complete, and a prototype is fully implemented with a
thorough test suite.
In testing, it has been used to perform real uploads.

As tag2upload is security-sensitive, the design has had careful,
independent security review from Russ Allbery and Jonathan McDowell, who
did not have any part in the original design and implementation.
I note that Jonathan is one of the highly trusted maintainers of our
keyring of human uploaders.

=====
NEED FOR A GR

So, why am I proposing a GR?

The ftpmaster team have refused to trust uploads coming from the
tag2upload service. This GR is to override that decision.

In our design, the git tag contains simple metadata that can be written
out by hand. ftpmaster stated a hard requirement that the signed tag
must additionally include a manifest of all files in the .dsc.

However, due to several factors, such a file manifest cannot be
generated without the uploader building a source package.
The whole point of tag2upload is to move that process off the
uploader's system, and onto controlled project infrastructure.

We think that it should be possible to upload packages without any
complex Debian-specific tools, and we want to support as many of our
existing git workflows as we can.
Meeting these goals requires accepting source packages constructed and
uploaded by the tag2upload service.

=====
CONSERVATISM & TRACEABILITY

We are concerned that ftpmaster's position is due more to conservatism,
leading to an unwillingness to extend trust beyond our existing
processes, no matter how carefully designed and implemented the new
processes may be.

While we want people in Debian in critical paths for archive security to
be relatively conservative, that conservatism can be taken too far, and
we think that is what has happened in this case.

In fact, tag2upload significantly *improves* the traceability of our source-only uploads.

Currently, source packages are constructed from git with relatively
ad-hoc command line invocations, using whatever tooling the maintainer
has installed on their laptop.
This does not give an adequate level of traceability.

tag2upload will be a massive *improvement* to traceability since it will restore the formal and traceable link between what most maintainers
actually work with and treat as canonical (git, nowadays), and what
Debian as an institution officially publishes (packages).

=====
THE DESIGN & IMPLEMENTATION ARE LATE-STAGE

We wish to be clear that tag2upload can be deployed without *any* code
changes to dak. It just needs to be given a suitably trusted key,
very similar to how buildds have trusted keys.

There are a few loose ends we want to complete to turn the prototype
into the finished service. Some design adjustments made in response to
Russ Allbery's security review are still to be implemented, and we will
arrange how the deployment will work in consultation with DSA.

Should this GR pass, the tag2upload project will be unstuck, and could
be deployed in a matter of months. Then the source-only uploads of as
many of us who want it can become just 'git debpush' and done, without
any other workflow changes or learning.

There do not exist any other designs that are anywhere near complete,
and there are no other implementations, for upload-by-git-tag.

=====
WHAT'S NEXT

Initially, we'll complete the implementation and deployment work, in collaboration with DSA. When we're ready, we'll advertise for early
adopters, who are happy to put up with teething troubles.

Eventually we expect many people to switch to using tag2upload for all
their source-only uploads, thanks to its convenience.

What comes after that will be up to all of us.
We intend tag2upload to be an incremental change, which meets people
where they are, and only gives them more options.

Debian is big, and different packages and situations call for different solutions. We do not pretend that tag2upload will be capable of
handling all of them.

But it will indeed handle most of our day-to-day source-only uploads.

=====
LINKS


https://salsa.debian.org/dgit-team/dgit/-/blob/master/TAG2UPLOAD-FAQ.md
-- answers to some Frequently Asked Questions (FAQ)

https://wiki.debian.org/DebianEvents/gb/2023/MiniDebConfCambridge/Jackson
-- recent mini-debconf talk outlining the system

https://www.eyrie.org/~eagle/notes/debian/tag2upload.html
-- Russ's security review


https://salsa.debian.org/dgit-team/dgit/-/blob/master/git-debpush.1.pod
-- the tool maintainers will use

https://salsa.debian.org/dgit-team/dgit/-/blob/master/TAG2UPLOAD-DESIGN.txt
-- the design & deployment of the service

https://salsa.debian.org/dgit-team/dgit/-/blob/master/tag2upload.5.pod
-- the syntax & semantics of the tags git-debpush makes


The design is not expected to change significantly, but we may tweak
details in response to feedback from d-vote, and while finishing the server-side deployment implementation, in consultation with DSA.

=====
BEGIN FORMAL RESOLUTION TEXT

tag2upload allows DDs and DMs to upload simply by using the
git-debpush(1) script to push a signed git tag.

1. tag2upload, in the form designed and implemented by Sean Whitton and
Ian Jackson, and design reviewed by Jonathan McDowell and Russ
Allbery, should be deployed to official Debian infrastructure.

2. Under Constitution §4.1(3), we overrule the ftpmaster delegate's
decision: the Debian Archive should be configured to accept and trust
uploads from the tag2upload service.

3. Future changes to tag2upload should follow normal Debian processes.

4. Nothing in this resolution should be taken as requiring maintainers
to use any particular git or salsa workflows.

END FORMAL RESOLUTION TEXT
=====

This resolution requires a simple majority.
There is no supermajority requirement for Constitution §4.1(3).

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmZ9EZ4ZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQDZ8D/46MrrMVE/QsDSW5KN68S8F BtuE7DDJ0TyRoZi0LVnWG2gk9SSvTVZ4ikV0t2ZhSmh2UUG/iUXsok08ziZDmLvU 4o6l3UobiMPSn2+UiRaCJFUC0XmBEbugRKDx1PyvTElIvglzTXQ7nzUvv6O2pYgJ kOk+gr4OoBfOlPSPGlT/VtpQJEaVHBYxUKeGVHLTcTXvUlfiLenp2AmU8+N2Bv4r W/MEfhRxLDxrRb+NVLoLjRHYChuk/fDffz2qyxTJe1QJ4DHVNkm5ufi6el8vQMnj Yf85yNllmgwZBQW7Pk65rbVw0qqh7XTWBlMPeTFV/i8dj51ZXWSIeQ32AFRgkaEz EdBDBsR41bgTmBTlwO+Syxi6eQ6h8fzFPv4Bv9sxxvKY8GRL6i91akQfzAt5yN1f YyF6R0hQU0wqKh2co2EX5O7YEXt8vYtXaapwtUXsZXIhx47x4jvsegkGj6Ly3hjQ SMZWyqp9m0FfJNd7718nt5Si+i/rVDV/ntNl+ZXml5CfeakbzgYhy33J0LN4QLUS ir63xtNOnlxxXLsPJBHmDYGDNafd+aT+CaoP/0aC+UxihhFf3OC8XM1y1OCRkY14 u9tvODKeWRmFCGbaHeD+9R0EBXr2n+LcCM0x7WW9afpeX9oRBA6n/bjnUnqdKLzi hCplMXdzhGn8aYFlzTDIzw==m0Jn
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

On 17273 March 1977, Sean Whitton wrote:

I seek seconds for the General Resolution at the end of this e-mail.
The preceding sections are an introductory explanation and rationale.

So, we are even still discussing things in that other monster thread.
And the second one beside it. FTPMaster has shown that we want it, but requested some changes. (And is even flexible on them and still up for
finding a way. *WE* are willing, appears you are not.). Where is the
hurry to run a GR now? You waited 5 years without ever bringing this
forward, and now it must be done right now, and can't wait more time? Oh
come on.

All of the things asked got rejected, this appears a "my way only or we
f*ck
you over with a GR". Helpful. Not.

It's about the worst way to get something into Debian.

I did think better of you, but meh, another disappointment. :(

--
bye, Joerg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Jun 27, 2024 at 03:15:42PM +0800, Sean Whitton wrote:

=====
BEGIN FORMAL RESOLUTION TEXT

tag2upload allows DDs and DMs to upload simply by using the
git-debpush(1) script to push a signed git tag.

1. tag2upload, in the form designed and implemented by Sean Whitton and
Ian Jackson, and design reviewed by Jonathan McDowell and Russ
Allbery, should be deployed to official Debian infrastructure.

2. Under Constitution �4.1(3), we overrule the ftpmaster delegate's
decision: the Debian Archive should be configured to accept and trust
uploads from the tag2upload service.

3. Future changes to tag2upload should follow normal Debian processes.

4. Nothing in this resolution should be taken as requiring maintainers
to use any particular git or salsa workflows.

END FORMAL RESOLUTION TEXT
=====

Seconded.

It's a shame we've come to a GR on this, but I do believe it adds a
significant improvement to the git workflow when working in Debian.

J.

--
/-\ | "Oh, you are awesome when you're
|@/ Debian GNU/Linux Developer | sarcastic. Please do carry on
\- | :-)." -- iwj to rra on Ruby.

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQSAYP1ALvrBQa1odmMPwJuF4mk8PAUCZn0howAKCRAPwJuF4mk8 PKg0AP9+g+pA/mc8ZQlED1nGACNJa6RCK4gsDuahgtF1NvbzTQEApSjGGGsno5OO jHpVoyFj6K9oxNoaZH33mkPN3259BQU=
=SsTN
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17273 March 1977, Sean Whitton wrote:

=====
NEED FOR A GR

So, why am I proposing a GR?

Because you aren't appearently interested in actual cooperation, but
want to force something down the throat of others, ignoring their
wishes.

The ftpmaster team have refused to trust uploads coming from the
tag2upload service. This GR is to override that decision.

This is wrong, there has *NOT* been such a decision.

In our design, the git tag contains simple metadata that can be
written
out by hand. ftpmaster stated a hard requirement that the signed tag
must additionally include a manifest of all files in the .dsc.

And that is wrong too.

We think that it should be possible to upload packages without any
complex Debian-specific tools, and we want to support as many of our
existing git workflows as we can.
Meeting these goals requires accepting source packages constructed and uploaded by the tag2upload service.

FTPMaster actually has a very similar wish.

We are concerned that ftpmaster's position is due more to
conservatism,
leading to an unwillingness to extend trust beyond our existing
processes, no matter how carefully designed and implemented the new
processes may be.

Wrong, again.

Should this GR pass, the tag2upload project will be unstuck, and could
be deployed in a matter of months. Then the source-only uploads of as
many of us who want it can become just 'git debpush' and done, without
any other workflow changes or learning.

"In a matter of months", but you can't even wait to end the running
discussion first. Where is the hurry?

=====
BEGIN FORMAL RESOLUTION TEXT

tag2upload allows DDs and DMs to upload simply by using the
git-debpush(1) script to push a signed git tag.

1. tag2upload, in the form designed and implemented by Sean Whitton
and
Ian Jackson, and design reviewed by Jonathan McDowell and Russ
Allbery, should be deployed to official Debian infrastructure.

2. Under Constitution §4.1(3), we overrule the ftpmaster delegate's
decision: the Debian Archive should be configured to accept and
trust
uploads from the tag2upload service.

Which decision do you want to overrule? There has not been any.
FTPMaster is talking with you (or trying, but you don't appear to be
open to listen) and trying to get this in, but you are "My way or
nothing" set.
So no, point 2 is not true.

--
bye, Joerg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Sean Whitton writes ("General Resolution to deploy tag2upload"):

BEGIN FORMAL RESOLUTION TEXT

tag2upload allows DDs and DMs to upload simply by using the
git-debpush(1) script to push a signed git tag.

1. tag2upload, in the form designed and implemented by Sean Whitton and
Ian Jackson, and design reviewed by Jonathan McDowell and Russ
Allbery, should be deployed to official Debian infrastructure.

2. Under Constitution §4.1(3), we overrule the ftpmaster delegate's
decision: the Debian Archive should be configured to accept and trust
uploads from the tag2upload service.

3. Future changes to tag2upload should follow normal Debian processes.

4. Nothing in this resolution should be taken as requiring maintainers
to use any particular git or salsa workflows.

END FORMAL RESOLUTION TEXT

Seconded.

-----BEGIN PGP SIGNATURE-----

iQFUBAEBCAA+FiEEVZrkbC1rbTJl58uh4+M5I0i1DTkFAmZ9OU4gHGlqYWNrc29u QGNoaWFyay5ncmVlbmVuZC5vcmcudWsACgkQ4+M5I0i1DTmRLQf+LDv0LFDYGbLX q75/ZvmBA5C7v/w4OuoJq14O3RezZqeR19smbX87Ss7VTweTUZ/LK7hl5GjqIq4r 0nx1FMKmbJV/rrdHyjz1KNzCoSn+m/ADAdAW048KsRdQ4nVtedBZvBs6yBwai8vv BN6q3YzSGfqhkdHZqDttotojwisJlYzI+z/0qLXEwORA/STHrldVVM4NNPgAZSGa 5ers6Id8GTKwWq0IpCBFinW+lGDOtY4B8OY1CaAnBhSC7LygYbzWZkjN2ExNIDer Oaw5UCOppqzMLfvghQxFIfmjV24n7I1Up3x26AC5r5DvSPmEebLTHLj86r+jXLWI
CEhMkjAxMg==
=gBnj
-----END PGP SIGNATURE-----
--
Ian Jackson <[email protected]> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, June 27, 2024 6:07:33 AM EDT Aigars Mahinovs wrote:

Refusing to make a decision is a decision. Ansgar has explicitly set a requirement for including the checksums of the end result Debian source package in the tag. This requirement was not withdrawn or overridden by
other FTP masters in the public list communications. And all (detailed) explanations why this requirement is not appropriate have been ignored. Ansgar even explicitly stated that no replies or explanations were read
(due to lack of time).

If FTP masters (as a team) override this requirement publicly, then there should be no further obstacles to deploying tag2upload. Everything else has been already fully discussed.

If not, then the GR is quite appropriate IMHO.

If this was the same kind of discussion that happened five years ago, I can see why it was not continued. There is no point in service building a
Debian source package where there is a hard requirement that the Debian source package must be a part of the inputs provided to the system.

On Thu, Jun 27, 2024, 12:30 Joerg Jaspert <[email protected]> wrote:

The ftpmaster team have refused to trust uploads coming from the tag2upload service. This GR is to override that decision.

This is wrong, there has *NOT* been such a decision.

In our design, the git tag contains simple metadata that can be
written
out by hand. ftpmaster stated a hard requirement that the signed tag must additionally include a manifest of all files in the .dsc.

And that is wrong too.

I think you are confusing an FTP Master participating in the discussion with a decision by the delegates as a team. As far as I'm aware, no decision has
been taken. There are, in fact, discussions still going on within the FTP
Team (I'm an FTP Assistant, but not a delegated FTP Master) about ways to support tag2upload.

I'm unable to find any record of the FTP Masters being asked to accept uploads from tag2upload before this GR discussion was started.

It's true that the Debian constitution gives developers the authority via GR
to make decisions for delegates, so the fact that there's nothing to override isn't a strict bar to a GR like this, but it seems like it would be better to attempt to do this collaboratively.

It's true that the FTP Masters have not agreed to trust uploads via
tag2upload, but that's because they were never asked to do so.

Also, before whoever it was that did it the first time sends the Community Team after me again, don't bother. I'm not going to participate further in this discussion as it's become quite clear there's no desire for any kind of useful collaboration.

Scott K
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE53Kb/76FQA/u7iOxeNfe+5rVmvEFAmZ9PoQACgkQeNfe+5rV mvErjQ//Tnaxeiht1O7DG3whvMf8s/pFEjiFNNhyGoPWAEiH/W+lRBcgG1mpbT5t gJut9eBTL8o247G+F5dIUFZYVVylu1mF1UqsfcgR1nv7vJLFqrSonWULOf86Y5rj 7ALpy3lnG8b3FvBpS8l9Zv8YS19aBuGRQjlcSBiZw2Bp1qIE5VRr3og5eRrxUCEZ aWpeaV/I5tW3LlfEXQNUJ2dlxlT24vuQHFIbhcSYrCikrouGYc9vkDVp0MXhyQrV W1l898J4frGfVnBin8Q90Wr29DhqORC3anhImCz5DTF8sFIPPjqytgCEnOX+3ERd StBhqKWLorEyuj6z9sj83BjaN7x8EWwarxDY/5MiDLEVWUJF4PSe7qdfftJISbo+ vk4A/oyg2fkLMbgokLuz/3/8C9T7h/sGefMHpmYFRvuc9ooaLIirMpsLMN0kEh8b X+dDeAxIlWGEWarvC58Si3V6vv9OfgyAQFIxZxMF8qBlFdvkzj225rgrOAOOhRpp /EOw6vWiBgfz9oMHwpBAt2PLa5YRLrb09NJJhy8xXTy/ZaybZK2asahK2RbGjzXy BARtzJ6JK7pAXm7kZtEpRitXRraWWRcLY/sCRJLyldp1Db95zkJzbjY77Jku2nYv KJwelhzeo2eJ6X9D03g69mtxTe2UHtvvqZ5egMJuL2VePA9sC5Y=
=66xs
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 2024-06-27 15:15:42 +0800, Sean Whitton wrote:

=====
BEGIN FORMAL RESOLUTION TEXT

tag2upload allows DDs and DMs to upload simply by using the
git-debpush(1) script to push a signed git tag.

1. tag2upload, in the form designed and implemented by Sean Whitton and
Ian Jackson, and design reviewed by Jonathan McDowell and Russ
Allbery, should be deployed to official Debian infrastructure.

2. Under Constitution �4.1(3), we overrule the ftpmaster delegate's
decision: the Debian Archive should be configured to accept and trust
uploads from the tag2upload service.

3. Future changes to tag2upload should follow normal Debian processes.

4. Nothing in this resolution should be taken as requiring maintainers
to use any particular git or salsa workflows.

END FORMAL RESOLUTION TEXT
=====

Seconded.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEExgRcgTiHt3wt/5elfFas/pR4l9gFAmZ9SAIACgkQfFas/pR4 l9hIYQ//R0pfiEzJf9cbcqHjaRvM+AZlN4++/t9Pv3AB707ZBEdgRPoLYSRKiipw oBxMEZJbkRcNpxI+rklgmTBFzxnhttcRpaE5SlJIQIkJhXWfeOkzctOsCXidePJ1 M0sfDh64YhZbD6udfNzI654MsIGIJtvVzxw2zvTIx7/yRCUmwq8Nf73xoA+ZJHJW 1CJhRdz78wJPLC6vNnE+O2Jy4ghRm4SVZkE/0+NPpCC8lepCqNa1OkGre9lNySTu 7KBuGOBb2zxf8lECTiJDrFWbH/0nSry7+eNcDtYF+TKYe+yjBdxYs4pXPdSjSf69 Itjc5GMdXQK+mUTT7hSwJ4p/REWO5XSNv3tfyphGhAnsD7YzBC4k0+sWY8106JWH HGkuRRR+8SAUv0U8lyhtjS0mI+NtkOttR0deF2WU3zgUYbEWlCn7MFRfDS0CBVEL gxDnGzKptaZvScKFYXMOv/QsO8PGDRZTthP1Kb0gQfuOMN6W4sHm1+iVBMwOef4u 3ldbvnyoeaxEocx5LlRm7GURtz/VV5ntdm8ZmmOhiiaW5xni205ZKkF1KPT1TnMN 9+qQn9vZHtW2Q3LusKMF8T00ui00sA62QsCfcaP0ep7f1LggZ8wodGoK0ueKFGTC MKy+LUQaESbzZ/yDfUDnYDAAVcwcAkF/GfcCYwMQbAbfC3pGvYo=
=kkeX
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Sean" == Sean Whitton <[email protected]> writes:

Sean> Hello everyone, I seek seconds for the General Resolution at
Sean> the end of this e-mail. The preceding sections are an
Sean> introductory explanation and rationale.

Sean> We have reviewed the discussion we've already had and prepared
Sean> an FAQ, linked below.

I think you are about a week too early to ask for seconds on this.
I do think the discussion threads are winding down, and I do think this
should come to a vote soon.
But I really do think you have misjudged by about a week.
I also think that week will significantly affect the perceived cost of
this vote on the project.


-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQSj2jRwbAdKzGY/4uAsbEw8qDeGdAUCZn167QAKCRAsbEw8qDeG dDT6AQCSYOFxpFZCRB3FJnGfW6D4Baio98IqyaEKxsJ3QZGmNAD/TmSvXs17XwgQ G6dMNbsmpNSVqda63h42Ipq8b7y/ogY=
=tSgz
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17273 March 1977, Aigars Mahinovs wrote:

Refusing to make a decision is a decision.

We haven't refused to make one.
We haven't been asked for one, even.

If this was the same kind of discussion that happened five years ago,
I can
see why it was not continued. There is no point in service building a
Debian source package where there is a hard requirement that the
Debian
source package must be a part of the inputs provided to the system.

We already said that we will do it in a way, that it can be done with
*minimal* things necessary on client side.

--
bye, Joerg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------a4qfwfIoZR954ccBXVqOZ6PE
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

T24gMjcuMDYuMjQgMTY6MjEsIEpvZXJnIEphc3BlcnQgd3JvdGU6DQo+IFdlIGhhdmVuJ3Qg cmVmdXNlZCB0byBtYWtlIG9uZS4NCj4gV2UgaGF2ZW4ndCBiZWVuIGFza2VkIGZvciBvbmUs IGV2ZW4uIA0KDQpHaXZlbiB0aGF0IEFuc2dhciBzdGlsbCBtb3JlLW9yLWxlc3MgaW5zaXN0 cyBvbiBoaXMgY2hlY2tzdW0gYXBwcm9hY2gsIA0Kd2hpY2ggQUZBSUNUIGNhbm5vdCB3b3Jr IGZvciBtYW55IGRnaXQgd29ya2Zsb3dzLCB0aGVyZSdzIHJlYWxseSBubyANCnBvaW50IGlu IGFza2luZyBpbiB0aGUgZmlyc3QgcGxhY2UgSU1ITy4NCg0KQWxzbywgUnVzcyBkaWQgdXBk YXRlIGhpcyBzZWN1cml0eSByZXZpZXcuIE9uZSBvZiB5b3UgY291bGQgaGF2ZSByZWFjdGVk IA0Kd2l0aCBlaXRoZXIgIk9LLCB0aGFua3MgdGhhdCdzIGdvb2QgZW5vdWdoLCB3aGF0IGRv IHlvdSBuZWVkIGZyb20gdXMgZm9yIA0KdGhlIG5leHQgc3RlcHM/IiAqb3IqICJzb3JyeSBi dXQgdGhhdCBkb2Vzbid0IGNvbnZpbmNlIHVzLCBiZWNhdXNlIA0KwqtyZWFzb27CuyIgKG9y IHBvc3NpYmx5ICJobW0sIE9LLCB3ZSAoPSB0aGUgZnRwbWFzdGVycykgYXJlIGdvaW5nIHRv IA0KZmlndXJlIG91dCBhIGNvbnNlbnN1cyBwb3NpdGlvbiBvbiB0aGlzLCBnaXZlIHVzIGEg d2VlayBwbGVhc2UiKSB3aXRob3V0IA0KYmVpbmcgYXNrZWQgZXhwbGljaXRseS4NCg0KWWVz LCB0aGVyZSdzIGEgZmFpciBhbW91bnQgb2YgY29tbXVuaWNhdGlvbnMgYnJlYWtkb3duIGhl cmUsIG9idmlvdXNseSwgDQpidXQgSSBkb24ndCB0aGluayBpdCdzIGFzIG9uZS1zaWRlZCBh cyB5b3UgaW1wbHkgaGVyZS4NCg0KLS0gDQotLSByZWdhcmRzDQotLSANCi0tIE1hdHRoaWFz IFVybGljaHMNCg0K

--------------a4qfwfIoZR954ccBXVqOZ6PE--

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEr9eXgvO67AILKKGfcs+OXiW0wpMFAmZ9jEIFAwAAAAAACgkQcs+OXiW0wpPX DhAAv9fD8ZEP/DKnAIcNspRMkV/HWaETAPPi298NbrKj2LGB5MqanLWL/QGuZSOWWlSq5tWpsLAP 13+ObYNObMzLkjY3F+x3v20mykCMxZH+wCzFnuMizxo3hz9+bwAZhC7F0Ay92WMYD/F828dHOJtR 9RFh5JPmL048JpxOwXH9w41O8sX+CqmK3lc4wXcYBifAS2tw6si95iM0+6BoP/Zgf704PTZxyIqi G02WaEMyWRfYBnlJRLTanveSgvi+Gx5FdPSaMRdamZNYt2/El+UJBvUHtf8SGc6YtB+Sy3ICQ07s fsw4e6P7UuOnqBV5PQdVHM1t7OUuRDpbcJYlR2jAtx+DHzh+JzyMUyCtpobgLm2XodnnXTg3LZzq dlDt+J4or7Cz2oRitkevMg0a6z1NrJtZlw/vel55Yjrr14XJGHub+vzICcXAnt0gxe4dH6/bji98 2lGLGYX41fFldnUXt+8BHZFYRgVPSgAhARAWVlezSiH7zYUZPIprE7knY55HAzrQ5GaeLfVxzQ2n OlD4xmEhbxipjoM9vim8v0R5gjTbOj317ZFMLp3+2AVZdFrnlccIp6tKSBe5tThdYug5F6UxA95e aLdGc2ElCjnSGUHeZFAD34ozEdI1OFPs5VtXENLif3BRJ7phOa769ZG4jrq32apaLICDTHXmY7F0 DPE=
=a/6O
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Joerg Jaspert <[email protected]> writes:

On 17273 March 1977, Aigars Mahinovs wrote:

Refusing to make a decision is a decision.

We haven't refused to make one.
We haven't been asked for one, even.

Don't you think this is getting kind of absurd? I flatly don't believe
that you actually believe that. There is literally no way that you could think, after all of this discussion, that you haven't been asked for a
decision or what that decision is about.

*As soon as* you indicated that there was some willingness to move your position, people reinvested substantial effort into trying to have that discussion, including multiple replies and attempted discussion with
Ansgar despite his quite open hostility earlier in this discussion. You
said at that time, and I am quoting from your message in <[email protected]>:

| I would ask you to wait a bit more before continuing with a GR (in the
| term of days, not months), at least some time, but do whatever you feel.

That was ten days ago. Sean did exactly what you asked.

When that conversation stopped, entirely on the FTP master side, people
waited and then Sean you to provide some indication of whether you were
still considering the options. There wasn't a response.

This process is utterly exhausting. You are asking people to prolong it
even further. You have to give them *something* that justifies doing that
if you expect them to agree, at least a message saying that there's a lot
of material to digest and providing some rough timeline. You can't ask
people to wait days but not weeks for a GR, stop responding to them, and
then get angry at them for doing what you asked and moving forward when
you didn't reply further. Or, well, you *can*, but it doesn't seem
justified to me.

I know people are reluctant to go to a GR for these types of decisions,
but at some point there *has to be an end*. Otherwise, it's just a form
of decision by attrition: exhaust people until they no longer care whether their request is approved or not, or possibly about Debian at all.

If you think there's something more to discuss that would help you change
your mind, the GR isn't happening tomorrow. But there has to be an end in sight. Doing things in Debian cannot be an endless series of procedural
hoops, beyond which is simply more procedural hoops.

--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Russ,

On Thu, 2024-06-27 at 09:15 -0700, Russ Allbery wrote:

*As soon as* you indicated that there was some willingness to move your position, people reinvested substantial effort into trying to have that discussion

Yes, I remember. For example getting examples from Russ Allbery about
what would surely not work, but that would work trivially... That's
kind of energy draining and removes motivation to continue to read the
thread. (Yes, that is the reason why I haven't read further mails yet
(as Sean should know). Well done to now use that against me!)

Ansgar

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ansgar 🙀 <[email protected]> writes:

On Thu, 2024-06-27 at 09:15 -0700, Russ Allbery wrote:

*As soon as* you indicated that there was some willingness to move your
position, people reinvested substantial effort into trying to have that
discussion

Yes, I remember. For example getting examples from Russ Allbery about
what would surely not work, but that would work trivially...

It's very unfortunate that you didn't read Ian's message, in which he
confirmed that I was correct originally, my example was valid, and I had misunderstood what was going on. The only reason why this *appears* to be trivial is because I was running dgit locally: in other words, precisely
the thing that would not happen in the tag2upload case. As soon as I
stopped doing that because I was using tag2upload, my example would have behaved in the way that I was describing to you.

--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 27 Jun 2024 16:21:47 +0200, Joerg Jaspert wrote:

On 17273 March 1977, Aigars Mahinovs wrote:

Refusing to make a decision is a decision.

We haven't refused to make one.
We haven't been asked for one, even.

There is no point in service building a
Debian source package where there is a hard requirement that the Debian source package must be a part of the inputs provided to the system.

We already said that we will do it in a way, that it can be done with *minimal* things necessary on client side.

Two comments, one more emotional and one more analytical:

* Part of my gut feeling is that the call for a GR might be a bit
premature, as I have the feeling that especially Gannef is not
opposed to t2u in general but is trying to work out how it might
work; and I really appreciate this positive attitude!

* On the other hand, I have the impression, based on my own
experiences with the FTP team, that this can go on for another 5
years or longer, as the FTP team usually avoids taking any formal
decisions; and this (meta level now) comes from the fact the no
delegated or ad-hoc team in Debian (except the TC) has any
bylaws/procedures for taking a decision, so it's easier to just not
decide.

Not sure what my conclusion might be; maybe something like "Wait for
4 more weeks for an official statement of the FTP team, and failing
that, call for a GR."


Cheers,
gregor

--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmZ97BxfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ qgYK6A/+NtRB7s+v7dHNMLU1X9Ks53m5HEW9AhOPpLQgN4Z9nVMVQsHKrc4TuYuH jaua+Jp0ArhmAWWV+kBjQZpSTxVi7p7iEzarA0UsNc9zP14KUD1RZub+YzsVMIov CpiqS2DHkEe+wE2NRdi0J/3pgjtaggPh0rbqQ5L7dGVUNYUTlDrZlD1JKwQMZbOm nbt4kOpTooc5Lhw4GjemeFWrePE7POmOrYBuzn3vwHvYKLtxeX9/kjXJJunr1zwt JnUi7vuAxvxrDcyNLBoVt/s6x7oLT3H/83A/EcyzoI2pb6MxFNvaM0qF+6yP6nUZ 68bOkGNH/w0emhOVMBKpP1+4EZqRag1OdetnhyakUvIb+Lz/5lkLH+SfpSkzLzcm zr9Ck5jlkm2viPzAbyouv1/iAdVDloZQmK9HZG+G9/Ge2jtmp6AzYW1c52olqy2b rGfsDNsWxlI5vu1MsOvZXpr9meOWUvsyP9DNsdQ9MI6CZrLfL0uiwO6i/G9u3JSp G3QPNj/QmJg2KgcAWehPZzt0AiC1W5JX1L0bBRqwdp2WOFeR9fjh0eZTZiMsXUCe mdtVv3m1JFE02eT7Us8Vgvcq+LL72IQKGvXYo+CC0m3Dx+oRk+ejlrGlX6aLVH5p rwbus+I1V0fABFV+rF8YQHcrbhVfDabsyUnfBgcFgD/pSQ1bNho=
=U6cV
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I'd like to submit a ballot option.

Not really happy with the current text though. The idea is simple : I
have been convinced, reading the previous discussion, that no formal
opinion from ftpmaster has been provided.

I'm not sure that it was asked explicitly, and I think that before
having a GR to force a tool down their throats, we should simply require
a formal statement from ftpmaster as delegates on the matter.

I also saw valid points that are too easily ignored by Sean and Ian
regarding their implementation, probably due to them not being eager to
change something that works.

I really think this GR is counter-productive in its current state. To be
clear, I'd vote for the default option above any ballot option trying to
force ftpaster (and then DSA) to push a tool that has not received a
formal review from ftpmaster, except if ftpaster decides to ignore the assessment request thrown th them (in which case at some point I'd view
this as a decision - silent, but still).

That being said, I do feel that ftpmaster failed multiple times to reply
to requests from other DDs regarding rejects et al. I'd like to see this change.

LBNL, I would expect tag2upload to work only if both a tag and the
commit it points to are signed. I also view the requirement to have a
proper DSC embedded some way is a sane one (as I consider it a sane idea
to build something before uploading it).

I'm happy to get counter-proposals regarding this option.

=====
BALLOT OPTION BEGIN

tag2upload allows DDs and DMs to upload simply by using the git-debpush
script to push a signed git tag.

1. tag2upload should be deployed to official Debian infrastructure.

2. ftpmaster is expected to provide a formal opinion regarding the
current implementation of tag2upload and the proposal from Sean
Whitton and Ian Jackson to add it as a trusted source for the Debian
Archive. Should ftpmaster consider that tag2upload can't be added as
a trusted source for the Debian Archive as it is, ftpmaster is
expected to provide a reasonable way forward.

3. Should ftpmaster fail to provide a proper and formal reply by
September the 30th 2024, then under Constitution §4.1(3), the
ftpmaster delegate decision would be overruled and become: the Debian
Archive should be configured to accept and trust uploads from the
tag2upload service.

BALLOT OPTION END
=====

--
PEB

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJDBAEBCgAtFiEE5CQeth7uIW7ehIz87iFbn7jEWwsFAmZ98JwPHHBlYkBkZWJp YW4ub3JnAAoJEO4hW5+4xFsLFagP/3FrixHmmXvgpZ5ATZehoqXYI2iSxg6RkK9Y dZDHRCXei0IBfc8h72Co+SUqiW7+rpFIQ8uJQUQM/3ooxedx+sEIOkKE8K2PEi1n Mku0/84nInATKoT2Mz6oxjTHDNj7JJrjtgK470IKCr55jANCpt8dU5XV2+YQOTEk 85KkWdh0EO50y3oMNP6oKpWvYc1JN52qZqAkhmvtHE2orIq8Z3xNBvz3rTAX8cHr 6MCVoTr9y5Z4Rs8h+6nfSFXUJNH9PobtC92kI1p4weR/7bGncIYUsyLyZYu866Lw Y19LTLqOKD84mXpspF60YYeUWJJBhq+Rtj0rFRDWGUsdCpxjM+FYKkMD61nEDeCU l1yePfYPz7jCZgT+vMl0XESp4MwutDZb3Oi8bIkLPDvJ2ctk+YmbOoaQIMagC54b L+0/vzBWyJZmP7GIRpPgAj3XE8qLPUDUOYJ7KR63n9UWHMbq+77zniuwjSW9zDEF 44OMefT8B2nevTf8Ru/AuiKQOt4RQmSxgHakDGrKDr4s11E+ozw7VlEDqfy2T3FQ wYms2yC7XGQDbhJPF9r3pGDsydI/DWd20gzVD5bun5LV/PpWOsV2xEVW/6XzaQMQ 7dUtCfhRm8NxyUCfJEgY3bEkzqBf41NSyoOsWSrwZeo2Uzp09fuy9XcmNDBV0mAg
rzNFSzoB
=1D
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Two comments, one more emotional and one more analytical:

* Part of my gut feeling is that the call for a GR might be a bit
premature, as I have the feeling that especially Gannef is not
opposed to t2u in general but is trying to work out how it might
work; and I really appreciate this positive attitude!

This is how I feel as well. I'm doing my best to follow the discussion since its beginning, so far having no major concerns about t2u implementation itself, but disliking the way this suddenly became, apparently, the most urgent thing in the project.

* On the other hand, I have the impression, based on my own
experiences with the FTP team, that this can go on for another 5
years or longer, as the FTP team usually avoids taking any formal
decisions; and this (meta level now) comes from the fact the no
delegated or ad-hoc team in Debian (except the TC) has any
bylaws/procedures for taking a decision, so it's easier to just not
decide.

Not sure what my conclusion might be; maybe something like "Wait for
4 more weeks for an official statement of the FTP team, and failing
that, call for a GR."

I agree with the above. Not certain about 2, 4, 12 weeks... But such a direction would definitely reduce the potential for a disruption in an important part of Debian, at the (small?) cost of a possible implementation delay that wouldn't result in any important damage here, in my view.

Bests,

--
Tiago

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sean Whitton <[email protected]> writes:

=====
BEGIN FORMAL RESOLUTION TEXT

tag2upload allows DDs and DMs to upload simply by using the
git-debpush(1) script to push a signed git tag.

1. tag2upload, in the form designed and implemented by Sean Whitton and
Ian Jackson, and design reviewed by Jonathan McDowell and Russ
Allbery, should be deployed to official Debian infrastructure.

2. Under Constitution §4.1(3), we overrule the ftpmaster delegate's
decision: the Debian Archive should be configured to accept and trust
uploads from the tag2upload service.

3. Future changes to tag2upload should follow normal Debian processes.

4. Nothing in this resolution should be taken as requiring maintainers
to use any particular git or salsa workflows.

END FORMAL RESOLUTION TEXT
=====

Seconded.

The timing of this GR follows the schedule suggested by Joerg in <[email protected]>. The discussion is not getting anywhere, and
I don't see any evidence that it's going to get anywhere. We're still
stuck on the same question that we were stuck on in 2019.

I could say a lot about process, and I expect there are a lot of process arguments to come, but, to be frank, I am exhausted. I am exhausted with
the burden of process being entirely on the side of people who just want
to deploy their work. I am exhausted with trying to eke small progress
out of discussions being conducted in obvious bad faith. There were so
many opportunities here for someone to say, "You have done a bunch of hard
work on this, I don't understand the problem you're trying to solve
clearly enough, and I have clearly misunderstood how much it matters to
you. Give us a couple of weeks to review the design in detail and put
together a list of questions so that you can explain the things we don't understand, and then we will try to understand the answers and give you a
clear yes or no decision." And yet this never happened.

The GR is the only decision-making process that the project has that
produces a clear answer in a well-defined time frame. If we don't like
that fact, that is something that is on those of us who are project
delegates to address. In the meantime, if people want to penalize project members for trying to get a clear decision in the well-defined way that
the project constitution says that they can, well, obviously I can't stop
you. But please don't lose sight of how frustrating and draining it is to
be told you have to keep discussing something with no end or progress in
sight.

--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEE1zk0tJZ0z1zNmsJ4fYAxXFc23nUFAmZ+ClYACgkQfYAxXFc2 3nWA8Qf/YyHnYGGLQxrZp12G6uVrIjR3rNnS0HKw3jrWlwFEzQANSRemPhtNhbvq HNx4rvO+TeQBiFfyLNl3LnXMzS8+RDY0OL8o+CsvcCLR2VvnQKfpm7wb26zN/9AI vqHwo7KAPvfuE/VeKe1m6u9PuwoQ3PJllhNO586VbIn3/M6iXICG6z9TSkxUTlvk i2KIH8cEoQqf3UszmxnWSv7Pg1RD8T7Ye5TLtJTOA8VH1aqX/ap7skxgQAYsk9Bg YaZTQkbo/TemmXgXtBIBeL71Md0Mobf9ssn5oTjBKf94v5GGKFBx4QyF+NhGfYGP HMJR67/Jw6bkkJqmVfVc2yl4sjMqlQ==0+db
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

I called for seconds when I did because I was hoping to minimise how
much this GR would interact with debcamp and debconf.

A number of people have said that in doing so, I misjudged the extent to
which discussion is still ongoing. I am only one participant in this discussion, so I appreciate the feedback.

It's also true that a number of other people have said that they agree
with starting the GR process now, and they've given good arguments, with
which I agree, about the importance of achieving closure.

The Constitution gives us numerous options, here, and I am still
thinking and reading about what would be best for our project.
As the proposer, I wanted to share my current thoughts.

--
Sean Whitton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Sean,

I have two comments on your GR; I think you could accept them as
amendments and keep the seconds it has already got:

Sean Whitton dijo [Thu, Jun 27, 2024 at 03:15:42PM +0800]:

=====
BEGIN FORMAL RESOLUTION TEXT

tag2upload allows DDs and DMs to upload simply by using the
git-debpush(1) script to push a signed git tag.

1. tag2upload, in the form designed and implemented by Sean Whitton and
Ian Jackson, and design reviewed by Jonathan McDowell and Russ
Allbery, should be deployed to official Debian infrastructure.

I think you should rather write:

1. tag2upload, based in the form designed and implemented by Sean
Whitton and Ian Jackson, (...)

Many points have been raised during the current discussion, and you
have accepted some observations as valid and worth including in the implementation. But not only that: If something good (design
improvement) or bad (vulnerability nobody thought of before) comes
along in the future, this GR could be seen as tying the hands of the maintainers to a specific implementation. By changing to "based in" or
"derived from" a specific design idea that you and Ian implemented,
then later Jonathan and Russ studied and commented upon, and then the
bunch of us gave some thought and discussion to, it allows for it to
be modified in the future.

Not only that: It also allows you and ftp-masters to come to specific compromises _leading to an implemented service_.

2. Under Constitution §4.1(3), we overrule the ftpmaster delegate's
decision: the Debian Archive should be configured to accept and trust
uploads from the tag2upload service.

3. Future changes to tag2upload should follow normal Debian processes.

Of course, that paragraph could be included by your #3. But #3 is so
vague that it leads to ambiguity. There is too much ground covered by
it.

4. Nothing in this resolution should be taken as requiring maintainers
to use any particular git or salsa workflows.

This is a good clarification, but IMO it should be seen as a side
note, and not part of the GR itself.

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRNFAUGU6QC1zaHBJ0kBMlUbhRTYAUCZn7tQAAKCRAkBMlUbhRT YKGLAQC2tjQYTIeIwRYR7vY6tbSnXhfUcjZ4loHZZMI1EUC2pAEAwPRH/ICJbmpw 3OZPOkSdqqyZGRFGO4oEz7SwHKn/YQg=
=QRQp
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Gunnar Wolf writes ("Re: General Resolution to deploy tag2upload"):

I have two comments on your GR; I think you could accept them as
amendments and keep the seconds it has already got:

Thanks for the contribution. Speaking personaly, I'm certainly open
to wording tweaks

I think you should rather write:

1. tag2upload, based in the form designed and implemented by Sean
Whitton and Ian Jackson, (...)

Many points have been raised during the current discussion, and you
have accepted some observations as valid and worth including in the implementation. But not only that: If something good (design
improvement) or bad (vulnerability nobody thought of before) comes
along in the future, this GR could be seen as tying the hands of the maintainers to a specific implementation. By changing to "based in" or "derived from" a specific design idea that you and Ian implemented,
then later Jonathan and Russ studied and commented upon, and then the
bunch of us gave some thought and discussion to, it allows for it to
be modified in the future.

I can see why you're suggesting this. Getting the wording right, for
this point, is not entirely straightforward.

To my mind the problem with your wording is that the opoosing
ftpmasters contend that the change they want us to make is but a minor technicality. If GR with your wording passed, they might reasonably
argue that the modification they are demanding is consistent with the
GR text. We'd be back where we started.

Not only that: It also allows you and ftp-masters to come to specific compromises _leading to an implemented service_.

I am sure that there will be improvements, that we and ftpmaster can
both agree on. I don't expect that to be a problem.

The question comes if ftpmaster *demand* changes of us, that we don't
like. These might include the change they are currently requesting; conceivably, it might also include other changes, which they might
realise later that they want us to make.

My hope is that the GR clearly empower us to deploy the current
design, subject to any changes which are *agreed*.

2. Under Constitution �4.1(3), we overrule the ftpmaster delegate's
decision: the Debian Archive should be configured to accept and trust
uploads from the tag2upload service.

3. Future changes to tag2upload should follow normal Debian processes.

Of course, that paragraph could be included by your #3. But #3 is so
vague that it leads to ambiguity. There is too much ground covered by
it.

Yes, that is what we intended paragraph 3 to cover. I agree it's
quite vague.

Making some random texts up, how about

3. This resolution does not prevent mutually agreed changes to
tag2upload's design or implementation, or future changes made
according to normal Debian processes.

I don't like this because it's longer.

4. Nothing in this resolution should be taken as requiring maintainers
to use any particular git or salsa workflows.

This is a good clarification, but IMO it should be seen as a side
note, and not part of the GR itself.

I have had multiple conversations with people who fear the imposition
of changes to their workflows. Given the history of some other recent
changes within Debian, and indeed some of the rhetoric that one
sometimes encounters, that is a very reasonable fear.

So I think this sentence is essential.

Ian.

--
Ian Jackson <[email protected]> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Aigars,

On Thu, 2024-06-27 at 13:07 +0300, Aigars Mahinovs wrote:

Refusing to make a decision is a decision. Ansgar has explicitly set
a requirement for including the checksums of the end result Debian
source package in the tag.

No, I have never made that a requirement. (Though an implementation
doing that would be fine too.)

Ansgar



--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Jun 28, 2024 at 01:05:40AM +0200, Pierre-Elliott Bécue wrote:

I'd like to submit a ballot option.

Not really happy with the current text though. The idea is simple : I
have been convinced, reading the previous discussion, that no formal
opinion from ftpmaster has been provided.

I'm not sure that it was asked explicitly, and I think that before
having a GR to force a tool down their throats, we should simply require
a formal statement from ftpmaster as delegates on the matter.

I also saw valid points that are too easily ignored by Sean and Ian
regarding their implementation, probably due to them not being eager to change something that works.

I really think this GR is counter-productive in its current state. To be clear, I'd vote for the default option above any ballot option trying to force ftpaster (and then DSA) to push a tool that has not received a
formal review from ftpmaster, except if ftpaster decides to ignore the assessment request thrown th them (in which case at some point I'd view
this as a decision - silent, but still).

That being said, I do feel that ftpmaster failed multiple times to reply
to requests from other DDs regarding rejects et al. I'd like to see this change.

LBNL, I would expect tag2upload to work only if both a tag and the
commit it points to are signed. I also view the requirement to have a
proper DSC embedded some way is a sane one (as I consider it a sane idea
to build something before uploading it).

I'd absolutly second this and I'm glad it doesn't seem to be neccessary.

(Still writing this mail to not imply consent by being silent.)


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

That morning, the young barista woman told me that a customer came in with a mask, but not wearing it. When she asked the customer to put on her mask please, the woman said: "Why? There's no-one in here."

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmaFYhwACgkQCRq4Vgaa qhymLxAAjd33fVsJBs3NPe+GCzKY60UnMOimZs64VL+tE+d4FNl6mSoFadMXL6PK p36wF/m6YHwlLnPoLs/69Efn9dN9Qjz3I3mu9v87mM6iuYdsqB+NsoFT+0XGB/EZ /bcHmul7Wdhi+OvVXhtiEmfVeMJANpzBSU+HHL3BNTsGlkTt7SrDqJ9sEIzo/bMq k2+sW9YgBfRkbDkeBcTjTXohi5/r9qLnrV+8OtnGHiH6ipwA6srVuOYIoE1pNs6/ jckEFbsvcRJ1w34NlYpkSn4AsdumsZFHFcB1T1dkQMagIywrbM7ThJtfAcOaZqln CQjp/2kst/KCX8SDOIiJXJtsHumbB18/ZbLoYYtiwD5xoWMLKng9BcjXIU4WHd76 I3qrnzfwP5fBFIY99XMKXNI72vwXe2ymm+eI/1SE2wvrHv1eEHl1mOjeDSHexJVf OoadRFjDZ/+gTUDGYwNpB6CWfaTLdk3shh8fpK

Hello,

On Thu 27 Jun 2024 at 03:15pm +08, Sean Whitton wrote:

=====
BEGIN FORMAL RESOLUTION TEXT

tag2upload allows DDs and DMs to upload simply by using the
git-debpush(1) script to push a signed git tag.

1. tag2upload, in the form designed and implemented by Sean Whitton and
Ian Jackson, and design reviewed by Jonathan McDowell and Russ
Allbery, should be deployed to official Debian infrastructure.

2. Under Constitution §4.1(3), we overrule the ftpmaster delegate's
decision: the Debian Archive should be configured to accept and trust
uploads from the tag2upload service.

3. Future changes to tag2upload should follow normal Debian processes.

4. Nothing in this resolution should be taken as requiring maintainers
to use any particular git or salsa workflows.

END FORMAL RESOLUTION TEXT
=====

I hereby withdraw this General Resolution, given: <https://salsa.debian.org/dgit-team/dgit/-/commit/e5512e874ddd755e2168b34d1b95f5f3ee487e71>.

Ian and I are both very pleased that this is now a SMOP.

Thank you Joerg for figuring this out with us.

Thank you to everyone else, especially Russ, for the support.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmaHMKoZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQHJQD/9ooeWqRr1A9rITgK1HbDCm QtVqZgklSr+myyEEcthaj9NYtmQR0QY78fMLF+p4nXCf6vysr2xfuBxZI86wWvGi k7utrQhZ24B/KbjpznMKx3FNSWvBpZLlik62o/R5NHRaxmEK5AfDZl0N1TJFiCDd N8BD8ZaKb14r8FtrADaJZN9cLAZ4unscRcNscmg4/tUAAKjYXdNUhasXgsp9NvZL Vh/2k9fGumwMnKIrlt3bYU7DFTSNzrkeoQnomET92LuzFMw0gTLrmp8+V0S9q9+D cmJxFbsmRU+Lj9XHmWo/caFFUPYA6e0i5qMf4WCDJ0KOq9VONUlhWhNzSSSwDp3l 5rfIZ5tbvxqTQ+gnu8XgE5mKESNuMiTxtA1WCRJDIQL8GfIyrTGzUK+UucZhAoB6 3dgWN6Maf83BugFP/6SjlbQaFHS5X0/Hv0lZDcjQn/bTTKWKW2uME5uf48oAi50s dds2Y8e5sorhr3L/yMZ6a67+1bxUeUXBGalcIGkK7/cvgHmi4WXXj1g8LECQosYf aCvC8MBCOipbniVGoi6Q72Op08GwKikLMNLOkFW+wDi5MbdPwPxdfr3Wabzjo1aN +lBELGRmtgG913dHXRDkRH0EEQqFgIxadbiyRYnKoOubyTKxRl5kf/2qs5cebT7m e02wwdLsSKhFd5302EVwhw==OQz4
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

On Fri, Jul 05, 2024 at 07:30:50AM +0800, Sean Whitton wrote:

I hereby withdraw this General Resolution, given:

Hi,

The 24 hour period has passed, so I now consider this withdrawn.


Kurt

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)