Re: PSA: builds using forge macros with tags broken on rawhide

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

 






----- Original Message -----
> From: "Nicolas Mailhot" <nicolas.mailhot@xxxxxxxxxxx>
> To: "Robert-André Mauchin" <nicolas.mailhot@xxxxxxxxxxx>, jcajka@xxxxxxxxxx
> Sent: Monday, October 22, 2018 5:32:55 PM
> Subject: Re: PSA: builds using forge macros with tags broken on rawhide
> 
> Le 2018-10-22 16:52, Nicolas Mailhot a écrit :
> 
> >> -rpm.define("gosetup(a:b:cDn:Tq) %forgesetup %{?**}")
> >> +rpm.define("gosetup %forgesetup")
> > 
> > Rhaa that's an old leftover of the time when Jan pulled a copy of the
> > forge macros in go macro copy, because he thought redhat-rpm-config
> > maintainers would take ages to review stuff. I thought every trace of
> > this had been eradicated long time ago. %gosetup is certainly not part
> > the use pattern documented in the wiki since march.
> 
> Anyway Jan removed every trace of his attempt to internalise the the
> forge macros a week after the commit you point to, *except* for this
> stray line. Don't know if leaving this line was an afterthought, or if
> he didn't want to fix some specs that had been created in the weeks when
> he experimented with the internal forge macro implementation. The thing
> is done now.
> 
> And what this line does is awfully dangerous and brittle. I could not
> put anything like this in redhat-rpm-config, it would be rejected
> directly.
> 
> So, we probably need to spin another go-macros build with a normal
> gosetup declaration not hidden within another macro. And then live
> unhappily afterwards with the messup set in stone. Not exactly the kind
> of thing you want to do in the middle of a sig reorg.
> 
> No chance to remove the problem call from the specs I suppose?

Bringing this back to devel as I don't understand why this discussion should be held in private.

AFAIK unless you are volunteering to fix and rebuild all the affected packages, it is not going away on its own. I don't think that playing the blame game will move us anywhere. It has been there for some time so it got some considerate adoption.

I don't understand why are you not following process for system wide changes for such disruptive change. It seems to me that you are not realizing possible impacts of your changes and are actively downplaying testing(IMO integral part of the development) before pushing it in to the production(rawhide). I perceive this kind of practices as extremely dangerous for sustainability of Fedora packaging. Could we please revert the change(Igor?) and stop pushing it until it is formalized(including docs, so it is outright obvious what is intended as supported) as System Wide Change proposal and approved by FESCO(for F30)?

JC

> 
> --
> Nicolas Mailhot
> 
_______________________________________________
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




[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