On Wed, 2018-07-11 at 12:16 -0400, Josh Boyer wrote: > On Wed, Jul 11, 2018 at 11:58 AM Igor Gnatenko > <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote: > > > > On Wed, Jul 11, 2018 at 5:02 PM Josh Boyer <jwboyer@fedoraproject.o > > rg> wrote: > > > > > > On Wed, Jul 11, 2018 at 10:40 AM Jason L Tibbitts III <tibbs@math > > > .uh.edu> 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. > > > > > > I will disagree with this (and I also think there was an FPC ticket > > about this). > > Do you expect automated tooling to go to upstream and file PRs? > > People can > > I'd expect automated tooling to skip such packages based on a keyword > or control file in dist-git. > > > maintain their specs wherever they want, but they should be > > prepared that > > Fedora will change their specs and they should not overwrite such > > changes. > > I said that as well. What you're missing is the part where people > tell the actual maintainers something changed. > > > > > 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*. > > > > > > It's not only changelogs, people keep re-adding BuildRoot and > > %clean section. > > People keep overriding changes we've done in Fedora when they > > import from > > "upstream". > > Because nobody is communicating with upstream and fixing it > there. In > some cases it'll be met with a shrug (like changelogs). In many, it > might actually result in upstream making a similar fix. Isn't tooling in our dist-git commit hooks or push hooks that simply reject commits that remove changelogs or re-add unwanted sections the way to go here ? > > Fedora dist-git is canonical location for spec files. They are > > supposed to build > > in Fedora buildsystem and work there. No one is going to understand > > whole > > spec file just to make some fix in Fedora. Fullstop here. > > This is a human problem that the existing tools and guidelines aren't > going to solve. But tools can solve, for example they can lint spec files in git hooks and reject pushes that break lint. > So we can either adjust the tools and guidelines to > actually be helpful to humans, or we can continue to stare at our > navels and pretend having these things written down is going to fix > the issues you're highlighting. I'd rather have a compromise that > works on collaboration. In reality, I expect nothing to change here > and we'll have this conversation again down the road. Well said. Simo. _______________________________________________ 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/G4UEJBTXPKFQKTNYZUWMMUGE6OZA267C/
