>>>>> "Ian" == Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
Ian> I would like to comment briefly on the general idea about the
Ian> TC offering advice and making statements of opinion.
Ian> If someone in authority in the project, such as a maintainer of
Ian> the ftpmasters or the release team, is doing something which
Ian> the TC thinks is wrong, then (if the question is important) I
Ian> think it would be entirely appropriate for the TC to issue a
Ian> statement of opinion, disagreeing with the other authority.
Ian> Conversely, if a contributor has been criticised, they may
Ian> welcome a message of support from the TC. That may help lay to
Ian> rest an unfounded criticism and save the contributor the energy
Ian> required to wonder whether they're really right, rebut any
Ian> public criticisms, and so on.
Ian> And finally if a question needs authoritative input but the
Ian> relevant authority in Debian has not made a clear decision, TC
Ian> involvement might help get the matter properly resolved.
Agreed on both the first two points.
Also, from the discussion on IRC, it seems fairly clear that most TC
members agree that we can give advice if we wish.
I agree in general on the third point about authority and clear
decisions, with a lot of emphasis on the "might."
Sometimes that's good, sometimes it is not.
Ian> In this case I think that it would be worth TC members
Ian> considering, for themselves, briefly, and without too much
Ian> back-and-forth enquiry, what their initial assessments of the
Ian> merits of the situation are.
I'm fairly sure that's happened for a majority of the TC members.
Ian> If TC members feel that the submitter of #817092 (Luke, who is
Ian> complaining that the aggregated file is not source, along with
Ian> Ben, Jonas etc.) are right, they could ask the release team and
Ian> the ftpmasters (informally, perhaps) whether the release team
Ian> would welcome a supportive TC intervention.
The release team has indicated that this call is the FTP team's.
The members of the TC and members of the FTP team have talked informally.
Ian> That would allow the TC to help settle this long-running
Ian> question (which keeps coming up on -devel and is frankly quite
Ian> annoying).
So, here's why I personally don't think that would be helpful.
I want to emphasize this is pure Sam, not even Sam making a best guess
at how things might fall out if other people got involved, not me giving
my read on anything else.
As best I can tell, the ftp team has a clear position; it is reflected
in their new rejection FAQ, and in their decisions.
(As an aside, there was a keynote at Debconf talking about how it would
(in the speaker's opinion) be better to get more transparency in that. Based
on what I heard at
the keynote I think getting the TC involved in that would slow it
down/make it more political)
I haven't seen a lot of doubt expressed from the ftp team about what its
policies are. You see careful language from people not wanting to step
on each others' toes, but they are all saying the same thing.
Having an outsider to the process like the TC say something isn't going
to help in a case where there is already fairly good internal consensus
and not a lot of doubt.
I think the reason this comes up on -devel is that there may not be a
consensus project-wide, and if there is a rough consensus project-wide
on this issue, it's really on the rough side.
In general, I think that those who spend a lot of time in Debian are
more radically pro-free-software than the developers as a whole. That
is, folks on the TC, the DPL, the ftp team, etc are probably not
representative of the developers overall. I think we've seen this when
we've taken things like getting rid of non-free or binary firmware to a
GR. The project is clearly pro-free-software, but also fairly clearly
pro-getting-stuff-done-for-real-users even when that gets messy with
regard to free software.
Part of having good governance is to have those discussions on devel.
You have an honest disagreement between parts of your community--between
the people deciding and the people affected by the decisions.
That's not inherently a sign that the people deciding are wrong: Debian
culturally chooses to give significant power to those doing the work.
The TC isn't going to be able to add anything here. We have similar
biases to the ftp team. We deal with licenses less often, so they are
probably even more aware of the issues than we are.
Having two teams say the same thing isn't going to shut up anyone on
devel frustrated that we're insisting they do significantly more work.
We also need to continue to pay attention to those discussions and bugs
filed like this. If we
find that the overall project unhappiness with the balance we strike is
growing, we need to do something.
That said, my personal opinion about this issue is that it is a
datapoint, not a trend.
In closing, I hear Pirate's hope that we have a project in which we can
fork software, and that the preferred form of source code can shift over
time for given software. It's clear to me that the ftp team folks I've
talked to and the TC are all sensitive to this issue. We are humans
making subjective interpretations, and we can deal with those sorts of
situations.
For example if the handlebars gem community had a vibrant culture of
patching the aggregated form, I would consider that aggregate the source
code for this package.
However, as it stands, i think a more realistic interpretation is that
the handlebars gem is not really in the business of changing handlebars
much and as such doesn't include source for handlebars, only the
handlebars aggregate.
Yes, members of the TC did look at things like how often the aggregate
was changed in the gem's git and what form those changes took in making
up their individual minds.
Past ftp team decisions make it clear that ftpmaster is willing to
listen to arguments like that.
