Re: Updated proposal for improving the FTP NEW process

On Sat, Apr 14, 2018 at 01:00:08PM +0100, Ian Jackson wrote: > Adrian Bunk writes ("Re: Updated proposal for improving the FTP NEW > process"): >... > > What happens outside of our archive (e.g. in Ubuntu or .debian.net) > > is nothing we officially provide t

Re: Updated proposal for improving the FTP NEW process

Adrian Bunk writes ("Re: Updated proposal for improving the FTP NEW process"): > Note that there are also many other situations where you already end up > with different contents under the same version. Not different source code. > An obvious example would be if you put b

Re: Updated proposal for improving the FTP NEW process

On Fri, Apr 13, 2018 at 03:54:29PM +0100, Ian Jackson wrote: >... > Now you seem to be saying > > 1 having the same version version number referring to >multiple different source versions is completely fine > because > 2 reusing version version numbers should not be forbidden >... > I

Re: Updated proposal for improving the FTP NEW process

Adrian Bunk writes ("Re: Updated proposal for improving the FTP NEW process"): > Debian version numbers are usually not globally unique. > > The binary packages of dgit 4.3 in Debian and Ubuntu are different > builds from the same sources, and for binary-any packages s

Re: Updated proposal for improving the FTP NEW process

On Wed, Apr 11, 2018 at 02:05:03PM -0700, Russ Allbery wrote: > Adrian Bunk writes: > > > Imagine tomorrow a random person from the internet noone has ever heard > > of uploads a package dgit 5.0 to mentors.d.n. > > > It is clear that this would not be sponsored. > > >

Re: Updated proposal for improving the FTP NEW process

Adrian Bunk writes ("Re: Updated proposal for improving the FTP NEW process"): > On Mon, Apr 09, 2018 at 02:24:23PM +0100, Ian Jackson wrote: > > apt-listchanges will present the right section of the changelog > > anyway. > > Assuming your "skip 10 v

Re: Updated proposal for improving the FTP NEW process

Adrian Bunk writes: > Imagine tomorrow a random person from the internet noone has ever heard > of uploads a package dgit 5.0 to mentors.d.n. > It is clear that this would not be sponsored. > "detected by tooling" would mean that this would result in dak > autorejecting any

Re: Updated proposal for improving the FTP NEW process

On Mon, Apr 09, 2018 at 02:24:23PM +0100, Ian Jackson wrote: > Adrian Bunk writes ("Re: Updated proposal for improving the FTP NEW > process"): > > A version is published to our users when it gets accepted into > > the archive. > > > > Readable inf

Re: Updated proposal for improving the FTP NEW process

Adrian Bunk writes ("Re: Updated proposal for improving the FTP NEW process"): > A version is published to our users when it gets accepted into > the archive. > > Readable information in apt-listchanges is IMHO more important > than theoretical discussions around wh

Re: Updated proposal for improving the FTP NEW process

On Tue, Mar 06, 2018 at 11:40:52PM +, Holger Levsen wrote: > On Tue, Mar 06, 2018 at 05:54:55PM +0100, Adam Borowski wrote: > > With my one of most active sponsors hat on: the current policy is that a > > version that has never hit the archive must not have a separate changelog > > entry,

Re: Updated proposal for improving the FTP NEW process

On Sat, 2018-03-10 at 23:06 +0100, Andreas Tille wrote: > In this longish thread I have read one contribution where a developer > expressed that he was happy about checking his SONAME bumped package > that was erroneous and luckily ftpmaster found the problem. I'm happy that the ftp masters are

Re: Updated proposal for improving the FTP NEW process

On Sat, Mar 10, 2018 at 11:06:49PM +0100, Andreas Tille wrote: > In this longish thread I have read one contribution where a developer > expressed that he was happy about checking his SONAME bumped package > that was erroneous and luckily ftpmaster found the problem. (Sorry, I'm > to lazy to

Re: Updated proposal for improving the FTP NEW process

On March 10, 2018 10:18:58 PM UTC, Andreas Tille wrote: >On Sat, Mar 10, 2018 at 05:37:28PM +, Scott Kitterman wrote: >> I'm afraid you have a rather narrower view of the FTP Master role >than the project [1], in particular, "... oversee and maintain the >well-being of

Re: Updated proposal for improving the FTP NEW process

On Sat, Mar 10, 2018 at 05:37:28PM +, Scott Kitterman wrote: > I'm afraid you have a rather narrower view of the FTP Master role than the > project [1], in particular, "... oversee and maintain the well-being of > Debian's official package repositories ...". The specifics listed later in >

Re: Updated proposal for improving the FTP NEW process

Hi Chris, On Sat, Mar 10, 2018 at 05:25:46PM +, Chris Lamb wrote: > > a single example in this thread that a developer was happy about the > > check since a mistake was avoided. But this would have happened by a > > random user via BTS as well. > > (I don't quite follow this, sorry.. can

Re: Updated proposal for improving the FTP NEW process

On March 6, 2018 7:27:40 PM UTC, Ian Campbell wrote: >On Tue, 2018-03-06 at 19:18 +0100, Mattia Rizzolo wrote: >> On Tue, Mar 06, 2018 at 06:34:28PM +0100, Adam Borowski wrote: >> > What might be reasonable is making the separation between binNEW >and srcNEW >> > more obvious,

Re: Updated proposal for improving the FTP NEW process

On March 10, 2018 11:13:46 AM UTC, Andreas Tille wrote: >Hi Chris, > >On Wed, Mar 07, 2018 at 02:44:32PM +, Chris Lamb wrote: >> > I think the suggestion of randomized spot checking is meant to >replace - >> > not add - to the present system of checking that penalizes

Re: Updated proposal for improving the FTP NEW process

Hi Andreas, > a single example in this thread that a developer was happy about the > check since a mistake was avoided. But this would have happened by a > random user via BTS as well. (I don't quite follow this, sorry.. can you rephrase?) Regards, -- ,''`. : :' : Chris Lamb

Re: Updated proposal for improving the FTP NEW process

On Sat, 10 Mar 2018 at 12:13:46 +0100, Andreas Tille wrote: > I share your assumption that if we try to get a real random set of > packages checked instead of checking those who are ending up by random > reasons in new we will end up with less re-checked packages. However, > this does not give

Re: Updated proposal for improving the FTP NEW process

Andreas Tille, on sam. 10 mars 2018 12:32:50 +0100, wrote: > On Tue, Mar 06, 2018 at 04:44:43PM -0700, Sean Whitton wrote: > > > On Mon, Mar 05, 2018 at 02:43:34PM -0700, Sean Whitton wrote: > > >> If a package is maintained in git, then re-using a version number > > >> means force-pushing a git

Re: Updated proposal for improving the FTP NEW process

Hi Sean, On Tue, Mar 06, 2018 at 04:44:43PM -0700, Sean Whitton wrote: > > On Mon, Mar 05, 2018 at 02:43:34PM -0700, Sean Whitton wrote: > >> If a package is maintained in git, then re-using a version number > >> means force-pushing a git tag > > Just don't tag uploads until they are accepted.

Re: Updated proposal for improving the FTP NEW process

On Tue, Mar 06, 2018 at 11:40:52PM +, Holger Levsen wrote: > On Tue, Mar 06, 2018 at 05:54:55PM +0100, Adam Borowski wrote: > > With my one of most active sponsors hat on: the current policy is that a > > version that has never hit the archive must not have a separate changelog > > entry,

Re: Updated proposal for improving the FTP NEW process

Hi Chris, On Wed, Mar 07, 2018 at 02:44:32PM +, Chris Lamb wrote: > > I think the suggestion of randomized spot checking is meant to replace - > > not add - to the present system of checking that penalizes uploads of > > existing source but new binaries. So human resources should not be

Re: Updated proposal for improving the FTP NEW process

On 14969 March 1977, Gert Wollny wrote: > Sure thing, I'll give it a try. Since I'm not familiar with the dak > code, would you be so kind to point me to the functions and variables > (if available) that are there to > - extract or hold the bugs listed in the last changelog entry, > - query

Re: Updated proposal for improving the FTP NEW process

On Wed, Mar 07, 2018 at 08:35:08PM +1100, Ben Finney wrote: > Gert Wollny writes: > > > […] simply asking the peers doesn't make the process very public. > > That is, IIUC, by design and for good reason. > > Before a review of the copyright status of the work is done, we

Re: Updated proposal for improving the FTP NEW process

On Wed, 2018-03-07 at 08:05 -0600, Steve Robbins wrote: > I think the suggestion of randomized spot checking is meant to > replace - not add - to the present system of checking that penalizes > uploads of existing source but new binaries. So human resources > should not be the issue. Yes, that's

Re: Updated proposal for improving the FTP NEW process

Steve, > I think the suggestion of randomized spot checking is meant to replace - > not add - to the present system of checking that penalizes uploads of > existing source but new binaries. So human resources should not be the > issue. In my experience, time/energy/focus is not as fungible

Re: Updated proposal for improving the FTP NEW process

I think the suggestion of randomized spot checking is meant to replace - not add - to the present system of checking that penalizes uploads of existing source but new binaries. So human resources should not be the issue. I would imagine that the packages currently being selected are not

Re: Updated proposal for improving the FTP NEW process

My preferred algorithm is dead simple : if the source package is the same, it is not NEW. Sorry for the top -post. My mobile device client is deficient. On March 6, 2018 11:34:29 AM CST, Bastian Blank wrote: >Hi Steve > >Please don't top-post and fix the length of your

Re: Updated proposal for improving the FTP NEW process

Am Mittwoch, den 07.03.2018, 20:35 +1100 schrieb Ben Finney: > Gert Wollny writes: > > > […] simply asking the peers doesn't make the process very public. > > That is, IIUC, by design and for good reason. > > Before a review of the copyright status of the work is done,

Re: Updated proposal for improving the FTP NEW process

On Wed, Mar 07, 2018 at 06:02:10AM +, Chris Lamb wrote: > Andrey Rahmatullin wrote: > > > > I know for a fact that quite regularly licence checks on binNEW > > > > packages causes RC bugs to pop up. I acknowledge it may be a > > > > burder for the ftp team, but that reason alone probably

Re: Updated proposal for improving the FTP NEW process

Gert Wollny writes: > […] simply asking the peers doesn't make the process very public. That is, IIUC, by design and for good reason. Before a review of the copyright status of the work is done, we don't have confidence the Debian Project has permission to redistribute it

Re: Updated proposal for improving the FTP NEW process

Am Mittwoch, den 07.03.2018, 08:09 +0100 schrieb Joerg Jaspert: > > If someone comes up with a patch to process-new which does this in a > halfway reliable way, it doesn't need a long time wasting thread on > devel to get it. Sure thing, I'll give it a try. Since I'm not familiar with the dak

Re: Updated proposal for improving the FTP NEW process

On 14967 March 1977, Gert Wollny wrote: I so like proposals from people who have never ever done any of the work they propose something one. BUt hey... > (1) Given that all new source package come with an ITP bug, when a > package must be rejected, the FTP team could CC this bug in the >

Re: Updated proposal for improving the FTP NEW process

On Wed, Mar 07, 2018 at 06:02:10AM +, Chris Lamb wrote: > Andrey Rahmatullin wrote: > > > > > I know for a fact that quite regularly licence checks on binNEW packages > > > > causes RC bugs to pop up. I acknowledge it may be a burder for the ftp > > > > team, but that reason alone probably

Re: Updated proposal for improving the FTP NEW process

Andrey Rahmatullin wrote: > > > I know for a fact that quite regularly licence checks on binNEW packages > > > causes RC bugs to pop up. I acknowledge it may be a burder for the ftp > > > team, but that reason alone probably deserves to keep binNEW as it is. > > > > That would seem to justify

Re: Updated proposal for improving the FTP NEW process

On Tue, Mar 06, 2018 at 06:15:10PM +, Ian Jackson wrote: > Adam Borowski writes ("Re: Updated proposal for improving the FTP NEW > process"): > > On Tue, Mar 06, 2018 at 03:17:11PM +, Ian Jackson wrote: > > > IMO Debian's rules should require that the revis

Re: Updated proposal for improving the FTP NEW process

Hello, On Tue, Mar 06 2018, Andrey Rahmatullin wrote: > On Mon, Mar 05, 2018 at 02:43:34PM -0700, Sean Whitton wrote: >> If a package is maintained in git, then re-using a version number >> means force-pushing a git tag > Just don't tag uploads until they are accepted. This means that uploading

Re: Updated proposal for improving the FTP NEW process

On Tue, Mar 06, 2018 at 05:54:55PM +0100, Adam Borowski wrote: > With my one of most active sponsors hat on: the current policy is that a > version that has never hit the archive must not have a separate changelog > entry, unless there are non-negligible users (such as a derivative, upstream >

Re: Updated proposal for improving the FTP NEW process

Hello, On Tue, Mar 06 2018, Adam Borowski wrote: > gaps in version numbering that come without an explanation also raise > an eyebrow (thus such a gap needs a comment in the changelog). I think this is the problem. Ian's concern about non-identical but identically versioned source packages

Re: Updated proposal for improving the FTP NEW process

On Wed, 2018-03-07 at 00:30 +0500, Andrey Rahmatullin wrote: > On Tue, Mar 06, 2018 at 07:27:40PM +, Ian Campbell wrote: > > > I know for a fact that quite regularly licence checks on binNEW packages > > > causes RC bugs to pop up. I acknowledge it may be a burder for the ftp > > > team, but

Re: Updated proposal for improving the FTP NEW process

On Tue, Mar 06, 2018 at 07:27:40PM +, Ian Campbell wrote: > > I know for a fact that quite regularly licence checks on binNEW packages > > causes RC bugs to pop up. I acknowledge it may be a burder for the ftp > > team, but that reason alone probably deserves to keep binNEW as it is. > >

Re: Updated proposal for improving the FTP NEW process

On Tue, 2018-03-06 at 19:18 +0100, Mattia Rizzolo wrote: > On Tue, Mar 06, 2018 at 06:34:28PM +0100, Adam Borowski wrote: > > What might be reasonable is making the separation between binNEW and srcNEW > > more obvious, especially for us on the other side. This would also > > encourage the

Re: Updated proposal for improving the FTP NEW process

On Tue, Mar 06, 2018 at 06:15:10PM +, Ian Jackson wrote: > > A changelog bloated with every replaced attempt is hard to read; gaps in > > version numbering that come without an explanation also raise an eyebrow > > (thus such a gap needs a comment in the changelog). > > How many replaced

Re: Updated proposal for improving the FTP NEW process

On Tue, Mar 06, 2018 at 06:34:28PM +0100, Adam Borowski wrote: > What might be reasonable is making the separation between binNEW and srcNEW > more obvious, especially for us on the other side. This would also > encourage the ftpmasters to skip license checks for binNEW -- but again, > without

Re: Updated proposal for improving the FTP NEW process

Adam Borowski writes ("Re: Updated proposal for improving the FTP NEW process"): > On Tue, Mar 06, 2018 at 03:17:11PM +, Ian Jackson wrote: > > IMO Debian's rules should require that the revision should be > > incremented (at least) when you have shared the previou

Re: Updated proposal for improving the FTP NEW process

Hi Steve Please don't top-post and fix the length of your lines. On Tue, Mar 06, 2018 at 10:22:22AM -0600, Steve Robbins wrote: > Or: change the mechanism to avoid a trip through NEW for simple cases that > Chris outlined: new binary or soname bump. Reserve NEW for truly new things. Can you

Re: Updated proposal for improving the FTP NEW process

On Tue, Mar 06, 2018 at 10:22:22AM -0600, Steve Robbins wrote: > Or: change the mechanism to avoid a trip through NEW for simple cases that > Chris outlined: new binary or soname bump. Reserve NEW for truly new > things. Let's not try to be wiser than ftpmasters: if, despite the increased

Re: Updated proposal for improving the FTP NEW process

Or: change the mechanism to avoid a trip through NEW for simple cases that Chris outlined: new binary or soname bump. Reserve NEW for truly new things. On March 5, 2018 9:00:06 AM CST, "W. Martin Borgert" wrote: >Quoting Chris Lamb : >>> In many cases,

Re: Updated proposal for improving the FTP NEW process

On Tue, Mar 06, 2018 at 03:17:11PM +, Ian Jackson wrote: > Scott Kitterman writes ("Re: Updated proposal for improving the FTP NEW > process"): > > If you consider it absurd to not increment the revision due to > > changes that never made it in the arch

Re: Updated proposal for improving the FTP NEW process

Scott Kitterman writes ("Re: Updated proposal for improving the FTP NEW process"): > If you consider it absurd to not increment the revision due to > changes that never made it in the archive, then I don't know where > it stops. IMO Debian's rules should require that

Re: Updated proposal for improving the FTP NEW process

On Mon, Mar 05, 2018 at 02:43:34PM -0700, Sean Whitton wrote: > If a package is maintained in git, then re-using a version number means > force-pushing a git tag Just don't tag uploads until they are accepted. -- WBR, wRAR signature.asc Description: PGP signature

Re: Updated proposal for improving the FTP NEW process

On Monday, March 05, 2018 04:46:27 PM Sean Whitton wrote: > Hello, > > On Mon, Mar 05 2018, Scott Kitterman wrote: > > I'm not sure you actually read what I wrote since I wrote that I > > thought REQUIRING the revision to be bumped was a bad idea and you > > gave me a case where it made sense to

Re: Updated proposal for improving the FTP NEW process

Hello, On Mon, Mar 05 2018, Scott Kitterman wrote: > I'm not sure you actually read what I wrote since I wrote that I > thought REQUIRING the revision to be bumped was a bad idea and you > gave me a case where it made sense to do so. Nowhere in this thread > have I ever said bumping the

Re: Updated proposal for improving the FTP NEW process

On Monday, March 05, 2018 02:43:34 PM Sean Whitton wrote: > Hello, > > On Mon, Mar 05 2018, Scott Kitterman wrote: > > Taken to it's logical end, then every VCS commit should have it's own > > revision. > > Could you explain how this follows? I don't see it. If you consider it absurd to not

Re: Updated proposal for improving the FTP NEW process

Hello, On Mon, Mar 05 2018, Scott Kitterman wrote: > Taken to it's logical end, then every VCS commit should have it's own > revision. Could you explain how this follows? I don't see it. > I think requiring a maintainer to increment the Debian revision of a > package based on things that

Re: Updated proposal for improving the FTP NEW process

Hello, On Mon, Mar 05 2018, Philipp Kern wrote: > The most common counterpoint to bumping the version is that it's > harder to get right because for some reason our tools rely on the > whole delta to be present in the .changes file rather than inferring > it from the in-package changelog. So bug

Re: Updated proposal for improving the FTP NEW process

On 03/05/2018 08:08 PM, Scott Kitterman wrote: > On March 5, 2018 7:01:14 PM UTC, Don Armstrong wrote: >> On Mon, 05 Mar 2018, Scott Kitterman wrote: >>> I think requiring a maintainer to increment the Debian revision of a >>> package based on things that happen outside the

Re: Updated proposal for improving the FTP NEW process

On March 5, 2018 7:01:14 PM UTC, Don Armstrong wrote: >On Mon, 05 Mar 2018, Scott Kitterman wrote: >> I think requiring a maintainer to increment the Debian revision of a >> package based on things that happen outside the Debian archive is >"not >> a good idea'[1]. > >I don't

Re: Updated proposal for improving the FTP NEW process

On Mon, 05 Mar 2018, Scott Kitterman wrote: > I think requiring a maintainer to increment the Debian revision of a > package based on things that happen outside the Debian archive is "not > a good idea'[1]. I don't want to make it a requirement, just recommended good practice when an upload has

Re: Updated proposal for improving the FTP NEW process

On Monday, March 05, 2018 05:54:59 PM Ian Jackson wrote: > Gert Wollny writes ("Re: Updated proposal for improving the FTP NEW process"): > > The only option I see for doing this in the BTS would be to ask the ftp > > team to file the reject messages as a new bug again

Re: Updated proposal for improving the FTP NEW process

Gert Wollny writes ("Re: Updated proposal for improving the FTP NEW process"): > The only option I see for doing this in the BTS would be to ask the ftp > team to file the reject messages as a new bug against the source > package. I refrained from proposing this because thi

Re: Updated proposal for improving the FTP NEW process

On Mon, 05 Mar 2018, Gert Wollny wrote: > Since the re-upload to NEW would have the same version like the > version the bug is filed against You don't have to upload with the same version (I usually don't, because I've already tagged the previous upload in git). > the BTS might get a hiccup.

Re: Updated proposal for improving the FTP NEW process

On Monday, March 05, 2018 04:00:06 PM W. Martin Borgert wrote: > Quoting Chris Lamb : > >> In many cases, there is an issue open about the new binary package > > > > (In my experience, there is not.) > > > >> When there is no bug report open at all, well, bad luck. > > > >

Re: Updated proposal for improving the FTP NEW process

Simon McVittie wrote: > Are binary-NEW packages more likely to violate the DFSG than randomly > chosen packages? I can't speak to a randomly-selected package, but IME entirely new source packages are less likely have problems IME than older ones that Just Visiting, thus ... > If the goal is to

Re: Updated proposal for improving the FTP NEW process

Am Montag, den 05.03.2018, 14:27 + schrieb Chris Lamb: > Hi Gert, > > > (1) Given that all new source package come with an ITP bug, when a > > package must be rejected, the FTP team could CC this bug in the > > rejection message. > > Do you have any concrete suggestions for packages that are

Re: Updated proposal for improving the FTP NEW process

On Mon, 05 Mar 2018 at 14:27:31 +, Chris Lamb wrote: > > (1) Given that all new source package come with an ITP bug, when a > > package must be rejected, the FTP team could CC this bug in the > > rejection message. > > Do you have any concrete suggestions for packages that are "Just >

Re: Updated proposal for improving the FTP NEW process

On Mon, 2018-03-05 at 14:51 +, Chris Lamb wrote: > Hi Martin, > > > In many cases, there is an issue open about the new binary package > > (In my experience, there is not.) > > > When there is no bug report open at all, well, bad luck. > > Well, possbibly, but if one is investing time and

Re: Updated proposal for improving the FTP NEW process

Quoting Chris Lamb : In many cases, there is an issue open about the new binary package (In my experience, there is not.) When there is no bug report open at all, well, bad luck. Well, possbibly, but if one is investing time and effort in changing a process it seems a

Re: Updated proposal for improving the FTP NEW process

Hi Martin, > In many cases, there is an issue open about the new binary package (In my experience, there is not.) > When there is no bug report open at all, well, bad luck. Well, possbibly, but if one is investing time and effort in changing a process it seems a shame not to cover these cases

Re: Updated proposal for improving the FTP NEW process

On 2018-03-05 12:18, Gert Wollny wrote: > (1) Given that all new source package come with an ITP bug, when a > package must be rejected, the FTP team could CC this bug in the > rejection message. i would really like to see this. sometimes i miss rejection emails - or at least wonder whether i

Re: Updated proposal for improving the FTP NEW process

Quoting Chris Lamb : Do you have any concrete suggestions for packages that are "Just Visiting" NEW, such as ones adding, say, a python3-foo, a -doc, a SONAME bump, first upload to experimental, etc. etc.? They do not have ITP bugs. In many cases, there is an issue open about

Re: Updated proposal for improving the FTP NEW process

Hi Gert, > (1) Given that all new source package come with an ITP bug, when a > package must be rejected, the FTP team could CC this bug in the > rejection message. Do you have any concrete suggestions for packages that are "Just Visiting" NEW, such as ones adding, say, a python3-foo, a -doc, a

Re: Updated proposal for improving the FTP NEW process

On Mon, Mar 5, 2018 at 7:18 PM, Gert Wollny wrote: > (2) To improve the initial quality of uploads to NEW I also propose the > introduction a (voluntary) review step: These sort of things have been proposed multiple times before but never materialised into policy, convention or common activity.

Updated proposal for improving the FTP NEW process

Dear all, thanks for all the feedback, based on this I'd like to modify the proposal like follows: (1) Given that all new source package come with an ITP bug, when a package must be rejected, the FTP team could CC this bug in the rejection message. This would have the advantage that for