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: "Jakub Cajka" <jcajka@xxxxxxxxxx>
> Cc: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx>
> Sent: Monday, October 22, 2018 1:55:02 PM
> Subject: Re: PSA: builds using forge macros with tags broken on rawhide
> 
> Le 2018-10-22 13:09, Jakub Cajka a écrit :
> 
> > I think that it would be reasonable to test the changes against the
> > Fedora package base before even pushing the change in to the rawhide.
> > This kind of unnecessary breakage is easily avoidable if you would
> > spent sometime on testing this by scratch rebuilding the Fedora
> > packages locally, prior pushing this.
> 
> There's certainly many things that could be done better if someone took
> the time to do it. But, everyone's time is limited including mine. I
> already rebuild hundreds of Go packages regularly to QA the changes. It
> takes days. Those 40 packages were not part of the set.

In my experience this doesn't require that much time as this is fully scriptable from getting all the dependent(Go based packages) and rebuilding them locally(even using something dumb as mockchain, it takes under 1 day to complete for Go, without needing any babysitting(in VM on i7/ssd laptop)). One day(of computation power) seems like reasonable trade-off for not wasting time of significant number of (Go) packagers by breaking macros. Or AFAIK it should be possible to do such change in the koji side tag(ideally with formal change proposal) not affecting the main tag.

> 
> So, if we want more things to be done with the existing manpower, we
> need to fix all the thousands of little things that waste the available
> contributor time:
>   * rehost things cleanly on pagure
>   * clean up the maze of repurposed Go infra specs so any change or fix
> can be QAed and pushed quickly
>   * contribute the fixes we want or need to the Fedora packages that ship
> the corresponding code, instead of 'saving' time by doing messy
> ill-thought workarounds in a private spec file generator

I'm sure that we all want to advance Fedora, but could you be more specific? What needs to be done in your opinion? Would you mind opening issues in Go SIG for those specific changes(or better PRs in respective packages)?

JC

> 
> And then when things are clearly in one place this place can be used to
> sync the reviews, QA runs and Koji/copr mass rebuilds. Which is clearly
> not the case today.
> 
> Call that purism if you like
> 
> --
> 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