Re: Deciding on Fedora Go (Golang) packaging future

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

 






----- Original Message -----
> From: "Robert-André Mauchin" <zebob.m@xxxxxxxxx>
> To: golang@xxxxxxxxxxxxxxxxxxxxxxx
> Sent: Sunday, March 17, 2019 3:36:47 PM
> Subject: Re: Deciding on Fedora Go (Golang) packaging future
> 
> On dimanche 17 mars 2019 09:29:28 CET Nicolas Mailhot wrote:
> > Le dimanche 17 mars 2019 à 03:31 +0100, Robert-André Mauchin a écrit :
> > Hi,
> > 
> > > 
> > > Numerous Golang packages are plagued with an issue caused when
> > > jchaloup uploaded Glide files. In a lot of case he has doubled the
> > > glide.yaml instead of adding the qlide.lock:
> > > 
> > > Source1:        glide.yaml
> > > Source2:        glide.yaml
> > > 
> > > The problem is that when goinstall doesn't find the glide.lock file:
> > > 
> > > 
> > >  %goinstall glide.lock glide.yaml
> > 
> > 
> > The fix to avoid creating things that do not exist just because the
> > packager specified them explicitly in its spec has been written for a
> > month¹:
> > https://pagure.io/go-rpm-macros/c/73222d467d9e95e9281a6c37d4b5808b118bde9b
> > 
> > Like all the fixes that accumulated in golist and in go macros for a
> > year, it is waiting for the Go SIG to decide what it wants to do with
> > its packaging tooling. Waiting for jchaloup to change things on his own
> > authority without asking anyone does not work anymore².
> > 
> > ***********************************************************************
> > It would be really nice if a sufficient number of Fedora Go packagers
> > attended the next SIG meeting so we have the quorum to decide what to
> > do, find volunteers to do the necessary work, and mandate them to do
> > this work.
> > ***********************************************************************
> > 
> > The  next meeting is scheduled in three days on 2019-03-20 from
> > 16:00:00 to 17:00:00 UTC at fedora-golang@xxxxxxxxxxxxxxxx
> > 
> > Of course some packagers are more equal than others, so whatever the
> > quorum I can't imagine anything going forward without the approval and
> > support of the Fedora golang maintainer.
> > 
> > Right now we have one proposal on the table:
> > https://pagure.io/GoSIG/go-sig/issue/20
> > 
> > People are free to write up their own alternative, either a variation
> > on this plan or something else entirely. Remember, any plan is
> > worthless if no one volonteers to implement it. So "someone (else)
> > should do things" and no one wants to do it won't take us anywhere.
> > 
> > The key weakness of my plan is that it only considers short-term
> > existing problems, upstream has stated it will switch on Go modules by
> > default in August, and that will change Go packaging a lot. My
> > preference would be to fix what we have before engaging in a Go module
> > journey, but an alternative would be keep things as they are (bugs
> > included) and just dump the existing packaging code to replace it with
> > *something else* at Go module time (big bang approach).
> > 
> > However, if the *something else* is written by me, it is likely to
> > require pretty much the same tooling setup and spec syntax as proposed
> > in my plan (replacing golist with something module-oriented).
> > 
> > Regards,
> > 
> > 
> > ¹ Of course it will not fix the consequences of past errors, just
> > prevent new ones
> > 
> > ² And, jchaloup had facilities others do not have (working @rh, trusted
> > by the Fedora golang maintainer, owning many key packages).
> > 
> > --
> > Nicolas Mailhot
> 
> 
> The issue seems to hinge or writing new Go guidelines for the new macros, he
> example SPECs could be a part of that but not the only source.

Precisely, that is my main issue. Whenever I have brought this up with Nicolas, I have been told that he is not going to do such a thing as it is useless and it will require significant effort. I can agree only with the latter. As long there is no (draft of) policy and user/packager facing documentation and Nicolas is effectively only person that understands how the new macros work and he doesn't want to share this knowledge with wide public. I can't endorse them in anyway and I will dare to say they are not fit for Fedora in anyway until this crucial part is added.

And as Nicolas is pointing out he will probably have to take ownership of all the dependencies of his macros. Golist exist based on Nicolas's initial requests and requirements(created based on them by jchaloupka in his free time over one year ago), if they have shifted he will probably need to change/implement the tools that he needs as unfortunately Jan doesn't have free time that he could dedicate to Fedora anymore(or at least it seems so).

Lastly I believe that this official change of macros will require official "System wide change proposal" filed as it affects literally every Go package in Fedora, regardless if it will get SIG's(or anyone's) endorsement.

Looking forward to see you all on the next SIG meeting.

JC

PS: CC'ed also Fedora's devel as the initial post did

> 
> _______________________________________________
> golang mailing list -- golang@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to golang-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/golang@xxxxxxxxxxxxxxxxxxxxxxx
> 
_______________________________________________
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