On Wed, 2018-07-11 at 12:16 -0400, Josh Boyer wrote:
On Wed, Jul 11, 2018 at 11:58 AM Igor Gnatenko
> On Wed, Jul 11, 2018 at 5:02 PM Josh Boyer <jwboyer(a)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
> > > > > > > > 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
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
> > > we
> > > certainly shouldn't get rid of a "be nice to each other"
> > > 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
Because nobody is communicating with upstream and fixing it
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
> 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.