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

["Joseph R. Justice" <jayarejay@gmail.com>]

On Thu, Oct 6, 2016 at 12:55 AM, Tollef Fog Heen <tfheen@err.no> 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