On 09/13/2016 12:56 AM, Thomas Goirand wrote:
On 09/09/2016 09:53 PM, Russ Allbery wrote:
Furthermore, we're talking about upstream test behavior here, and I don't
think this argument passes the sniff test for conversations with upstream.
We already have enough issues with upstream over licensing, where we've
decided that our very aggressive stance is worth the effort. Please let's
not pick fights that *aren't* worth the effort and will cause upstream to
look at us like we're paranoid nit-pickers. This sort of thing is really
bad for cooperation with other projects.
I very much agree here. I've had hard time convincing some upstream that
these minified JS were non-free. Now, if I have to tell them how to
write their unit test, they will just tell me to not run them...
A bit off-on-topic but bare with me.
Lets say some upstreams are paid to work on software that is (by Debian
community) in Debian archive. Also lets assume that majority do it just
for fun or in their free time.
Now I really do believe that majority of our choices are Freedom
respecting and also good technical choices. And we choose to stand by
that with our Social Contract. And this is why are we here, but we can't
take our choices to anyone else by "force".
In this particular case, we have (imho) a good decision to not allow
network access during the build but that is for sound choice for Debian
and maybe not for upstream for whatever reason (lack of time, not fun,
doesn't see it as great decision). So the "pain" of disabling network
access during build must fall on us. We choose it that way. Again, it is
Social Contract. And Debian Policy. And our care for users freedom,
privacy, security. So, my solution to this would be to first politely
talk to our upstream and have a statement (that we all together would
make it as generic letter for outreach to our upstreams) why they
should change tests and if we can help them. Who know, maybe they even
accept. If they don't, we just disable those tests or all tests.
Now, if we are actually considered and like tests (as I think we should)
we should also do something about it. But lets do if for fun, lets make
it fun and now *just* another set of rules that we *must* comply to or
otherwise Mr.Lintian will scream on us and our builds will fail. Can we
have a build machine that will run tests of every single package without
having the rule of "network must be disabled" so we personally see it
passes or fails even without interfering the build process - what
engineering cost would it take to still have it and make it fun for us?
Or some other solution (scripts to fix this issues, scripts to find and
isolate all network tests etc).
Why am I writing all this - it appears to me that we are trying hard to
make it all correct in our world view. And that is awesome. But I also
feel that we are loosing too much energy on this and this is not
sustainable long term, nor fun. We must still do what we do, and we do
it for a good reason but we must transform our way of approaching such
deals that we end up having fun discussions and trying to find
collaborative fun solutions to it. Hackers. We will have hundreds more
of such decisions and discussion and if we don't want to take 10 years
of our lives on this kind of debates that go on and on and we obviously
see cracks appearing all over FLOSS ecosystem - we must transform. We
are enough big to make such decisions and changes, lets just make more
feasible for us all and maybe even upstream will be more happy to follow us.
My 0b10 cents,
zlatan
