Les Mikesell <lesmikesell@xxxxxxxxx> wrote: > Jeff Spaleta wrote: [...] > > 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. That means even more of the bureaucracy that people are so quick to disparage here... > 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. That isn't always obvious to the packager of some piece of infrastructure. Change GCC, the "normal" applications continue compiling fine (or get fixed as part of the update in the distributin), but some strange package somewhere was relying on a GCC bug (or misfeature, or sloppiness) and blows up when you try to build it. Has happened dozens of times to me, and I'm still grateful GCC moves forward and becomes more standards-conforming. > > 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 That is done, albeit imperfectly. It usually gets caught and fixed quickly. > or 3rd > party programs built on the platform you just shipped. That is impossible, and besides the point anyway: Part of the benefit of being part of the distribution is the previous point. [...] > > 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? New upstream versions... go talk to them ;-) > 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. It is fast /because/ it integrates upstream changes as early as possible. Can't have fast advances and no change at the same time. > If some > upstream project can't settle on an interface you are doing your users > a favor by keeping it away from them. OK. Leave out the kernel, ... > > 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 Choose something else and leave us in peace then. > and don't understand why anyone would > develop for something intentionally non-standard. Some people do so even if you don't understand them. That would mean your understanding of what and why people do as they do is flawed, not (necessarily) said developers. [A standard is developed by consensus among people trying various non-standard approaches on what the best way to do something is. This means exploring non-standard approaches (even ones going against said standards at times).] > 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. LSB and similar standards mean aiming at the lowest common denominator. I.e., it might work just fine, but it will certainly waste much of what Fedora (or any other particular distribution) is all about > > 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)? I'm using Fedora rawhide daily. Our labs (several hundred users) are running latest Fedora most of the time (except when the releases fall at awkward times in our terms). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
