[Rdo-list] OPM downstream patches
lbezdick at redhat.com
Wed Jan 13 16:36:30 UTC 2016
On Tue, 2016-01-12 at 13:16 -0500, Emilien Macchi wrote:
> Also, the way we're packaging OPM is really bad.
> * we have no SHA1 for each module we have in OPM
> * we are not able to validate each module
you have Puppetfile and our own patches as patches to tar
> * package tarball is not pure. All other OpenStack RPMS take upstream
> tarball so we can easily compare but in OPM... no way to do it.
Tarballs are always taken from github releases:
And yes, dropping single package and creating metapackage is the way to
> Those issues are really critical, I would like to hear from OPM
> and find solutions that we will work on during the following weeks.
> On 01/12/2016 12:37 PM, Emilien Macchi wrote:
> > So I started an etherpad to discuss why we have so much downstream
> > patches in Puppet modules.
> > https://etherpad.openstack.org/p/opm-patches
> > In my opinion, we should follow some best practices:
> > * upstream first. If you find a bug, submit the patch upstream,
> > wait for
> > at least a positive review from a core and also successful CI jobs.
> > Then
> > you can backport it downstream if urgent.
> > * backport it to stable branches when needed. The patch we want is
> > in
> > master and not stable? It's too easy to backport it in OPM. Do the
> > backport in upstream/stable first, it will help to stay updated
> > with
> > upstream.
> > * don't change default parameters, don't override them. Our
> > installers
> > are able to override any parameter so do not hardcode this kind of
> > change.
> > * keep up with upstream: if you have an upstream patch under review
> > that
> > is already in OPM: keep it alive and make sure it lands as soon as
> > possible.
> > UPSTREAM FIRST please please please (I'll send you cookies if you
> > want).
> > If you have any question about an upstream patch, please join
> > #puppet-openstack (freenode) and talk to the group. We're doing
> > reviews
> > every day and it's not difficult to land a patch.
> > In the meantime, I would like to justify each of our backports in
> > the
> > etherpad and clean-up a maximum of them.
> > Thank you for reading so far,
> > _______________________________________________
> > Rdo-list mailing list
> > Rdo-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/rdo-list
> > To unsubscribe: rdo-list-unsubscribe at redhat.com
> Rdo-list mailing list
> Rdo-list at redhat.com
> To unsubscribe: rdo-list-unsubscribe at redhat.com
More information about the rdo-list