+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(a)redhat.com> 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,
--
Emilien Macchi
_______________________________________________
Rdo-list mailing list
Rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe(a)redhat.com