Summary/Minutes from today's FESCo Meeting (2015-10-07)
Bastien Nocera
bnocera at redhat.com
Tue Oct 13 09:41:28 UTC 2015
----- Original Message -----
> Bastien Nocera wrote:
> > 2 distributions add slightly different versions of the same functionality
> > -> incompatible
>
> I said that carrying more feature patches makes it "more likely" that
> packages from other distros will work, not "100% certain" (which is
> obviously not possible when there are incompatible versions of the same
> patchset floating around).
>
> > Application compiled on Fedora using the new features -> doesn't work on
> > other distribution
>
> And that's not a problem for OUR users, only for those of the other
> distribution. So why would that be ours to worry about?
That's a problem for OUR users because when they use Fedora, they want to be
able to make a tarball of their software for their friend on Ubuntu to test.
Here, you're making Fedora a bad choice for developers that want to target
more than just Fedora.
> > Your advice would be making Fedora a _worse_ distribution for third-party
> > developers, and you equate those third-party developers to developers of
> > proprietary applications.
>
> GCC supports __attribute__((deprecated("message"))) these days. So we can
> tag the added functions with something like:
> __attribute__((deprecated("nonstandard function added by a non-upstream
> patch to make FooApp work, use in other applications strongly
> discouraged")))
>
> If the developers opt to use those functions anyway, then that's not our
> problem.
This isn't made to tag symbols that aren't upstream, and the end-user application
will just barf out with unresolved symbols when you try to run it, which is
far from useful.
> > Not all Free Software is easy to compile from source, not all Free
> > Software is packaged in Fedora. Forcing users to become packagers before
> > they can use a third-party software is detrimental to Fedora's success.
>
> I don't really agree, at least not fully. I think packaging software
> properly is a much more effective way to spend our time than making third-
> party blobs work as is, especially WHEN those binaries are actually Free
> Software and can thus be packaged properly from source.
Should I send you emails every time a software I want to use isn't packaged?
Because that's what it sounds like you want me to do :)
> Sure, the USERS
> should not have to become packagers, but the existing packagers should not
> waste their time on compatibility with binary blobs, but spend it usefully
> on packaging Free Software from source.
I'll ask something, in earnest: have you ever written and shipped non-trivial software on Linux?
Because I don't think you would give those advices if you had.
More information about the devel
mailing list