On 2016-09-19 12:28, Jakub Wilk wrote:
* Adam D. Barratt , 2016-09-18, 11:28:
"Fixed in NMU" has not been a distinct state for several years, since
the introduction of BTS version tracking.
To clarify, the state still exists:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=fixed
... but I gu
* Adam D. Barratt , 2016-09-18, 11:28:
"Fixed in NMU" has not been a distinct state for several years, since the
introduction of BTS version tracking.
To clarify, the state still exists:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=fixed
... but I guess most packages were tagged like this
On Sun, 18 Sep 2016 15:39:38 +0100, "Adam D. Barratt"
wrote:
[...]
> In order to determine whether a particular upload is "descended" from
> any other previous upload, the information used by the BTS is generated
> by parsing changelogs and building a tree of uploads, with each stanza
> being cons
On Sun, 2016-09-18 at 14:30 +0200, Stephen Kitt wrote:
> On Sun, 18 Sep 2016 11:28:55 +0100, "Adam D. Barratt"
> wrote:
> > If your next maintainer upload includes the changelog stanza for the NMU
> > in its changelog then the BTS will automatically know that your upload
> > includes those fixes,
On Sun, 2016-09-18 at 16:01 +0200, Santiago Vila wrote:
> On Sun, Sep 18, 2016 at 02:25:13PM +0100, Ben Hutchings wrote:
>
> > That depends on what you mean by 'after'. If you mean 'with a greater
> > version', then the answer is no. The BTS parses changelogs to
> > determine whether a version c
On Sun, Sep 18, 2016 at 02:25:13PM +0100, Ben Hutchings wrote:
> That depends on what you mean by 'after'. If you mean 'with a greater
> version', then the answer is no. The BTS parses changelogs to
> determine whether a version currently in the archive is derived from a
> version where the bug
On Sun, 2016-09-18 at 14:30 +0200, Stephen Kitt wrote:
> On Sun, 18 Sep 2016 11:28:55 +0100, "Adam D. Barratt"
> > wrote:
> >
> > On Sun, 2016-09-18 at 11:45 +0200, Marc Haber wrote:
> > >
> > > So when I do the first upload after an NMU all bugs that the BTS has
> > > as "fixed in NMU" get chan
On Sun, 18 Sep 2016 11:28:55 +0100, "Adam D. Barratt"
wrote:
> On Sun, 2016-09-18 at 11:45 +0200, Marc Haber wrote:
> > So when I do the first upload after an NMU all bugs that the BTS has
> > as "fixed in NMU" get changed to "closed"?
>
> "Fixed in NMU" has not been a distinct state for severa
On Sun, 2016-09-18 at 11:45 +0200, Marc Haber wrote:
> On Sun, 18 Sep 2016 10:10:14 +0800, Paul Wise wrote:
> >With the BTS version tracking feature, acking NMUs is no longer needed
> >as the BTS tracks changelog heritage IIRC, so I'd not mention that in
> >the description.
>
> So when I do the f
On Sun, 18 Sep 2016 10:10:14 +0800, Paul Wise wrote:
>With the BTS version tracking feature, acking NMUs is no longer needed
>as the BTS tracks changelog heritage IIRC, so I'd not mention that in
>the description.
So when I do the first upload after an NMU all bugs that the BTS has
as "fixed in N
Hi Manuel,
On 09/17/16 20:53, Manuel A. Fernandez Montecelo wrote:
>> On Sun, Aug 28, 2016 at 10:13:44AM +0100, Manuel A. Fernandez
>> Montecelo wrote:
>>> I think that one measure to improve the current situation is that, for
>>> the people doing NMUs, to orphan the package when the number of NMU
On Sun, Sep 18, 2016 at 2:53 AM, Manuel A. Fernandez Montecelo wrote:
> 2016-08-28 21:50 Sean Whitton:
>> On Sun, Aug 28, 2016 at 10:13:44AM +0100, Manuel A. Fernandez Montecelo
>> wrote:
>>>
>>> I think that one measure to improve the current situation is that, for
>>> the people doing NMUs, to or
2016-08-28 21:50 Sean Whitton:
Hello,
On Sun, Aug 28, 2016 at 10:13:44AM +0100, Manuel A. Fernandez Montecelo wrote:
I think that one measure to improve the current situation is that, for
the people doing NMUs, to orphan the package when the number of NMUs
exceeds for example 3 or 5 in a row, o
On Wed, 2016-08-31 at 00:19 +, Sean Whitton wrote:
> The nice thing about the homepage being there is that the user can get
> it by running `apt-cache show foo`. Unless you plan to pull in that
> information when building the binary package?
It woudn't need to be present when building the bi
Hello,
On Tue, Aug 30, 2016 at 10:20:21AM +0800, Paul Wise wrote:
> On Tue, Aug 30, 2016 at 1:56 AM, Niels Thykier wrote:
>
> > Frankly, I do not think that the source package is the correct place for
> > the Maintainer / Uploaders data. There are plenty of cases where it
> > would make sense to
On Tue, Aug 30, 2016 at 1:56 AM, Niels Thykier wrote:
> Frankly, I do not think that the source package is the correct place for
> the Maintainer / Uploaders data. There are plenty of cases where it
> would make sense to update it "retroactively" after the package has been
> uploaded (E.g. orphan
Ian Jackson:
> Holger Levsen writes ("Re: removal instead of orphaning?"):
>> Maybe a solution would be a third kind of maintainer/uploader, so
>> people could indicate that they are happy to do house-cleaning work on
>> this package, even though they are
Holger Levsen writes ("Re: removal instead of orphaning?"):
> Maybe a solution would be a third kind of maintainer/uploader, so
> people could indicate that they are happy to do house-cleaning work on
> this package, even though they are not apt to maintain it properl
Hello,
On Sun, Aug 28, 2016 at 10:13:44AM +0100, Manuel A. Fernandez Montecelo wrote:
> I think that one measure to improve the current situation is that, for
> the people doing NMUs, to orphan the package when the number of NMUs
> exceeds for example 3 or 5 in a row, or 1 year since the oldest NM
2016-08-28 02:22 gregor herrmann:
On Sat, 27 Aug 2016 11:40:03 +0200, Paul Gevers wrote:
On 26-08-16 23:40, Julien Cristau wrote:
> off the top of my head:
> - it's wasting time of anyone doing QA work
> - it's wasting time of any user who looks for a piece of software to
> do
> $stuff and
On Sat, 27 Aug 2016 11:40:03 +0200, Paul Gevers wrote:
> On 26-08-16 23:40, Julien Cristau wrote:
> > off the top of my head:
> > - it's wasting time of anyone doing QA work
> > - it's wasting time of any user who looks for a piece of software to
> > do
> > $stuff and gets to eliminate all the
On Sat, Aug 27, 2016 at 02:02:39PM +0200, Paul Gevers wrote:
> And how do we balance the work it takes for those doing QA on those
> packages (for whatever reason) versus the value mentioned by Paul? As
> mentioned so often, popcon has it's value, but is definitely not the answer.
We have several
Hi Paul,
On 27-08-16 13:15, Paul Wise wrote:
> The long tail of less used and orphaned packages has value.
> Deletionism is bad on Wikipedia and in Debian too.
Can you also please explain WHY you have this opinion? Because I don't
understand it. I think I understand it for Wikipedia, but why for
Hi
On 27-08-16 13:33, Vincent Bernat wrote:
> Sometimes, a package is still worthwhile even without a maintainer.
And all I ask is the original maintainer to take this into account (of
course only making an estimate for the users) when (s)he is deciding
what to do with the package.
Paul
signa
❦ 27 août 2016 12:23 CEST, Andrew Shadura :
>> Today I was, once again, surprised to see how many (low popcon) orphaned
>> packages we have. I believe that orphanage is a burden to our community
>> in the sense that not all packages are picked up by a new maintainer and
>> these packages need so
On Fri, Aug 26, 2016 at 10:12 PM, Paul Gevers wrote:
> I suggest that everybody that orphans a package makes a statement in the
> wnpp bug report on why (s)he believes orphaning is better than removal.
> If people agree with my idea here, I'll suggest a change to the
> reportbug template for orpha
On 26-08-16 23:40, Julien Cristau wrote:
>> Who is this a burden for? As long as there are no RC bugs filed for
>> the orphaned packages, I don't see any a direct reason to remove
>> them. If no-one used the package, then sure, the package is really
>> useless. But if at least some people are using
* Sebastian Reichel , 2016-08-27, 02:24:
rc-alert -dU `wnpp-alert | grep "^O " | cut -d' ' -f 3`
I don't think this handles the case when the RC bug was filed against a
binary package that has a different name than the source package.
Anyway, it's not like orphaned are the only packages that
Hi,
On Fri, Aug 26, 2016 at 09:47:39PM +0200, Adam Borowski wrote:
> On Fri, Aug 26, 2016 at 09:38:02PM +0200, Guus Sliepen wrote:
> > > Should unrelated people spend time on packages they don't care about?
> >
> > No, that's why they are orphaned in the first place.
>
> You can run the attached
On Fri, Aug 26, 2016 at 08:49:00PM +, Niels Thykier wrote:
> > Possible things this tool could do:
> >
> > - Notify about orphaned packages the DD is using
> > - Notify about installed packages with RC bugs
> > - Notify about installed packages with RFH/RFA bugs
> > [...]
>
> Aren't these 3
On Fri, Aug 26, 2016 at 19:01:52 +0200, Guus Sliepen wrote:
> On Fri, Aug 26, 2016 at 04:12:46PM +0200, Paul Gevers wrote:
>
> > Today I was, once again, surprised to see how many (low popcon) orphaned
> > packages we have. I believe that orphanage is a burden to our community
> > in the sense th
On Fri, Aug 26, 2016 at 08:49:00PM +, Niels Thykier wrote:
> > Possible things this tool could do:
> >
> > - Notify about orphaned packages the DD is using
> > - Notify about installed packages with RC bugs
> > - Notify about installed packages with RFH/RFA bugs
> > [...]
> >
>
> Aren't thes
Guus Sliepen:
> On Fri, Aug 26, 2016 at 09:47:39PM +0200, Adam Borowski wrote:
> [...]
> Possible things this tool could do:
>
> - Notify about orphaned packages the DD is using
> - Notify about installed packages with RC bugs
> - Notify about installed packages with RFH/RFA bugs
> [...]
>
Aren'
On Fri, Aug 26, 2016 at 09:47:39PM +0200, Adam Borowski wrote:
> You can run the attached script to see if there are any RC bugs on an
> orphaned package you might give a damn about.
Interesting. Might it be an idea to create a package that contains this
kind of wisdom, and makes it easy for DDs
On Fri, Aug 26, 2016 at 07:43:20AM -1000, David Prévot wrote:
> > As long as there are no RC bugs filed for the
> > orphaned packages, I don't see any a direct reason to remove them.
>
> What about, e.g., security issues: if nobody cares about maintaining
> code, whether dormant or dead upstream,
On Fri, Aug 26, 2016 at 09:38:02PM +0200, Guus Sliepen wrote:
> > Should unrelated people spend time on packages they don't care about?
>
> No, that's why they are orphaned in the first place.
You can run the attached script to see if there are any RC bugs on an
orphaned package you might give a
On Fri, Aug 26, 2016 at 09:38:02PM +0200, Guus Sliepen wrote:
> > > > I believe that orphanage is a burden to our community [...]
> > >
> > > Who is this a burden for?
> > Transitions. Mandatory packaging changes, like python helper one.
> > True, a package can get an RC bug and be removed during
On Fri, Aug 26, 2016 at 10:34:29PM +0500, Andrey Rahmatullin wrote:
> > > I believe that orphanage is a burden to our community [...]
> >
> > Who is this a burden for?
> Transitions. Mandatory packaging changes, like python helper one.
> True, a package can get an RC bug and be removed during th
Hi,
Le 26/08/2016 à 07:01, Guus Sliepen a écrit :
> On Fri, Aug 26, 2016 at 04:12:46PM +0200, Paul Gevers wrote:
>
>> Today I was, once again, surprised to see how many (low popcon) orphaned
>> packages we have. I believe that orphanage is a burden to our community
>> in the sense that not all pa
On Fri, Aug 26, 2016 at 07:01:52PM +0200, Guus Sliepen wrote:
> > Today I was, once again, surprised to see how many (low popcon) orphaned
> > packages we have. I believe that orphanage is a burden to our community
> > in the sense that not all packages are picked up by a new maintainer and
> > the
On Fri, Aug 26, 2016 at 04:12:46PM +0200, Paul Gevers wrote:
> Today I was, once again, surprised to see how many (low popcon) orphaned
> packages we have. I believe that orphanage is a burden to our community
> in the sense that not all packages are picked up by a new maintainer and
> these packa
Hi all,
Today I was, once again, surprised to see how many (low popcon) orphaned
packages we have. I believe that orphanage is a burden to our community
in the sense that not all packages are picked up by a new maintainer and
these packages need some QA once in a while and often don't get enough
o
42 matches
Mail list logo