Open Stack

On 06/03/2015 04:22 PM, Thomas Goirand wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi James B.,
>
> Thanks for this reply.
>
> As you asked for ACK from all parts, my words will be very much like the
> ones of James P. (I've just read his message, and I'm jealous of his
> nice native-English wording...:)).
>
> On 06/03/2015 12:41 AM, James E. Blair wrote:
>> Hi,
>>
>> This came up at the TC meeting today, and I volunteered to provide an
>> update from the discussion.
>
> Thanks.
>
>> In general, I think there is a lot of support for a packaging effort in
>> OpenStack.  The discussion here has been great; we need to answer a few
>> questions, get some decisions written down, and make sure we have
>> agreement.
>>
>> Here's what we need to know:
>>
>> 1) Is this one or more than one horizontal effort?
>>
>> In other words, do we think the idea of having a single packaging
>> project/team with collaboration among distros is going to work?
>>
>> Or should we look at it more like the deployment projects where we have
>> puppet and chef as top level OpenStack projects?
>
> I don't really know about the puppet project, so I don't know what you
> refer to here.
>
> However, talking with James Page (from Canonical, head of their server
> team which does the OpenStack packaging), we believe it's best if we had
> 2 different distinct teams: one for Fedora/SuSe/everything-rpm, and one
> for Debian based distribution.
>
> We could try to work as a single entity (RPM + deb teams), but rpm+yum
> and dpkg+apt are 2 distinct worlds which have very few common
> attributes. So even if it may socially be nice, it's not the right
> technical decision.

You could still have one shared repository with the understanding of who 
approves what. Working on one repo makes it easier to see what the other 
"team" does.

If you want to unify packaging - there are always arbitrary choices you 
can make - it's better to have a common team.

> At least, during the summit, what we agreed on is that we don't want
> Debian/Ubuntu guys having the rights to core-review RPM packaging and
> vice-versa. So the core reviewer lists will have to be separated. The
> list of repositories will also have to be split, because repositories
> must match package names, and we have different naming (and even naming
> policies). Plus the ACLs will be better managed on a per-repo basis than
> on a per-branch one.

This could also be a social contract. You might want to share config 
files between distros, so having them in one repository could make life 
easier. On the other hand, it means you have to collaborate to not break 
each other...


> It would also maybe make sense to have separate PTLs too (though we're
> open to other views, if it's easier to have a single one for the rest of
> the community).
>
>> Either way is fine, and regardless, we need to answer the next
>> questions:
>>
>> 2) What's the collaboration plan?
>>
>> How will different distros collaborate with each other, if at all?  What
>> things are important to standardize on, what aren't and how do we
>> support them all.
>
> I can answer only for the Debian/Ubuntu part, and I'll let the RPM world
> guys reply from themselves
>
> First, we already worked together between Debian and Ubuntu. All of Juno
> in Ubuntu was using Python packages I worked on (in fact, all of
> OpenStack but the core packages). We have the intention to at least
> merge all of our efforts on everything but the core packages first, then
> see on case by case basis how we can merge all packaging for the more
> complex packages. Nova and Neutron packages have unfortunately diverged
> over the years, so we have to be extra careful on how this is
> technically going to happen, without breaking any distro. But I'm
> confident we'll succeed.
>
> What sparked this, is that during the summit, Mark Shuttleworth told me
> he was supportive of more collaboration between Debian & Ubuntu. Just 5
> minutes after his words, I (very fortunately) bumped into James Page,
> and we decided to push everything to /stackforge, then try to merge all
> of our source packages.
>
> Then, when discussing the mater with others, I heard sentences like "you
> should push this into the /openstack namespace to make it more
> big-tent-ish", on which I agree.
>
> So there is at least a strong will to maintain OpenStack packages for
> Debian and Ubuntu collectively. This means it would be both James Page
> team (for Canonical) and myself (working in Debian). I hope to push
> everyone else in Mirantis who works on MOS to also do packaging on
> upstream Gerrit, at least for the Debian/Ubuntu part. So that is 3
> OpenStack distributions that will work as one.
>
> Also, I have to say that the merging effort between Debian and Ubuntu
> has already started.
>
>> 3) What are the plans for repositories and their contents?
>>
>> What repos will be created, and what will be in them.  When will new
>> ones be created, and is there any process around that.
>
> Currently, OpenStack in Debian represents 237 packages, which are all
> listed there:
> https://qa.debian.org/developer.php?login=openstack-devel@lists.alioth.debian.org
>
> Some of the more generic ones will be moved to do package maintenance
> under the DPMT (Debian Python Module Team). I'm thinking for example
> about python-nose-parametrized, python-nose-timer, python-termcolor,
> python-termstyle, python-rednose, python-jingo, python-couleur,
> python-croniter, python-nosehtmloutput, python-nose-exclude,
> python-mockito... This kind of packages.
>
> That's maybe 20 to 30 packages to move there. However, I am waiting for
> the DPMT to finish its migration from SVN to Git, as I don't really want
> to jump 20 years in the past. These packages can stay under the Debian
> OpenStack package group on alioth.debian.org in the mean while (James
> Page already contributes to this git repository collection).
>
> All of the other Git repositories, with anyone OpenStack upstream, will
> move to upstream Gerrit. So, all of python-*client, python-oslo.*,
> python-xstatic-*, python-migrate, etc. I haven't yet counted how many
> repositories that represent, but that's a lot. Maybe between 150 to 200,
> and of course, growing as we constantly add new packages.

Do you really need separate repositories for each package? Why not have 
one repository with several directories in it?

> We would like to prefix all Debian packaging Git repository with "deb-".
>
>> 4) Who is on the team(s)?
>>
>> Who is interested in the overall effort?  Who is signing up for
>> distro-specific work?
>
> As a start, and for the Debian+Ubuntu part, there's going to be James
> Page, Chuck Short and myself as a start as core contributors with
> special ACLs. Then we will see, with time, who to add as core. Maybe
> Corey Bryant (also working on packaging at Canonical).
>
> Then I hope more people Mirantis guys will soon get involved as well.
>
> But also, what drives this initiative is to have the operation guys to
> have a say as well. So we hope that experienced package maintainers will
> be able to review their proposals which will be more than welcome.
>
>> Who will be the initial PTL?
>
> James Page and myself agreed that I would be the PTL for this Liberty
> cycle. We also agree to change PTL on each cycle (as we both believe
> it's a big overhead which we would like to share).
>
>> I think if the discussion here can answer those questions, you should
>> update the governance repo change with that information
>
> Done for the PTL part. Is there anything else I should change? The list
> of repo can't be written right away. But can I write openstack/deb-* ?
>
>> we can get all
>> the participants to ack that, and the TC will be able to act.
>
> We have Debian + Ubuntu doing the ACK already. :)
>
>> Thanks again for driving this.
>
> Thanks a lot for your support.


Andreas
-- 
  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
    GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
        HRB 21284 (AG Nürnberg)
     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126