On Wed, Jul 11, 2018 at 10:40 AM Jason L Tibbitts III <tibbs@xxxxxxxxxxx> wrote: > > >>>>> "JB" == Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> writes: > > JB> That's impossible to enforce and unrealistic. > > I will go as far as "it's somewhat difficult to enforce and idealistic", > but no further. > > JB> We can say that as much as we'd like, but there is nothing we can do > JB> to prevent people from syncing from elsewhere. > > There are lots of things we can't completely prevent, but that doesn't > mean we shouldn't have rules against them. OK. I'll go further and say it's actively antagonistic to people that want to maintain spec files in a common location across a variety of distributions. It seems more reasonable to have a guideline that requires people to put a comment in the spec file if it is maintained outside of Fedora and point to the proper location to file issues against. That doesn't prevent people in the Fedora project from making changes in dist-git and it'd certainly be way more helpful in the long run to get the issue corrected upstream so we don't keep having the same import issues over and over. > JB> Having it in the guidelines seems to give a false sense of security. > > I don't understand how a guideline would ever give any "sense of > security". What would you expect a guideline to secure against? > They say what you are and aren't supposed to do, and not much more. Yet people are surprised when they aren't followed, which is what I meant by a false sense of security. "The guidelines say this so it must be true!", yet the guideline is unrealistic. > It's not much different than a code of conduct. If there's anything > that's "impossible to enforce and unrealistic", it's that. But we > certainly shouldn't get rid of a "be nice to each other" rule just > because such a rule would give someone a false sense of security that > they can post to a mailing list without getting nasty emails (as recent > threads on the subject of specfile cleanups have shown). Heh, that's fair. I think the analogy conflates two very different things though. CoC is for human behavior norms, which are wide and varied. Packaging guidelines tend to be more concrete, focused around technology and less open to interpretation. They say "guidelines" but if they aren't followed people treat them as rules and require exceptions and exclusions. > And certainly we can work to enforce this particular rule. It's not > hard to watch for commits which delete, say, the mass rebuild changelog > entries or reintroduce one of these recently removed tags and then alert > someone when necessary. That work is already in progress. It's would > technically be even easier to do that check in a git hook and simply > refuse to accept the push, if we really wanted to go that far. I know you said this for argumentation's sake, but you're just proving my two points above. All of that makes participating in Fedora harder, for little benefit outside of sticking to a guideline that doesn't make sense. You and I are going to likely disagree on this point, and that's OK. And I think the mass rebuild changelogs are unnecessary and convey no valuable information, so *shrug*. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/OB25UC6RUBON3CN7QMV3U7GHB4QHQUHU/