On Mon, 2009-10-12 at 13:26 -0500, Mike McGrath wrote: > Once it's in rawhide, it'll end up in F12 no matter what we do. Even if > it was a mistake. That's not true. A rollback + epoch can be done in cases where it is deemed the "going backwards" will cause less harm than "trudging forward". > That's a separate issue from doing major updates in > F-11. Perhaps this whole need / niche market (wanting a stable desktop + > a couple of selected updates from my suggested experimental repo) will > disappear when rawhide isn't so messy. > > But if I am concerned about quality, and if doing weird mashup repos that > provide stable software for all and less stable software for those that > want it isn't going to help. What is? If you're concerned about quality, we need to shift the desires of packagers away from always having the latest software and into a more conservative approach to our packaging, avoiding picking up beta releases of software, or betas that aren't expected to go "final" before we ship which ever distro we're working on at the time. Adding more repos for people to potentially push things, and more buildroot confusion makes it /harder/ to test things, not easier. > > > > > > > Additionally stuff "working" in testing and being pushed to stable is the > > > problem. The firefox example is a good example of this as is the > > > thunderbird update mentioned on fedora-devel. Thunderbird should never > > > have been pushed to F-11 under this proposal. The new thunderbird would > > > be released and updated in the experimental repo. The old thunderbird > > > would continue to get updates in F-11 proper. > > > > This makes a big set of assumptions. A) the developer had foresight > > enough to see late changing highly disruptive UI changes in the future > > for the build. B) The beta period for thunderbird would last beyond the > > development period for Fedora 11. C) the developer had foresight enough > > to see that the older thunderbird code would remain usable and keep > > getting bug fixes. None of these is terribly good assumptions to make. > > > > But had we made them, it's possible the broken Firefox and newer > thunderbird wouldn't be in F-11 right now and it would have provided a > better experience for our users. There are certainly problems with my > proposal but I've not seen any alternatives. Even if this suggestion > wouldn't have done it, what would have? We have no way to fix mistakes we > make. If we had them, what's to stop the maintainer from getting good feedback on the experimental repo, and pushing it along to the stable repo, given that it's the only upstream code getting work? > > > In the particular thunderbird case, I think this whole mess would have > > been avoided if the maintainer had simply patched the F11 build to > > retain the previous UI defaults, while enabling the choice for > > interested people to experiment with the new options. The F12 (or F13 > > build by now) build would enable the new UI by default to match > > upstream. I really don't think we need to create a ton of extra repos > > and logistics issues to avoid a maintainer having to think a little bit > > about what it is they're updating and how it will effect users. > > > > In this particular thunderbird case and in all packages we have no > procedure in place to determine what might be right, what might be wrong > and how to fix mistakes. I think there's a strong argument that > thunderbird should not have been updated in F-11. But we can't fault the > packager because they were likely doing what they thought was best. They > had no direction on whether to update it or not. And no options to bring > an updated thunderbird to F-11 while leaving the old one alone. https://fedoraproject.org/wiki/Package_update_guidelines if followed, would have gone a long way to prevent the thunderbird situation. This is a people/policy issue, not a technical issue. In my opinion, thunderbird /should/ have been updated, however it should have been modified to retain the old UI style, as opposed to forcing the new UI on all existing users. You can most certainly bring a new thunderbird to updates-testing, and just leave it there. Those who want it can get it there. Trying to keep both a new thunderbird up to sync as well as continue to do bugfix releases on the "old" thunderbird runs into a lot of problems though, starting at the source control level. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
