On Mon, 2022-04-11 at 23:34 +0200, Thomas Goirand wrote: > Any idea how we could automate the Reply-To: thingy in a REJECTED > action, depending on uploader's preference? (not: I'm not > volunteering, just trowing a piece of idea... :) Here is an idea I posted on IRC a while back that should work and would solve the issues with not every package in NEW having an ITP: #debian-ftp: <pabs> random unpolished idea for NEW: instead of rejects, while the package is in NEW, dak could export the Source/Maintainer/Uploaders to the BTS but not the package itself, then ftp-masters would file RC issues against the "NEW" package, which would get closed by new revisions of the package uploaded to NEW <spwhitton> pabs: if the BTS knew about NEW packages that would be great. I have to make notes to file bugs the next day etc. * pabs asked about feasibility in #debbugs #debbugs: <pabs> dondelelcaro: wondering about the feasibility of the BTS side of this idea from #debian-ftp: <pabs> <pabs> random unpolished idea for NEW: instead of rejects, while the package is in NEW, dak could export the Source/Maintainer/Uploaders to the BTS but not the package itself, then ftp-masters would file RC issues against the "NEW" package, which would get closed by new revisions of the package uploaded to NEW <dondelelcaro> pabs: I'm OK with that in principle; we'd need to figure out the right way to share that data, but the BTS basically only needs the information from the .changes anyway <pabs> dondelelcaro: how about debbugs downloads the deb822 for NEW? https://ftp-master.debian.org/new.822 <pabs> it is almost the same as Sources files <pabs> hmm, no Uploaders though <pabs> IIRC debbugs doesn't look at that though <pabs> the rest of the info in it seems similar to .changes <dondelelcaro> hrm; that could work. the bit that we're missing is the .versions file for NEW which lists the changelogs <dondelelcaro> but maybe that's not super important for things in NEW <dondelelcaro> since presuambly there'd only be a few bugs, and they'd be RC, so someone could just manually fix them up if they weren't properly versioned after the package completes NEW <pabs> hmm ok. might be possible to get dak to export the .versions somehow too <pabs> anyway, just an idea at this stage. thanks for clarifying it is reasonable and potentially feasible -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part