Open Stack

On 3/18/2014 7:21 AM, Thomas Goirand wrote:
> 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?

How about for one simply requiring that the global-requirements change 
is actually tied to something needed in OpenStack, i.e. package x at 
version y fixes openstack bug z.  Think of it like how we sync 
olso-incubator patches in nova, the rule is it should be a sync for a 
change needed in nova, be it bug fix or feature, we don't just sync to sync.

>
> Cheers,
>
> Thomas Goirand (zigo)
>
> [1]
> http://qa.debian.org/developer.php?login=openstack-devel@lists.alioth.debian.org
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 

Thanks,

Matt Riedemann