On 04. 01. 21 13:14, Petr Menšík wrote:
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.
To be clear, I'm not trying to reprimand you, but rather to try to establish
some consensus of what's "good" and what's not. This is just one case of many
that reminded me to discuss this. No need to discuss this particular case
specifically.
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.
Give this (experimental) merge driver a try:
https://github.com/encukou/rpm-spec-merge-driver/
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
