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