On Tue, Apr 14, 2020 at 05:36:37PM +0100, Ben Hutchings wrote:
>
> If a package hasn't been uploaded for 7 years, then:
>
> * At least some of its binary packages were probably built by the
> uploader, not on a buildd
> * If it's written in C or C++, it hasn't been built with all the
>
Le mardi, 14 avril 2020, 13.12:55 h CEST Wouter Verhelst a écrit :
> > One could expect from maintainers that they check their packages for
> > compliance regularly and that they document that.
>
> Perhaps, but it is *also* documented that an upload just to bump the
> Standards-Version is
On Tue, 2020-04-14 at 20:32 +0200, Lucas Nussbaum wrote:
> On 14/04/20 at 19:40 +0200, Adam Borowski wrote:
> > > I think we should be rebuilding everything at least once per release
> > > cycle, so we don't have a nasty surprise when these "mature" packages
> > > need bug fixes.
> >
> > There's
On 14/04/20 at 19:40 +0200, Adam Borowski wrote:
> > I think we should be rebuilding everything at least once per release
> > cycle, so we don't have a nasty surprise when these "mature" packages
> > need bug fixes.
>
> There's enough automated testing to spot FTBFS, thus rebuilding would only
>
On Tue, Apr 14, 2020 at 05:36:37PM +0100, Ben Hutchings wrote:
> On Tue, 2020-04-14 at 13:12 +0200, Wouter Verhelst wrote:
> > Perhaps, but it is *also* documented that an upload just to bump the
> > Standards-Version is severely frowned upon. If there is no other reason
> > to upload in 7 years,
On Tue, 2020-04-14 at 13:12 +0200, Wouter Verhelst wrote:
> On Sun, Apr 12, 2020 at 09:11:57PM +0200, Ole Streicher wrote:
[...]
> > One could expect from maintainers that they check their packages for
> > compliance regularly and that they document that.
>
> Perhaps, but it is *also* documented
On Sun, Apr 12, 2020 at 09:11:57PM +0200, Ole Streicher wrote:
> Wouter Verhelst writes:
> > On Sat, Apr 04, 2020 at 08:03:09PM +0200, Ole Streicher wrote:
> >> Adam Borowski writes:
> >> > Idea: perhaps we could make no unrestricted (maintainer, team, or QA)
> >> > upload
> >> > for 10 years a
Hi Jonas and -devel,
Jonas Smedegaard writes:
> Quoting Mattia Rizzolo (2020-04-11 17:20:48)
>> On Sat, Apr 11, 2020 at 11:10:48AM +0200, Wouter Verhelst wrote:
>> > On Fri, Apr 03, 2020 at 10:41:55PM +0200, Lucas Nussbaum wrote:
>> > > https://trends.debian.net/ was just updated (with data
On Sun, Apr 12, 2020 at 09:11:57PM +0200, Ole Streicher wrote:
> One could expect from maintainers that they check their packages for
> compliance regularly and that they document that. For a package that had no
> documented check for seven years it is OK to file an RC bug in order to
> clarify
On April 12, 2020 7:11:57 PM UTC, Ole Streicher wrote:
>Wouter Verhelst writes:
>> On Sat, Apr 04, 2020 at 08:03:09PM +0200, Ole Streicher wrote:
>>> Adam Borowski writes:
>>> > Idea: perhaps we could make no unrestricted (maintainer, team, or
>QA) upload
>>> > for 10 years a RC bug on its
Wouter Verhelst writes:
> On Sat, Apr 04, 2020 at 08:03:09PM +0200, Ole Streicher wrote:
>> Adam Borowski writes:
>> > Idea: perhaps we could make no unrestricted (maintainer, team, or QA)
>> > upload
>> > for 10 years a RC bug on its own? That threshold could then be gradually
>> > reduced to
On 11.04.20 17:20, Mattia Rizzolo wrote:
> On Sat, Apr 11, 2020 at 11:10:48AM +0200, Wouter Verhelst wrote:
>> On Fri, Apr 03, 2020 at 10:41:55PM +0200, Lucas Nussbaum wrote:
>>> https://trends.debian.net/ was just updated (with data until April 1st).
>>
>> There is a significant bump in the
Quoting Mattia Rizzolo (2020-04-11 17:20:48)
> On Sat, Apr 11, 2020 at 11:10:48AM +0200, Wouter Verhelst wrote:
> > On Fri, Apr 03, 2020 at 10:41:55PM +0200, Lucas Nussbaum wrote:
> > > https://trends.debian.net/ was just updated (with data until April 1st).
> >
> > There is a significant bump in
On Sat, Apr 11, 2020 at 11:10:48AM +0200, Wouter Verhelst wrote:
> On Fri, Apr 03, 2020 at 10:41:55PM +0200, Lucas Nussbaum wrote:
> > https://trends.debian.net/ was just updated (with data until April 1st).
>
> There is a significant bump in the number of co-maintained packages
> during the
On Fri, Apr 03, 2020 at 10:41:55PM +0200, Lucas Nussbaum wrote:
> Hi,
>
> https://trends.debian.net/ was just updated (with data until April 1st).
There is a significant bump in the number of co-maintained packages
during the buster release cycle. It is not at all clear to me what
happened
On Sat, Apr 04, 2020 at 08:03:09PM +0200, Ole Streicher wrote:
> Adam Borowski writes:
> > Idea: perhaps we could make no unrestricted (maintainer, team, or QA) upload
> > for 10 years a RC bug on its own? That threshold could then be gradually
> > reduced to eg. 5 years, as worst offenders get
On Apr 04, Niels Thykier wrote:
> Some of the technical debt is "doing harm" in the sense that we will
> have work around and deprecated code that linger and slow down our work
> on improving Debian.
You have cited specific issues which cause troubles, which is quite
different from just
Hello,
On Sat 04 Apr 2020 at 08:17PM +02, Niels Thykier wrote:
> [explanation]
>
> Therefore, I would like us to acknowledge the fact that technical debt
> is doing harm in that it has a cost for our contributors. But at the
> same time, I know it is hard to compare objectively to the cost of
Adam Borowski writes:
> Idea: perhaps we could make no unrestricted (maintainer, team, or QA) upload
> for 10 years a RC bug on its own? That threshold could then be gradually
> reduced to eg. 5 years, as worst offenders get fixed.
One could deprecate old Standards-Version and require a version
Sean Whitton:
> Hello,
>
> On Sat 04 Apr 2020 at 09:28AM +02, Lucas Nussbaum wrote:
>
>> Well, no, there doesn't seem to be any serious user-visible issues.
>>
>> That's why I keep wondering whether it makes sense to just keep all this
>> technical debt around.
>
> It could be useful to
Hello,
On Sat 04 Apr 2020 at 09:28AM +02, Lucas Nussbaum wrote:
> Well, no, there doesn't seem to be any serious user-visible issues.
>
> That's why I keep wondering whether it makes sense to just keep all this
> technical debt around.
It could be useful to someone, and it is not clear that it
On Sat, Apr 04, 2020 at 09:37:16AM +0200, Sebastiaan Couwenberg wrote:
> On 4/4/20 9:28 AM, Lucas Nussbaum wrote:
> > On 04/04/20 at 08:09 +0200, Paul Gevers wrote:
> >>> I keep wondering if we should make an effort to remove from testing
> >>> packages whose packaging 'style' is clearly outdated,
On Sat, Apr 04, 2020 at 11:43:21AM +0100, Simon McVittie wrote:
> On Sat, 04 Apr 2020 at 08:09:34 +0200, Paul Gevers wrote:
> > On 03-04-2020 22:41, Lucas Nussbaum wrote:
> > > - first, one can see how the number of package in testing decreases
> > > slowly during freezes, as broken packages are
On Sat, 04 Apr 2020 at 08:09:34 +0200, Paul Gevers wrote:
> On 03-04-2020 22:41, Lucas Nussbaum wrote:
> > - first, one can see how the number of package in testing decreases
> > slowly during freezes, as broken packages are removed
>
> And interesting to see that this hardly happened during
On 4/4/20 9:28 AM, Lucas Nussbaum wrote:
> On 04/04/20 at 08:09 +0200, Paul Gevers wrote:
>>> I keep wondering if we should make an effort to remove from testing
>>> packages whose packaging 'style' is clearly outdated, such as packages
>>> not updated since 2004 ('beav' is an example)...
>>
>> Is
On 04/04/20 at 08:09 +0200, Paul Gevers wrote:
> Hi Lucas
>
> On 03-04-2020 22:41, Lucas Nussbaum wrote:
> > There are a few things that strike me:
> >
> > - first, one can see how the number of package in testing decreases
> > slowly during freezes, as broken packages are removed
>
> And
Hi Lucas
On 03-04-2020 22:41, Lucas Nussbaum wrote:
> There are a few things that strike me:
>
> - first, one can see how the number of package in testing decreases
> slowly during freezes, as broken packages are removed
And interesting to see that this hardly happened during the last freeze.
Lucas Nussbaum writes ("trends.debian.net updated"):
> I updated https://trends.debian.net .
This is very cool and I wasn't even aware it existed! Yay!
I have one quibble which I'm not sure how to address and, relatedly, a
feature request.
The feature request first. Would it be easy to add a
28 matches
Mail list logo
