[openstack-dev] Icehouse dependency freeze
mriedem at linux.vnet.ibm.com
Tue Mar 18 17:46:55 UTC 2014
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  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
> 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.
> Thomas Goirand (zigo)
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev