Fedora 31 Self-Contained Change proposal: Adopt new Go Packaging Guidelines

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines

== Summary ==

The [[PackagingDrafts/Go| current Go packaging guidelines]] have been in a draft
state for several years now, and they do not reflect the
[[ More_Go_packaging|current practices ]] from the Go SIG. As a result of new
RPM macros developed by [[User:nim| Nicolas Mailhot]], the Go SIG wishes to
formally adopt new Go Packaging Guidelines, which aim at automation, reliability
and simplicity.

== Owner ==
* Name: [[User:eclipseo| Robert-André Mauchin]]
* Name: [[User:jcajka| Jakub Cajka]]
* Name: [[User:nim| Nicolas Mailhot]]
* Name: [[User:qulogic| Elliott Sales de Andrade]]

* Email: <golang(a)lists.fedoraproject.org&gt;


== Detailed Description ==

Over 775 Go packages are currently residing in Fedora's repositories, yet no
formal guidelines have ever been approved. As a result, the various Go SPECs are
inconsistent and most often outdated. Moreover, the next version of Go, 1.13,
will introduce the concept of modules by default, which will completely change
how Go libraries are distributed. With the current state of our tooling, the Go
SIG is not prepared to face such a drastic change.

[[User:nim| Nicolas Mailhot]] has worked on a set of new RPM macros which
will allow us to disconnect the upstream Go tooling from the downstream
integration inside RPM. This will allow us to adapt easily to future upstream
changes without the need to rewrite our SPEC catalogue.

== Benefit to Fedora ==

* Simplicity: SPEC files are simpler, less error-prone
* Automation: the new macros computes packages definition, Requires,
Provides and has provision for the new automated BuildRequires
* Standardization of SPEC files across the Go library
* Drastic reduction of boilerplate and SPEC size
* Automatic removal of vendored code
* Ease of testing: all units tests are detected and run
* Ease of upkeep
* Ease of adaptation to upstream changes

== Scope ==

* Proposal owners:
** [https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/51
Get the last macros approved in ''redhat-rpm-config'']
** Get ''[https://pagure.io/golist golist]'', the tool detecting
dependencies, updated and split from the
''[https://src.fedoraproject.org/rpms/go-compilers/ go-compilers]''
package
** Release ''GOPATH'' directory ownership from the
''[https://src.fedoraproject.org/rpms/golang golang]'' package, so it
can be  managed by the ''[https://pagure.io/go-rpm-macros
go-rpm-macros]'' package
** Get ''[https://pagure.io/go-rpm-macros go-rpm-macros]'' packaged and
reviewed
** Retire ''[https://src.fedoraproject.org/rpms/go-srpm-macros
go-srpm-macros]'' and
''[https://src.fedoraproject.org/rpms/go-compilers/ go-compilers]''
** Port existing Go packages to the new macros (it probably won't be
finished by [[Releases/31 | Fedora 31]])

* Other developers: N/A (not a System Wide Change)


* Policies and guidelines:
[https://pagure.io/packaging-committee/pull-request/883 Get the Go
packaging guidelines approved by the Packaging Committee]

== Upgrade/compatibility impact ==

No compatibility impact is expected. All the new macros are backward compatible
with the old ones.

== How To Test ==

The COPR [https://copr.fedorainfracloud.org/coprs/nim/macros-ng/ nim/macros-ng]
can be used to test the new macros on Rawhide. Sample SPEC files are available
in the FPC Guidelines proposal.

== User Experience ==

The user impact is minimal or nil. As a result of the simplification of SPEC
files, we may ship updated libraries more quickly, and it may be easier for new
contributors to package Go applications.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==

* Contingency mechanism: If the required packages are not merged by
the deadline target, or if the Guidelines are not approved, we may
continue with our current set of non-approved practices. No other
impact is expected.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
* Blocks product? No

== Documentation ==

The FPC Guidelines proposal is available on
[https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/
eclipseo personal space].

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him

[Jakub Cajka]

----- Original Message -----
>  From: "Ben Cotton" <bcotton(a)redhat.com&gt;
>  To: devel-announce(a)lists.fedoraproject.org, "Development discussions related to
> Fedora"
>  <devel(a)lists.fedoraproject.org&gt;
>  Sent: Friday, April 12, 2019 10:11:51 PM
>  Subject: Fedora 31 Self-Contained Change proposal: Adopt new Go Packaging Guidelines
>  
>  https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines
>  
>  == Summary ==
>  
>  The [[PackagingDrafts/Go| current Go packaging guidelines]] have been in a
>  draft
>  state for several years now, and they do not reflect the
>  [[ More_Go_packaging|current practices ]] from the Go SIG. As a result of new
>  RPM macros developed by [[User:nim| Nicolas Mailhot]], the Go SIG wishes to
>  formally adopt new Go Packaging Guidelines, which aim at automation,
>  reliability
>  and simplicity.
>  
>  == Owner ==
>  * Name: [[User:eclipseo| Robert-André Mauchin]]
>  * Name: [[User:jcajka| Jakub Cajka]] 
Hello, as much as this change proposal excites me and I'm looking forward to it.
I'm unfortunately currently not able to own this change, regardless as much I would
really like to. 

I would also like to note that I have been added as owner arbitrarily, without notice and
without my consent and therefore I would like to be removed from the owner list.

Thanks.


>  * Name: [[User:nim| Nicolas Mailhot]]
>  * Name: [[User:qulogic| Elliott Sales de Andrade]]
>  
>  * Email: <golang(a)lists.fedoraproject.org&gt;
>  
>  
>  == Detailed Description ==
>  
>  Over 775 Go packages are currently residing in Fedora's repositories, yet no
>  formal guidelines have ever been approved. As a result, the various Go SPECs
>  are
>  inconsistent and most often outdated. Moreover, the next version of Go, 1.13,
>  will introduce the concept of modules by default, which will completely
>  change
>  how Go libraries are distributed. With the current state of our tooling, the
>  Go
>  SIG is not prepared to face such a drastic change.
>  
>  [[User:nim| Nicolas Mailhot]] has worked on a set of new RPM macros which
>  will allow us to disconnect the upstream Go tooling from the downstream
>  integration inside RPM. This will allow us to adapt easily to future upstream
>  changes without the need to rewrite our SPEC catalogue.
>  
>  == Benefit to Fedora ==
>  
>  * Simplicity: SPEC files are simpler, less error-prone
>  * Automation: the new macros computes packages definition, Requires,
>  Provides and has provision for the new automated BuildRequires
>  * Standardization of SPEC files across the Go library
>  * Drastic reduction of boilerplate and SPEC size
>  * Automatic removal of vendored code
>  * Ease of testing: all units tests are detected and run
>  * Ease of upkeep
>  * Ease of adaptation to upstream changes
>  
>  == Scope ==
>  
>  * Proposal owners:
>  ** [https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/51
>  Get the last macros approved in ''redhat-rpm-config'']
>  ** Get ''[https://pagure.io/golist golist]'', the tool detecting
>  dependencies, updated and split from the
>  ''[https://src.fedoraproject.org/rpms/go-compilers/ go-compilers]''
>  package
>  ** Release ''GOPATH'' directory ownership from the
>  ''[https://src.fedoraproject.org/rpms/golang golang]'' package, so it
>  can be  managed by the ''[https://pagure.io/go-rpm-macros
>  go-rpm-macros]'' package
>  ** Get ''[https://pagure.io/go-rpm-macros go-rpm-macros]'' packaged and
>  reviewed
>  ** Retire ''[https://src.fedoraproject.org/rpms/go-srpm-macros
>  go-srpm-macros]'' and
>  ''[https://src.fedoraproject.org/rpms/go-compilers/ go-compilers]''
>  ** Port existing Go packages to the new macros (it probably won't be
>  finished by [[Releases/31 | Fedora 31]])
>  
>  * Other developers: N/A (not a System Wide Change)
>   
I believe this affects all packagers maintaining Go based packages as they should update
their packages up to the new standard, so we don't fragment the package base. So IMO
this should be system wide change.

JC

> 
> * Policies and guidelines:
> [https://pagure.io/packaging-committee/pull-request/883 Get the Go
> packaging guidelines approved by the Packaging Committee]
> 
> == Upgrade/compatibility impact ==
> 
> No compatibility impact is expected. All the new macros are backward
> compatible
> with the old ones.
> 
> == How To Test ==
> 
> The COPR [https://copr.fedorainfracloud.org/coprs/nim/macros-ng/
> nim/macros-ng]
> can be used to test the new macros on Rawhide. Sample SPEC files are
> available
> in the FPC Guidelines proposal.
> 
> == User Experience ==
> 
> The user impact is minimal or nil. As a result of the simplification of SPEC
> files, we may ship updated libraries more quickly, and it may be easier for
> new
> contributors to package Go applications.
> 
> == Dependencies ==
> N/A (not a System Wide Change)
> 
> == Contingency Plan ==
> 
> * Contingency mechanism: If the required packages are not merged by
> the deadline target, or if the Guidelines are not approved, we may
> continue with our current set of non-approved practices. No other
> impact is expected.
> * Contingency deadline: N/A (not a System Wide Change)
> * Blocks release? No
> * Blocks product? No
> 
> == Documentation ==
> 
> The FPC Guidelines proposal is available on
> [https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/
> eclipseo personal space].
> 
> --
> Ben Cotton
> Fedora Program Manager
> TZ=America/Indiana/Indianapolis
> Pronouns: he/him
> _______________________________________________
> 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]
>