On 25. 01. 21 19:32, Robbie Harwood wrote:
Miro Hrončok <mhroncok@xxxxxxxxxx> writes:
Before I try to word it more carefully I'd like to hear some feedback
on this. What do you think?
I'm struggling to understand what you think this will accomplish.
I want packagers to have a documented "dos and don'ts" of what is considered the
best practice. Similarly to the updates policy, there will be people who
outright ignore it and do whatever they think is best anyway and no amount of
policy will change that. I realize that. But once I ask a maintainer: "Could you
please not do this?" And they ask: "Why?" I can reply with a link to a respected
source instead of trying to explain (again and again).
Leaving aside ideological disagreement about the nature of rawhide (I
don't think rawhide should be expected to be in perfect working
order[1]), this won't prevent the problem of incomplete changes landing
in dist-git. All it will do is give people an excuse to yell more at
the unfortunate maintainer who ran the wrong push command. The wrath of
the heavens already descends on people who break rawhide; we don't need
even more.
I don't think this will add more wrath. I think this will help to change the
"you broke my thing" argument to "this is not what we do in Fedora". I (maybe
naively) think that people who care will read the policy when they are not sure
what to do or even when they actually accidentally run the wrong push command
(the policy should strive to give guidance on what to do in that case as well).
I believe that "in the future, please don't do this, see the XYZ policy about
how we do things" sends a more friendlier message than "in the future, please
don't do this, I've just spent 2 hours debugging problems you've introduced". I
believe a good policy can help making things less emotional.
It seems to me that this problem would be better solved by making
rebuilds smarter. Instead of building tip of dist-git (which might
never have been build), rebuild the last thing that *was* successfully
built. There are a number of ways to potentially track this
information[2].
Koschei already does that (and hence IMHO makes the problem worse, becasue it
happily reports the package "green" while the git tip fails outright in %prep).
Let's say I approach a package I need to bump and rebuild and the latest
successful build is 5 commits old. What do I do? Do I revert the 5 commits and
push a release bump on top? Or do I branch from the latest working state and
push a tagged commit to build it creating a new git history for what was built
(different to what was pushed by the maintainer)?
--
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
