On Fri, 12 Mar 2010 18:59:30 +0000 Andy Green <andy@xxxxxxxxxxx> wrote: > On 03/12/10 18:06, Somebody in the thread at some point said: > > >>> In this context, if you're writing homegrown apps, you're a > >>> "developer", not a "user", so the above sentence obviously does > >>> not apply. Instead, my original point does (you'll be compiling > >>> your own software very often anyway). > >> > >> It's a bit of a false dichotomy because I may be developing my > >> stuff and using someone else's, but I take your point. > > > > You can call it a straw man, no problem calling things as they are. > > > > I love people quoting other people slightly out of context and > > putting their spin on it to make a point ... > > My dear Simo your IFF is malfunctioning. "I take your point" is me > agreeing that I took his words out of context when I went back and > read what he clearly quoted. Having understood his larger point, I > don't think splitting people into "developers" and "users" is a > worthwhile distinction because all developers are users of something > else. I think we misunderstood each other on how we are referring to what. Given the matter is completely knotted I give up commenting and preemptively apologize to anyone that feel I said something wrong or wrongly attributed something. > At the company I am working for this whole subject has been a matter > of great debate these last days about the best way to update our own > stable packages for our own repo on top of a Fedora basis, by focus > on backport or elevating our equivalent of rawhide into stable after > thorough testing. In general I think that point releases are a mean to provide users with something usable somewhat consistent and that doesn't change too much, so they can stick with it. The others can adventure into rawhide. If everything turns into rawhide why are we even doing point releases at all ? Just have rawhide and push to ""stable"" stuff once enough karma accumulates and have a constantly rolling release with no numbers or anything. Needless to say I don't think a constantly rolling release helps our users. Even developers need to have something that doesn't move too much under your feet. Developers are users too and need a distro they can use for most of their tasks or the will move and develop elsewhere. Although *some* developers need bleeding edge, they are normally a minority, and they don't need bleeding edge everything, they can easily pick from testing or rawhide what they need, or just rebuild from sprm themselves. > AFAICS the best way through it is a mixture depending on the exact > situation of each package and the divergence in the sources and libs. > If a fix we would like to have in stable is dependent on new APIs in > uplevelled libs, backporting becomes Hell given the need to retain > the old APIs for packages that don't get updated while integrating > new ones for the fix. I agree with you. It is not a clear cut ban this, approve that. But it is more a matter of tendency. The unstable repositories should tend to upgrade often, the released stable repos shouldn't and sometimes you have to just let a bug there and tell people to use the newer release rather than breaking more stuff in a "stable" release to cram in an update to fix a minor bug. Security releases are more delicate and if necessary exceptions can be made there, that's where rel-eng comes in. > It pushes me towards thinking a solution by bringing in the new libs > and accepting the damage in terms of uplevelling and retesting the > users of the library can often be the right way. And that seems to > be Kevin's POV which is why I was surprised to misread what I misread. I am not sure what's Kevin POV anymore, probably he has some sort of view of what is the target user base and which packages should be fast movers, but I can't make it up from his emails anymore. If the position is that the status quo is fine, I have to disagree, we have way too many updates in F-12, so from my POV something should change to slow down the pace a bit. Whether that should be only done for CRITPATH first and exclude some category of software that is not installed by default I don't know; we can discuss that. But the current status is not good IMO. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
