In the OpenShift Origin/CRI-O/Kubernetes effort we have a dilemma.

[Daniel Walsh]

Users of OpenSHift Origin require CRI-O 1.10 right now.  But Kubernetes 
users want to try out the latest packages for kubernetes 1.11 which 
would require CRI-O 1.11.  Origin might not be ready to move to 
Kubernetes 1.11 for a while.

Bottom line we want to be able to ship CRI-0 1.10.* and CRI-O 1.11.* 
releases in the same Fedora 28.

I believe this is what Modularity was designed to fix.

Can I do this with Modularity?  If I can how do I use fedpkg to make 
this happen?

Dan

[Stephen Gallagher]

On Fri, Jun 29, 2018 at 8:32 AM Daniel Walsh  wrote:
> Users of OpenSHift Origin require CRI-O 1.10 right now.  But Kubernetes
> users want to try out the latest packages for kubernetes 1.11 which
> would require CRI-O 1.11.  Origin might not be ready to move to
> Kubernetes 1.11 for a while.
>
> Bottom line we want to be able to ship CRI-0 1.10.* and CRI-O 1.11.*
> releases in the same Fedora 28.
>
> I believe this is what Modularity was designed to fix.
>
> Can I do this with Modularity?  If I can how do I use fedpkg to make
> this happen?'

Yes you can, we can help you get set up in #fedora-modularity on Freenode
if you like.

The basics are documented at
https://docs.fedoraproject.org/fedora-project/subprojects/fesco/en-US/making...

[Stephen Gallagher]

On Fri, Jun 29, 2018 at 8:42 AM Stephen Gallagher 
wrote:
> On Fri, Jun 29, 2018 at 8:32 AM Daniel Walsh  wrote:
> > Users of OpenSHift Origin require CRI-O 1.10 right now.  But Kubernetes
> > users want to try out the latest packages for kubernetes 1.11 which
> > would require CRI-O 1.11.  Origin might not be ready to move to
> > Kubernetes 1.11 for a while.
> >
> > Bottom line we want to be able to ship CRI-0 1.10.* and CRI-O 1.11.*
> > releases in the same Fedora 28.
> >
> > I believe this is what Modularity was designed to fix.
> >
> > Can I do this with Modularity?  If I can how do I use fedpkg to make
>
> this happen?'
> >
>
> Yes you can, we can help you get set up in #fedora-modularity on Freenode
> if you like.
>
> The basics are documented at
> https://docs.fedoraproject.org/fedora-project/subprojects/fesco/en-US/making...

Oops, I meant to link to
https://fedoraproject.org/wiki/Modularity/Adding_New_Modules_and_Managing_De...

[Dusty Mabe]

On 06/29/2018 08:42 AM, Stephen Gallagher wrote:
> On Fri, Jun 29, 2018 at 8:32 AM Daniel Walsh <[e-mail] > wrote:
> Users of OpenSHift Origin require CRI-O 1.10 right now.  But Kubernetes
> users want to try out the latest packages for kubernetes 1.11 which
> would require CRI-O 1.11.  Origin might not be ready to move to
> Kubernetes 1.11 for a while.
>
> Bottom line we want to be able to ship CRI-0 1.10.* and CRI-O 1.11.*
> releases in the same Fedora 28.
>
> I believe this is what Modularity was designed to fix.
>
> Can I do this with Modularity?  If I can how do I use fedpkg to make
> this happen?'
>
>
>
> Yes you can, we can help you get set up in #fedora-modularity on Freenode if you like.
>
> The basics are documented at https://docs.fedoraproject.org/fedora-project/subprojects/fesco/en-US/making...

Did we decide to convert the CRI-O / kube stack to a module?

If it needs a self contained change request the deadline is today!

Dusty

[Nicolas Mailhot]

Le 2018-06-29 14:31, Daniel Walsh a écrit :

Hi,
> Users of OpenSHift Origin require CRI-O 1.10 right now.  But
> Kubernetes users want to try out the latest packages for kubernetes
> 1.11 which would require CRI-O 1.11.  Origin might not be ready to
> move to Kubernetes 1.11 for a while.
>
> Bottom line we want to be able to ship CRI-0 1.10.* and CRI-O 1.11.*
> releases in the same Fedora 28.

I actively don't care what version you choose as long as the 
kubernetes/dockers/whatever stack you settle on is done with proper 
srpms that expose in a clean -devel package Go source code that can be 
used to build any other Go software that wants to integrate with them. 
IE make them proper distro components the rest of the distro can work 
upon, not selfish binaries that care nothing about the rest of the 
Fedora universe.

Regards,

[Daniel Walsh]

On 06/29/2018 10:03 AM, Nicolas Mailhot wrote:
> Le 2018-06-29 14:31, Daniel Walsh a écrit :
>
> Hi,
> > Users of OpenSHift Origin require CRI-O 1.10 right now.  But
> > Kubernetes users want to try out the latest packages for kubernetes
> > 1.11 which would require CRI-O 1.11.  Origin might not be ready to
> > move to Kubernetes 1.11 for a while.
> >
> > Bottom line we want to be able to ship CRI-0 1.10.* and CRI-O 1.11.*
> > releases in the same Fedora 28.
>
> I actively don't care what version you choose as long as the 
> kubernetes/dockers/whatever stack you settle on is done with proper 
> srpms that expose in a clean -devel package Go source code that can be 
> used to build any other Go software that wants to integrate with them. 
> IE make them proper distro components the rest of the distro can work 
> upon, not selfish binaries that care nothing about the rest of the 
> Fedora universe.
>
> Regards,

Right, I think there should be a Kubernetes 1.11 module and a kubernetes 
1.12 module, and in these modules we would have the appropriate 
kubernetes/CRI-O/crictl (Potentially docker and other packages)

[Lokesh Mandvekar]

On Fri, Jun 29, 2018 at 04:03:28PM +0200, Nicolas Mailhot wrote:
> Le 2018-06-29 14:31, Daniel Walsh a écrit :
>
> Hi,
> > Users of OpenSHift Origin require CRI-O 1.10 right now.  But
> > Kubernetes users want to try out the latest packages for kubernetes
> > 1.11 which would require CRI-O 1.11.  Origin might not be ready to
> > move to Kubernetes 1.11 for a while.
> >
> > Bottom line we want to be able to ship CRI-0 1.10.* and CRI-O 1.11.*
> > releases in the same Fedora 28.
>
> I actively don't care what version you choose as long as the
> kubernetes/dockers/whatever stack you settle on is done with proper srpms
> that expose in a clean -devel package Go source code that can be used to
> build any other Go software that wants to integrate with them. IE make them
> proper distro components the rest of the distro can work upon, not selfish
> binaries that care nothing about the rest of the Fedora universe.

Just to confirm, as long as you get a cri-o-devel/docker-devel package,
you're all set, yes?
> Regards,
>
> -- 
> Nicolas Mailhot
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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]/...

[Neal Gompa]

On Fri, Jun 29, 2018 at 11:41 AM Lokesh Mandvekar
 wrote:
> On Fri, Jun 29, 2018 at 04:03:28PM +0200, Nicolas Mailhot wrote:
> > Le 2018-06-29 14:31, Daniel Walsh a écrit :
> >
> > Hi,
> > > Users of OpenSHift Origin require CRI-O 1.10 right now.  But
> > > Kubernetes users want to try out the latest packages for kubernetes
> > > 1.11 which would require CRI-O 1.11.  Origin might not be ready to
> > > move to Kubernetes 1.11 for a while.
> > >
> > > Bottom line we want to be able to ship CRI-0 1.10.* and CRI-O 1.11.*
> > > releases in the same Fedora 28.
> >
> > I actively don't care what version you choose as long as the
> > kubernetes/dockers/whatever stack you settle on is done with proper srpms
> > that expose in a clean -devel package Go source code that can be used to
> > build any other Go software that wants to integrate with them. IE make them
> > proper distro components the rest of the distro can work upon, not selfish
> > binaries that care nothing about the rest of the Fedora universe.
>
> Just to confirm, as long as you get a cri-o-devel/docker-devel package,
> you're all set, yes?

I think he's referring to the fact that the container team has not
been helping with maintaining Go packages at all, instead vendoring
everything and not making their packages useful for integrating into
other software.

[Lokesh Mandvekar]

On Fri, Jun 29, 2018 at 11:43:11AM -0400, Neal Gompa wrote:
> On Fri, Jun 29, 2018 at 11:41 AM Lokesh Mandvekar
>  wrote:
> > On Fri, Jun 29, 2018 at 04:03:28PM +0200, Nicolas Mailhot wrote:
> > > Le 2018-06-29 14:31, Daniel Walsh a écrit :
> > >
> > > Hi,
> > > > Users of OpenSHift Origin require CRI-O 1.10 right now.  But
> > > > Kubernetes users want to try out the latest packages for kubernetes
> > > > 1.11 which would require CRI-O 1.11.  Origin might not be ready to
> > > > move to Kubernetes 1.11 for a while.
> > > >
> > > > Bottom line we want to be able to ship CRI-0 1.10.* and CRI-O 1.11.*
> > > > releases in the same Fedora 28.
> > >
> > > I actively don't care what version you choose as long as the
> > > kubernetes/dockers/whatever stack you settle on is done with proper srpms
> > > that expose in a clean -devel package Go source code that can be used to
> > > build any other Go software that wants to integrate with them. IE make them
> > > proper distro components the rest of the distro can work upon, not selfish
> > > binaries that care nothing about the rest of the Fedora universe.
> >
> > Just to confirm, as long as you get a cri-o-devel/docker-devel package,
> > you're all set, yes?
>
> I think he's referring to the fact that the container team has not
> been helping with maintaining Go packages at all, instead vendoring
> everything and not making their packages useful for integrating into
> other software.

Whoever's interested in handling golang dependency heaven,
I'll be happy to add them as co-maintainers so they
can handle it themselves.

Let me know if any takers..
> -- 
> 真実はいつも一つ！/ Always, there's only one truth!
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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]/...

[Lokesh Mandvekar]

FWIW, a fun read from the debian pkg-go list about packaging docker
https://www.mail-archive.com/[e-mail]/msg0...

On Fri, Jun 29, 2018 at 12:09:06PM -0400, Lokesh Mandvekar wrote:
> On Fri, Jun 29, 2018 at 11:43:11AM -0400, Neal Gompa wrote:
> > On Fri, Jun 29, 2018 at 11:41 AM Lokesh Mandvekar
> >  wrote:
> > > On Fri, Jun 29, 2018 at 04:03:28PM +0200, Nicolas Mailhot wrote:
> > > > Le 2018-06-29 14:31, Daniel Walsh a écrit :
> > > >
> > > > Hi,
> > > > > Users of OpenSHift Origin require CRI-O 1.10 right now.  But
> > > > > Kubernetes users want to try out the latest packages for kubernetes
> > > > > 1.11 which would require CRI-O 1.11.  Origin might not be ready to
> > > > > move to Kubernetes 1.11 for a while.
> > > > >
> > > > > Bottom line we want to be able to ship CRI-0 1.10.* and CRI-O 1.11.*
> > > > > releases in the same Fedora 28.
> > > >
> > > > I actively don't care what version you choose as long as the
> > > > kubernetes/dockers/whatever stack you settle on is done with proper srpms
> > > > that expose in a clean -devel package Go source code that can be used to
> > > > build any other Go software that wants to integrate with them. IE make them
> > > > proper distro components the rest of the distro can work upon, not selfish
> > > > binaries that care nothing about the rest of the Fedora universe.
> > >
> > > Just to confirm, as long as you get a cri-o-devel/docker-devel package,
> > > you're all set, yes?
> >
> > I think he's referring to the fact that the container team has not
> > been helping with maintaining Go packages at all, instead vendoring
> > everything and not making their packages useful for integrating into
> > other software.
>
> Whoever's interested in handling golang dependency heaven,
> I'll be happy to add them as co-maintainers so they
> can handle it themselves.
>
> Let me know if any takers..
> > -- 
> > 真実はいつも一つ！/ Always, there's only one truth!
> > _______________________________________________
> > devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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]/...
>
> -- 
> Lokesh
> IRC: lsm5
> GPG: 0xC7C3A0DD
> https://keybase.io/lsm5

[Robert-André Mauchin]

On vendredi 29 juin 2018 18:19:23 CEST Lokesh Mandvekar wrote:
> FWIW, a fun read from the debian pkg-go list about packaging docker
> https://www.mail-archive.com/[e-mail]/msg0
> 0032.html

I wish we had a formal Go Packaging Team like them. It would be more efficient 
to churn out packages and review them in the same breath.

[Nicolas Mailhot]

Le vendredi 29 juin 2018 à 12:19 -0400, Lokesh Mandvekar a écrit :
> FWIW, a fun read from the debian pkg-go list about packaging docker
> https://www.mail-archive.com/[e-mail]
> t/msg00032.html

And so what? I hit this problem months ago (and I have the github
tickets to prove it, with the Debian maintainers me-too-ing a few weeks
later). And some of those have been fixed since thanks to the reporting.

The problem is not this message, that's upstream software needing
fixing, we handle tons of those in Fedora all year round, the problem is
that you seem to find normal *others* identified it, you seem to find
normal *not* *involving* yourself in the reporting and the fixing, you
seem to find normal functioning in some sort of fourth dimension where
FLOSS community fixing and collaborating happens to someone else.

Go upstream state is a hard problem. But it needs to be solved because
no matter how you look at it there is a ton of go software that wants to
integrate with either kubernetes or docker. Stuff that is usually
*useful* for container users BTW. Stuff *you* could pull on for future
openshift enhancements if you made a minimum effort to nurture its
packaging in Fedora.

Making temporary exceptions for bits of bundling because they're too
broken to integrate right now is one thing. Passing on entirely and
letting the whole thing rot for years is something else entirely.

There is maybe 95% of Go packages that kubernetes need that present no
technical challenge to package as rpm and use as rpm (some of this code
has not been changed upstream for years!). The 5% remaining problem
stuff could be bundled and then chipped at years after year till it's
not a problem anymore. It *needs* chipping at to improve the codebase
and the maintainability of it all.

But you use this 5% as the reason not to play the game at all.

Why ?

[Nicolas Mailhot]

Le samedi 30 juin 2018 à 12:46 +0200, Nicolas Mailhot a écrit :
> Le vendredi 29 juin 2018 à 12:19 -0400, Lokesh Mandvekar a écrit :
> > FWIW, a fun read from the debian pkg-go list about packaging docker
> > https://www.mail-archive.com/[e-mail].
> > ne
> > t/msg00032.html
>
> And so what? I hit this problem months ago (and I have the github
> tickets to prove it, with the Debian maintainers me-too-ing a few
> weeks later).

And, to follow on your example, just in case someone thinks it was smart
to vendor blindly whatever code upstream was stuck at, and leave
dependency checking to someone else.

Updating the Azure component Debian people complain about in their
message was necessary to update the Azure component dealing with
authentification and resource  management, and the changelog of *this*
component states:

/Fixed a race condition in token refresh./

Race condition in auth management on one of the three big clouds? No
biggie! Sleep well everyone.

[Lokesh Mandvekar]

On Sat, Jun 30, 2018 at 01:22:46PM +0200, Nicolas Mailhot wrote:
> Le samedi 30 juin 2018 à 12:46 +0200, Nicolas Mailhot a écrit :
> > Le vendredi 29 juin 2018 à 12:19 -0400, Lokesh Mandvekar a écrit :
> > > FWIW, a fun read from the debian pkg-go list about packaging docker
> > > https://www.mail-archive.com/[e-mail].
> > > ne
> > > t/msg00032.html
> >
> > And so what? I hit this problem months ago (and I have the github
> > tickets to prove it, with the Debian maintainers me-too-ing a few
> > weeks later).
>
> And, to follow on your example, just in case someone thinks it was smart
> to vendor blindly whatever code upstream was stuck at, and leave
> dependency checking to someone else.
>
> Updating the Azure component Debian people complain about in their
> message was necessary to update the Azure component dealing with
> authentification and resource  management, and the changelog of *this*
> component states:
>
> /Fixed a race condition in token refresh./
>
> Race condition in auth management on one of the three big clouds? No
> biggie! Sleep well everyone.

Please help me understand, was this a runtime dependency or a build
dependency?

Thanks,
> -- 
> Nicolas Mailhot

[Tomasz Torcz]

On Sat, Jun 30, 2018 at 12:46:28PM +0200, Nicolas Mailhot wrote:
> Le vendredi 29 juin 2018 à 12:19 -0400, Lokesh Mandvekar a écrit :
> > FWIW, a fun read from the debian pkg-go list about packaging docker
> > https://www.mail-archive.com/[e-mail]
> > t/msg00032.html
>
> And so what? I hit this problem months ago (and I have the github
> tickets to prove it, with the Debian maintainers me-too-ing a few weeks
> later). And some of those have been fixed since thanks to the reporting.
>
> The problem is not this message, that's upstream software needing
> fixing, we handle tons of those in Fedora all year round, the problem is
> that you seem to find normal *others* identified it, you seem to find
> normal *not* *involving* yourself in the reporting and the fixing, you
> seem to find normal functioning in some sort of fourth dimension where
> FLOSS community fixing and collaborating happens to someone else.
>
> Go upstream state is a hard problem. But it needs to be solved because
> no matter how you look at it there is a ton of go software that wants to
> integrate with either kubernetes or docker. Stuff that is usually
> *useful* for container users BTW. Stuff *you* could pull on for future
> openshift enhancements if you made a minimum effort to nurture its
> packaging in Fedora.

BTW, kubernetes package is quite pathological. Installing it brings
kubernetes-master, which contains following four binaries:

-rwxr-xr-x.   3 root root 152M 04-26 11:34 /usr/bin/hyperkube
-rwxr-xr--.   1 root kube 128M 04-26 11:34 /usr/bin/kube-apiserver
-rwxr-xr-x.   3 root root 152M 04-26 11:34 /usr/bin/kube-controller-manager
-rwxr-xr-x.   3 root root 152M 04-26 11:34 /usr/bin/kube-scheduler

That's almost 600 MiB (!!!) in 4 binary files. We can forget about
trying to create minimal fedora install image  for cloud, if installing
single component of k8s triples the installation size.

[Nicolas Mailhot]

Le samedi 30 juin 2018 à 14:22 +0200, Tomasz Torcz a écrit :
> BTW, kubernetes package is quite pathological. Installing it brings
> kubernetes-master, which contains following four binaries:
>
> -rwxr-xr-x.   3 root root 152M 04-26 11:34 /usr/bin/hyperkube
> -rwxr-xr--.   1 root kube 128M 04-26 11:34 /usr/bin/kube-apiserver
> -rwxr-xr-x.   3 root root 152M 04-26 11:34 /usr/bin/kube-controller-
> manager
> -rwxr-xr-x.   3 root root 152M 04-26 11:34 /usr/bin/kube-scheduler
>
> That's almost 600 MiB (!!!) in 4 binary files. We can forget about
> trying to create minimal fedora install image  for cloud, if
> installing
> single component of k8s triples the installation size.

Yes, Go as a whole is hitting the limits of the "pile lots of third
party code, hide it in vendored tree, think about modularising and APIs
later"

But, the code itself is nice and without major problems, it just needs a
 major injection of release engineering to split what needs splitting
and stabilise what needs stabilising.

The core problem is that people got used to accumulating technical debt
and hoping someone else will take care of it later, and no self-
respecting Go dev wants to tackle this if he can avoid it.

[Jan Chaloupka]

On 06/30/2018 05:05 PM, Nicolas Mailhot wrote:
> Le samedi 30 juin 2018 à 14:22 +0200, Tomasz Torcz a écrit :
> > BTW, kubernetes package is quite pathological. Installing it brings
> > kubernetes-master, which contains following four binaries:
> >
> > -rwxr-xr-x.   3 root root 152M 04-26 11:34 /usr/bin/hyperkube
> > -rwxr-xr--.   1 root kube 128M 04-26 11:34 /usr/bin/kube-apiserver
> > -rwxr-xr-x.   3 root root 152M 04-26 11:34 /usr/bin/kube-controller-
> > manager
> > -rwxr-xr-x.   3 root root 152M 04-26 11:34 /usr/bin/kube-scheduler
> >
> > That's almost 600 MiB (!!!) in 4 binary files. We can forget about
> > trying to create minimal fedora install image  for cloud, if
> > installing
> > single component of k8s triples the installation size.
>
> Yes, Go as a whole is hitting the limits of the "pile lots of third
> party code, hide it in vendored tree, think about modularising and APIs
> later"

+1
> But, the code itself is nice and without major problems, it just needs a
>   major injection of release engineering to split what needs splitting
> and stabilise what needs stabilising.

+1
> The core problem is that people got used to accumulating technical debt
> and hoping someone else will take care of it later, and no self-
> respecting Go dev wants to tackle this if he can avoid it.

Absolutely -1. Even the super cool Go packaging guidelines will not 
help. It's the same old story sad story. We need human power + tooling. 
At best, the tooling will do the hard part and we humans will just 
decide what to do. It's not about people do not care, it's about people 
seeing the neverending pile of **** (fill in any word you like, e.g. 
work) that needs to be done and repeated everytime something is updated. 
Please, allocated me someone who can spend at least 4hours a day on the 
tooling I am implementing (and want to implement) and the burden on each 
package maintainer will get reduced.

[Lokesh Mandvekar]

On Sat, Jun 30, 2018 at 12:46:28PM +0200, Nicolas Mailhot wrote:
> Le vendredi 29 juin 2018 à 12:19 -0400, Lokesh Mandvekar a écrit :
> > FWIW, a fun read from the debian pkg-go list about packaging docker
> > https://www.mail-archive.com/[e-mail]
> > t/msg00032.html
>
> And so what? I hit this problem months ago (and I have the github
> tickets to prove it, with the Debian maintainers me-too-ing a few weeks
> later). And some of those have been fixed since thanks to the reporting.
>
> The problem is not this message, that's upstream software needing
> fixing, we handle tons of those in Fedora all year round, the problem is
> that you seem to find normal *others* identified it, you seem to find
> normal *not* *involving* yourself in the reporting and the fixing, you
> seem to find normal functioning in some sort of fourth dimension where
> FLOSS community fixing and collaborating happens to someone else.
>
> Go upstream state is a hard problem. But it needs to be solved because
> no matter how you look at it there is a ton of go software that wants to
> integrate with either kubernetes or docker. Stuff that is usually
> *useful* for container users BTW. Stuff *you* could pull on for future
> openshift enhancements if you made a minimum effort to nurture its
> packaging in Fedora.

Could you please give details on *stuff*, *integration* and *enhancements*
you're talking about, and how exactly would unbundling help achieve that?

Thanks,
> Making temporary exceptions for bits of bundling because they're too
> broken to integrate right now is one thing. Passing on entirely and
> letting the whole thing rot for years is something else entirely.
>
> There is maybe 95% of Go packages that kubernetes need that present no
> technical challenge to package as rpm and use as rpm (some of this code
> has not been changed upstream for years!). The 5% remaining problem
> stuff could be bundled and then chipped at years after year till it's
> not a problem anymore. It *needs* chipping at to improve the codebase
> and the maintainability of it all.
>
> But you use this 5% as the reason not to play the game at all.
>
> Why ?
>
> -- 
> Nicolas Mailhot

[Jakub Cajka]

----- Original Message -----
> From: "Nicolas Mailhot" 
> To: "Development discussions related to Fedora" 
> Cc: [e-mail], [e-mail], [e-mail]
> Sent: Saturday, June 30, 2018 12:46:28 PM
> Subject: Re: In the OpenShift Origin/CRI-O/Kubernetes effort we have a dilemma.
>
> Le vendredi 29 juin 2018 à 12:19 -0400, Lokesh Mandvekar a écrit :
> > FWIW, a fun read from the debian pkg-go list about packaging docker
> > https://www.mail-archive.com/[e-mail]
> > t/msg00032.html
>
> And so what? I hit this problem months ago (and I have the github
> tickets to prove it, with the Debian maintainers me-too-ing a few weeks
> later). And some of those have been fixed since thanks to the reporting.
>
> The problem is not this message, that's upstream software needing
> fixing, we handle tons of those in Fedora all year round, the problem is
> that you seem to find normal *others* identified it, you seem to find
> normal *not* *involving* yourself in the reporting and the fixing, you
> seem to find normal functioning in some sort of fourth dimension where
> FLOSS community fixing and collaborating happens to someone else.
>
> Go upstream state is a hard problem. But it needs to be solved because
> no matter how you look at it there is a ton of go software that wants to
> integrate with either kubernetes or docker. Stuff that is usually
> *useful* for container users BTW. Stuff *you* could pull on for future
> openshift enhancements if you made a minimum effort to nurture its
> packaging in Fedora.
>
> Making temporary exceptions for bits of bundling because they're too
> broken to integrate right now is one thing. Passing on entirely and
> letting the whole thing rot for years is something else entirely.
>
> There is maybe 95% of Go packages that kubernetes need that present no
> technical challenge to package as rpm and use as rpm (some of this code
> has not been changed upstream for years!). The 5% remaining problem
> stuff could be bundled and then chipped at years after year till it's
> not a problem anymore. It *needs* chipping at to improve the codebase
> and the maintainability of it all.
>
> But you use this 5% as the reason not to play the game at all.
>
> Why ?

Menpower? Do you know how many active packagers are in Go part of Fedora? In my experience there is less than 10, more like 5 or less for like ~600 packages.

For the record what you find as "new and surprising" we(me and jchaloup) have discovered roughly over 2y ago and have been working(mostly Jan, guidelines and gofed) on resolving it in Fedora in our spare time. Can I read your e-mail in a way that you are volunteering to commit for full time ground work on de-bundling and stabilizing the Go world(in Fedora)? We will be excited to guide you through as anyone else interested.

I would be really happy to see you all at flock so we can discuss it and work on solutions, especially if you are interested in actually working on fixing it not only discussing it. I think it would be cool if we would be able to start Fedora's Go SIG there and start systematically addressing the issues.

JC

PS: I have opened talk proposal at flock https://pagure.io/flock/issue/24(co-speakers are welcomed), but I would love to meet there even if it won't make it.
> --
> Nicolas Mailhot
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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]/...