Open Stack

On 03/18/2014 06:12 PM, Thierry Carrez wrote:
> Thomas Goirand wrote:
>> We're now 1 month away from the scheduled release date. It is my strong
>> opinion (as the main Debian OpenStack package maintainer) that for the
>> last Havana release, the freeze of dependency happened really too late,
>> creating issues hard to deal with on the packaging side. I believe it
>> would be also hard to deal with for Ubuntu people (with the next LTS
>> releasing soon).
>>
>> I'd be in the favor to freeze the dependencies for Icehouse *right now*
>> (including version updates which aren't packaged yet in Debian).
>> Otherwise, it may be very hard for me to get things pass the FTP masters
>> NEW queue in time for new packages.
> 
> I'm all for it. In my view, dependency freeze should be a consequence of
> feature freeze -- we should count any change that requires the addition
> of a new dependency as a feature.
> 
> That said, the devil is in the details... There are bugs best fixed by
> adding a library dep, there are version bumps, there are Oslo
> libraries... I've added this topic for discussion at the Project/release
> meeting today (21:00 UTC) so that we can hash out the details.

There's a few level of difficulties.

1- Upgrading anything maintained by OpenStack (Oslo libs, python-client*
packages, etc.) isn't a problem.

2- Update for anything in the QA page of the OpenStack Debian packaging
team [1] is less of a problem.

3- Updating anything that is team-maintained in the Python Module team,
then I'm less comfortable.

4- Updating anything that is not maintained in any team in Debian is
problematic.

5- Adding a new Python module that doesn't exist in Debian at all for
the moment is *REALLY* a *BIG* issue, because it would go through the
FTP master new queue.

Not freezing dependencies for 1- until the release is ok, 2- should be
frozen at some point (let's say 2 weeks before the release?), for all
other cases, I think we should consider that shouldn't do modifications.

On 03/18/2014 07:28 PM, Sean Dague wrote:
> Things which are currently outstanding on freeze.
>
> Upstream still requires - SQLA < 0.8. Thomas has forked debian to
> allow 0.9. I think we should resolve that before release.

I of course agree with this.

> Trove turned out to not be participating in global requirements, and
> has 3 items outside of requirements.

Could you list them?

> I also think we probably need a larger rethink of the
> global-requirements process because I see a lot of review's bumping
> minimum versions because "some bugs are fixed upstream". And those all
> seem to be sailing through. I think for incorrect reasons. No one's
> objected at this point, so maybe that's ok. But it's probably worth a
> huddle up.

What would be the way to fix it then?

Cheers,

Thomas Goirand (zigo)

[1]
http://qa.debian.org/developer.php?login=openstack-devel@lists.alioth.debian.org