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 <ijack...@chiark.greenend.org.uk> 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.
