Quoting Xavier (2019-10-22 14:45:50) > Le Mardi, Octobre 22, 2019 14:07 CEST, Jonas Smedegaard <jo...@jones.dk> a > écrit: > > Quoting Xavier (2019-10-22 13:23:28) > > > Personnaly I think that we should enable test anywhere it is > > > possible to provide quality packages. That's why I prefer > > > embedding than pushing package without test. > > > > I agree we should test instead of not test. > > > > I agree we should package testing tools to improve ability to test. > > > > I agree we should embed when embed tiny projects into other > > packages. > > > > I disagree that testing inherently requires embedding. > > Inherently not, ... but... Concrete example: node-though-cookie is > outdated. Upgrade needs node-psl. psl is a real package, widely used, > then I decided to package it separately... 4 months ago (package is > clean, no lintian warnings, no ftpmaster question, just too many > time)...
Sounds reasonable to introduce psl as new _binary_ package (not embed in _binary_ package node-though-cookie and add "Provides: node-psl" hint): Upstream project has many seemingly unrelated reverse dependencies which are probably not all also depending on node-though-cookie, so it would be annoying to have those needlessly pull in node-though-cookie. Sounds reasonable to instroduce psl as new _source_ package (not embed in src:node-though-cookie): It isn't tiny. NEW entry: https://ftp-master.debian.org/new/psl.js_1.2.0+ds-1.html No lintian warnings is a good _baseline_ - i.e. avoids speedy _rejection_ but not a reason for speedy _acceptance_ by ftpmasters. My understanding is that NEW queue is not processed as a FIFO, but ftpmasters work on packages as they have time, as the volunteers they are - just like you and me. As I understand it, silence generally means no ftpmaster has gotten around to look at the package yet. Why might that be? Could be the very fact it is JavaScript with its reputation of commonly having problems and rejections commonly being discussed, so not really fun for ftpmasters to touch. Could be that it is related to Public Suffix List yet it does not depend or build-depend on publicsuffix, indicating high risk of problems concretely. > Then when/if psl.js is accepted, I'll update node-tough-cookie and > package that depends on it will be able to upgrade. Every new project we introduce into Debian need ftpmaster inspection. That's tied to our core values of Free Software. Embedding that new upstream project into an already inspected package means that new codebase is missed a crucial inspection. That'd be bad! It is painful when inspection is slow. But blaming ftpmasters is not helping. Upstream spawns new projects at a higher rate than we can package in Debian (read: we need more people in the JavaScript team), and upstream care less about freedom than Debian (read: we do need ftpmaster processing!). And JavaScript team introduces upstream projects to Debian at a higher rate than ftpmasters can process (read: We need more ftpmasters). Sounds to me like Debian need more people volunteering for ftpmaster tasks - more people who understand and care for JavaScript, so that they might prioritize processing those packages in the NEW queue over other tasks in the ftpmaster team. ...but beware: I am _not_ suggesting anyone to volunteer for ftpmaster tasks by the expectation that they can get packages approved that others in the ftpmaster team would reject. So I am _not_ suggesting that volunteering for ftpmaster tasks in any way _replaces_ doing proper Debian packaging. I only suggest that more worker bees reduce time. > But if one upgrade needs a new package, then a new 4-6 months is > needed. In this delay, node-tough-cookie will probably need a new > dependency... Each time a _new_ project needs to get introduced to Debian, there is a wait, which _may_ be months but can be weeks or days or hours. There is no need to wait until the package is processed: You can queue up additional revisions of an unapproved package, and the ftpmasters will (in my experience) process them together. Upstream projects crucially needing _new_ dependencies every 3-4 months sounds like projects unsuitable for long-term maintenance - i.e. unfit for Debian. > Following our udd.debian.org page, most of our package are strongly > outdated (I upgraded this morning node-superagent from 0.2.x to 5.x > !!!). That's a big problem IMO, Debian Buster proposes a lot of > totally outdated/unusable node package. Agreed, that's a big problem. For our team, not for NEW queue. > Embedding was a way to try to deliver some package with better > quality, Wrong. Embedding just avoids metadata. Embedding which implies a speedup - because it is seen as a way to introduce new upstream code projects without needing to pass through NEW queue - then embedding is being _abused_ for the wrong reason. > but if it can't be used in this way (and since nothing will > change in new queue), we should limit strictly the number of package > provided by this group: a good node.js, node-gyp and npm/yarn, and > then only dependencies of other project (jquery, bootstrap, > react,...). Regardless of the speed of NEW queue, and regardless of embedding, we should tighten our responsibility for the packages we maintain. As a start, let's do as the Multimedia team: Use Uploaders field to indicate who is actively caring for each package, and require that packages must list at least 2 Uploaders to belong in the team. Packages with fewer active uploaders is then an indication that more people in the team need to step up and care more for a package, or the package should either be moved outside the team (maintained by a single maintainer independently, or flagged as orphaned so that everyone in Debian can see how "rotten" it becomes, or dropped from Debian. But let's start with making it possible to identify what we care for - as independent measure from how up-to-date it is or how long ago it was touched. Let's treat "Uploaders" as "caretakers"! > Like you, I'm also member of Perl Team, and I never see a Perl package > staying more than 3-4 weeks in NEW queue. Pers modules are generally far easier to process, both by maintainers and (in my experience, implied by processing time) by ftpmasters. - 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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
