Golang SIG primary goals?

[Robert-André Mauchin]

Hey guys and gals,

Can we start to discuss this SIG goals? What each of you are expecting?
A few ideas:

 - Making https://fedoraproject.org/wiki/More_Go_packaging official and 
working on bringing them to EPEL7

 - Assigning current Go packages to the SIG so each member of the SIG can work 
on them, similar to https://src.fedoraproject.org/group/rust-sig
Many Google packages are inter-dependent, this would ease synchronising them.

 - Working toward packaging more: I'm thinking about unbundling kubernetes and 
docker.

 - Developing tools to maintain up-to-date our current set of Go packages, 
some of which are left outdated since their creation.

Any other ideas? I'd like to move forward as soon as possible.

Best regards,

Robert-André

[Ricardo Martinelli Oliveira]

Hi Robert,

Maybe a document with Go packaging guidelines would be very helpful.
Also, it would be good document and maintain gofed as part of the go
packager toolkit.

I don't know if they are all already part of golang-SIG, but I'm in to
help improving the wiki pages.

On Fri, Aug 24, 2018 at 12:59 PM Robert-André Mauchin <zebob.m(a)gmail.com&gt; wrote:
>
> Hey guys and gals,
>
> Can we start to discuss this SIG goals? What each of you are expecting?
> A few ideas:
>
>  - Making https://fedoraproject.org/wiki/More_Go_packaging official and
> working on bringing them to EPEL7
>
>  - Assigning current Go packages to the SIG so each member of the SIG can work
> on them, similar to https://src.fedoraproject.org/group/rust-sig
> Many Google packages are inter-dependent, this would ease synchronising them.
>
>  - Working toward packaging more: I'm thinking about unbundling kubernetes and
> docker.
>
>  - Developing tools to maintain up-to-date our current set of Go packages,
> some of which are left outdated since their creation.
>
> Any other ideas? I'd like to move forward as soon as possible.
>
> Best regards,
>
> Robert-André
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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/[e-mail].o...

[Jakub Cajka]

----- Original Message -----
>  From: "Robert-André Mauchin" <zebob.m(a)gmail.com&gt;
>  To: golang(a)lists.fedoraproject.org, devel(a)lists.fedoraproject.org
>  Sent: Friday, August 24, 2018 4:42:03 PM
>  Subject: Golang SIG primary goals?
>  
>  Hey guys and gals,
>  
>  Can we start to discuss this SIG goals? What each of you are expecting 
IMO meeting would be best so we can introduce ourselves. See my other email :)

I have taken liberty and have created pagure group https://pagure.io/group/GoSIG for the
SIG and tracking project https://pagure.io/GoSIG/go-sig for all the ideas and work. I have
added all folks listed in the wiki page to the group. Also there is issue for adding new
members(or those that I have forgotten to add) https://pagure.io/GoSIG/go-sig/issue/1.

>  A few ideas:
>  
>   - Making https://fedoraproject.org/wiki/More_Go_packaging official and
>  working on bringing them to EPEL7 
Don't forget about EPEL6, too. ;)

I have created issue for the guidelines at the tracker. Along with some other that popped
on my mind.

>  
>   - Assigning current Go packages to the SIG so each member of the SIG can
>   work
>  on them, similar to https://src.fedoraproject.org/group/rust-sig
>  Many Google packages are inter-dependent, this would ease synchronising them.
>  
>   - Working toward packaging more: I'm thinking about unbundling kubernetes
>   and
>  docker.
>  
>   - Developing tools to maintain up-to-date our current set of Go packages,
>  some of which are left outdated since their creation.
>  
>  Any other ideas? I'd like to move forward as soon as possible. 
Would you please create tracking issues(https://pagure.io/GoSIG/go-sig/new_issue) for the
above ideas(or any other you might have) in the pagure project so we can discuss it there
with better tracking/threading?

JC

> 
> Best regards,
> 
> Robert-André
> 
> _______________________________________________
> golang mailing list -- golang(a)lists.fedoraproject.org
> To unsubscribe send an email to golang-leave(a)lists.fedoraproject.org
> 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/[e-mail]....
>

[Nicolas Mailhot]

Hi,

Just to get people thinking before the meet…

IMHO, the core objective of the SIG should be to maintain a consistent 
self-hosting up-to-date baseline of Go software in rpm form, that can 
then be used to build other forms of Fedora deliverables (flatpacks, 
coreos images, etc)

That implies:
— continuing to improve the go/rpm plumbing
   (packager time should be spent on fixing project-specific problems, 
not writing lots of generic automatable declarations)
– getting one form of Go packaging guidelines approved by FPC
– producing a package set that conforms to the above
– refreshing periodically the set (at least one mass rebuild/version 
refresh per Fedora release).
– reporting upstream everything that fails in the set to raise the bar 
on the bits we package, gain legitimacy and provide value to upstream – 
ideally also work on fixes but just identifying and reporting problems 
regularly would be a huge first step
– scrapping all the Fedora Go packages that do not comply. Not a fan of 
zero defect approaches but there is a point where keeping lots of 
obsolete/non conformant packages discourages old and new packagers alike

I don't really see the point of producing another set of 
bundled/containerized/imaged Go software, there are lots of them on the 
market, the drawbacks are increasingly well known (lots of rotting 
insecure third party code squirreled away inside the bundled sets), I'd 
rather have a smaller breadth of software that can demonstrate a 
software engineering approach than lots of half-assed packages that 
muddle waters and satisfy no one. Though given how Go software in 
massively reusing other code even focusing on a small set of apps will 
require a huge number of packages.

The areas that need work short term are:

A packaging

B cleaning up and consolidating guidelines (need to spread the load as 
it is quite soul crushing work).

C defining an org to import sets of Go packages within the SIG. Get 
approval to whatever changes in the Fedora process necessary to review 
and import easily apps spread over hundreds of packages (the Fedora 
process is really not geared towards apps that reuse hundreds of other 
projects and require hundreds of packages imported as a set)

D investigate vgo:
   1. get POC support in go-macros (go-compiler & go-srpm-macros)
   2. test if the result can be used :
      — are the module definitions written upstream forward-facing or 
locking specific version we can not use
      – Go devs could not write a dep engine that worked like the rest of 
the software world, rpm included, does it matter in practice if 
dependency declarations written for the Go dep engine are dumped in the 
rpm dep engine, that follows differing resolution rules
   3. decide if we adopt vgo or not. If yes, probably easier to define 
how to write Fedora-friendly module definitions for projects that lack 
them than try to support an hybrid set of packages (with and without 
module defs). Module defs can be upstreamed as part of the packaging

E investigate automation of build requires (other SIGs did it but 
there's no support in rpm syntax for it, you need to talk to mock over a 
socket ie code a specific utility)

D. finishing a working baseline for Fedora Next, then rebase EPEL on it 
and forget about the past (the Go non compiler parts in EPEL have rotten 
to much for anyone to use, and I don't see anyone willing to invest the 
effort that would be required to salvage them in an evolutionary way, 
just accept it, get an exemption, and reboot from working Fedora state)

I could spend some time on most of those (though I'd rather pass on B, 
already done my part, and D/E would be the most fun and probably the 
most useful for the rest of the SIG).

However, my initial objectives were to produce clean prometheus and 
grafana Fedora packages, I finished the Go part a few months ago, but 
they both include a javascript layer, so I'll probably have to spend 
part of my packaging time on the js front. I'd really prefer if someone 
started a javascript SIG I could offload those to, I really don't have 
the cycles to progress quickly on packaging rules and tooling for two 
separate programming languages.

Regards,

-- 
Nicolas Mailhot

[Neal Gompa]

On Tue, Aug 28, 2018 at 7:06 AM Nicolas Mailhot
<nicolas.mailhot(a)laposte.net&gt; wrote:
>  However, my initial objectives were to produce clean prometheus and
>  grafana Fedora packages, I finished the Go part a few months ago, but
>  they both include a javascript layer, so I'll probably have to spend
>  part of my packaging time on the js front. I'd really prefer if someone
>  started a javascript SIG I could offload those to, I really don't have
>  the cycles to progress quickly on packaging rules and tooling for two
>  separate programming languages.
>  
The NodeJS SIG absorbed the JavaScript SIG, so those are the folks to talk to.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Jakub Cajka]

----- Original Message -----
>  From: "Nicolas Mailhot"
> <nicolas.mailhot(a)laposte.net&gt;
>  To: golang(a)lists.fedoraproject.org
>  Cc: devel(a)lists.fedoraproject.org
>  Sent: Tuesday, August 28, 2018 10:37:06 AM
>  Subject: Re: Golang SIG primary goals?
>  
>  Hi,
>  
>  Just to get people thinking before the meet…
>  
>  IMHO, the core objective of the SIG should be to maintain a consistent
>  self-hosting up-to-date baseline of Go software in rpm form, that can
>  then be used to build other forms of Fedora deliverables (flatpacks,
>  coreos images, etc)
>  
>  That implies:
>  — continuing to improve the go/rpm plumbing
>     (packager time should be spent on fixing project-specific problems,
>  not writing lots of generic automatable declarations)
>  – getting one form of Go packaging guidelines approved by FPC
>  – producing a package set that conforms to the above
>  – refreshing periodically the set (at least one mass rebuild/version
>  refresh per Fedora release).
>  – reporting upstream everything that fails in the set to raise the bar
>  on the bits we package, gain legitimacy and provide value to upstream –
>  ideally also work on fixes but just identifying and reporting problems
>  regularly would be a huge first step
>  – scrapping all the Fedora Go packages that do not comply. Not a fan of
>  zero defect approaches but there is a point where keeping lots of
>  obsolete/non conformant packages discourages old and new packagers alike
>  
>  I don't really see the point of producing another set of
>  bundled/containerized/imaged Go software, there are lots of them on the
>  market, the drawbacks are increasingly well known (lots of rotting
>  insecure third party code squirreled away inside the bundled sets), I'd
>  rather have a smaller breadth of software that can demonstrate a
>  software engineering approach than lots of half-assed packages that
>  muddle waters and satisfy no one. Though given how Go software in
>  massively reusing other code even focusing on a small set of apps will
>  require a huge number of packages.
>  
>  The areas that need work short term are:
>  
>  A packaging
>  
>  B cleaning up and consolidating guidelines (need to spread the load as
>  it is quite soul crushing work).
>  
>  C defining an org to import sets of Go packages within the SIG. Get
>  approval to whatever changes in the Fedora process necessary to review
>  and import easily apps spread over hundreds of packages (the Fedora
>  process is really not geared towards apps that reuse hundreds of other
>  projects and require hundreds of packages imported as a set)
>  
>  D investigate vgo:
>     1. get POC support in go-macros (go-compiler & go-srpm-macros)
>     2. test if the result can be used :
>        — are the module definitions written upstream forward-facing or
>  locking specific version we can not use
>        – Go devs could not write a dep engine that worked like the rest of
>  the software world, rpm included, does it matter in practice if
>  dependency declarations written for the Go dep engine are dumped in the
>  rpm dep engine, that follows differing resolution rules
>     3. decide if we adopt vgo or not. If yes, probably easier to define
>  how to write Fedora-friendly module definitions for projects that lack
>  them than try to support an hybrid set of packages (with and without
>  module defs). Module defs can be upstreamed as part of the packaging
>  
>  E investigate automation of build requires (other SIGs did it but
>  there's no support in rpm syntax for it, you need to talk to mock over a
>  socket ie code a specific utility)
>  
>  D. finishing a working baseline for Fedora Next, then rebase EPEL on it
>  and forget about the past (the Go non compiler parts in EPEL have rotten
>  to much for anyone to use, and I don't see anyone willing to invest the
>  effort that would be required to salvage them in an evolutionary way,
>  just accept it, get an exemption, and reboot from working Fedora state) 
Could you please turn those in to issue in pagure(https://pagure.io/GoSIG/go-sig/issues)?
I don't believe that these ML will be best for keeping track of those and I'm
afraid that they might stay rotting here.

>  
>  I could spend some time on most of those (though I'd rather pass on B,
>  already done my part, and D/E would be the most fun and probably the
>  most useful for the rest of the SIG). 
For B I would much appreciate if you would mark which parts of your proposals got
implemented and in which way. It would greatly help anyone picking this topic after you.
If you really do not plan to finish all the work that you have started.

Thanks,

JC

> 
> However, my initial objectives were to produce clean prometheus and
> grafana Fedora packages, I finished the Go part a few months ago, but
> they both include a javascript layer, so I'll probably have to spend
> part of my packaging time on the js front. I'd really prefer if someone
> started a javascript SIG I could offload those to, I really don't have
> the cycles to progress quickly on packaging rules and tooling for two
> separate programming languages.
> 
> Regards,
> 
> --
> Nicolas Mailhot
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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/[e-mail]
>

[Nicolas Mailhot]

Le 2018-08-28 13:49, Jakub Cajka a écrit :

Hi Jakub

> > I could spend some time on most of those (though I'd rather
> pass on B,
> > already done my part, and D/E would be the most fun and probably the
> > most useful for the rest of the SIG).
>  
>  For B I would much appreciate if you would mark which parts of your
>  proposals got implemented and in which way. It would greatly help
>  anyone picking this topic after you. If you really do not plan to
>  finish all the work that you have started. 
I'm pretty sure most of what's on the page is now done and can be used 
to package Go in Fedora (kudos to jchaloup who did a huge part of the 
work).

But sure, I'll make a pass to check if it contains references to stuff 
that turned out slightly differently than the initial plan

Regards,

-- 
Nicolas Mailhot

[Nicolas Mailhot]

Le 2018-08-28 13:27, Neal Gompa a écrit :
>  On Tue, Aug 28, 2018 at 7:06 AM Nicolas Mailhot
>  <nicolas.mailhot(a)laposte.net&gt; wrote:
> > 
> > 
> > However, my initial objectives were to produce clean prometheus and
> > grafana Fedora packages, I finished the Go part a few months ago, but
> > they both include a javascript layer, so I'll probably have to spend
> > part of my packaging time on the js front. I'd really prefer if 
> > someone
> > started a javascript SIG I could offload those to, I really don't have
> > the cycles to progress quickly on packaging rules and tooling for two
> > separate programming languages.
> > 
>  
>  The NodeJS SIG absorbed the JavaScript SIG, so those are the folks to 
>  talk to. 
Thanks for the pointer, I'll contact them !

-- 
Nicolas Mailhot