Jeff Spaleta wrote:
That's the wrong question. The real question is, what interface did you
just break in an update? You don't need to know anything about anyone else's
software. You just need to provide working interfaces. Or, when you
whimsically break them in updates, give a hint about how to get a working
version back.
Are you suggesting that we should never provide an unstable interface
in any of the libraries or scripting modules that we package?
No, I'm saying that necessary changes should be planned, and to the
extent possible, batched at version releases. And where that isn't
possible, interface and command line changes to expect should be
published before the update so users and 3rd parties know how to work
around the breakage.
And
that we only provide technologies that upstream has committed to API
stability between subsequent releases?
I'd like that very much but given what you have to work with, I'll agree
it is impossible. However, like any other QA aspect, I'm suggesting
that you do the best you can not to break local or 3rd party programs
built on the platform you just shipped.
Surely you aren't suggesting
that. You can't really expect us to hold an API stable when upstream
isn't...that's just silly.
No, what is silly is to actually try to use a platform that you know is
going to break because the people building it have no concern for the
people using it. Even simple things like the change in samba that broke
backuppc's ability to pass windows authentication some time ago can be a
disaster.
At best you could maybe hope for a subset of available technologies to
be identified as upstream interface stable, and get a subset of
maintainers to pledge to keep interfaces stable inside a release
timeframe in conjunction with those upstream projects.
Who forces you to push interface-changing updates out of rawhide? If I
wanted today's bugs from an upstream project I'd grab it from there
instead of using a distribution's release version of the code. The
fedora major release cycle is already fast enough anyway. If some
upstream project can't settle on an interface you are doing your users a
favor by keeping it away from them.
There is no
coherent initiative towards what could be generously termed a 'Fedora
SDK'. I've seen no interest from a group of active
maintainers..ever..to take on that problem space and commit to seeing
it happen. Something like this would require a community member to
step forward and be a strong, active, persuasive leader on the effort.
I'm not sure what that even means. If fedora has something unique, I
don't particularly want it and don't understand why anyone would develop
for something intentionally non-standard. What I'd really want is for
LSB-compliance to someday get to the point where programs running on
Fedora would never need to know that it is fedora at all, much less the
version and last-update-date underneath.
I very much doubt that you are the right person to lead such an
effort, even if you did decide this is the issue that would finally
get you off the fence and working on something constructively. So my
advice to you is, dial back the rhetoric and see if you can get other
people talking about this and identify the person you think can lead
this initiative.
Is there someone involved in development that eats his own dog food
(i.e. uses fedora with current updates as infrastructure for some large
project or even in a lab setting with many users)?
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
