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