On 6/10/19 3:00 PM, Kevin Kofler wrote: > Martin Kolman wrote: >> But even for package development and integration you need something that >> works at least a bit. If you won't get a compose for a few weeks due to >> the constant breakage you won't get much work done on landing your latest >> library rebase or integrating a new package. > > In the past, the compose would not fail just because a release-blocking > deliverable failed to compose, the package compose would just ship without > the deliverables that failed to compose. That's what needs to happen again. With the 'no more alphas' change, we strive to make rawhide always alpha quality at least. This means all the release blocking deliverables are there and working. > There is no technical reason why an error composing a live ISO prevents the > changed RPMs from going out. Rawhide is not a release, there should be time > until the actual release to fix the release-blocking deliverable. But the problem is there is not time. If you don't fix things as soon as they happen, more pile up behind it making it harder and harder to fix. > And ideally, we would keep the last successful compose of each deliverable > on the mirrors, no matter whether it matches the current package compose or > not. (We did not do that in the past, the ISO was just missing when the > latest version failed to compose, which is suboptimal.) > > We need to stop having unreasonable expectations about Rawhide's quality, > and ISOs always composing successfully is one such unreasonable expectation. I disagree. I think we need gating to block as much stuff that breaks things from landing as we can and then we should find that keeping composes going is much easier on all of us. Then things can be fixed when gating catches them and it's on the person who broke things. kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
