I very much hope that you're feeling better! And once again I really appreciate your messages in this discussion. I think they have been very helpful in clarifying the FTP team position.
Joerg Jaspert <jo...@debian.org> writes: > On 17263 March 1977, Russ Allbery wrote: >> What signed artifact do I need to provide so that the FTP team will be >> comfortable accepting my tag2upload-built source package? [...] > I do like that workflow. The one magic part seems to be the thing that > creates debian/patches files out of your git tree. As soon as that step > is done, I think everything should be there that makes up the thing that > gets uploaded? > But I bet there are other ways to work that make it less trivial magic > than what you seem to have. > To answer your question from above: At the point the magic is done, > anything that lists the files and checksums of (ignore metadata like > file timestamps) that will appear when one unpacks the source package. Okay, I think we have identified the point of irreconcilable difference. So, to make sure, let me repeat what I understand of both positions and make sure that I have this right, and also why I think it's irreconcilable. My understanding of the FTP team position is that the uploader must generate and sign either the final source package, or the files that constitute the unpacked view of the final source package, or a trivial variation thereof, and include that signature in the upload. If the uploader does not sign the final contents of the source package, then no matter what else they sign and no matter where else the source package is created, the FTP team will not accept the package into the archive. It is fine for tag2upload to build the source package and to upload things to dak for the uploader, but the uploader must provide a signed attestation of the final generated contents of the source package as well. My understanding of the tag2upload developer position is that this requirement prohibits the goal of tag2upload. People who want to build the source package locally can already use the same algorithm today; that's what dgit is. The whole point of the tag2upload project is to remove the requirement that the package uploader install dgit or equivalent software locally and build the source package locally. This FTP team requirement therefore makes it impossible for tag2upload to proceed; any system that would have the required property would fail to accomplish the core goal of the tag2upload project. Therefore, this delegate decision is blocking the deployment of tag2upload. I am seeing in this discussion a lot of confusion and bafflement on both sides over why the other side cares about the things that they do and considers essential the things that they consider essential. This is sometimes how it works in life; people care about different things and come to different conclusions and find each other's arguments unpersuasive. There are other points of disagreement that could potentially be hashed out, but this point of disagreement is fundamental and, so far as I can tell from the discussion (both now and in 2019), irreconcilable. Therefore, we have a situation where a delegate decision is blocking deployment of something that a different team wants to deploy in Debian. Assuming no one changes their positions, the clear options the tag2upload developers have under the project constitution are to abandon the work or to appeal the delegate decision to the project via a GR. Does anyone think I've missed anything? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
