Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux