On Wed, Oct 11, 2017 at 12:52:11PM -0700, Adam Williamson wrote: > 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. OTOH, let's consider two points: one, FF57 is disruptive, and two, FF57 will be released as an update in Fedora when Mozilla make the release, as specified by our policy for FF updates. In the light of this, it seems reasonable to push FF57 to updates-testing right now, the sooner the better. I don't get the whole kerfuffle about FF57 being beta: F27 is in beta now too, and it's the time to test what will be in the relased version, and using a pre-release of a package seems to be a better way to do this than using some old version that will be soon replaced. If we had a different updates policy for Firefox in Fedora, things would be different, but we don't. Zbyszek > 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
