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@xxxxxxxxxxxxxxxxx> wrote: >> >> 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. > > > 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. > 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. 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. 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/HNFEBIEV3YREJZIFEOOQBRCV6Y5XPK7F/
