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 to our
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
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
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
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.
>
> > "detected by tooling" wou
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
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 future uploads of a
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
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 whether
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, unles
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 d
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 rerea
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 Debian's official pack
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
>
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 you
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, especially for us
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 uploads
>of
>> > exis
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
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 any
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 ta
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.
+1
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, unles
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 the
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 t
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 don't
> have confidence
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
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 or
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 arbitr
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 lines.
>
>On Tue, Mar 06
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, we don't
> have confiden
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 deser
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
publicly.
If it turns
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
cod
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
> rejectio
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 de
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 so
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
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
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
> repo
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 flyi
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 t
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.
>
> That
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 ftpmast
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 attem
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 kno
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 pr
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 de
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
workloa
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, there is an issue open about the new bina
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 archive, th
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 requir
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
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 d
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 revision
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 inc
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 happe
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
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 Debian archive is
>>> "
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 want to make it a r
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 be
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
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 this wo
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. For
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.
> >
> > Well, possbibly, but i
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
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
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
> Visiting
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 e
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 shame not to cover the
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 I
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 miss
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 the new binary pac
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
S
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. H
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 everyon
75 matches
Mail list logo
