Re: [Pkg-javascript-devel] pre-spring cleaning, please advise

[Jérémy Lal]

2017-01-28 17:46 GMT+01:00 Ross Gammon :
> On 01/28/2017 10:52 AM, Paolo Greppi wrote:
>> This is a good idea ! There is a lot of cruft, especially packages created 
>> for some obscure reason 2-3 years ago and since then abandoned both by the 
>> maintainer and by upstream, and superseded by the next cool thing in the 
>> nodejs ecosystem.
>>
>> I propose to extract from UDD a list of candidate packages to be removed: 
>> those not fulfilling the criteria proposed by Jérémy, plus some more like:
>>
>> - popcon > 20
>> ..
>>
>> The list would be published for scrutiny here in this mailing list or on the 
>> wiki for say 2 weeks.
>>
>> To address the point raised by Ben (i.e. to make sure we don't remove a 
>> library needed at some point in the future for some other package not yet 
>> uploaded), I would leave it to the owner of the high-level package IPTs: for 
>> each of those there is a Task in the wiki or a non-disclosed WIP list - in 
>> any case the ITP owner knows best and she should manually remove from the 
>> list the packages she thinks she'll need, providing a rationale (i.e. 
>> "needed for yarnpkg").
>>
>> Once the 2 weeks are over we can proceed mass filing those "candidate for 
>> removal" bugreports.
>>
>> Once the additional 2 weeks are over the bugreports can be reassigned to 
>> ftpmaster.
>>
>> Paolo
>>
>> On 28/01/2017 10:17, Jonas Smedegaard wrote:
>>> Quoting Ben Finney (2017-01-28 03:07:01)
 Jérémy Lal  writes:

> - or having a reverse (build-)dependency, or what's the point ?
 I am very much in favour of this: node libraries should be in Debian
 to provide a library that is needed for some actual program of benefit
 to Debian users.
>>> Agreed.
>>>
>>>
 But my eagerness to remove useless packages makes me worry that some
 useful ones could be swept up also.

 One use case I don't see addressed: How will we ensure that a library
 is not needed for some other package not yet uploaded to Debian?
>>> Removal from testing involves filing a bugreport to ftpmaster.  I guess
>>> it makes sense if at all uncertain to first file bugreport against the
>>> package and cc this list - of not-to-high severity - suggesting the
>>> intent (removal from stretch or removal from Debian completely) some
>>> time (2 weeks?) before reasigning to ftpmaster.
>>>
>>> Discussing only here is not adequate: Being part of this team and
>>> subscribing to this mailinglist is voluntary.
>>>
>>>
>>>  - Jonas
>>
>
> I agree. But...
>
> It might be a good idea to keep the alioth repo for a while though.
> Upstreams can sometimes get going again when some need is identified and
> someone willing steps up to maintain it. Then we can at least quickly
> resurrect the package if required.
>
> Can we be a little less aggressive on the timescales? It should be a
> Buster goal. It can take me most of a release cycle to get all the other
> dependencies in shape in order for the final reverse dependency to get
> uploaded (I failed with several things this release cycle). Trying to
> re-remember what package I don't want to get "dropped out" (which could
> be maintained by someone else) and then adjusting bug severities does
> take up valuable time which could be spent getting the other
> dependencies ready.
>
> Also, as we enable more and more autopkgtests & buildtime testsuites,
> packages in bad shape will naturally fall out of testing anyway -
> without us doing any work. Periodically looking at the packages that
> have not been in testing for a long time could be another metric to use.
> I know I have a couple of those that weren't worth working on until a
> series of other dependencies were ready.

My proposal was not to remove the debian package entirely, it was more
about not letting a bunch of under-maintained node packages go to next
stable, so the time-scale would be crucial here.
In a second move, of course some packages need to be entirely removed,
but that's something that can be done much more slowly.

Jérémy


-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] pre-spring cleaning, please advise

[Ross Gammon]

On 01/28/2017 10:52 AM, Paolo Greppi wrote:
> This is a good idea ! There is a lot of cruft, especially packages created 
> for some obscure reason 2-3 years ago and since then abandoned both by the 
> maintainer and by upstream, and superseded by the next cool thing in the 
> nodejs ecosystem.
>
> I propose to extract from UDD a list of candidate packages to be removed: 
> those not fulfilling the criteria proposed by Jérémy, plus some more like:
>
> - popcon > 20
> ..
>
> The list would be published for scrutiny here in this mailing list or on the 
> wiki for say 2 weeks.
>
> To address the point raised by Ben (i.e. to make sure we don't remove a 
> library needed at some point in the future for some other package not yet 
> uploaded), I would leave it to the owner of the high-level package IPTs: for 
> each of those there is a Task in the wiki or a non-disclosed WIP list - in 
> any case the ITP owner knows best and she should manually remove from the 
> list the packages she thinks she'll need, providing a rationale (i.e. "needed 
> for yarnpkg").
>
> Once the 2 weeks are over we can proceed mass filing those "candidate for 
> removal" bugreports.
>
> Once the additional 2 weeks are over the bugreports can be reassigned to 
> ftpmaster.
>
> Paolo
>
> On 28/01/2017 10:17, Jonas Smedegaard wrote:
>> Quoting Ben Finney (2017-01-28 03:07:01)
>>> Jérémy Lal  writes:
>>>
 - or having a reverse (build-)dependency, or what's the point ?
>>> I am very much in favour of this: node libraries should be in Debian 
>>> to provide a library that is needed for some actual program of benefit 
>>> to Debian users.
>> Agreed.
>>
>>
>>> But my eagerness to remove useless packages makes me worry that some 
>>> useful ones could be swept up also.
>>>
>>> One use case I don't see addressed: How will we ensure that a library 
>>> is not needed for some other package not yet uploaded to Debian?
>> Removal from testing involves filing a bugreport to ftpmaster.  I guess 
>> it makes sense if at all uncertain to first file bugreport against the 
>> package and cc this list - of not-to-high severity - suggesting the 
>> intent (removal from stretch or removal from Debian completely) some 
>> time (2 weeks?) before reasigning to ftpmaster.
>>
>> Discussing only here is not adequate: Being part of this team and 
>> subscribing to this mailinglist is voluntary.
>>
>>
>>  - Jonas
>

I agree. But...

It might be a good idea to keep the alioth repo for a while though.
Upstreams can sometimes get going again when some need is identified and
someone willing steps up to maintain it. Then we can at least quickly
resurrect the package if required.

Can we be a little less aggressive on the timescales? It should be a
Buster goal. It can take me most of a release cycle to get all the other
dependencies in shape in order for the final reverse dependency to get
uploaded (I failed with several things this release cycle). Trying to
re-remember what package I don't want to get "dropped out" (which could
be maintained by someone else) and then adjusting bug severities does
take up valuable time which could be spent getting the other
dependencies ready.

Also, as we enable more and more autopkgtests & buildtime testsuites,
packages in bad shape will naturally fall out of testing anyway -
without us doing any work. Periodically looking at the packages that
have not been in testing for a long time could be another metric to use.
I know I have a couple of those that weren't worth working on until a
series of other dependencies were ready.

Cheers,

Ross


-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] pre-spring cleaning, please advise

[Paolo Greppi]

This is a good idea ! There is a lot of cruft, especially packages created for 
some obscure reason 2-3 years ago and since then abandoned both by the 
maintainer and by upstream, and superseded by the next cool thing in the nodejs 
ecosystem.

I propose to extract from UDD a list of candidate packages to be removed: those 
not fulfilling the criteria proposed by Jérémy, plus some more like:

- popcon > 20
..

The list would be published for scrutiny here in this mailing list or on the 
wiki for say 2 weeks.

To address the point raised by Ben (i.e. to make sure we don't remove a library 
needed at some point in the future for some other package not yet uploaded), I 
would leave it to the owner of the high-level package IPTs: for each of those 
there is a Task in the wiki or a non-disclosed WIP list - in any case the ITP 
owner knows best and she should manually remove from the list the packages she 
thinks she'll need, providing a rationale (i.e. "needed for yarnpkg").

Once the 2 weeks are over we can proceed mass filing those "candidate for 
removal" bugreports.

Once the additional 2 weeks are over the bugreports can be reassigned to 
ftpmaster.

Paolo

On 28/01/2017 10:17, Jonas Smedegaard wrote:
> Quoting Ben Finney (2017-01-28 03:07:01)
>> Jérémy Lal  writes:
>>
>>> - or having a reverse (build-)dependency, or what's the point ?
>>
>> I am very much in favour of this: node libraries should be in Debian 
>> to provide a library that is needed for some actual program of benefit 
>> to Debian users.
> 
> Agreed.
> 
> 
>> But my eagerness to remove useless packages makes me worry that some 
>> useful ones could be swept up also.
>>
>> One use case I don't see addressed: How will we ensure that a library 
>> is not needed for some other package not yet uploaded to Debian?
> 
> Removal from testing involves filing a bugreport to ftpmaster.  I guess 
> it makes sense if at all uncertain to first file bugreport against the 
> package and cc this list - of not-to-high severity - suggesting the 
> intent (removal from stretch or removal from Debian completely) some 
> time (2 weeks?) before reasigning to ftpmaster.
> 
> Discussing only here is not adequate: Being part of this team and 
> subscribing to this mailinglist is voluntary.
> 
> 
>  - Jonas


-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] pre-spring cleaning, please advise

[Jonas Smedegaard]

Quoting Ben Finney (2017-01-28 03:07:01)
> Jérémy Lal  writes:
> 
> > - or having a reverse (build-)dependency, or what's the point ?
> 
> I am very much in favour of this: node libraries should be in Debian 
> to provide a library that is needed for some actual program of benefit 
> to Debian users.

Agreed.


> But my eagerness to remove useless packages makes me worry that some 
> useful ones could be swept up also.
> 
> One use case I don't see addressed: How will we ensure that a library 
> is not needed for some other package not yet uploaded to Debian?

Removal from testing involves filing a bugreport to ftpmaster.  I guess 
it makes sense if at all uncertain to first file bugreport against the 
package and cc this list - of not-to-high severity - suggesting the 
intent (removal from stretch or removal from Debian completely) some 
time (2 weeks?) before reasigning to ftpmaster.

Discussing only here is not adequate: Being part of this team and 
subscribing to this mailinglist is voluntary.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] pre-spring cleaning, please advise

[Ben Finney]

Jérémy Lal  writes:

> - or having a reverse (build-)dependency, or what's the point ?

I am very much in favour of this: node libraries should be in Debian to
provide a library that is needed for some actual program of benefit to
Debian users.

But my eagerness to remove useless packages makes me worry that some
useful ones could be swept up also.

One use case I don't see addressed: How will we ensure that a library is
not needed for some other package not yet uploaded to Debian?

-- 
 \ “The aim of science is not to open the door to infinite wisdom, |
  `\but to set some limit on infinite error.” —Bertolt Brecht, |
_o__)_Leben des Galilei_, 1938 |
Ben Finney


-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] pre-spring cleaning, please advise

[Jérémy Lal]

Would it be a good idea to keep in next release only
node packages matching one of these conditions:

- providing a meaningful binary (not that stupid rimraf,
but marked-man of course yes)

- or depending on node-gyp (keep them because that's what
debian nodejs addons do best, npm sucks at installing
nodejs addons depending on system libs).

- or having a reverse (build-)dependency, or what's the point ?

- or being less than one year (approx.) behind upstream (yes i think npm
or node-postgres should not be in next stable)

If we don't take some action before release, users are going to be angry
of the poor quality of the packages we put in stable.
I have my share of responsibility in that fact, in this email is an attempt
at fixing things... Thank you for considering it seriously.

Jérémy


-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel