Open Stack

On 03/05/2013 10:02 PM, Mark McLoughlin wrote:
> In practical terms, I'm proposing doing:
> 
>  -package = 'oslo-config'
>  -version = '2013.1'
>  +package = 'oslo.config'
>  +version = '1.1.0'
> 
> in oslo-config's setup.py

I'm sorry, I will have to be the bad guy complaining and ranting here. I
hate to do so, but I have to explain what the consequences can be, since
it doesn't seem to be understood or known.

As I wrote on IRC, we can talk for a century about repainting the shed,
this wont make things work better. This is only added work for no real
benefits.

On the Debian packaging side of things, I will to:

- wait until python-oslo-config gets in, since it's still in the FTP
masters NEW queue with lots of other Openstack packages:
http://ftp-master.debian.org/new.html

I will not consider asking the FTP masters to remove the package from
the NEW queue, as I don't want to miss my turn, waiting time is
currently already too high (it takes between 1 or 2 months currently, to
have a new package accepted).

Then when it's in debian experimental, I have 2 alternatives:

1# Once it's in, upload the "fixed name" version, and wait (another 1
month?), add a Break: python-oslo-config and a Replaces:
python-oslo-config in debian/control, which I will have to carry for the
next millennium otherwise, someone might complain that I'm not providing
a correct upgrade path in SID to SID upgrades.

- Fix all dependencies in all Grizzly packages (they all have already,
hard-coded in build-depends: and depends:, a dependency to
python-oslo-config).

- When done, ask for removal of python-oslo.config.

- Pray that there wont be a time where python-oslo-config *AND*
python-oslo.config will be required at the same time (this can happen if
not all package updates are available at the same time, and that some
are lagging waiting for FTP masters approval).

Now, imagine that if Wheezy was out, and Grizzly uploaded to SID, then
I'd have to manage a transition with the release team, just because "it
looks better". Lucky, I will not have to do such thing, as none of
Grizzly is uploaded yet.

Or:

2# Keep python-oslo-config, and simply add a Provides:
python-oslo.config for the rare cases where I forgot, and add
pydist-override, and that's it. Unfortunately, this also means doing
something different from Ubuntu, which I am always trying to avoid if
possible (in the hope that we can, in some vague future, have a tiny
hope of doing the packaging work together... :P).

If I was a lazy man, and didn't want to bother FTP masters, release
team, and so on, I could choose #2, and keep python-oslo-config as the
"main" package name, so your efforts will be wasted.

I'm also wondering who you are trying to please here. Because you
clearly chatted about the name of the distributions package name, saying
that we could call it python-oslo.config. Well, the distribution guy is
telling you: don't change what's right now, it's fine and not broken, so
don't try to fix anything! :)

Don't get me wrong, I do agree with the theory that oslo.config "looks
nicer" than oslo-config. But why do we have to care so much? Seriously,
don't we have something more important to do??? How many distro already
picked-up the dash instead of the proposed dot, and thought this
packaging part was already done? How many human hours are you proposing
to waste here, in unnecessary added work, just because "it looks nicer"?
You even wrote: "I don't think there's necessarily a standard for naming
these things", so why bother?

As for the version numbering, that's going to be an ugly added epoch in
the visioning, which doesn't show in the file names. Eg, the package
version will have to be 1:1.1.0-1. While I hate these, it's unavoidable,
and we have already so many of them in the Openstack packages. I've lost
any kind of hope a long time ago for upstream authors to have consistent
(eg: always increasing) version numbers anyway, and it's not such a big
deal.

Again like I wrote on IRC, I've expressed my opinion, feel free to
ignore it if you like, and go ahead with the rename. Distributions
should adapt to upstream changes anyway. But if you do, please remember
that we, downstream distribution maintainers, have to deal with such
painful changes. I strongly feel that we should try to keep such kind of
last minute changes *before* a freeze, as this is typically what should
*not* be granted a freeze exception, IMO.

Thomas