On Tue, Oct 4, 2016 at 10:30 AM, Sam Hartman <hartm...@debian.org> wrote:
First off, I would like to, sincerely and truly, thank you for responding to my message. I'd been wondering if maybe they were going into a black hole of some sort. You give me some reassurance that they are not, or at least not entirely. Thanks for your detailed message. I don't agree with all of it, but I > find it a lot easier to interact with than some of the requests we've > gotten related to this issue. > No problem, thanks back, and fair enough that you don't agree with all of it. FWIW, in some ways, it might be easier for me dealing with this than it is, say, Mr. Praveen. He is (inevitably!) emotionally invested in this issue, since it's something important to him, something he's working on. It's not something I'm particularly invested in; if anything, this is something I'm doing "pour le sport". He is intimately familiar with this stuff; I am not, so stuff that's obvious to him isn't obvious to me. And, no disrespect intended to him (or anyone), but I think I write mor gud (or at least more verbosely!) than he does. Just think of me as a roaming mercenary volunteer hired gun lawyer / advocate / mouthpiece, here to right wrongs, keel keel keel the bad guys, and sneak off into a haystack in the back barn with the comely schoolmarm before I ride off into the sunset on my faithful steed, Horse. (We're still trying to figure out which of us is smarter. My vote is on the guy with four legs, myself.) > 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? I do note however that Mr. Praveen has subsequent to your message stated that he has filed a formal request with the FTP team concerning browserified Javascript in general (although IMO he hasn't clearly stated that in his message opening the bug, tho I do believe that's what he means). To make life easier for anyone reading the bug log, the full link to the bug is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839801 . I've looked at it as I write this response; there's been no response to that bug yet (tho I hardly would expect one, it hasn't even been a day since the bug was filed, after all, and this is a non-trivial decision being asked for). > 2) It's not clear constitutionally that the TC can overrule the ftp > team's decision regarding whether something is DFSG-free. Even if we > could, it's not clear that is a technical decision in our scope. > So, asking the TC to overrule such a decision is asking for the hardest > political choice possible in such a situation--a really hard sell within > the project and the TC. > Mmmm. I respect that. FWIW, I don't think Mr. Praveen necessarily wants a ruling that browserified Javascript meets the full definition as-interpreted of "source code available". (Or, rather, I think *he* thinks browserified Javascript by itself is "good enough as-is", but he's willing to concede that something better is possible and preferable. He's said as much. 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.) Mmmm... With respect to politics... I fully agree that this is / will be, at least in part and possibly in large part, a political decision. Mr. Praveen has already started that ball in motion, by suggesting that this issue will cause many (presumably) important pieces of web-based software to have to be moved to contrib and the libraries they depend on be moved to non-free, at least until and if grunt (or a sufficiently capable replacement) can be added to the main archive. I'm aware that, for many people, *not* being in main is like saying "You're not *really* part of Debian Linux". 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. It's also of interest as to what, if anything, this software having to go to contrib / non-free will have on direct and indirect Debian downstream distributions (probably most important of course the U-elephant in the room), and on non-derivative competitors to Debian in the ecosystem, e.g. Fedora and RHL / CentOS, SUSE and OpenSUSE, etc etc. Will the gain achieved by allowing this software to be in Debian main outweigh the cost of having to allow a variance, at least a temporary variance (I haven't seen Mr. Praveen say he wants a permanent variance) to RC-buggyness status? What will be of the most benefit to Debian and to Debian's users? What will hurt Debian least? Mmmm... Even if the TC as a body does not believe it can, or does not believe it should, overrule the FTP and/or Release Team concerning this, e.g. to get Mr. Praveen the temporary variance from RC-bug status he wants for this issue, *if* the TC as a body believes that Mr. Praveen's request for a variance is justified given the circumstances, I think it would be helpful for them to say so if they believe it is worth the price it will cost them to their moral authority, even if it's just an advisory opinion. If nothing else, if Mr. Praveen chooses to escalate this to a GR issue, I have to think it can't hurt him, and likely would help him, to be able to say "the TC sides with my position in the matter". > 3) We'd need a rationale for overruling someone. That might not be a > strict requirement, but if we're going to say that "browserified > javascript" is DFSG-free, what exactly are we saying? There was a > discussion of what is source code, with a number of different > considerations brought up. Something that was responsive to that part > of the discussion would be a lot more likely to move things forward than > simply an assertion. I don't even have a clear enough understanding of > what browserified means to have any understanding of what a ruling based > on those terms would mean. Put another way, the TC is more comfortable > acting when it's building a coherent policy that fits together. To gain > traction, a ruling almost certainly needs to fit into some intellectual > framework about what source means. It's quite unlikely that we'd decide > something was source simply because it would be inconvenient for us and > our users if it were not source. > User convenience is something we're likely to consider, but "source is > what we need source to be so things work well for users," is going to be > a really improbable sell. > That is a reasonable position. FWIW, I don't necessarily think the TC should say "browserified Javascript is DFSG-free, end of story". People, including Mr. Praveen, have said it would be preferable to be able to regenerate browserified Javascript from unbrowserified Javascript, it's just that (currently) the tooling to do so is not in Debian main. In a message I wrote several minutes ago, I noted the mail message someone wrote which pretty much (as I read it) said forcing software to be in contrib / non-free was in part a way of putting pressure on resolving the browserified Javascript issue once and for all (e.g. by packaging and/or replacing grunt and/or people's way of using grunt), and allowing it to be in main would just relieve this pressure. Given that, I don't think people would thank the TC for relieving that pressure once and for all. OTOH, I understand that the freeze date for the in-preparation release is approaching and (relatively) soon, as things go. I understand that it is a Big Deal to get software into testing, and not RC-buggy, prior to the freeze, because it is such a PITA (if it is even possible) to get things added to a release once it is declared released and stable. (It is, of course, an entirely separate issue as to how difficult or even possible it is to add new software to a stable release, and still another as to how long it takes to make a new stable release once the in-preparation one is declared stable. These issues are separate from the one at hand, of course, but they are certainly driving it for at least some extent.) And again I understand that it is a Big Deal to get software into the *main* archive, as opposed to the *contrib* / *non-free* archive, for a given release. If that *wasn't* a big deal, this discussion wouldn't be occurring -- I haven't seen anyone say that browserified Javascript (even that with other problems, such as the lexer/parser use issue) is not suitable for non-free. But, non-free and contrib "isn't Debian". Your lack of understanding of what it means to be "browserified"... I'll Fully Agree that is an issue. I certainly don't have a good understanding. Someone with an understanding of the issue, be it Mr. Praveen or someone else, needs to give a good, hard, well specified definition of what this means. And, given the lexer/parser use issue that was discovered, and potentially other similar issues apart from that of mere concatenation of files, it needs to be stated what's included under the term "browserification" and what isn't. Perhaps there are multiple levels or forms of browserification, and some of these are more or less problematic w.r.t. being "sufficiently good enough *for* *now* in terms of being DSFG-compliant for source code". As yet, I'll agree, that hasn't been done, and it's certainly not something I can do. (I might be able to assist with something being insufficiently coherent, but I can't explain technical issues when I know nothing about them.) If we go back for a moment... Let's ignore the whole "is browserified Javascript DSFG-free (in terms of source code availability)" question for a instant. Yes, saying "Yes, it is" to that question would resolve the whole problem, and maybe in his heart of hearts Mr. Praveen would ideally like that resolution, but that isn't what he's actually *asked for*. That isn't the least intrusive means of solving the issue at hand, at least for the moment. In his original message opening this bug, Mr. Praveen wrote "I suggest including browserified js in stretch and make an effort to package grunt for stretch+1." (He meant stretch main archive, of course, since he already has it in the non-free archive, but that is insufficient to be "in Debian".) The least intrusive means of achieving this would be for the applicable authority to declare that "browserified Javascript" (whatever that ends up being defined to mean) which cannot be generated from non-browserified Javascript using only tools found in Debian main will not be considered RC-buggy for Stretch, but will be RC-buggy for Stretch+1. (E.g. grunt or a replacement which can resolve the browserified Javascript issue will need to be successfully packaged for Stretch+1, and all this software made to use it.) It's my impression and belief that declarations of temporary variances to RC-buggyness, to allow software to be incorporated into a soon-forthcoming release, have been granted at times in the past, tho I can't off-hand point to any. So, assuming I'm correct, it's not as if this hasn't happened before, there's a precedent. It's just a question of can and should it be done again for this issue. 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? (I note that, if grunt et al fails to be successfully packaged for Stretch+1, then this whole issue will need to be revisited again then, with probably *more* politics at hand *then*! But, at least it wouldn't be any of *your* all's problems by then, hopefully... Right? *cough*) Thanks for your time. Hope this is of some use, interest. Joseph
