[Rdo-list] OPM downstream patches
David Moreau Simard
dms at redhat.com
Tue Jan 12 17:43:56 UTC 2016
+1 to upstream first.
Also, if any downstream modifications are deemed necessary, I'm
convinced we should be maintaining actual patches, not entire forked
repositories but I think that's another topic.
RPM packaging spec files have built-in mechanisms to pull patches and
we should leverage it.
David Moreau Simard
Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter]
On Tue, Jan 12, 2016 at 12:37 PM, Emilien Macchi <emilien at redhat.com> wrote:
> So I started an etherpad to discuss why we have so much downstream
> patches in Puppet modules.
> 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
> * 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,
> Emilien Macchi
> Rdo-list mailing list
> Rdo-list at redhat.com
> To unsubscribe: rdo-list-unsubscribe at redhat.com
More information about the rdo-list