CC'ing packaging@
On 05/03/2016 07:02 PM, Jan Chaloupka wrote:
Hi,
Since F17, golang started to get attention in Fedora distribution.
Long way was travelled since with currently activelly maintaining f22+
and el6 branches. The number of Go projects packaged in Fedora grown
to more than 250 packages. The current effort is to keep in shape all
activelly managed branches including el6. As the Golang language is
spreading across new architectures, new challenges pop up. With 250
packages in distribution we have a free source of Go source code to
play with and run various analysis on. To see how the Golang compiler
is doing on secondary architectures. To see how new OSes accept new
versions of projects written in Go. Or be a witness to dynamic changes
in Go community.
Currently, we have Fedora, RHEL and CentOS in our disposal. It has
been quite a ride to watch how all the projects evolve, what
challenges they generate, questions they rise. With the infrastructure
we have, with the variability of OSes and architectures, it is a
perfect time to experiment and push the community further.
A lot of work has been already done. I would like to continue with
that effort and extend the currently maintained branches to epel7. It
is a great opportunity to see how the Go actually works for all the
projects on RHEL. The more projects we can test and run, the higher
chance to discover bootlenecks we have. At the same time all the
projects can be tested with newer version of Go compiler even before
it gets into RHEL and fix the critical issues in advance.
There are already some Go packages built in RHEL7. It has been one of
the reasons in the air why it is not efortfull to maintain Go in
epel7. Once a package gets into RHEL7, it has to be retired from
epel7. Thus, it would generate an amount of work that would be thrown
away. Still, it makes sense to keep both Fedora and RHEL in sync on a
level of Go packaging.
CentOS has its own collection of Go packages already. Another
opportunity to test and run and see how everything works.
For quite some time I have been working on gofed tool [1]. At the
current state it is strongly oriented on packaging. With its help I am
able to update and build Go packages on all affected branches with
minimal effort. For that, I would like to extend the coverage to both
epel7 and centos7. There are already BZs opened for epel7 packaging
which should not be ignored.
I would like to start with epel7. As there are just few Go packages
with epel7 branch, it will require some time spent on generated
requests for new branch and (re)building entire Go part of epel7. The
primary aim is to backport devel subset of each Go project. It does
not mean there will be no rpms with binaries. First, I would like to
sync epel7 with Fedora rawhide. Then, start fixing all projects that
fail to build. Any help on collection requirements for it is
appreciated. There will be some collisions with Go packages already in
RHEL7 so one needs to be carefull.
Steps I suggest:
1) make a list of all Go packages that are missing epel7 branch and
does not conflict with RHEL7
2) request for missing epel7 branches (at least 200)
3) backport all affected Go packages from Fedora rawhide to epel7
4) start fixing all failing tests and reporting issues to upstream
There are other tasks that needs to be done or initiated:
- start running unit-test in all Go packages periodically,
- scan the distribution for broken or breaking packages
- provider better feedback to developers
- finish the Go packaging guidelines
The current emphasis of the gofed tool is extend the concentration on
ecosystem analysis. I have already implemented scans of the latest
rpms in distribution. So the tool is already capable of collection
basic information about Go projects we have. From the collected data,
dependency graph among rpms can be constructed. And other analysis
that are already there. Another step is "just" to start running all
the scans and analysis periodically and collect the current state of
the ecosystem.
I would like to thank to all who have contributed and help making the
Go ecosystem better. It is a lot of effort, a lot of free time spent
and dreamless nights. Let's continue in the great work we have done so
far.
[1] https://github.com/gofed/gofed
Kind regards
Jan Chaloupka
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/packaging@xxxxxxxxxxxxxxxxxxxxxxx
