On Wed, Jul 11, 2018 at 5:02 PM Josh Boyer <jwboyer@fedoraproject.org> wrote:
On Wed, Jul 11, 2018 at 10:40 AM Jason L Tibbitts III <tibbs@math.uh.edu> wrote:
>
> >>>>> "JB" == Josh Boyer <jwboyer@fedoraproject.org> 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
maintain their specs wherever they want, but they should be prepared that
Fedora will change their specs and they should not overwrite such changes.
 
> 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".

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.
--

-Igor Gnatenko