[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



For the record for this bug / discussion:

I note Didier 'OdyX' Raboud 's mail to the Debian Secretary, CC'd to the TC list and the FTP Master list, requesting a general interpretation of the TC's ability (if any) to override the decisions made by various Debian delegate teams and individuals.  A copy of the mail can be found at https://lists.debian.org/debian-ctte/2016/10/msg00060.html .  If the request had been made as a bug filed to the bug tracking system, perhaps to a "secretary" meta-package, I'd have suggested this bug be blocked by that bug.

(As an aside, perhaps there should be a wishlist bug to create such a meta-package, for use in similar situations in the future?)

While the request for interpretation was clearly prompted by the discussion in this bug (indeed, the request explicitly says as much!), it is phrased to be very general in nature, which I personally think is a good idea.

I look forward to any discussion on that request for interpretation.  (I suspect I'll have to subscribe to the secretary mailing list, if there is one such, to make sure I see all of it.)



To all: Should Mr's Raboud's request for interpretation be expanded to include clarification on whether, and if so when and how, the TC can require some other delegate to take a particular action or actions, even if the delegate has not made a decision (or perhaps even been asked to make a decision) on the action?  (This, presumably if and only if the TC is capable of overriding a delegate's decision in the first place; if the TC cannot override a delegate's decision, it does not make sense then that they could require a delegate to decide to take an action!)

The particular specific case here would be as to whether the TC can require the release masters to add stretch-ignore tags either to bugs for individual packages affected by the "browserified _javascript_" issue (whatever it is determined that "browserified _javascript_" is ultimately defined to mean; in particular, I am *not* claiming at this time that the definition of browserified _javascript_ does include or should include packages affected by the includes generated lexer/parser code / jison (?) issue) and/or for all bugs which fall under this issue (e.g. bugs which are determined to block a meta-bug "resolution of browserified _javascript_" issue and/or which are determined to be blocked by a "ITP: grunt" or "IT Create and Package: sufficiently capable replacement for grunt" bug.

I realize that the idea of the TC overriding a delegate's decision *can* be interpreted to include this sort of thing, too.  However, I do not know if it is sufficiently obvious that such an interpretation should be made (the obvious counter-question is "How can the TC override a decision which has not yet been made, or which has not yet been requested to be made, or which perhaps is not a request-able decision in the first place (e.g. that there is no procedure in place to request that such a decision be made)?").

I am tempted to write the secretary to request just such an expanded consideration of Mr. Raboud's request.  However, before I do so, I think it is prudent to seek the counsel of older and wiser heads as to whether or not this is a good idea or if it will instead just confuse things and muddy the waters.

So...  What, if anything, do all'y'all think?



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



Joseph

Reply to: