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

[Pirate Praveen]

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 feel these responses make TC more like a bureaucracy, where focus is given on 
process and having people to go around asking many people.

I have to go now, will try to reply in detail later.


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

Adrian> On Tue, Oct 04, 2016 at 05:54:55PM -0400, Sam Hartman wrote:
>> > "Adrian" == Adrian Bunk  writes:
>> 
Adrian> In other words, the best way forward for getting any
Adrian> decision would be an RC bug against perl claiming that the
Adrian> Configure script is not DFSG-free.
>> 
>> This RC bug was filed, and I think everyone involved including
>> the Perl maintainers agreed it was RC.
>> 
>> I'd be really surprised if the TC or FTP team disagreed about our
>> need to be able to regenerate the perl configure script using
>> tools only in Debian.

Adrian> RC bug #762638 was resolved with
Adrian> 
https://sources.debian.net/src/perl/5.24.1~rc3-3/debian/README.source/#L128

Sigh.
I'm entirely unsatisfied by that conclusion and disagree with the Perl
maintainer's decision.

I think that if the metaconfig.git sources for the version of perl in
Debian were also in Debian,
then the README.source discussion would be sufficient.

Adrian> Are you saying Pirate Praveen could also use this solution
Adrian> for browserified javascript in main?

No.
The circumstances are different in nontrivial details and I think the Perl
maintainer is wrong.

--Sam

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

[Adrian Bunk]

On Tue, Oct 04, 2016 at 05:54:55PM -0400, Sam Hartman wrote:
> > "Adrian" == Adrian Bunk  writes:
> 
> Adrian> In other words, the best way forward for getting any
> Adrian> decision would be an RC bug against perl claiming that the
> Adrian> Configure script is not DFSG-free.
> 
> This RC bug was filed, and I think everyone involved including the Perl
> maintainers agreed it was RC.
> 
> I'd be really surprised if the TC or FTP team disagreed about our need
> to be able to regenerate the perl configure script using tools only in
> Debian.

RC bug #762638 was resolved with
  https://sources.debian.net/src/perl/5.24.1~rc3-3/debian/README.source/#L128

Are you saying Pirate Praveen could also use this solution for 
browserified javascript in main?

Or are you saying that you will reopen #762638?

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)

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

Adrian> In other words, the best way forward for getting any
Adrian> decision would be an RC bug against perl claiming that the
Adrian> Configure script is not DFSG-free.

This RC bug was filed, and I think everyone involved including the Perl
maintainers agreed it was RC.


I'd be really surprised if the TC or FTP team disagreed about our need
to be able to regenerate the perl configure script using tools only in
Debian.

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

[Adrian Bunk]

On Tue, Oct 04, 2016 at 10:30:01AM -0400, Sam Hartman wrote:
>...
> 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.
> 
> 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.
> 
> 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.

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.

If anyone disputes that perl is not DFSG-free due to the Configure 
script, "Is the perl Configure script DFSG-free?" would be a clear 
question that could be escalated to FTP/TC/GR.

This is also a case where it would be easier for you to get a clear 
understanding.

The relevant part of #762638 is:
  Clearly perl isn't going to be kicked out of Debian because of this,
  but a less important package might well be.

That is exactly the problem here - browserified javascript is
not important enough, so FTP team and TC are getting away with
not making a decision.

Pirate Praveen is simply doing the wrong thing by pursuing a path
where everyone is just trying to avoid making a an explicit decision,
sustaining an implicit decision against him.

perl is important enough that noone would get away with not making a 
decision, and the only realistic way forward for browserified javascript 
would be to force a decision whether or not the perl Configure script is 
DFSG-free.

After forcing a decision on perl, there will be decisions that would 
also settle the main questions regarding browserified javascript.

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.

If you want to build a coherent policy for that, that policy would of 
course equally apply to other similar cases like the perl Configure
or SQLite, so there is nothing bad about starting the process with
the perl Configure.

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 Hartman]

Dear joseph:

This message will be hurried: I'm on a train and approaching my stop.


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.

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.

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.

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.

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

[Sam Hartman]

Dear Pirate:

I hear that you're fairly frustrated by the response you're getting from
the TC.

Speaking as someone who has read extensively the earlier bug log, I
think that your cause would be advanced by getting an additional primary
advocate who has a better understanding of what the TC can do, what the
TC is likely to do, and who can more articulately ask for things to
advance your position.
If Joseph were more involved in Debian, I'd suggest him as a
possibility.

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, and not responding to advice people have given you on how
to move forward.

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

[Didier 'OdyX' Raboud]

Le mardi, 4 octobre 2016, 07.12:24 h CEST Sam Hartman a écrit :
> I'd be willing to vote on the ballot you propose.
> I disagree with your rationale for why this bug is not for the TC to
> decide.

Good. Can you outline shortly why ?

> But I agree that this bug is not for the TC to decide at this time.

Are you saying it might be for the TC to decide at a hypothetical later point 
in time when FTP Team has issued a concrete decision? Or through mediation?

> So, if that's all we're voting on, and I don't need to agree with your
> rationale to vote C, I'm fine with your ballot.

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 understand where our disagreement lies though.
-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

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

[Sam Hartman]

I'd be willing to vote on the ballot you propose.
I disagree with your rationale for why this bug is not for the TC to
decide.
But I agree that this bug is not for the TC to decide at this time.
So, if that's all we're voting on, and I don't need to agree with your
rationale to vote C, I'm fine with your ballot.

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

[Didier 'OdyX' Raboud]

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)

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'm therefore putting the following ballot up for discussion within the TC:

==
C: Close 830978 as not being something for the TC to decide
FD: Further Discussion
==

To make things maybe clearer: we have said through the initial bug closure 
(and would be reaffirming this) that deciding about DFSG compliance is not for 
the TC to decide (we're refusing to rule about something clearly in the FTP 
Team's jurisdiction; that is).

You seem to be asking us to decide on DFSG compliance (in place of the FTP 
Team); but it's not at all clear that the constitution enables the TC to 
override Delegates or decisions made by delegates (see §6.1). We have 
recommended you (through Sam's message when closing the bug) to discuss this 
question with the FTP Team:

> With regard to the particular issue of Browserified javascript (…) the best
> way forward is for the submitter to discuss the question with the FTP team. 

Has this happened? What was the outcome?

(For completeness, if you had discussed with FTP Team, reached a point of 
disagreement, noticed that the TC would continue to decline to rule in place 
of the FTP Team, your next recourses would be to go through a GR (§4.1.3) to 
override the FTP Team's decision on interpreting DFSG for the specific cases 
you have in mind; or through amending the DFSG itself (through §4.1.5). )

-- 
Cheers,
OdyX

[0] http://meetbot.debian.net/debian-ctte/2016/debian-ctte.
2016-07-28-18.00.html
[1] http://meetbot.debian.net/debian-ctte/2016/debian-ctte.
2016-07-28-18.00.log.html#l-172
[2] https://bugs.debian.org/830978#212 
[3] Which you didn't; you opened a new bug, anyway, let's not nitpick on 
details.

signature.asc
Description: This is a digitally signed message part.