Re: Proposed New Incoming System
On 9 Feb 2002, James Troup wrote:
> o uploads in incoming must have been there > 24 hours before they
> are REJECTed. If they are processed before that and have problems
> they will be SKIPped (with no notification to the maintainer and/or
> uploader).
Didn't know this, it explains some things.
> o Only 'unchecked' is locally world-writeable. The others are all,
> of course, locally world-readable but only 'install' and 'byhand'
> are publicly visible on http://incoming.debian.org/
How does non-US fit into http://incoming.debian.org/ ?
> o list notification and bug closures are changed to be done for
> ACCEPTs, not INSTALLs. Mail is sent only to the maintainer/uploader
> on INSTALL.
> [Rationale: this reduces the load both on our list server and our
> BTS server; it also gives people better notice of uploads to
> avoid duplication of work especially, for example, in the case of NMUs]
> [NB: see [3] for clarifications of when ACCEPT/INSTALL mails are sent]
Er, this seems wrong. What about the out-of-date Maintainers file problem?
If bug closure mails are sent long before the package is installed(which means
dinstall has not yet made the new Maintainers file), then won't this be
problematic?
As an owner@bugs person, I would like to have the new Maintainers file first,
before getting the slew of bug closure mails.
I am willing to add a new state to the bts, to allow these pending-closed and
pending-fixed bugs, so they show up on the cgi frontend.
> o Allows previously-prohibitively-expensive checks to be added to dinstall
I've got a few that need to be added. dpkg-source v2 checks(don't want it
used until it is in stable). We can discuss later, when I actually have
dpkg-source rewritten.
> What breaks:
> ------------
>
> o uploads of large packages directly to incoming over a slow link
> can lead to bogus rejections.
>
> * solution: Ensure the .changes file is the last file to be
> uploaded (dput and dupload already do this) or upload
> to a temporary directory then mv them into place with
> ssh.
dupload does not do this. All my recent uploads have had the .changes be the
second to last file.
>
> o people who upload packages but then want to retract or replace the
> upload.
>
> * solution: mostly "Don't do that then"; i.e. test your uploads
> properly. Uploads can still be replaced, simply by uploading a
> higher versioned replacement. Total retraction is harder but
> usually only relevant for NEW packages.
This is a win, not a loss, imho.
> [3]
> --> reject
> /
> /
> unchecked ---------------------------[*]-------> install ------[+]------> pool
> \ ^ ^
> | / /
> |--> new -- /
> | |[4] /
> | V /
> |--> byhand --/
>
> [*] is ACCEPT and when list notification and bug closure occurs
> [+] is INSTALL and when maintainer/uploader notification occurs
Again, I'd like bug closure emails sent after the bts has been pulsed. I know
this is not how it is currently done, but this is what I would like.
Reply to: