and while users of updates-testing get punished on F26 with a unwanted because way too early FF57 update important security updates (as often in the past for FF and TB) like in the meantime even by CentOS announced Thunderbird 52.4 (https://koji.fedoraproject.org/koji/buildinfo?buildID=979918 built 8 days) is noteven in updates-testing at all and needs to be downloaded from koji - the persons responsible for mozilla packages at the moment are doing everything wrong they can

and while users of updates-testing get punished on F26 with a unwanted because way too early FF57 update important security updates ...

I want to clarify here... this wasn't a update. By definition an update is something that is intended to be pushed to stable. This wasn't the case in this instance. The maintainer decided he wanted to do some early testing on software and therefore threw it into the updates-testing process. That is the problem. People who participate in the updates-testing process are expecting to be testing updates - not to be testing something which by the maintainers own admission isn't intended to be pushed to stable. That is the purpose of RAWHIDE.

I believe that the pushing of firefox to updates-testing that was intended to never be pushed stable goes against the intent of updates-testing, the updates- in the name is because that is where the update is intended to go. I also believe it is appropriate for the maintainer to do the build in koji and ask on devel@ and test@ for people to test and provide feedback. Maybe we want to investigate having a experimental stream for testing new things that may or may not come, however I believe it has been years since something like this has come up. we would want to investigate how much it would be used to determine if it is worth doing.

I will add that I believe that the firefox maintainer had good intentions in doing what was done, and perhaps it should have just been communicated better.

I will add that I believe that the firefox maintainer had good intentions in doing what was done, and perhaps it should have just been communicated better.

I also believe that the maintainer had good intentions, and I stated as such in bugzilla ticket that was opened for this and referenced in the devel discussion. That said, as I mentioned above, it just isn't good policy to misuse the updates-testing process in this manner and doing so just opens up a can of worms.

How does "I'm surprised that people use updates-testing for stable/production machines, have problem with handling the update and act like newbies. If you can't handle that, don't use that. Fedora is really a bleeding edge so don't complain you get new software with new features - even as testing only" sound like good intentions as repsonse to updates-testing users which want to continue give karma for packages intended pushed to stable and dislike type "--exclude=firefox" for a whole month?

I am inclined to agree that updates-testing should not be used for builds that are not intended to be released into stable. As pointed out, we already have two other systems that are appropriate for this: copr and Rawhide.

For what it's worth, I agree with what seems to be the general sentiment here. If the problem is that Copr or Rawhide don't provide enough feedback, we should work on that separately. We don't want Fedora to be bleeding edge — the intention is to delicately balance in the space of "leading edge".

Also in our no-more-alphas glorious future (which is to say, now), Rawhide should as much as possible follow this same general rule, because at any point, it should be at what was previously considered alpha quality. Packages not meant to hit stable shouldn't be going there either (at least not without some very careful planning and discussion in special cases).

FESCo Meeting 2017-10-13

jforbes will create a Policy change proposal to be voted on next week

I think the following should be added to the https://fedoraproject.org/wiki/Updates_Policy page.

Bodhi use:
Bodhi is meant as the method for getting updates into an existing release or pre-release. It does provide a testing mechanism to make sure that nothing unforeseen will arise, but the expectation is that packages submitted are likely ready to ship as an update. As such, any packages submitted to bodhi must be done with the intent that the package submitted is ready for general consumption. The users kind enough to test these packages have come to expect this, and doing anything else moves against their good will, and is likely to drive testers away. Bodhi and updates-testing are not a place for experimentation or advanced notification of potentially disruptive updates. These should be handled with packages in copr or another public repository with a message to call for testing on the appropriate mailing lists.

@jforbes LGTM. +1

As this was agreed to in the meeting on 2017-10-20, the page has been updated. Closing the issue.