Bug#839570: Browserified javascript and DFSG 2 (reopening)
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)
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
Bug#839570: Browserified javascript and DFSG 2 (reopening)
On Wed, Oct 5, 2016 at 12:04 AM, Pa irate Praveen wrote: > On 2016, ഒക്ടോബർ 4 7:49:28 PM IST, Sam Hartman > wrote: > > >You're asking questions that don't make sense from a p.process > >standpoint, doing things that have a very low probability of making > >anyone happy, > > A quick update, I have asked ftp masters to make a ruling on the issue. > #839801. > I saw that. I look forward to any response they (or others) care to make concerning that bug. FWIW, I for one was under the impression (in part based on what you originally wrote when you opened this bug, and looking at the bugs you referenced in that message) that there had already been a decision by them to declare browserified Javascript as failing to be DFSG-free on the grounds of failing source code availability (because grunt is not currently available in the Debian main archive). If this was not the case, then I'll agree with others it's important you get an explicit ruling from them one way or another, so that if the ruling goes against you you can go to the TC and say "This is what was decided, and this is why I disagree", and you actually *have* something to point to in terms of what was decided! Based on what Mr. Hartman has written, I would encourage you to explain for everyone involved just exactly what you mean by "browserified Javascript", what sort of processes and transformations are included by that term and what are not. Try to be as specific and precise as possible, not just handwavy. I've seen some stuff that makes it sound like it's merely concatenation of files, but then I've seen other stuff that makes it sound like it's *not* just that. So I'm confused. Remember, the people on the TC are generally technically adept, but they're *not* specialists in Javascript as you apparently are! You need to teach them some stuff, so they can make an educated and informed decision. I would also suggest you explain exactly how the issue raised in bugs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830986 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830987 (the bugs related to the generated lexer/parser code issue) relate to the concept of browserified Javascript in general? Is part of what's described in these bugs routinely considered to be part of what it means to browserify Javascript, so that if browserified Javascript is (temporarily) declared to not be RC-buggy for Stretch, that means this stuff is not RC-buggy for Stretch? Or, is what's described by these bugs entirely separate and apart from the process of browserification, such that even if browserification is not RC-buggy for the moment, software with these bugs is still RC-buggy and needs to have the bug resolved or else have the software go to the non-free archive? > I feel these responses make TC more like a bureaucracy, where focus is > given on process and having people to go around asking many people. > >From what I understand of Mr. Hartman, he is particularly interested in process. But, for your purposes, that is not a *bad* thing! He's not necessarily interested in simply denying your request (tho, he *is* interested in making sure your request is seen by him only after the people who should see and decide on your request first have had a chance to do so). That doesn't mean he'll necessarily agree with your position. But, I think it's important to him that you get a fair hearing and be treated as fairly as possible. It's important however for *you*, if you are to get what you want (which as far as I can tell is a temporary variance for the duration of Stretch for browserified Javascript files from being considered RC-buggy while you work to package grunt for Stretch+1), to explain *why* this variance should be granted. And what you're going to do to permanently resolved this issue for Stretch+1, so it doesn't come up again as a problem. You have to convince the TC to take your side; it's not enough for you to say "Well, you should do what I want because ... Just because." I'm sorry if you feel like this is a bureaucracy. For what it's worth, I think people are just trying to make sure they're doing what's right or what's best, not just what's convenient or expedient at the moment. Hope this is of some use, interest. Thanks for your time. Joseph
Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)
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. I am choosing to send my response here to the bug mail address, at least in part so there is a record there that not all the discussion related to this bug is available at the bug itself, but instead is only found in the debian-ctte list archives. On Tue, Oct 4, 2016 at 11:31 AM, Adrian Bunk wrote: > On Tue, Oct 04, 2016 at 10:30:01AM -0400, Sam Hartman wrote: > > > Here are some factors to consider: > [...] > In other words, the best way forward for getting any decision would be > an RC bug against perl claiming that the Configure script is not DFSG-free. > For the record, having read Mr. Hartman's draft analysis at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#217 , and some other things related to the perl Configure script source code availability issue, I admit that I would be ... "amused", for a suitable definition of the word amused, if this issue were brought up. (*cough*). > If anyone thinks that this hardball approach would not be necessary, > please describe to Pirate Praveen a better way for getting an explicit > decision in time for stretch. > Get a variance from RC-buggyness for browserified Javascript for Stretch, and package grunt and/or alternative for Stretch+1. That's what he's asked for, anyway. Admittedly, if grunt et al fails to be successfully packaged for Stretch+1, and/or if packaging grunt et al proves to be insufficient for the browserified Javascript source code availability issue, then the RC-bug issue reappears for Stretch+1, with an even more tangled thicket around it But, that's the risk one takes. Hope this is of some use, interest. Thanks for your time. Be well. Joseph
Bug#839570: Browserified javascript and DFSG 2 (reopening)
]] "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). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#839570: Browserified javascript and DFSG 2 (reopening)
On Tue, Oct 4, 2016 at 10:30 AM, Sam Hartman 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 becaus
Bug#839570: Browserified javascript and DFSG 2 (reopening)
On Tue, Oct 4, 2016 at 9:18 AM, Sam Hartman wrote: > > "Didier" == Didier 'OdyX' Raboud writes: > I do think there are things we could do in this space. > We could set policy consistent with the DFSG on what the definition of > source code in Debian is. > 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? That's what Mr. Praveen is actually asking for, after all. (IMO, of course.) He wants the software he is interested in in the Debian main archive at the time Debian Stretch is released (because, politically and ... I can't think of the right word, but in terms of advertising capabilities, it's undesirable for the software to have to be relegated to the contrib and non-free archives, those don't count for many as being part of "Debian"). But, in practical terms, while the source code for the software may effectively be available within Debian now, it does not meet the full and pristine interpretation of the DFSG in terms of what it means to have source code available. So, while he works on that (by packaging grunt), he's seeking a waiver from RC-bug status for this issue for the in-preparation release. Mmmm. I believe I saw ... Found it. https://lists.debian.org/debian-devel/2016/07/msg00253.html . Quoting from that message (first paragraph from Mr. Praveen, remainder by Philip Hands ): = > And why is the people who are so strict about packaging the build tool > not stepping up to package it? FRP for node-grunt was filed in 21 May > 2012 and it is still not complete. So removing these packages until > grunt is packaged makes debian better? They should be in contrib. Allowing them in main removes any incentive to do the work to fix this problem, which I'd imagine is the reason it's not been done. When this was last raised, I looked into it and concluded that grunt is a tangled mess. [...] Simply letting them [ed: packages ultimately depending on the presence of grunt] into main removes that pressure [ed: to deal with the tangled mess of grunt either directly or else indirectly by finessing / replacing it, and/or by getting upstreams to alter their use of grunt, etc], it also means that we're deceiving our users, since they expect buildable source for all packages in main. = That's a political decision, too. (I'm not claiming or implying it's a wrong decision, mind you! I'm simply noting it as an observation, I was impressed by it the first time I read it.) Thanks for your time. Hope this is of some use, interest. Joseph
Bug#839570: Browserified javascript and DFSG 2 (reopening)
On Tue, Oct 4, 2016 at 7:37 AM, Didier 'OdyX' Raboud wrote: Would the following ballot be a better fit ? > == > C: Decline to rule on #830978 'Browserified javascript and DFSG 2' > FD: Further Discussion > == > I'd like to state again that, if you (the TC as a body) choose not to vote in favor of Mr. Praveen's request, I believe he would be more satisfied if you chose to express an active preference against his position and in favor of the (presumable) FTP Team's position, rather than merely decline to make a ruling and close the bug. I believe, given his original message opening the bug, that he would find the latter action by you all highly unsatisfactory. (Not that I claim he would be satisfied by an active ruling against him, mind you!) Thanks for your time. Hope this is of some use, interest. Joseph
Bug#839570: Browserified javascript and DFSG 2 (reopening)
[I realize there have been several messages subsequent to this, but I'm working down the list in order of presentation by the GMail web interface.] On Tue, Oct 4, 2016 at 4:13 AM, Didier 'OdyX' Raboud wrote: > Le dimanche, 2 octobre 2016, 14.29:49 h CEST Pirate Praveen a écrit : > > > package: tech-ctte > > > > Following up on #830978. I would like this to be reopened and request > > CTTE make a formal vote. > > The discussion that lead to closing #830978 happened on IRC [0] , see the > full > log from line 172 [1] , and Sam put a clear rationale in the mail closing > the > bug [2]. I'll quote on specific part of it: > > With regard to the particular issue of Browserified javascript, > > particularly in the libjs-handlebars package, the best way forward is > > for the submitter to discuss the question with the FTP team. Such a > > discussion would be less confusing if it took place after #830986 is > > resolved. > > (#830986 isn't resolved) > FWIW, it's not clear to me at least that ""browserified" Javascript" necessarily includes the issue pointed out in 830986, e.g. the generated lexer/parser code. (I'm not saying it *doesn't* include the 830986 issue, mind you! I'm just not saying either that it *does* include it. Reviewing https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978 , I see some comments that, to me at least, imply that browserification does not necessarily imply the 830986 issue in in play for any given instance of browserified code.) In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#5 , Mr. Praveen lists bugs which ultimately refer to several other Javascript library packages beyond that of libjs-handlebars. I suppose it's possible that all of them include generated lexer/parser code, but if there are some that do not then apparently "browserification" does not necessarily involve use of external lexer/parser generators (tho certainly it's possible that browserification, in the form Mr. Praveen means it, might include always having the capability to invoke a lexer/parser as part of the process of browserifying Javascript libraries). In any event, for any browserified libraries which do *not* include code generated by a lexer/parser, the bug at 830986 should not apply to them. Further, in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#35 , Mr. Praveen says "the browserified javascript can be modified by anyone who understand javascript without difficulty and can satisfy dfsg requirement for source" where the browserified javascript refers to "libjs-handlebars, libjs-fuzzaldrin-plus and other browserified javascript". Given what I understand about the sort of code typically generated by lexer/parsers, e.g. that it typically can *not* be modified, in generated form, by "anyone" "without difficulty", I have to think that either (a) Mr. Praveen does not mean libraries of this sort (e.g. containing generated lexer/parser code) when he is speaking of browserification in general, or else (b) he is mistaken in his claim about how easy to modify such libraries. So... If there can be / are browserified libraries which do not suffer from an issue of containing generated lexer/parser code, then it may make sense to consider whether such libraries are suitable for inclusion in the "main" archive separately from the issue of any such libraries which *do* suffer from an issue of containing generated lexer/parser code. (For the record, I myself do not know if there are any such libraries, nor am I claiming that there are any such. I'm just raising the possibility as a "What if?" sort of thing.) > Now, moving forwards… We decided to close the bug without a formal vote, > because it was clear for all the present TC members that we were in > agreement. > We have also agreed (amongst us) to avoid the use of unnecessary > bureaucracy > when possible; hence our delegation to close the bug to Sam. Now, the > offer to > "repoen the bug and ask for a formal vote" [3] stood to enable anyone to > ask > for the bug closure to respect our formal procedures (saying "please don't > close the bug because you think you're in agreement, but run a formal > vote"). > > For what I'm concerned, the situation hasn't evolved, and the conclusion > that > Sam outlined still stands (FTP Team is responsible for DFSG, and has > decided, > Release Team has decided DFSG is RC and has deferred DFSG-compliance > determination to FTP Team). > I'll go into this point in more detail in other responses, I expect, but I'll at least say for now that I think it is possible to find that there are differing levels or degrees of DFSG non-compliance, in terms of their severity of non-compliance or the amount of harm that can be done by distributing them despite the fact that they are not fully compliant with *all* the terms of the DSFG and their current interpretation by Debian, and that therefore it is possible that it might be reasonable in some circumstances to decide that a variance from finding som
Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)
Philip Hands writes: > Praveen, please respond to #830986 Actually, I withdraw that request -- I doubt replying there is going to be a productive use of your time, and is probably not going to improve your chances of getting what you want either. 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. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)
On Wed, Oct 05, 2016 at 08:21:40PM +0200, Philip Hands wrote: > Adrian Bunk writes: > > > Why are TC members complaining that they do not even properly understand > > what "browserified" means, instead of using the power to give advice to > > structure the discussion? > > Probably because without a response to #830986, "browserified" either > means including Jison output into things, or it cannot possibly cover > what's being done to libjs-handlebars, either of which makes the recent > bugs against tech-ctte and ftp-master just a little astonishing. > > Praveen, please respond to #830986 Yesterday Sam stated that the TC would first require a ruling from the FTP team for being able to overrule it. The result is #839801. This is exactly why I am saying the TC should structure the discussion. > Without such a response, I wasn't even sure if the re-opening of the bug > was instead an attempt to get some sort of permission to let the likes > of gitlab into main, by temporarily ignoring the non-free > dependencies. (I'm not suggesting that as a way forward BTW, but it > seemed at least as plausible as what was actually being asked) I would assume good faith. My impression is that there are several problems mixed with only the most obvious one inititially discussed, and that the best way forward would be if a TC member would look at the packages in question as well as what terminology is used in the JS world. You really need someone who will also look for issues like #830986 to actually get first-hand knowledge. It would also be good if that person could get an understanding which of these problems would be fixed when Grunt is packaged. And then also looks at cases like Perl or SQLite. Any TC member should be able to do that in 1-2 days, and then there would be a proper description of the problem that could serve as basis for an actual discussion of the problem. > 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
Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)
Adrian Bunk writes: > Why are TC members complaining that they do not even properly understand > what "browserified" means, instead of using the power to give advice to > structure the discussion? Probably because without a response to #830986, "browserified" either means including Jison output into things, or it cannot possibly cover what's being done to libjs-handlebars, either of which makes the recent bugs against tech-ctte and ftp-master just a little astonishing. Praveen, please respond to #830986 Without such a response, I wasn't even sure if the re-opening of the bug was instead an attempt to get some sort of permission to let the likes of gitlab into main, by temporarily ignoring the non-free dependencies. (I'm not suggesting that as a way forward BTW, but it seemed at least as plausible as what was actually being asked) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)
On Wed, 05 Oct 2016 19:10:35 +0300, Adrian Bunk wrote: > The TC is clearly not too busy, just too lazy. I find your recent mails quite aggressive which makes them unpleasant to read for me. Please try to change your tone a bit. Cheers, gregor Cheers, gregor -- .''`. Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Pink Floyd: The Great Gig In The Sky signature.asc Description: Digital Signature
Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)
> "Don" == Don Armstrong writes: Don> I don't believe there is anyone on the TC who is arguing that Don> perl doesn't (or at least didn't) have a DFSG issue.[1] Don> We merely believe the TC does not have the power to make a Don> decision for the ftpmasters without being delegated that Don> decision. We can help try to clarify the issue for the Don> ftpmasters and the project, but the bully pulpit (up to and Don> including §6.1.5) is the only special power we think we have in Don> this area. For what it's worth I think our power in this area extends beyond 6.1.5 in some cases.
Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)
On Wed, Oct 05, 2016 at 10:06:57AM -0500, Don Armstrong wrote: > On Wed, 05 Oct 2016, Adrian Bunk wrote: > > Please describe the relevant differences between browserified > > javascript and perl that make the TC believe that the former has a > > DFSG issue but the latter probably has not, in a way that I can deduct > > what the TC would believe regarding the similiar problem related to > > SQLite. > > I don't believe there is anyone on the TC who is arguing that perl > doesn't (or at least didn't) have a DFSG issue.[1] > > We merely believe the TC does not have the power to make a decision for > the ftpmasters without being delegated that decision. We can help try to > clarify the issue for the ftpmasters and the project, but the bully > pulpit (up to and including §6.1.5) is the only special power we think > we have in this area. >... What I am dismayed about is how the TC seems to try to find excuses to avoid making any decision or being in any other way helpful. Just yesterday the chairman (!) of the TC was stating "but it's not at all clear that the constitution enables the TC to override Delegates or decisions made by delegates": https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#40 For comparison, here is a vote by the very same person last year where he does override a decision made by a delegate, with the TC even making a decision on a question it wasn't asked: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#1042 You did also vote the same: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#1037 Looking at [1], the TC made two decisions in 2015. Each of them took over a year. No decisions in 2016 so far. The TC is clearly not too busy, just too lazy. I do agree with Ian that even though I doubt that Pirate Praveen will get the decision he hopes for, he is entitled to a proper resolution of the issue. Why are TC members complaining that they do not even properly understand what "browserified" means, instead of using the power to give advice to structure the discussion? I do not see anything controversial about the TC generating an overview of the relevant issues related to javascript as well as similar non-javascript cases. You have 8 of the most experienced Debian developers in the TC, no other TC work at hand, and any one of you should be able to help resolving this conflict by doing this. How a final decision would look like, and who would make that, would be the next step. In any case you have to first understand the problem properly. And I would not even exclude the possibility that there might be solutions that were not visible before understanding the problem. cu Adrian [1] https://www.debian.org/devel/tech-ctte -- "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)
On Wed, 05 Oct 2016, Adrian Bunk wrote: > Please describe the relevant differences between browserified > javascript and perl that make the TC believe that the former has a > DFSG issue but the latter probably has not, in a way that I can deduct > what the TC would believe regarding the similiar problem related to > SQLite. I don't believe there is anyone on the TC who is arguing that perl doesn't (or at least didn't) have a DFSG issue.[1] We merely believe the TC does not have the power to make a decision for the ftpmasters without being delegated that decision. We can help try to clarify the issue for the ftpmasters and the project, but the bully pulpit (up to and including §6.1.5) is the only special power we think we have in this area. 1: I just looked into this yesterday, and was amazed at how complicated the Configure regeneration process was. It even seems to depend on being run by a specific user. -- Don Armstrong https://www.donarmstrong.com Americans can always be counted on to do the right thing, after they have exhausted all other possibilities. -- W. Churchill
Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)
On Wed, Oct 05, 2016 at 10:00:53AM -0400, Sam Hartman wrote: >... > I think it's clear that the TC believes that this package is not DFSG > free. > I think it's clear that the TC believes perl would be better if the > situation was improved. > I thought it was clear we believed perl had a DFSG issue, although IRC > discussion today makes that less clear. > I don't think the value of having the TC formally say any of those > specific things is very high. >... Please describe the relevant differences between browserified javascript and perl that make the TC believe that the former has a DFSG issue but the latter probably has not, in a way that I can deduct what the TC would believe regarding the similiar problem related to SQLite. > --Sam 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)
> "Sam" == Sam Hartman writes: Sam> Obviously, there's a level at which I agree with you. When Sam> this came around last time, I wanted us to issue advice. This was something I intended to send to Ian privately, not to the bug. Apologies for the spam and for emphasis that probably doesn't help the public discussion.
Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)
On Wed, Oct 05, 2016 at 12:59:36PM +0100, Ian Jackson wrote: >... > I think the TC has many reasonable options. > > * You could say that you think you aren't authorised, by the >constitution, to overrule a decision on DFSG-ness, and invite the >petitioners to consider a GR. In any case the TC is entitled to offer advice in the form of structuring the discussion and advising/helping in getting a decision. A large part of the problem seems to be a lack of understanding what terms like "browserified" or "minified" actually mean, and what other related problems might exist with javascript. 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. >... > * With respect to Perl's Configure, one possible answer that has not >been considered is to declare that you agree that there is a >software freedom problem, but to distinguish the proper action with >respect to Configure on the basis of several possible factors. For >example, one might argue that an exception should be made in the >same way as we have collectively previously made exceptions for >certain freedom problems; or that while the Perl situation is a >problem, people agree that it should be fixed, and that it does not >justify introducing new problems; or whatever. >... Not installing firmware by default is causing an enormous amount of trouble for users of Debian, if Debian wants to make an exception anywhere then look no further. For Perl's Configure I do not see so far why this would be a problem in any case. The most extreme requirement I could imagine would be to strip the Configure from the source tarball and ship a metaconfig checkout from the commit used for this release of Perl. And even implementing this most extreme requirement wouldn't look like a huge problem to me. > 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
Bug#839570: Browserified javascript and DFSG 2 (reopening)
Obviously, there's a level at which I agree with you. When this came around last time, I wanted us to issue advice. The advice I wanted to issue isn't the advice you wished we issued, but it would have at least been advice. However, I was the only one on the TC who wanted to touch the issue. It was quite clear from the IRC meeting that I didn't have the support. I think the TC did reach a consensus not to touch the general question and give advice there. I think it's clear that the TC believes that this package is not DFSG free. I think it's clear that the TC believes perl would be better if the situation was improved. I thought it was clear we believed perl had a DFSG issue, although IRC discussion today makes that less clear. I don't think the value of having the TC formally say any of those specific things is very high. I don't think having a formal vote to confirm the TC consensus to say nothing does much good. I do think such an outcome would accurately represent the current thinking of the TC as a body. I haven't seen anyone who has reviewed the log claim otherwise. I also don't think asking for a formal vote in a situation where there is a clear consensus is the right way to ask someone to change their mind. I think the TC is making the wrong call here. So do you. I guess I don't mind that you're bringing that up again. I'll be delighted if it changes peoples' minds. I don't entirely know what I'm saying. Perhaps just expressing disappointment in this overall process. --Sam
Bug#839570: Browserified javascript and DFSG 2 (reopening)
Didier 'OdyX' Raboud writes ("Bug#839570: Browserified javascript and DFSG 2
(reopening)"):
> Would the following ballot be a better fit ?
> ==
> C: Decline to rule on #830978 'Browserified javascript and DFSG 2'
> FD: Further Discussion
> ==
I think this would be an extremely unsatisfactory outcome.
Once again, we have a situation of ongoing disagreement. It runs on
and on. The people involved are trying to properly escalate the
situation. If the TC produces this unrationalised dismissal, the
dispute will continue to rumble on.
It must also be very frustrating for the petitioners that the
decisionmaking process is deflecting their arguments, and not engaging
properly even to state disagreement. The point about Perl's Configure
is very well made.
Personally I actually disagree with the petitioners as to the right
action to take, but I think they are entitled to a proper resolution
of their complaint.
I think the TC has many reasonable options.
* You could say that you think you aren't authorised, by the
constitution, to overrule a decision on DFSG-ness, and invite the
petitioners to consider a GR.
* You could say whether or not you actually agree with the
petitioners about the DFSG-freenees of the browswerified JS. If
your decision is that the JS is non-free then you should explicitly
express some opinion about the situation with Perl's Configure.
* If you agree with the petitioners and think you are
constitutionally authorised, you could resolve to overrule. I
doubt anyone would gainsay the TC, other than by GR. If you agree
with the petitioners and don't think you are constitutionally
authorised, you could issue advice.
* With respect to Perl's Configure, one possible answer that has not
been considered is to declare that you agree that there is a
software freedom problem, but to distinguish the proper action with
respect to Configure on the basis of several possible factors. For
example, one might argue that an exception should be made in the
same way as we have collectively previously made exceptions for
certain freedom problems; or that while the Perl situation is a
problem, people agree that it should be fixed, and that it does not
justify introducing new problems; or whatever.
* If you feel that the issue isn't ripe because ftpmaster haven't
formally made a decision, then TC members should explicitly invite
ftpmaster to provide a decision (and there should be a deadline
set). I agree with the complaint that this point, as taken so far
by members of the TC, is overly bureaucratic.
If the TC can't get consensus on any particular form of words, then
the right answer is not to try to gain consensus on dismissing the
petitioner with no explanation.
Instead, if there is not consensus on the various questions raised by
the petitioner, the TC should vote on various suitable options.
Ian.
--
Ian JacksonThese 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.
