On 09/06/15 10:37, Dirk Müller wrote:
Hi Derek,
2015-06-09 0:34 GMT+02:00 Derek Higgins <der...@redhat.com>:
This patch would result in 80 packaging repositories being pulled into
gerrit.
I personally would prefer to start with fewer but common packages
between all RPM distros (is there more than Red Hat and SUSE ?) than
starting the process with 80, but I wouldn't object to that.
I selected these 80 to move all of what RDO is currently maintaining on
gerrithub to review.openstack.org, this was perhaps too big a set and in
RDO we instead may need to go hybrid.
o exactly what namespace/prefix to use in the naming, I've seen lots of
opinions but I'm not clear if we have come to a decision
o Should we use "rdo" in the packaging repo names and not "rpm"? I think
this ultimatly depends whether the packaging can be shared between RDO and
Suse or not.
Well, we're (SUSE that is) are interested in sharing the packaging,
and a non-RDO prefix would be preferred for the upstream coordination
efforts.
+1, I'd also like to see us share packaging so a non-RDO prefix should
be avoided. I think we have a few possibilities here
1. pull what I've proposed (or a subset of it) into a rpm namespace and
from there work in package to get them to a point where all rpm
interested parties can use them.
2. pull them into an rdo namespace and from there work on convergence,
as each package becomes usable by all interested parties we rename to rpm-
I know renaming is a PITA for infra so maybe move to Attic and import a
new repo if its easier.
3. Same as 2 but start with Suse packaging
It is all a bit fuzzy for me right now as I'm not entirely
sure our goals for packaging are necessarily the same (e.g. we have
the tendency to include patches that have not been merged but are
proposed upstream and are +1'ed already into our packages should there
be a pressing need for us to do so (e.g. fixes an important platform
bug), but maybe we can find enough common goals to make this a
benificial effort for all of us.
For this specific example I think differences of opinion are ok, we
should provide the tools for each party interest in the packaging can
hook in their own patches (I'm not sure what this would look like yet),
I'm assuming here that we would also have deployer's out there
interested who would have their own custom patches and bug fixes that
they are interested in.
But yes, there will be other differences that I'm sure we'll have to
figure out.
There are quite some details to sort out as our packaging is for
historical and for various policy reasons that we need to stick to
slightly different than the RDO packaging. I think going over those
and see how we can merge them in a consolidated effort (or maintain
two variants together) is the first step IMHO.
+1, maybe we should schedule something in a few days where we could go
though the differences of a specific package and how things could take
shape.
Another important point for us is that we start with equal rights on
the upstream collaboration (at least on the RPM side, I am fine with
decoupling and not caring about the deb parts). I'm not overly
optimistic that a single PTL would be able to cover both the DEB and
RPM worlds, as I perceive them quite different in details.
yup, seems reasonable to me
Greetings,
Dirk
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
