On Wed, 2017-10-11 at 15:42 -0400, Stephen John Smoogen wrote: > On 11 October 2017 at 15:08, Martin Stransky <stransky@xxxxxxxxxx> wrote: > > On 10/11/2017 07:26 PM, Gerald B. Cox wrote: > > > > > > On Wed, Oct 11, 2017 at 10:04 AM, Heiko Adams <ml@xxxxxxxxxxxxxx> wrote: > > > > > > > Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox: > > > > > > > > By definition BETA software is never intended to be pushed to stable. Fx > > > > 57 is BETA. When the STABLE version is released, then it can go into > > > > updates-testing. Not before. Again, that is the purpose of RAWHIDE. > > > > > > > > Does this mean it's also not allowed to push packaged git-snapshots of a > > > > software to updates-testing because they are unreleased and potentially > > > > unstable? > > > > > > > > > > As Adam mentioned apparently this isn't the "Official Policy". > > > > > > My opinion however is common sense dictates that you don't put anything in > > > updates-testing unless you intend to push that software to stable. If you > > > want people to test out experimental software, put it in RAWHIDE. If it's > > > a git-snapshot and your INTENT is to push it to stable (for example, > > > you're > > > fixing a bug) then that is OK for updates-testing. > > > > > > In this instance, there is no intent to push Fx 57 BETA to stable. That's > > > why it does't belong in update-testing. > > > > > > I think there's a bit misunderstanding here. Some parts of the FF57 update > > are going to be in stable as is (if the testing goes well). That includes > > the CSD patch [1]. > > > > There are several misunderstandings here but they all stem from a core > problem which an old Mozilla quote covers: > > Surprise is the opposite of engagement. [1] > > It is something we forget a lot.. but is a reason why older > maintainers of XYZ software (Mozilla, X11, gcc, kernel, etc) would > make sure that a heads up email about a major version change goes out. > > If you put out a heads up that "tomorrow I will be pushing Firefox > 57BETA into updates-testing" you could have given people heads up and > would have also learned from someone that updates-testing is on for > everyone in the post-branch world. While in this case it probably > would not have affected your decision, in other cases it might have > made it clearer that you needed to do so after a different time. It > would have also queued in people to either skip updates or know why > their workflow died. > > In either case, people would be better informed. Agreed. It is true that in general people using updates-testing should more or less know what they're doing, but they're not necessarily expecting surprises like this. And as smooge says, updates-testing is enabled by default in Branched releases (so, F27 at present); anyone running F27 Beta will get this package as soon as it reaches the mirrors. I think Harald really has a point that the potentially disruptive nature of the changes in 57 should mean that, if anything, we go *slower* in pushing it out to our users, not *faster*. Unless it includes vital security fixes we can't backport, I don't think there's necessarily a reason we need to jump all over this and try to get it out on release day; why not wait a bit while providing a way for early adopters to try it out if they'd like to? Note that there is an alternative to both u-t and COPR; you can do scratch builds in Koji, or do real builds but don't actually submit them to updates-testing , and either provide a repo with those builds yourself, or just write a blog post or something explaining which packages people should pull from Koji if they want to test... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
