Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

2016-10-06 Thread Vincent Bernat 
 ❦  6 octobre 2016 20:47 CEST, Adrian Bunk  :

>> > If you fancy explaining what you think browserified means w.r.t. the
>> > Jison stuff, go ahead of course.  That might at least help to focus the
>> > discussion a bit.  Just don't feel obliged to because I said so.
>> 
>> The libjs-handlebars issue has little to share with browserified
>> JS. Browserified JS is usually just concatenated JS. Here, there is an
>> equivalent of flex/bison involved. That's quite unusual and is more a
>> build process. If the TC rules over this issue, it should drop the
>> "browserified" part. Otherwise, a negative answer would also apply to
>> more basic packages.
>>...
>
> Why is Grunt such a blocker here?

I didn't mention Grunt because in this case, it is not really a
problem. Whatever Grunt got packaged or not doesn't change the situation
for libjs-handlebars. What this package needs is jison. Once jison is
here, this package becomes buildable from tools in main and can enter in
main (since there is a tolerance for pre-generated files).

> If I understand it correctly, Grunt is a powerful build system that can 
> do a gazillion different things and has many dependencies.

Yes.

> For the basic browserified JS case, could a much simpler tool like
> node-browserify-lite produce the same output?

I can't say.
-- 
AWAKE! FEAR! FIRE! FOES! AWAKE!
FEAR! FIRE! FOES!
AWAKE! AWAKE!
-- J. R. R. Tolkien


signature.asc
Description: PGP signature

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

2016-10-06 Thread Adrian Bunk 
On Thu, Oct 06, 2016 at 09:48:02AM +0200, Vincent Bernat wrote:
>  ❦  5 octobre 2016 22:49 CEST, Philip Hands  :
> 
> > If you fancy explaining what you think browserified means w.r.t. the
> > Jison stuff, go ahead of course.  That might at least help to focus the
> > discussion a bit.  Just don't feel obliged to because I said so.
> 
> The libjs-handlebars issue has little to share with browserified
> JS. Browserified JS is usually just concatenated JS. Here, there is an
> equivalent of flex/bison involved. That's quite unusual and is more a
> build process. If the TC rules over this issue, it should drop the
> "browserified" part. Otherwise, a negative answer would also apply to
> more basic packages.
>...

Why is Grunt such a blocker here?

If I understand it correctly, Grunt is a powerful build system that can 
do a gazillion different things and has many dependencies.

For the basic browserified JS case, could a much simpler tool like
node-browserify-lite produce the same output?

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#839570: Browserified javascript and DFSG 2 (reopening)

2016-10-06 Thread Adrian Bunk 
On Thu, Oct 06, 2016 at 07:48:28PM +0200, Tollef Fog Heen wrote:
> ]] Adrian Bunk 
> 
> > On Thu, Oct 06, 2016 at 07:26:06PM +0200, Tollef Fog Heen wrote:
> > >...
> > > I think it'd be preferable for the software to be in contrib (AFAIK
> > > there's nothing here which is non-free?)
> > >...
> > 
> > When a package is not DFSG-free it is non-free.
> > 
> > Only DFSG-free packages that depend on non-free software are allowed 
> > in contrib.
> 
> from policy 2.2.2:
> 
> The contrib archive area contains supplemental packages intended to
> work with the Debian distribution, but which require software
> outside of the distribution to either build or function.
> 
> […]
> 
> Examples of packages which would be included in contrib are:
> 
> free packages which require contrib, non-free packages or packages
> which are not in our archive at all for compilation or execution,
> and
> 
> That sound like a pretty good match for those Javascript packages that
> require grunt to build.


Where you placed the dots policy says:

 Every package in _contrib_ must comply with the DFSG.


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#839570: Browserified javascript and DFSG 2 (reopening)

2016-10-06 Thread Tollef Fog Heen 
]] Adrian Bunk 

> On Thu, Oct 06, 2016 at 07:26:06PM +0200, Tollef Fog Heen wrote:
> >...
> > I think it'd be preferable for the software to be in contrib (AFAIK
> > there's nothing here which is non-free?)
> >...
> 
> When a package is not DFSG-free it is non-free.
> 
> Only DFSG-free packages that depend on non-free software are allowed 
> in contrib.

from policy 2.2.2:

The contrib archive area contains supplemental packages intended to
work with the Debian distribution, but which require software
outside of the distribution to either build or function.

[…]

Examples of packages which would be included in contrib are:

free packages which require contrib, non-free packages or packages
which are not in our archive at all for compilation or execution,
and

That sound like a pretty good match for those Javascript packages that
require grunt to build.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#839570: Browserified javascript and DFSG 2 (reopening)

2016-10-06 Thread Adrian Bunk 
On Thu, Oct 06, 2016 at 07:26:06PM +0200, Tollef Fog Heen wrote:
>...
> I think it'd be preferable for the software to be in contrib (AFAIK
> there's nothing here which is non-free?)
>...

When a package is not DFSG-free it is non-free.

Only DFSG-free packages that depend on non-free software are allowed 
in contrib.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#839570: Browserified javascript and DFSG 2 (reopening)

2016-10-06 Thread Tollef Fog Heen 
]] "Joseph R. Justice" 

> I'll be honest, I assumed from what I've read that a decision had
> already been made by the FTP team against Mr. Praveen. I figured that
> it must have been, or else why would he be raising this bug with the
> TC now?

It's not clear that it has, which is one of the reasons why there are so
many questions asked.

> He's just hoping to avoid the stigma of having to be in contrib
> / non-free for the release of Debian Stretch, by seeking a variance
> that this issue is RC-buggy *for now* so that the various pieces of
> software can be in main, while he works on achieving that possible,
> preferable outcome during the preparation of Stretch+1 which will
> permanently resolve the issue of whether this issue is RB-buggy.)

I think it'd be preferable for the software to be in contrib (AFAIK
there's nothing here which is non-free?) until those pretty important
defects are worked out.  If that is a black mark on the software, it
might just as easily be seen as motivation for something to be fixed as
some sort of stigma.  I also disagree with implying that software in
contrib or non-free carries stigma with it.  It just means that it needs
software outside of Debian to build or function, or has a license that
is not DFSG free.

Trying to use the timing of this as some sort of leverage to get an
exception because it's too hard to get grunt packaged in time fills me
with little sympathy.  The initial bug was filed back in March (817092),
and did not receive a reply until July.  I'd also question that grunt is
so hard to package it takes more than six months to even get it into the
archive at all.

[...]

> I'm not a web developer. I have absolutely no idea how important these
> applications are in actual practice. They may have little use in the
> Real World. They may have tons of use. It may have strong adverse
> effects on users or potential users of Debian if these applications
> are not in Debian main; it may have little or no effect at all. In the
> worst possible case, potential users (be they individuals, or end user
> companies, or people selling software and services making use of
> Debian stable) maybe decide to use another distribution because they
> can't get what they want out of Debian stable main.

On the other hand, if we ship software we can't support and which has
freeness related problems, we might alienate existing or new users.
It's not at all clear that our users are served better by having this
software included.

[...]

> What advice, if any, does the TC have to offer Mr. Praveen as to how
> can he best achieve this goal, and what assistance if any can the TC
> offer him in terms of achieving it?

Frankly, I don't think it's very realistic to see all of this properly
resolved (including having toolchains uploaded, etc) before stretch
freezes, so my answer to your question would be 無, or at best just get
those packages into contrib and start on it immediately.  There's always
a next release.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#839570: Browserified javascript and DFSG 2 (reopening)

2016-10-06 Thread Tollef Fog Heen 
]] Joseph R. Justice

> Is there any information yet on what formal policy (if any) will be
> used by the release managers for allowing bugs to be tagged
> stretch-ignore? *Was* there any formal policy ever set in place for
> the prior (the current stable) release of Debian, e.g. Jessie, or
> prior to that Wheezy? Was it / will it be entirely ad-hoc and at the
> discretion of the release team?

I believe it's at the discretion of the release team, but they would be
in a better position to answer that question properly.  I believe they
have exceptions for classes of bugs as well as individual cases in the
past (but I do not have the references at hand to back that up, so I
could be wrong).

> If the TC as a body does not feel it can, or does not feel it should,
> override the release team in terms of granting stretch-ignore tags for
> certain bugs or classes of bugs (and, I am not saying the TC *should*
> feel it can or should do this, mind you!), still the TC as a body can,
> if a developer so requests and if the TC as a body agrees it should do
> so, offer an advisory opinion concerning particular bugs / bug classes
> to the release team and/or offer a show of support to the affected
> developer, in terms of saying "we believe stretch-ignore tags should
> be applied to the following bugs / classes of bugs, because ..."
> Correct?

Yes, the TC is free to offer advice on any matter.

> Question of bug process, I guess ... For purpose of stretch-ignore
> tags (should they be granted, of course!), would it make sense to
> create a meta-bug, say "Browserified Javascript in Stretch", make all
> the individual package bugs somehow depend on or refer to this meta
> bug, and then apply a stretch-ignore tag to the meta-bug and allow it
> to propagate somehow to all the individual bugs? Or would it be better
> to just apply the stretch-ignore tag to each separate individual
> package bug? I'm thinking as to what will be most effective in making
> sure nothing gets missed, overlooked, forgotten about, either
> pre-Stretch or post-Stretch.

I would leave the desired process to the release team. I believe it'd be
tagging the individual bugs with stretch-ignore, since that's what's
looked at by tooling.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

2016-10-06 Thread Adrian Bunk 
On Thu, Oct 06, 2016 at 02:23:37PM +0200, Didier 'OdyX' Raboud wrote:
>...
> All of the above are imperfections (yes, bugs) in how src:firefox handles its 
> internal sqlite3.c code copy. In an ideal world:
> 
> * src:sqlite3 would provide sqlite3.c in a binary package (sqlite3-static ?)
> * src:firefox would build-depend against that package, and get rebuilt on 
> sqlite3 security uploads
> * firefox would use Built-Using pointing at the correct version of src:sqlite3

The reality in unstable is already even better than your ideal world:

Firefox does already use the shared SQLite library in unstable.
For unstable you could just remove the file from the sources
(and for most other affected packages that would just fix it).

The main problem is that the security team has given up patching 
Firefox years ago, and just ships the latest ESR.

SQLite in stable and oldstable is too old for recent Firefox,
and therefore the amalgamation is used in security updates.

>...
> As a conclusion, my point is we aren't talking about the same thing:
> 
> * On the src:sqlite3 (in src:firefox) side, we have a giant C file, merely a 
> concatenation of source files in Debian, using a script available in Debian, 
> all of which is free software.
> 
> * On the bug that triggered this discussion (#817092 in libjs-handlebars), we 
> have the "browserified" handlebars-v1.3.0.js [2] which a "transformation" of 
> source files not in Debian, using tools not in Debian. 

No non-amalgamation sources for the exact SQLite version used by Firefox 
in jessie are in jessie.

At that point the two cases have strong similarities.[1]

> As was pointed by Phil in [3], although the result is JavaScript code, the 
> transformation is more than "just" concatenation. The original source files 
> are 
> not available in Debian, and the tools aren't either.

As has already been pointed out, there are several issues mixed in the 
"browserified javascript" discussion.

This is a package with several issues, not a generic example.


Does the TC want to be constructive or not?

The TC seeme to have doubts whether or not the constitution allows the 
TC to override decisions by the FTP team on DFSG issues.
According to the constitution, the secretary has the power
of interpreting the constitution.

Has the TC already asked the secretary?
If not, why not?

If it would turn out that there is nothing short of a GR to override a 
decision of the FTP team on DFSG issues, I would expect the TC to state 
explicitely to Pirate Praveen that his only option is a GR.


In any case, and clearly within what the TC could do, it would be 
constructive if the TC could become active itself with gathering
a good understanding of the whole problem.

No matter whether this gets resolved by FTP team, TC or GR, the biggest 
obstacle currently is that noone has a proper understanding of the whole
problem.


> Cheers,
> OdyX

cu
Adrian

[1] there could be significant differences somewhere, but my current
impression is that the SQLite amalgamation might actually be more
problematic than the basic browserified javascript case

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#839570: Browserified javascript and DFSG 2 (reopening)

2016-10-06 Thread Adrian Bunk 
On Thu, Oct 06, 2016 at 11:48:36AM +0200, Philip Hands wrote:
>...
> The security team are going to have to track down every instance of that
> code and fix it.  If the bug is something to do with an interaction
> between the code and the tools used to "browserifiy" the code, that may be
> non-trivial.

For the DFSG it is perfectly fine if a package ships a private 
(potentially modified) copy of the code and only works with this 
specific copy.

And providing 3 years of security support for a huge amount
of JS packages sounds challenging in any case.

I would strongly distinguish between the "what is source code according 
to the DFSG" and "what can the security team support" questions.

The former is a general question that is relevant here,
the latter is a release-specific issue that should be
discussed separately.

>...
> Of course, for that to happen we'd have to start accepting tiny
> javascript packages, which is currently not happening (which also seems
> to be a blocker to grunt being packaged BTW).

https://sources.debian.net/src/node-number-is-nan/1.0.0-1/index.js/

I cannot imagine a package more tiny than this one that was accepted 
last month.

> Cheers, Phil.
>...

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#839570: Browserified javascript and DFSG 2 (reopening)

2016-10-06 Thread Didier 'OdyX' Raboud 
Le jeudi, 6 octobre 2016, 14.38:21 h CEST Adrian Bunk a écrit :
> I am not sure whether this has been filed as a bug in any affected 
> package, but src:sqlite3 is not affected.
> 
> The problem is the amalgamation in other packages, for example:
> https://sources.debian.net/src/firefox/49.0-4/db/sqlite3/src/sqlite3.c

This is of course problematic, especially because this source file is copied 
multiple times accross the archive. It should really be under the Security 
Team's radar through
https://wiki.debian.org/EmbeddedCodeCopies
(it apparently isn't)

That said, there _is_ code to reproduce this amalgamation (roughly, a 
concatenation) in Debian main already, see [0] for example.

mksqlite3.tcl as well as all the source files it will bundle in sqlite3.c are 
DFSG-free source, and are available in Debian. Sure, sqlite3.c as embedded in 
firefox 49.0-4 is in version 3.13.0 and that version of src:sqlite3 isn't in 
any Debian suite anymore (we have snapshot.d.o though [1])

All of the above are imperfections (yes, bugs) in how src:firefox handles its 
internal sqlite3.c code copy. In an ideal world:

* src:sqlite3 would provide sqlite3.c in a binary package (sqlite3-static ?)
* src:firefox would build-depend against that package, and get rebuilt on 
sqlite3 security uploads
* firefox would use Built-Using pointing at the correct version of src:sqlite3

Note that the latter mechanism could be used immediately to get dak to 
guarantee the availability of the correct version of src:sqlite3 in mirror's 
pool.

As a conclusion, my point is we aren't talking about the same thing:

* On the src:sqlite3 (in src:firefox) side, we have a giant C file, merely a 
concatenation of source files in Debian, using a script available in Debian, 
all of which is free software.
* On the bug that triggered this discussion (#817092 in libjs-handlebars), we 
have the "browserified" handlebars-v1.3.0.js [2] which a "transformation" of 
source files not in Debian, using tools not in Debian. 

As was pointed by Phil in [3], although the result is JavaScript code, the 
transformation is more than "just" concatenation. The original source files are 
not available in Debian, and the tools aren't either.

-- 
Cheers,
OdyX

[0] http://sources.debian.net/src/sqlite3/3.14.2-1/tool/mksqlite3c.tcl
[1] http://snapshot.debian.org/package/sqlite3/3.13.0-1/
[2] 
https://sources.debian.net/src/libjs-handlebars/1.3.0-1/handlebars-v1.3.0.js/
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#90

signature.asc
Description: This is a digitally signed message part.

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

2016-10-06 Thread Adrian Bunk 
On Thu, Oct 06, 2016 at 10:43:00AM +0100, Ian Jackson wrote:
> Adrian Bunk writes ("Re: Bug#839570: Browserified javascript and DFSG 2 
> (reopening)"):
> > Perl's Configure or SQLite are other examples of code with similar 
> > issues currently in Debian, and it would be helpful if the TC would 
> > start by gathering an overview of the different cases and how they
> > are similar or different.
> 
> You've mentioned sqlite3 several times in this thread, but I couldn't
> find a corresponding bug report against src:sqlite3.  Did I miss one ?

I am not sure whether this has been filed as a bug in any affected 
package, but src:sqlite3 is not affected.

The problem is the amalgamation in other packages, for example:
https://sources.debian.net/src/firefox/49.0-4/db/sqlite3/src/sqlite3.c

Upstream documentation:
http://sqlite.org/howtocompile.html
"The use of the amalgamation is recommended for all applications."
"Recall that the SQLite amalgamation contains a lot of C-code that is 
 generated by auxiliary programs and scripts."

> Ian.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

2016-10-06 Thread Adrian Bunk 
On Thu, Oct 06, 2016 at 01:13:16AM -0400, Joseph R. Justice wrote:
> For the record, I wish the message I am now responding to, and other
> subsequent responses and discussion, were being sent to the bug mail
> address *in addition to* all the other addresses they're being sent to.
>...

For the record, that was my fault and a problem in my mail setup.

> Joseph

Sorry for that
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#839570: Browserified javascript and DFSG 2 (reopening)

2016-10-06 Thread Philip Hands 
"Joseph R. Justice"  writes:

>> Here are some factors to consider:
>>
>> 1)  It's not clear to several TC members that the FTP team has decided
>> on this question.  It seems fairly clear how they would decide if they
>> did decide, but from a process standpoint, it's important to have a
>> formal dialogue with them before they are overruled.
>
> I'll be honest, I assumed from what I've read that a decision had already
> been made by the FTP team against Mr. Praveen.  I figured that it must have
> been, or else why would he be raising this bug with the TC now?

Well, quite.

Joseph, thanks for you efforts here, I think some light has been shed
( although as a dyslexic, shorter/fewer mails would be helpful ;-)
  That being the case I'm just going to reply to one mail and cover
  some of the points that you raised across several).

I'm just writing as an individual here BTW, but I'll obviously carry
these views into any discussion that the TC might have about this.

The repeatedly presented request is for a ruling on the question of
'browserified javascript' in general.  There are two serious problems
with that straight away.

Firstly, none of the people being asked to make to that general
decision are used to making general statements on such matters, and
many/most of them think that doing so is a bad idea.

Secondly, 'browserified' is poorly defined, and repeated attempts to
clarify its meaning seem to have been ignored.

Pretty much any response that any of us might be hoped to make to such
requests are things we're unwilling to say because we reject both the
assumption that a general statement is a good idea, and don't want to
make statements that are then open to wild reinterpretation because of
the fluffy terminology.

So we end up asking what look like picky, annoying questions about small
details in order to try and get something concrete to talk about.

Meanwhile Praveen is only interested in fixing the whole problem at once,
and pushes harder to get a general response.  This is not working.

Speaking purely for myself, no matter how trivial the transformation
being done to the source, I see no compelling reason for an exception.

My reason being more to do with the practical consequences of allowing
such an exception, than the subtle issue of what might constitute source.

Assuming for the sake of argument that the request for a special
exception were granted, then:

Let's imagine that there's one-line npm library that has an (as
yet undiscovered) flaw that allows some sort of serious remote attack.

Also, that library is popular enough to be included in numerous
"browserified" libraries, which because of the exception get packaged,
and then included in a release, and are depended upon by the likes of
gitlab and other such packages.

Wait a couple of years, and then discover the bug.

In the mean time, some of the browserified libraries have become
unpopular, and no longer have upstreams and because of developments in
grunt can now only be built with an obsolete version of grunt.  Some have
refactored and can now only be built with the latest version of grunt.
Some have moved on and no longer use the faulty code at all, so have no
interest in helping fix old versions.

The security team are going to have to track down every instance of that
code and fix it.  If the bug is something to do with an interaction
between the code and the tools used to "browserifiy" the code, that may be
non-trivial.

We have no real control over which versions of those tools were used,
and various upstreams are likely to say "just upgrade" or thay may
present us with vastly different versions of the browserified code,
especially if they've switched to different tools in the mean time.

None of this seems compatible with our normal security processes.

In a perfect world the person doing the security fix would go to the
buggy code in its own library, and then upload a new version, provoking
all the other packages to be rebuilt.  Job done.

Of course, for that to happen we'd have to start accepting tiny
javascript packages, which is currently not happening (which also seems
to be a blocker to grunt being packaged BTW).

In conclusion, Praveen's asking a question that I see no real prospect of
getting an answer in its current form.

In fact, I'm yet to imagine a way of framing this question that would
result in any of the packages being acceptable in 'main' and I don't see
any problem with them being moved to a combination of contrib and
non-free -- I think that is actually the correct outcome, because it
gives the correct impression about the level of security support they
should expect for those packages.  It also doesn't encourage people to
use packages that might well be removed in a subsequent release.

How good would it be, for instance, if in the lifetime of Squeeze,
Alioth were migrated to gitlab, only for it to be removed from Squeeze+1
when grunt proves to be unpackageable?  Temporoary

Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

2016-10-06 Thread Ian Jackson 
Adrian Bunk writes ("Re: Bug#839570: Browserified javascript and DFSG 2 
(reopening)"):
> Perl's Configure or SQLite are other examples of code with similar 
> issues currently in Debian, and it would be helpful if the TC would 
> start by gathering an overview of the different cases and how they
> are similar or different.

You've mentioned sqlite3 several times in this thread, but I couldn't
find a corresponding bug report against src:sqlite3.  Did I miss one ?

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#839570: Browserified javascript and DFSG 2 (reopening)

2016-10-06 Thread Joseph R. Justice 
On Wed, Oct 5, 2016 at 12:04 AM, Pirate Praveen  wrote:

A quick update, I have asked ftp masters to make a ruling on the issue.
> #839801.
>

Forgot to mention in my other response to this message...

Should this bug (839570) depend on the FTPmaster ruling request bug
(839801), or vice versa, so as to indicate that the TC is waiting on any
response from the FTP team before making a decision?  (Since, after all,
the FTP team might make a decision which satisfies Mr. Praveen, making
what's been asked of the TC moot.)

If this should be done, I encourage someone with the right to do this to do
so.  I certainly do not feel I have the right myself, and even if I did I
am unfamiliar enough with the bug tracking software to feel I should
attempt to do this.

Thanks for your time.  Hope this is of some use, interest.



Joseph

Bug#839570: Browserified javascript and DFSG 2 (reopening)

2016-10-06 Thread Joseph R. Justice 
On Thu, Oct 6, 2016 at 12:55 AM, Tollef Fog Heen  wrote:

> ]] "Joseph R. Justice"
>


> > Could the TC offer guidance, or issue a statement, on if (and if so
> > when) it should ever be permissible to allow a waiver from RC-bug
> > status for software whose source code is available but determined to
> > be insufficiently free for the DFSG while active efforts are underway
> > to get the source code into a state determined to be fully compliant
> > with the DFSG?
>
> This is very clearly release team territory and they have an RC bug
> policy already: https://release.debian.org/stretch/rc_policy.txt If this
> isn't clear enough or sufficient enough, that policy should be improved.
> The TC should not go out and overrule the release team's RC bug policy
> unless we have a really good reason (and it's still not completely clear
> that we can overrule them as a team either, but that entire discussion
> is unneeded unless we want/need to override them).
>

Read it.  Thank you.

Clearly (to me) what Mr. Praveen is asking for is stretch-ignore tags by a
release manager for software which has the browserified Javascript issue.
This software might and/or might not include software with the generated
lexer/parser code issue and/or other as yet unknown issues, depending on
what exactly browserification is defined to mean, which I will agree for
now has not yet been done.  E.g. it is not clear, there is not a hard and
firm definition, of what it means to browserify Javascript, such that one
can say "this software is merely browserified" or "that software is
browserified *and* *also* ..."

Is there any information yet on what formal policy (if any) will be used by
the release managers for allowing bugs to be tagged stretch-ignore?  *Was*
there any formal policy ever set in place for the prior (the current
stable) release of Debian, e.g. Jessie, or prior to that Wheezy?  Was it /
will it be entirely ad-hoc and at the discretion of the release team?

If the TC as a body does not feel it can, or does not feel it should,
override the release team in terms of granting stretch-ignore tags for
certain bugs or classes of bugs (and, I am not saying the TC *should* feel
it can or should do this, mind you!), still the TC as a body can, if a
developer so requests and if the TC as a body agrees it should do so, offer
an advisory opinion concerning particular bugs / bug classes to the release
team and/or offer a show of support to the affected developer, in terms of
saying "we believe stretch-ignore tags should be applied to the following
bugs / classes of bugs, because ..."  Correct?

Question of bug process, I guess ...  For purpose of stretch-ignore tags
(should they be granted, of course!), would it make sense to create a
meta-bug, say "Browserified Javascript in Stretch", make all the individual
package bugs somehow depend on or refer to this meta bug, and then apply a
stretch-ignore tag to the meta-bug and allow it to propagate somehow to all
the individual bugs?  Or would it be better to just apply the
stretch-ignore tag to each separate individual package bug?  I'm thinking
as to what will be most effective in making sure nothing gets missed,
overlooked, forgotten about, either pre-Stretch or post-Stretch.

Thanks for your time.  Hope this is of some use, interest.



Joseph