Re: [Pkg-javascript-devel] roadmap of jquery (and helpers)
Quoting Jonas Smedegaard (2016-09-18 17:48:44) > Quoting Paul Gevers (2016-09-18 09:40:30) >> On 09/17/16 10:51, Jonas Smedegaard wrote: >>> Quoting Paul Gevers (2016-09-16 20:01:27) How are other JavaScript chains handling the lack of automatic API tracking? [...] > I am unaware of any systematic checks being done to javascript > packages like the symbols files we have for C/C++ libraries. > > Would be awesome to improve on that! The "scope analyzer" part of > UglifyJS might be a start: http://lisperator.net/uglifyjs/scope A better starting point seems tobe Esprima: http://esprima.org/ - 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] roadmap of jquery (and helpers)
Quoting Paul Gevers (2016-09-18 09:40:30) > On 09/17/16 10:51, Jonas Smedegaard wrote: >> Quoting Paul Gevers (2016-09-16 20:01:27) >>> How are other JavaScript chains handling the lack of automatic API >>> tracking? >> >> At least 16 packages unacceptably violates Debian Policy, according >> to >> https://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=co > > This was not what I meant. What I meant is how JavaScript is handling > the lack of shlibs/symbols processing as we do during package building > for libraries and depending packages. I would love to know how I can > learn what version of $javascript-package I actually need for my > package to work properly. Oh - sorry for not reading properly what you indeed explicitly wrote! I am unaware of any systematic checks being done to javascript packages like the symbols files we have for C/C++ libraries. Would be awesome to improve on that! The "scope analyzer" part of UglifyJS might be a start: http://lisperator.net/uglifyjs/scope I don't know javascript well enough to program something myself, though. >>> Are there tools in the team to check for breakage? One of the stupid >>> but powerful things that I do for the cacti package (a web-app) is >>> to just recursively crawl all web-pages, I guess it must be possible >>> to also check JavaScript execution. >> >> In theory we have several tools to emulate javascript-enabled >> browsing, > > Could you please hint which ones you have in mind? Backbone used to use PhantomJS in its upstream testsuite. The testsuite as a whole required parts not packaged for Debian but I had lifted out the one line executing PhantomJS. But then PhantomJS had problems close to a freeze and I avoided PhantomJS (see bug#768754). Recently when upgrading Backbone, I had a look at that PhantomJS issue again, but failed for me to use xvfb (workaround noted in bug#817277). There are some alternatives to PhantomJS, and there are verious frameworks making use of either PhantomJS or some of its alternatives. http://stackoverflow.com/questions/14964108/alternative-to-phantomjs-for-testing mentions some alternatives, one of them being "jsdom" seemingly what we have in Debian as node-jsdom, but I gave up on trying to figure out how to use it. Backbone recently switched upstreeam to the helper tool https://github.com/karma-runner/karma - which at its website mentions a range of related helper tools, some of which might (directly or indirectly) support either PhantomJS or some alternatives. Another approach might be to sidestep the whole Nodejs environment for testing. Seems there are automated web browsing testing tools for java, python and perl - where "Selenium" pops up frequently as a protocol(?) commonly used... I am a perl guy mostly. If you are a python guy you might have more or different options available... >> I guess locally - *not* using Debian infrastructure - one might use >> npm > > Why not using Debian infrastructure, because one needs to download > stuff that isn't in the package? I was thinking of running these tests > as autopkgtest? Correct: Many tools used in upstream testsuites are not packaged in Debian yet. I don't know the rules for autopkgtest - if pulling in alien code then I guess that is an option - but IMO would be a severe bug in the rules for autopkgtest (but arguably that's besides the point of this discussion). - 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] roadmap of jquery (and helpers)
On Wed, Sep 14, 2016 at 08:53:40PM +0200, Paul Gevers wrote: > Hi all, > > [I am aware that this has probably been discussed before, but I fail to > find the right discussion in the archive. Please point me to it if you > know where it is.] > > I am currently preparing for a new major upstream version of my package > cacti (which I hope will be able to meet the stretch freeze). Upstream > has already for a long time been using jquery, and I have been able to > use the Debian package as my dependency. The next major version "needs > to avoid jQueryUI 1.2 as it's currently a hot stinking mess."¹ Note that jQueryUI and jQuery are not the same thing. > AFAIUI due to the nature of how the javascript eco-system works, it is > not trivial to "follow" newer versions. Could you please let me know > what the roadmap² of the javascript maintainer team is for the jquery > package and to jquery related packages. I see there is a 3.0 version in > experimental, but it is unclear to the outside world (and to me) when > that will migrate to unstable. Should I instead prepare for a > convenience copy of jquery (and related scripts), which I would really > hate to do? My plan is to have jQuery 3.x in stretch. Didn't do it yet because ENOTIME. So I guess I will just upload the version in experimental -- which according to upstream, is backwards-compatible wrt 1.x, except support for IE8 and earlier -- to unstable, soon. signature.asc Description: PGP 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] roadmap of jquery (and helpers)
Hi, On 09/17/16 10:51, Jonas Smedegaard wrote: > Quoting Paul Gevers (2016-09-16 20:01:27) >> How are other JavaScript chains handling the lack of automatic API >> tracking? > > At least 16 packages unacceptably violates Debian Policy, according to > https://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=co This was not what I meant. What I meant is how JavaScript is handling the lack of shlibs/symbols processing as we do during package building for libraries and depending packages. I would love to know how I can learn what version of $javascript-package I actually need for my package to work properly. >> Are there tools in the team to check for breakage? One of the stupid >> but powerful things that I do for the cacti package (a web-app) is to >> just recursively crawl all web-pages, I guess it must be possible to >> also check JavaScript execution. > > In theory we have several tools to emulate javascript-enabled browsing, Could you please hint which ones you have in mind? > I guess locally - *not* using Debian infrastructure - one might use npm Why not using Debian infrastructure, because one needs to download stuff that isn't in the package? I was thinking of running these tests as autopkgtest? Paul signature.asc Description: OpenPGP digital 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] roadmap of jquery (and helpers)
Quoting Paul Gevers (2016-09-16 20:01:27) > On 09/14/16 21:46, Jonas Smedegaard wrote: > > The Javascript team is only loosely coordinated: Not all of us nurse > > all of the packages in the team. > > So how many are there approximately? We are potentially 82, according to https://alioth.debian.org/projects/pkg-javascript/ How many of us have actively contributed in recent time I don't know. Probably a sensible feature to add to UDD dashboard (see bug#838067). > And how many are involved in the jquery stuff? Officially 3, according to Uploaders field as listed at https://tracker.debian.org/pkg/jquery Effectively only 1 has committed to master branch recently, according to https://anonscm.debian.org/cgit/pkg-javascript/jquery.git/log/ Numbers more broadly for "jquery stuff" is more tedious to resolve, I suspect. It involves resolving the contributors to somewhere between 24 and 1500 packages, according to quick looks at https://udd.debian.org/dmd/?pkg-javascript-devel%40lists.alioth.debian.org and the output of "build-rdeps libjs-jquery". > I am considering joining the team, but I don't want to be the only one > to care for jquery and its related packages (no offense intended > Antonio). I understand your concern, but which are the alternatives as you see it? Personally I find only these alternatives sensible: a) patch package to work with javascript libs available in Debian b) hack package to avoid javascript unadaptable/unsuitable in Debian c) convince existing maintainers of javascript libs to improve d) get involved and do the improvements yourself I.e. I don't find it sensible to maintain javascript libraries outside of this team, and don't find it sensible to embed code copies of javascript in other packages. I am curious which alternatives you see, and arguments supporting them. > > As I recall, maintenance of jquery in particular has lagged behind a > > lot in the past. So any and all help would be much appreciated. > So a statement on the current strategy would be nice, such that I can > evaluate if it makes sense to join the team. Anyone (potential/official/effective/whatever) involved with jquery stuff please speak up! > What I care for is that a modern version is available (maybe for the > time being next to an older API? Sounds sensible to me - but my voice count less than those caring about jquery in particular. > How are other JavaScript chains handling the lack of automatic API > tracking? At least 16 packages unacceptably violates Debian Policy, according to https://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=co > Are there tools in the team to check for breakage? One of the stupid > but powerful things that I do for the cacti package (a web-app) is to > just recursively crawl all web-pages, I guess it must be possible to > also check JavaScript execution. In theory we have several tools to emulate javascript-enabled browsing, but I have not yet been able to figure out how to use any of them. Anyone having positive experience with automated brower testing, please speak up! I guess locally - *not* using Debian infrastructure - one might use npm to pull down and run some of the more involved various upstream testing tools. Not that I would do so myself, just mentioning as an option... Ideally we should package the more popular of those tools, obviously, but dependency chains are often long, and deviates from your question. - 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] roadmap of jquery (and helpers)
Hi all, On 09/14/16 21:46, Jonas Smedegaard wrote: Quoting Paul Gevers (2016-09-14 20:53:40) The Javascript team is only loosely coordinated: Not all of us nurse all of the packages in the team. So how many are there approximately? And how many are involved in the jquery stuff? I am considering joining the team, but I don't want to be the only one to care for jquery and its related packages (no offense intended Antonio). As I recall, maintenance of jquery in particular has lagged behind a lot in the past. So any and all help would be much appreciated. So a statement on the current strategy would be nice, such that I can evaluate if it makes sense to join the team. What I care for is that a modern version is available (maybe for the time being next to an older API? How are other JavaScript chains handling the lack of automatic API tracking? Are there tools in the team to check for breakage? One of the stupid but powerful things that I do for the cacti package (a web-app) is to just recursively crawl all web-pages, I guess it must be possible to also check JavaScript execution. Paul PS: until I join the team, please keep CC-ing me. -- 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] roadmap of jquery (and helpers)
Hi Paul, Quoting Paul Gevers (2016-09-14 20:53:40) > [I am aware that this has probably been discussed before, but I fail > to find the right discussion in the archive. Please point me to it if > you know where it is.] > > I am currently preparing for a new major upstream version of my > package cacti (which I hope will be able to meet the stretch freeze). > Upstream has already for a long time been using jquery, and I have > been able to use the Debian package as my dependency. The next major > version "needs to avoid jQueryUI 1.2 as it's currently a hot stinking > mess."¹ > > AFAIUI due to the nature of how the javascript eco-system works, it is > not trivial to "follow" newer versions. Could you please let me know > what the roadmap² of the javascript maintainer team is for the jquery > package and to jquery related packages. I see there is a 3.0 version > in experimental, but it is unclear to the outside world (and to me) > when that will migrate to unstable. Should I instead prepare for a > convenience copy of jquery (and related scripts), which I would really > hate to do? I strongly recommend against embedding jquery into the cacti package: You will then effectively take responsibility for maintaining the code (albeit only for compatibility with that one package, but with full coverage of eventual security flaws), and it would be far better if you instead joined the effort of maintaining the proper packaging. The Javascript team is only loosely coordinated: Not all of us nurse all of the packages in the team. Personally I dislike jquery so am not involved in that. As I recall, maintenance of jquery in particular has lagged behind a lot in the past. So any and all help would be much appreciated. - 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
[Pkg-javascript-devel] roadmap of jquery (and helpers)
Hi all, [I am aware that this has probably been discussed before, but I fail to find the right discussion in the archive. Please point me to it if you know where it is.] I am currently preparing for a new major upstream version of my package cacti (which I hope will be able to meet the stretch freeze). Upstream has already for a long time been using jquery, and I have been able to use the Debian package as my dependency. The next major version "needs to avoid jQueryUI 1.2 as it's currently a hot stinking mess."¹ AFAIUI due to the nature of how the javascript eco-system works, it is not trivial to "follow" newer versions. Could you please let me know what the roadmap² of the javascript maintainer team is for the jquery package and to jquery related packages. I see there is a 3.0 version in experimental, but it is unclear to the outside world (and to me) when that will migrate to unstable. Should I instead prepare for a convenience copy of jquery (and related scripts), which I would really hate to do? Paul PS: please CC me on replies, I am not subscribed. ¹ http://bugs.cacti.net/view.php?id=2227#c7608 ² Maybe even worth a wiki page signature.asc Description: OpenPGP digital 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
