Samuel Thibault writes:
> I however agree that it seems poor practice to duplicate these build
> modules in every packages. But if the required versions are different,
> there is no real other way.
There is another solution: put several different versions of the same
source code into some Debian
On Fri, 04 Sep 2015 17:54:30 +0200
Vincent Bernat wrote:
> ❦ 4 septembre 2015 09:32 +0100, Neil Williams
> :
>
> [Applying patch to pre-minification source]
> >> Getting the same min.js is not a goal (we don't try to get the same
> >> binaries than upstream from source code in any other langu
❦ 4 septembre 2015 09:32 +0100, Neil Williams :
[Applying patch to pre-minification source]
>> This will become more difficult with jQuery 3.x (due to ES6 to ES5
>> transformation). But manual adaptation should stay straightfoward
>> ("transpilation" only does local transformation).
>
> Are the
On Fri, 04 Sep 2015 10:07:13 +0200
Vincent Bernat wrote:
> ❦ 4 septembre 2015 08:29 +0100, Neil Williams
> :
>
> > For those upstreams who have to embed JS not available in Debian,
> > then the upstream code often cannot be processed in Debian, neither
> > can the unminified JS be minified in
❦ 4 septembre 2015 08:29 +0100, Neil Williams :
>> > 2. Many javascript packages cannot be build from source with the
>> > tools in main.
>>
>> This is the one I don't agree. For me, pre-minification source is
>> source code. If you show the pre-minification version of jQuery, many
>> people w
On Thu, 03 Sep 2015 22:51:50 +0200
Vincent Bernat wrote:
> ❦ 3 septembre 2015 13:19 -0700, Nikolaus Rath :
>
> > 2. Many javascript packages cannot be build from source with the
> > tools in main.
>
> This is the one I don't agree. For me, pre-minification source is
> source code. If you sho
❦ 3 septembre 2015 13:19 -0700, Nikolaus Rath :
>>> Because you know you have the right and the ability to be a part of the free
>>> software community that created the software. That is why you are running
>>> Debian and don't have contrib or non-free in your sources.list.
>>>
>>> From your m
On Sep 03 2015, Vincent Bernat wrote:
> ❦ 3 septembre 2015 17:22 GMT, Bas Wijnen :
>
>> Because you know you have the right and the ability to be a part of the free
>> software community that created the software. That is why you are running
>> Debian and don't have contrib or non-free in your
❦ 3 septembre 2015 17:22 GMT, Bas Wijnen :
> Because you know you have the right and the ability to be a part of the free
> software community that created the software. That is why you are running
> Debian and don't have contrib or non-free in your sources.list.
>
> From your mails it is clea
* Neil Williams [150902 14:15]:
> On Wed, 2 Sep 2015 13:14:31 -0400 Marvin Renich wrote:
> > It is presumed that upstream already has what it considers "source";
> > in the case of this thread, that is minified JS.
>
> Actually, not. Source, for upstream of JQuery at least, is a set of
> directi
* Bas Wijnen [150902 17:36]:
> > On Wed, 2 Sep 2015 13:33:57 -0400 Marvin Renich wrote:
> > > No, "A preferred form" is what upstream uses. The DFSG does not use
> > > the term "THE preferred form", and I believe that was wise.
>
> The DFSG doesn't define source at all. There seems to be conse
* Neil Williams [150902 14:33]:
> Minified isn't source for modification... [large snip]
I don't believe I have disagreed with anything you said in the snipped
text. I certainly did not mean to. I said that minified JS can only go
in main if both the source and the tools to build it are also in
Paul Wise writes:
> On Wed, Sep 2, 2015 at 11:47 PM, Russ Allbery wrote:
>> If *no one* has access to anything better than a binary file, then
>> possession of that binary file puts you on an equal footing with
>> everyone else in the world, which I think is all that we can reasonably
>> ask.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Sep 03, 2015 at 08:47:11AM +0200, Vincent Bernat wrote:
> Without minification, we'll just ship packages that people won't
> use. Why would I run a crippled installation of Wordpress that will
> drive of part of my users to another competitor?
Vincent Bernat dijo [Wed, Sep 02, 2015 at 09:47:23AM +0200]:
> If you talk about uglifyjs or the like, it is already packaged and
> doesn't solve all the problems we have (see my message to Odyx,
> ).
>
> If you talk about Grunt, Grunt comes with a lot of plugins (and does
> almost nothing without
Lars Wirzenius dijo [Wed, Sep 02, 2015 at 09:32:12AM +0300]:
> However, I want to raise the point that upstreams do not always make
> sensible decisions, and if they don't, it's good to raise that with
> them. For example, there was recently an ITP bug for
> node-number-is-nan. Upstream source code
❦ 3 septembre 2015 21:03 +1000, Dmitry Smirnov :
>> Without minification, we'll just ship packages that people won't
>> use. Why would I run a crippled installation of Wordpress that will
>> drive of part of my users to another competitor?
>
> Sorry but that feels like exaggeration. Maybe it is
On Thursday 03 September 2015 08:47:11 Vincent Bernat wrote:
> Please, publish your own study.
I do not need to publish any studies to be sceptical.
> This number is well known and supported
> by an entity which is likely to have a population large enough to be
> significant.
You've mentioned n
On Wed, Sep 2, 2015 at 11:47 PM, Russ Allbery wrote:
> I think reading "preferred form of modification" from the perspective of
> upstream is a useful standard because it handles some edge cases like
> that, and because it feels ethically consistent with free software
> principles. The goal is th
❦ 3 septembre 2015 12:23 +1000, Dmitry Smirnov :
>> Amazon did a study that showed every ~100ms of page load
>> delay lost them 1% in sales.
>
> It could be that small percentage of Amazon users are impulsive trigger-happy
> buyers. :)
> However that conclusion is probably wrong due to number
On Tuesday 01 September 2015 17:46:30 Josh Triplett wrote:
> Nikolaus Rath wrote:
> > I don't think 28 kB vs 73 kB is a difference that people will notice
> > over the network in *most* situations. Even at just 100 kB/s that's
> > 0.28 vs 0.73 seconds, and only when the page is first loaded.
>
> T
The below is very much a tangent from the minified Javascript case, and
not applicable to that case.
Bas Wijnen writes:
> Here's a rule to limit the selection a bit: a file is certainly not
> source if it was originally generated from a different file, and has not
> been modified.
This makes fi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Sep 02, 2015 at 07:33:10PM +0100, Neil Williams wrote:
> On Wed, 2 Sep 2015 13:33:57 -0400
> Marvin Renich wrote:
>
> > * Ben Hutchings [150902 10:12]:
> > > My preferred form is a git repository of code written in C, Python,
> > > or some o
At Tue, 1 Sep 2015 18:56:45 +0200,
Raphael Hertzog wrote:
> For me, the javascripts bits in wordpress/publican are not part of the
> product, they are external libraries whose preferred form of use is
> by embedding a copy of the library... that sucks but it's the way it is.
>
> I do not see signi
On Wed, 2 Sep 2015 13:33:57 -0400
Marvin Renich wrote:
> * Ben Hutchings [150902 10:12]:
> > My preferred form is a git repository of code written in C, Python,
> > or some other language I know. That doesn't mean that a tarball of
> > Haskell code is non-free!
> No, "A preferred form" is what
On Wed, 2 Sep 2015 13:14:31 -0400
Marvin Renich wrote:
> * Neil Williams [150902 10:22]:
> > Upstream is another recipient of code distributed under copyleft.
> > Having changes in a format which upstream can use is absolutely a
> > sensible and sane criterion for what is regarded as the form of
* Ben Hutchings [150902 10:12]:
> My preferred form is a git repository of code written in C, Python, or
> some other language I know. That doesn't mean that a tarball of
> Haskell code is non-free!
I can't tell whether you are agreeing or disagreeing with me!
> The preferred form for modificat
* Neil Williams [150902 10:22]:
> Upstream is another recipient of code distributed under copyleft.
> Having changes in a format which upstream can use is absolutely a
> sensible and sane criterion for what is regarded as the form of the
> code for modification. To do otherwise is to make the main
On Wed, 2 Sep 2015 08:59:11 -0400
Marvin Renich wrote:
> * Thorsten Glaser [150902 07:50]:
> > There is (I just had an epiphany) another possible criterium to
> > apply for to determine what the preferred form of modification is:
>^ for
> [Okay, so I
On Wed, 2015-09-02 at 08:59 -0400, Marvin Renich wrote:
> * Thorsten Glaser [150902 07:50]:
> > There is (I just had an epiphany) another possible criterium to apply
> > for to determine what the preferred form of modification is:
>^ for
> [Okay, so I'
* Thorsten Glaser [150902 07:50]:
> There is (I just had an epiphany) another possible criterium to apply
> for to determine what the preferred form of modification is:
^ for
[Okay, so I'm being pedantic, but this is a common mistake.]
> Does upstream
Vincent Bernat debian.org> writes:
> 2. Upstream may generate the final pre-minification file with complex
> tools, like an AMD loader or an ES6/ES5 transpiler, along with the
> use of non-packaged build tools like Grunt.
> problem. For the second one, a solution would be to consider th
Vincent Bernat, le Wed 02 Sep 2015 11:20:32 +0200, a écrit :
> ❦ 2 septembre 2015 10:18 +0200, Samuel Thibault :
> >> Or maybe you propose to just ship the whole "node_modules" directory
> >> (which has all the dependencies) with jQuery sources?
> >
> > That'd be a lot better than nothing.
>
>
❦ 2 septembre 2015 10:18 +0200, Samuel Thibault :
>> Or maybe you propose to just ship the whole "node_modules" directory
>> (which has all the dependencies) with jQuery sources?
>
> That'd be a lot better than nothing.
OK. Also, node_modules for jQuery is 76M (for 3.x, 70M for 2.x). I still
f
Vincent Bernat, le Wed 02 Sep 2015 10:10:55 +0200, a écrit :
> ❦ 2 septembre 2015 09:54 +0200, Samuel Thibault :
>
> >> If you talk about Grunt,
> >
> > That's what I'm talking about.
> >
> >> Grunt comes with a lot of plugins (and does almost nothing without
> >> those) and each upstream will
❦ 2 septembre 2015 09:54 +0200, Samuel Thibault :
>> If you talk about Grunt,
>
> That's what I'm talking about.
>
>> Grunt comes with a lot of plugins (and does almost nothing without
>> those) and each upstream will require different plugins with different
>> versions (Grunt plugin versions a
Vincent Bernat, le Wed 02 Sep 2015 09:47:23 +0200, a écrit :
> If you talk about Grunt,
That's what I'm talking about.
> Grunt comes with a lot of plugins (and does almost nothing without
> those) and each upstream will require different plugins with different
> versions (Grunt plugin versions ar
❦ 2 septembre 2015 09:28 +0200, Samuel Thibault :
>> Healthy language communities have their own metadata systems and
>> standardized build systems that allow Debian packaging to be nearly
>> automated, *provided* that we use the same unit of distribution as
>> upstream.
>
> I understand that u
❦ 2 septembre 2015 09:32 +0300, Lars Wirzenius :
> However, I want to raise the point that upstreams do not always make
> sensible decisions, and if they don't, it's good to raise that with
> them. For example, there was recently an ITP bug for
> node-number-is-nan. Upstream source code is at
>
Russ Allbery, le Tue 01 Sep 2015 18:05:09 -0700, a écrit :
> Healthy language communities have their own metadata systems and
> standardized build systems that allow Debian packaging to be nearly
> automated, *provided* that we use the same unit of distribution as
> upstream.
I understand that usi
On Tue, Sep 01, 2015 at 06:05:09PM -0700, Russ Allbery wrote:
> Healthy language communities have their own metadata systems and
> standardized build systems that allow Debian packaging to be nearly
> automated, *provided* that we use the same unit of distribution as
> upstream. If we want to make
On Sep 01 2015, Josh Triplett wrote:
> Nikolaus Rath wrote:
>> I don't think 28 kB vs 73 kB is a difference that people will notice
>> over the network in *most* situations. Even at just 100 kB/s that's
>> 0.28 vs 0.73 seconds, and only when the page is first loaded.
>
> That's absolutely a critic
Josh Triplett writes:
> That said, we absolutely do need to fix this in Debian: it's not OK to
> build packages in main using tools not shipped in Debian, or to ship
> precompiled files. As a start, it would help if when JavaScript folks
> try to package the packages needed as part of their tool
Nikolaus Rath wrote:
> I don't think 28 kB vs 73 kB is a difference that people will notice
> over the network in *most* situations. Even at just 100 kB/s that's
> 0.28 vs 0.73 seconds, and only when the page is first loaded.
That's absolutely a critical difference, even on a faster connection.
Mu
On Tue, 01 Sep 2015, Vincent Bernat wrote:
> 1. Upstream may not ship this source but only the minified version
> because the JS code is just a dependency and some upstream are used
> to just ship the minified source. We can recover the original code
> from another source but there is a risk th
❦ 1 septembre 2015 21:10 +0200, Didier 'OdyX' Raboud :
> I think we should take a strong move there and exercise (as well as
> justify to the outer world) our free software right to recompile the
> software that we ship to our users: this could mean to only merge & gzip
> JS files if minifyi
Le mardi, 1 septembre 2015, 17.50:26 Vincent Bernat a écrit :
> ❦ 1 septembre 2015 08:21 -0700, Nikolaus Rath :
> >>> Couldn't we just use the non-minified versions in most situations?
> >>> A
> >>
> >> Not for anything which has actual users over the network.
> >
> > Why? (Don't forget about
❦ 1 septembre 2015 13:45 -0500, Gunnar Wolf :
>> uglifyjs is a KISS tool to minify. Unfortunately, many projects do not
>> require only minification. They require transpiling (convert from ES6 to
>> ES5 or from CoffeeScript/Typescript/... to vanilla JS) and dependency
>> handling (through loade
Vincent Bernat dijo [Fri, Aug 28, 2015 at 10:48:28AM +0200]:
> >> What will happen is that maintainers will fallback to the second less
> >> horrible solution and cripple the package (by using an older version of
> >> the JS lib for example) to allow it to stay in main.
> >
> > Why would they want
Vincent Bernat dijo [Fri, Aug 28, 2015 at 11:54:43AM +0200]:
> > I still find it hard to believe that *so* much code is required to
> > minify JS. The excuse that JS is "moving fast" is nonsense. The reality
> > would appear to be that nobody actually *cares* about the mess, they
> > just use it.
>
On Tue, Sep 01, 2015 at 04:42:15PM +0200, Helmut Grohne wrote:
> On Tue, Sep 01, 2015 at 08:15:19AM +0200, Guido Günther wrote:
> > Couldn't we just use the non-minified versions in most situations? A
> > heavily loaded wordpress site might not be good example but e.g. doxygen
> > documentation pro
On Sep 01, Nikolaus Rath wrote:
> I don't think 28 kB vs 73 kB is a difference that people will notice
> over the network in *most* situations. Even at just 100 kB/s that's
> 0.28 vs 0.73 seconds, and only when the page is first loaded.
Yes, this is a non trivial difference when loading a web pag
* Raphael Hertzog [150901 12:57]:
> Because we have alternative "compilers" (aka minifier) available to
> recreate another minified file thas should work just as well.
No. Debian does not allow you to ship a compiled C program that was
compiled elsewhere; the maintainer or a buildd is responsibl
Hi,
On Mon, 31 Aug 2015, Bas Wijnen wrote:
> > I certainly do not want to move wordpress or publican to contrib because
> > some of the javascript libraries that it uses can't be rebuilt from main.
>
> In that case, my question applies to you as well: why do you care for it to be
> in main, if yo
On Sep 01 2015, Vincent Bernat wrote:
> ❦ 1 septembre 2015 08:21 -0700, Nikolaus Rath :
>
Couldn't we just use the non-minified versions in most situations? A
>>>
>>> Not for anything which has actual users over the network.
>>
>> Why? (Don't forget about gzip encoding).
>
> See:
> https:
> On Mon, Aug 31, 2015 at 11:21:55AM -0400, Marvin Renich wrote:
> > * Bas Wijnen [150830 07:53]:
> > > On Sun, Aug 30, 2015 at 10:14:13AM +0200, Vincent Bernat wrote:
> > > > Is that the preferred form of modification? It depends, but from the
> > > > jQuery author point of view, it isn't:
> > >
❦ 1 septembre 2015 08:21 -0700, Nikolaus Rath :
>>> Couldn't we just use the non-minified versions in most situations? A
>>
>> Not for anything which has actual users over the network.
>
> Why? (Don't forget about gzip encoding).
See:
https://mathiasbynens.be/demo/jquery-size
--
Don't sacrif
On Sep 01 2015, Helmut Grohne wrote:
> On Tue, Sep 01, 2015 at 08:15:19AM +0200, Guido Günther wrote:
>> Couldn't we just use the non-minified versions in most situations? A
>> heavily loaded wordpress site might not be good example but e.g. doxygen
>> documentation probably doesn't suffer much fr
On Sep 01 2015, m...@linux.it (Marco d'Itri) wrote:
> On Sep 01, Guido Günther wrote:
>
>> Couldn't we just use the non-minified versions in most situations? A
>
> Not for anything which has actual users over the network.
Why? (Don't forget about gzip encoding).
Best,
-Nikolaus
--
GPG encrypt
On Tue, Sep 01, 2015 at 08:15:19AM +0200, Guido Günther wrote:
> Couldn't we just use the non-minified versions in most situations? A
> heavily loaded wordpress site might not be good example but e.g. doxygen
> documentation probably doesn't suffer much from non minified JS.
I fail to see what pro
❦ 31 août 2015 11:21 -0400, Marvin Renich :
>> > However, this is a readable source code that will accomodate any
>> > modification that a end user will deem necessary.
>
> I intentionally did not look at the file referred to above, and have no
> idea whether I would consider it to be a "preferr
On Sep 01, Guido Günther wrote:
> Couldn't we just use the non-minified versions in most situations? A
Not for anything which has actual users over the network.
> heavily loaded wordpress site might not be good example but e.g. doxygen
> documentation probably doesn't suffer much from non minifi
Hi,
On Mon, Aug 31, 2015 at 09:50:05AM +0200, Raphael Hertzog wrote:
> On Mon, 31 Aug 2015, Simon Josefsson wrote:
> > How would someone rebuild the minified javascript files from the
> > missing-sources files?
>
> They would not?
>
> The modified non-minified files are perfectly usable even if t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Aug 31, 2015 at 08:49:53AM +0200, Raphael Hertzog wrote:
> On Sun, 30 Aug 2015, Bas Wijnen wrote:
> > Why do you care that software is in main, if you evidently do not care about
> > any of the rules we have for it?
>
> I don't think that impl
First, let me make it clear that I am firmly in the camp that believes
minified JS cannot be distributed in main unless the tools to recreate
it are also in main. It bothers me that there appears to be a
not-insignificant number of people with upload rights who do not believe
this.
This message i
On Thu, Aug 27, 2015 at 04:14:53PM -0700, Russ Allbery wrote:
> Last time I checked, Doxygen includes minified Javascript in all of its
> generated output. Would we have to move every piece of Doxygen-generated
> documentation into a separate package so that we could put it in contrib,
> or strip
On Tue, Aug 25, 2015 at 07:08:06PM +0100, Ian Jackson wrote:
> Not regenerating configure doesn't pose any significant risk that
> we're shipping a configure script that we can't regenerate (or, at
> least, regenerate an equivalent or better one). I've not heard of
> people (for example) using pri
Raphael Hertzog writes:
> On Mon, 31 Aug 2015, Simon Josefsson wrote:
>> How would someone rebuild the minified javascript files from the
>> missing-sources files?
>
> They would not?
>
> The modified non-minified files are perfectly usable even if they are a
> bit larger than the minified ones.
On Mon, 31 Aug 2015, Simon Josefsson wrote:
> How would someone rebuild the minified javascript files from the
> missing-sources files?
They would not?
The modified non-minified files are perfectly usable even if they are a
bit larger than the minified ones.
> The included JavaScript file is m
On Mon, 31 Aug 2015 at 16:50 Raphael Hertzog wrote:
> In both cases, I worked around the problem by shipping the upstream
> sources in debian/missing-sources/ but I did not support doing changes
> there and did not rebuild the embedded libraries.
>
I haven't been paying lots of attention to this
Raphael Hertzog writes:
> In both cases, I worked around the problem by shipping the upstream
> sources in debian/missing-sources/ but I did not support doing changes
> there and did not rebuild the embedded libraries.
>
> In some cases, I do replace the embedded library with a symlink to the
> p
On Sun, 30 Aug 2015, Bas Wijnen wrote:
> Why do you care that software is in main, if you evidently do not care about
> any of the rules we have for it?
I don't think that implying that Vincent doesn't not care about Free
Software is very constructive.
Can we please stop this now?
If all the ene
Bastien ROUCARIÈS, le Sun 30 Aug 2015 23:15:39 +0200, a écrit :
> What could be done in order to improve the whole system performance in order
> to package really small package ?
Is it not possible to group them like X.org does?
Samuel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Aug 30, 2015 at 02:12:43PM +0200, Vincent Bernat wrote:
> This is becoming quite a stretch. At this rate, we will fail to match
> SC#2 because we ship previous versions of software and upstream is
> unlikely to accept a patch against a non-curr
On 08/28/2015 01:14 AM, Russ Allbery wrote:
> Bas Wijnen writes:
>
> Last time I checked, Doxygen includes minified Javascript in all of its
> generated output. Would we have to move every piece of Doxygen-generated
> documentation into a separate package so that we could put it in contrib,
> or
❦ 30 août 2015 11:52 GMT, Bas Wijnen :
>> However, this is a readable source code that will accomodate any
>> modification that a end user will deem necessary.
>
> That is not the only reason that we want the user to have source.
> They are not some detached "customer". When we make changes to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Aug 30, 2015 at 10:14:13AM +0200, Vincent Bernat wrote:
> The build script determines the outcome of what will effectively run on
> our users' machine. I fail to see how this is not an important
> issue.
You are correct, this is important.
>
On Sun, Aug 30, 2015 at 10:14 AM, Vincent Bernat wrote:
> The build script determines the outcome of what will effectively run on
> our users' machine. I fail to see how this is not an important
> issue. But until the effort to get ppc64el, not regenerating the
> configure script was just a fine o
❦ 29 août 2015 19:12 -0700, Steve Langasek :
> Yet you try to compare this with autoconf. Even if we tolerated configure
> scripts today in the archive that we can't rebuild using the software in
> Debian (which by and large we do *not* tolerate - because we've learned our
> lesson), there's a
]] Vincent Bernat
> 1. package the whole Grunt ecosystem (and maintain it),
> 2. cripple their package by substituting some components by a non-working
> version in Debian or,
> 3. ship a pre-compiled/minified version of the library with sources.
>
> I know this sucks, but if I have to pi
Steve Langasek writes:
> […] Nevertheless, for packages that *are* in Debian, we should expect
> that the source package contains the *full* corresponding source code
> for any minified javascript files. If we can't rebuild it then we
> don't actually have the source, and that's a practical as we
On Fri, Aug 28, 2015 at 07:42:42AM +0200, Vincent Bernat wrote:
> >> The main effect of this religious and overzealous application of our
> >> guidelines is that people just stay away of JS stuff in Debian and
> >> packaging any web-related app is becoming more complex as anyone needs
> >> to deal
On Fri, Aug 28, 2015 at 10:06:17AM +0200, Vincent Bernat wrote:
> ❦ 28 août 2015 08:22 +0100, Philip Hands :
>
> >>> Or alternatively, by packaging the minifier that is being used with the
> >>> package
> >>> that needs it. Yes, that's a horrible idea with lots of code
> >>> duplication, but
❦ 28 août 2015 17:37 +0100, Steve McIntyre :
>>The problem is that this *is* usable for nearly all the people who
>>currently use it, who just run one command to install it and have all
>>those dependencies pulled from a remote repo for them. Because the
>>dependency installation process is so
On Fri, Aug 28, 2015 at 4:12 PM, Jean-Michel Vourgère
wrote:
Vincent Bernat wrote:
> > (...)
> > It has already been said numerous time in the past, for some Javascript
> > code, we don't really have the tools in Debian to easily go from the
> > source to the minified version. It's possible, but
On Fri, Aug 28, 2015 at 4:12 PM, Jean-Michel Vourgère
wrote:
Vincent Bernat wrote:
> > (...)
> > It has already been said numerous time in the past, for some Javascript
> > code, we don't really have the tools in Debian to easily go from the
> > source to the minified version. It's possible, but
Steve McIntyre writes:
> Depressingly, it seems a lot of the same web typists don't have any
> problems with doing the equivalent of "curl http://some.site/install.sh
> | sudo bash" . That doesn't mean we have to do the same in Debian. If
> there's no sensible way to do controlled web development
Russ Allbery wrote:
>Neil Williams writes:
>
>> Usable software needs usable tools.
>
>The problem is that this *is* usable for nearly all the people who
>currently use it, who just run one command to install it and have all
>those dependencies pulled from a remote repo for them. Because the
>dep
Neil Williams writes:
> I still find it hard to believe that *so* much code is required to
> minify JS. The excuse that JS is "moving fast" is nonsense. The reality
> would appear to be that nobody actually *cares* about the mess, they
> just use it.
This is almost certainly correct.
> Usable s
Vincent Bernat wrote:
> (...)
> It has already been said numerous time in the past, for some Javascript
> code, we don't really have the tools in Debian to easily go from the
> source to the minified version. It's possible, but without the
> appropriate tools, it's painful.
I've been using yui-com
Dmitry Smirnov writes:
> On Monday 24 August 2015 13:54:21 Simon Josefsson wrote:
>> I believe the blog post below has relevance to Debian's stance on
>> including minified JavaScript in packages:
>>
>> https://zyan.scripts.mit.edu/blog/backdooring-js/
>
> Thank you for a nice argument against m
❦ 28 août 2015 12:03 +0200, Samuel Thibault :
> I wonder why mere gzip compression is not used. Don't all browsers
> support Accept-Compress: gzip?
Minification saves some additional bytes. About 10% (when gzipped).
--
If you tell the truth you don't have to remember anything.
Neil Williams, le Fri 28 Aug 2015 10:32:52 +0100, a écrit :
> On Fri, 28 Aug 2015 10:45:16 +0200
> Samuel Thibault wrote:
>
> > Vincent Bernat, le Fri 28 Aug 2015 10:06:17 +0200, a écrit :
> > > Maybe it can be trimmed a bit more, but that's still 239 unique
> > > dependencies.
> >
> > Note that
❦ 28 août 2015 10:32 +0100, Neil Williams :
> I still find it hard to believe that *so* much code is required to
> minify JS. The excuse that JS is "moving fast" is nonsense. The reality
> would appear to be that nobody actually *cares* about the mess, they
> just use it.
It's a feature. The JS
On Fri, 28 Aug 2015 10:45:16 +0200
Samuel Thibault wrote:
> Vincent Bernat, le Fri 28 Aug 2015 10:06:17 +0200, a écrit :
> > Maybe it can be trimmed a bit more, but that's still 239 unique
> > dependencies.
>
> Note that you don't have to make that 239 debian packages, you could
> as well just s
On Monday 24 August 2015 13:54:21 Simon Josefsson wrote:
> I believe the blog post below has relevance to Debian's stance on
> including minified JavaScript in packages:
>
> https://zyan.scripts.mit.edu/blog/backdooring-js/
Thank you for a nice argument against minification.
During packaging I a
Vincent Bernat, le Fri 28 Aug 2015 10:48:28 +0200, a écrit :
> ❦ 28 août 2015 10:29 +0200, Samuel Thibault :
>
> >> What will happen is that maintainers will fallback to the second less
> >> horrible solution and cripple the package (by using an older version of
> >> the JS lib for example) to a
❦ 28 août 2015 10:29 +0200, Samuel Thibault :
>> What will happen is that maintainers will fallback to the second less
>> horrible solution and cripple the package (by using an older version of
>> the JS lib for example) to allow it to stay in main.
>
> Why would they want to stay in main?
[...
Vincent Bernat, le Fri 28 Aug 2015 10:06:17 +0200, a écrit :
> Maybe it can be trimmed a bit more, but that's still 239 unique
> dependencies.
Note that you don't have to make that 239 debian packages, you could as
well just ship them all in one package, as long as the whole code passes
NEW, i.e.
Vincent Bernat, le Fri 28 Aug 2015 07:42:42 +0200, a écrit :
> > Yes, that is a danger. I think putting those things in contrib should be a
> > good solution if rebuilding is such a big problem. Because if it is, the
> > code
> > really really doesn't belong in main.
>
> What will happen is tha
1 - 100 of 147 matches
Mail list logo