Re: Packages which use the BuildRoot: directive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux