Discussion: stop sftp package uploads

[Jon Turney]

So, to follow on from the points raised in the thread ending [1], and 
perhaps start a discussion:

Having developers build executable packages locally and then upload them 
doesn't really meet contemporary standards.

Given my druthers, I'd just disable sftp package uploads right now, and 
make you all use the janky "build service" I hacked together in a few 
spare weekends.

Amongst the advantages this has:

* Ensures that the packaging git repo is updated when the package is.

* Ensures that the source package is complete; and that the build works 
and is repeatable.

* Ensures that the package is built in a sterile environment.

* Ensures that the package is serially developed in the git main branch 
(so when someone does a NMU, they don't also need to remember to 
explicitly communicate any changes made to the maintainer so they don't 
drop off again in the next release...)

* Transparency about, and some degree of auditability on how, the 
contents of the install package are generated.

* The way we provide a chrooted sftp session for uploads is weird and 
non-standard and this means sourceware no longer has to support it.

(A related consideration is that this probably also helps if/when we 
want to start providing arm64 packages (which will otherwise entail all 
the problems we had when x86_64 started being a thing - but at least in 
that case, most maintainers had the necessary hardware, if not the 
needed OS) - The alternative seems to be providing numerous cross-build 
packages, which doesn't seem like a good use of anyone's time...)


Unfortunately, there are some issues with my half-assed replacement:

* It relies on free CI services (GitHub and AppVeyor) to do the actual 
builds, which might be withdrawn or start charging.

* In particular, github requires an account to view the logs, which is a 
sticking point for some people.

* There's a number of problems with the current implementation: For a 
start it's a synchronous daisy-chain of actions, which isn't tolerant of 
intermittent connectivity or other transient problems.

* The "tokens" which can specified to control options in it are an 
ad-hoc mess. Idk what the ideal solution is, but the names of those 
options all need rethinking for a start...

* If you want to rebuild A and then B which requires the new B, you have 
to guess when to submit the build for B. (perhaps it needs private 
access to the repo rather than using a mirror, to ensure the copy it's 
looking at is up to date, but even then...)

* Some packages have circular dependencies, requiring some bootstrapping 
build of package A, using that to build B, before returning to rebuild 
package A properly with B available. This is completely unaccounted for 
in the current model of doing things.

* There are a couple of packagers using their own handcrafted packaging 
rather than cygport.

I'll be reaching out the those soon to discuss what can (reasonably) be 
done to accommodate them.


Any questions/thoughts/concerns?


[1] https://cygwin.com/pipermail/cygwin-apps/2025-June/044388.html