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