On 19-Jul-2016, Don Armstrong wrote:
> And now that enough people have read this thread, we probably could
> have re-implemented grunt by now and solved the libjs-handlebars
> problem.
Thanks. I have started a discussion for this on
http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/201
On Tue, 19 Jul 2016, Helmut Grohne wrote:
> Now I'm confused as to how we handled Perl (#762638). It has a
> Configure script that claims[2] to be generated by a
> configure-generator called metaconfig. A significant part of
> metaconfig's job (like grunt's) is concatenating snippets, but there
> a
On Wed, Jul 13, 2016 at 05:37:11PM +0100, Ansgar Burchardt wrote:
> On Wed, 2016-07-13 at 10:43 -0500, Don Armstrong wrote:
> > Or are you asking us to potentially overrule the ftpmasters inclusion
> > of libjs-handlebars? Or potentially overrule the release managers
> > determination of whether th
Uoti Urpala writes:
> On Mon, 18 Jul 2016 11:15:59 +0200 Philip Hands wrote:
>> Uoti Urpala writes:
>>
>> > In what sense couldn't everyone modify the concatenated form?
>>
>> Perhaps if I frame my question from:
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#90
>>
>> in a
On Mon, 18 Jul 2016 11:15:59 +0200 Philip Hands wrote:
> Uoti Urpala writes:
>
> > In what sense couldn't everyone modify the concatenated form?
>
> Perhaps if I frame my question from:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#90
>
> in another way, I'll get an answer.
Uoti Urpala writes:
> In what sense couldn't everyone modify the concatenated form?
Perhaps if I frame my question from:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#90
in another way, I'll get an answer.
Given the existence of the upstream source, would you really consider
edit
On Mon, 18 Jul 2016 09:02:08 +1000 Ben Finney wrote:
> On 17-Jul-2016, Uoti Urpala wrote:
> > If you want to argue "upstream convenience" as a reason for the
> > second,
>
> Maybe if that were the only justification offered. That's not the case
> though.
>
>
> Reading the discussion on debian-
On 17-Jul-2016, Uoti Urpala wrote:
> In essence, my central point is that you cannot consistently believe
> BOTH of these:
> * packaging not being up to date with latest upstream is just a
> wishlist bug
> * packaging concatenating source files is such a horrible bug that the
> package should
On Sat, 16 Jul 2016 00:02:55 +0100 Neil Williams
wrote:
> On Fri, 15 Jul 2016 23:45:01 +0530
> Pirate Praveen wrote:
>> If this argument is accepted, we will not be able to package a fork
>> because the original upstream won't accept a patch against the fork.
>> Similarly we'd be able to package
On Sat, 16 Jul 2016 06:49:56 -0400
Sam Hartman wrote:
> > "Neil" == Neil Williams writes:
> >> > * The point of having the source code (with an appropriate
> >> licence > etc.) is so that all our contributors, downstreams,
> >> and users are > able to modify the code and to s
Sam Hartman writes ("Re: Bug#830978: Browserified javascript and DFSG 2"):
> [stuff]
There is much that you've said that I don't necessarily disagree with,
but:
> Part of having good governance is to have those discussions on devel.
The problem isn't having the d
> "Neil" == Neil Williams writes:
>> > * The point of having the source code (with an appropriate
>> licence > etc.) is so that all our contributors, downstreams, and
>> users are > able to modify the code and to share their
>> modifications with each > other, with Debian, and
> "Ian" == Ian Jackson writes:
Ian> I would like to comment briefly on the general idea about the
Ian> TC offering advice and making statements of opinion.
Ian> If someone in authority in the project, such as a maintainer of
Ian> the ftpmasters or the release team, is doing
On Fri, 15 Jul 2016 23:45:01 +0530
Pirate Praveen wrote:
> On 2016, ജൂലൈ 15 10:46:51 PM IST, Ian Jackson
> wrote:
> >Sam Hartman writes ("Bug#830978: Browserified javascript and DFSG
> >2"):
> >> Speaking as an individual TC member, here's my p
Pirate Praveen writes:
...
>> * For Debian, therefore, the source code for a file or program is the
>> form which can be conveniently modified and shared; specifically,
>> the form in which upstream will accept patches.
>
> This was never the intention of dfsg, it was always about freedoms of
On 2016, ജൂലൈ 15 10:46:51 PM IST, Ian Jackson
wrote:
>Sam Hartman writes ("Bug#830978: Browserified javascript and DFSG 2"):
>> Speaking as an individual TC member, here's my personal reading of
>the
>> TC discussion.
>>
>> It's not clear that
Ian Jackson writes ("Re: Bug#830978: Browserified javascript and DFSG 2"):
> I would like to comment briefly
I'm sorry that I so evidently failed !
Ian.
Sam Hartman writes ("Bug#830978: Browserified javascript and DFSG 2"):
> Speaking as an individual TC member, here's my personal reading of the
> TC discussion.
>
> It's not clear that the TC is the right body for this discussion. We
> certainly could offer
Hi.
Speaking as an individual TC member, here's my personal reading of the
TC discussion.
It's not clear that the TC is the right body for this discussion. We
certainly could offer advice, but it's not clear that the ftpmasters or
release team--the parties most likely to need such advice-- would
Hi,
On 13/07/16 17:43, Don Armstrong wrote:
> On Wed, 13 Jul 2016, Sam Hartman wrote:
>> However, here we're asked to give advice on whether something is
>> source code. Is the question of what is the source code for a given
>> package technical, and thus within our remit?
>
> I think that's a na
On Wed, 13 Jul 2016, Pirate Praveen wrote:
> On Wed, 13 Jul 2016 10:43:34 -0500 Don Armstrong wrote:
> > Are you asking the CTTE to make a non-binding formal announcement
> > using 6.1.5 as to whether, in the opinion of the CTTE, browerified
> > source is source under the DFSG?
>
> Yes.
[...]
>
On Wed, 13 Jul 2016 10:43:34 -0500 Don Armstrong wrote:
> On Wed, 13 Jul 2016, Pirate Praveen wrote:
> > Browserified files are readable and editable javascript files. I
> > believe this meets DFSG 2 requirements. Someone who is familiar with
> > javascript can easily modify and run modified versi
"Paul R. Tagliamonte" writes:
> Traditionally, ftpteam has had to take this role, since it is the body
> that decides if an upload is fit for main.
Yup.
> I haven't talked in-depth with the rest of the ftpteam, but I assume
> they agree. CC'ing in case there's an objection.
>
> Not completely s
On Wed, 2016-07-13 at 10:43 -0500, Don Armstrong wrote:
> Or are you asking us to potentially overrule the ftpmasters inclusion
> of libjs-handlebars? Or potentially overrule the release managers
> determination of whether this particular bug is RC or not?
[...]
> I'd certainly be more comfortable
On Wed, 13 Jul 2016, Pirate Praveen wrote:
> Browserified files are readable and editable javascript files. I
> believe this meets DFSG 2 requirements. Someone who is familiar with
> javascript can easily modify and run modified versions.
[...]
> I don't think preferred format of upstream to acce
I would love nothing more than to do other things :)
Have at it!
Paul
On Wed, Jul 13, 2016 at 11:27 AM, Sam Hartman wrote:
>> "Paul" == Paul R Tagliamonte writes:
>
> Paul> Traditionally, ftpteam has had to take this role, since it is
> Paul> the body that decides if an upload is
> "Paul" == Paul R Tagliamonte writes:
Paul> Traditionally, ftpteam has had to take this role, since it is
Paul> the body that decides if an upload is fit for main.
Paul> I am one of those folks that treat minified JS as binary,
Paul> since things like removing comments and r
On 2016-07-13 16:26, Paul R. Tagliamonte wrote:
Traditionally, ftpteam has had to take this role, since it is the body
that decides if an upload is fit for main.
I am one of those folks that treat minified JS as binary, since things
like removing comments and renaming variables to `a`, `b` `c` i
Traditionally, ftpteam has had to take this role, since it is the body
that decides if an upload is fit for main.
I am one of those folks that treat minified JS as binary, since things
like removing comments and renaming variables to `a`, `b` `c` is done.
Dead code can also be trimmed (closure com
So, my first question is whether this is a matter that it's reasonable
for the TC to rule on.
I definitely think we're not an appropriate body to rule on a question
like whether a particular license is DFSG free.
However, here we're asked to give advice on whether something is source
code. Is
package: tech-ctte
Background: Javascript on the server (with nodejs) uses modules to split
libraries, but using the same on browser requires combining these
modules to single file.
DFSG Section 2 [1] gives requirement for source code
"Source Code
The program must include source code, and must
31 matches
Mail list logo
