On 1/4/21 12:38 PM, Miro Hrončok wrote: > On 04. 01. 21 12:26, Petr Menšík wrote: >> I had not time to coordinate rebuilt before Christmas, so I left it >> intentionally without build. It was built by Jeff Law one day before I >> departed to vacation. I haven't noticed that. > > As a matter of opinion (i.e. this is not a policy, but my own views), I > think that the state of distgit should always be "good" and any > provenpackager should safely assume that rebuilding any package does not > cause damage. > > If I need to rebuild many packages because of a dependency, I should not > need to explore if the latest commits are "ready". A work in progress > should be left in a pull request. > > Obviously, this does not always work, because sometimes change in > distgit is necessary for a rebuild from a side tag, but in most cases I > think we should avoid both "I've pushed a breaking upgrade but I > haven't built it" or "I've pushed a broken commit and will push more > later" approaches. > > WDYT? > I thought it was ready and there were no scheduled mass rebuild. ldns usually does not even receive bugs for months, let alone need for immediate build change. I even made a mistake and haven't added sources to upgrade. It should have ended with FTBFS bug instead of broken compose. I did that to save version bumping later, just to have it backed up somewhere. I admit I don't do MR to myself often, thought it was not necessary. I did not expect anyone would have need to touch it for a few weeks. No one touched it whole year and I relied on that. Is there tooling to help with rebases of changelog conflicts? If leave it in my branch and someone bumps the spec, can I make just git rebase equivalent without manual conflict solving? Some git commit message tag or something similar to help make bumps on merge? It is a little of work, but annoying. Is there existing automation for it? Makes MR outdated on any spec change and not too usable. -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@xxxxxxxxxx PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
Attachment:
OpenPGP_signature
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
