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-de...@lists.alioth.debian.org _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
