Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit

[Joerg Jaspert <joerg@debian.org>]

On 13182 March 1977, Thomas Goirand wrote:

> Note that the upstream changelog issue was quickly solved (and I agreed
> with the FTP masters view on it), though remains the "problem" of having
> too many binaries, according to the FTP masters.

Ay. I go into the reasons for that somewhere down below.

> I decided to leave up to before the OpenStack summit to the FTP masters,
> so that they could approve Nova. With no reply from them, which made me
> miss my dead line, I am left with no other option but to escalate the
> issue.

Whyever do you set yourself such a deadline, depending on other stuff
you can't control?
Also, if your goal would be to get the packages accessible for others -
reprepo, dpkg-scan* and co are all not hard to use.

> I would like first the new DPL to express his view: is this the role of
> the FTP masters to overrule the technical opinion of a DD? Do they have
> the rights to block a package just on the ground that they only don't
> like how many binary packages it contains? Shouldn't they use, like
> every other DD, the BTS and the project lists to discuss such a
> technical issue?

As Ian and Raphael already told you - and as the actual delegation also
tells, yes, it is.
And just for the record: We *do* open bugs for stuff we find in NEW, if
that stuff does not need to be fixed before accepting. You know, minor
stuff like bugs in scripts, control file, blargh. Things that don't
directly have impact on all of the archive and its consumers.

> As a consequence, I am questioning the motivation behind all this, and
> asking myself if we aren't seeing here (yet) another instance of
> miss-behavior from Ganneff, who probably disliked the fact that I
> defended my friend when he expelled him, and when I questioned the
> possibilities of getting rid of the NEW queue in a debian-devel thread.
> I have of course no proof to back this up, and will probably never know
> if this really is an act of revenge, though I would like both the ctte
> and the DPL to take note of the event as (very) inappropriate. I would
> also like to point that the tone from Ganneff isn't acceptable. From
> someone who is both DSA, FTP Master and DAM (why so many powerful roles
> on a single pair of hands btw?), this isn't to be expected. For the
> moment, I will just ignore this, but if it was to happen again anytime
> soon, I will act upon it.

You know, if the subject would have been "Serious problems with
Mr. Jaspert" that would so have made my day. I still don't have that in
my personal hall of fame, which makes me sad. Pretty please, could the
next one unhappy with me take that in their notes to check before
sending mail? :)

Seriously, if I would let such small and minor things like "he disagrees
with one of my decisions" influence my Debian work, than we could
basically close NEW, wouldn't have many people anymore to run for DPL
nor would I probably be in any position to ever receive my problems mail.
Honestly I hadn't even thought about that point you mention.

That I'm not DSA got already pointed out, but hey, you forgot a whole
ton of other roles I have. More accuracy please. :)

> Now, I would like some advice on how to move forward. Leaving this rot
> isn't an option for me.

Oh thats simple. You discuss with us and we get out somewhere in a
sensible middle.

On 13182 March 1977, Thomas Goirand wrote:

> I have no words to express how stupid I feel right now.

If we trust wc, then you had 261. In 33 lines with 1421 characters even!

> The effect of my mail is the exact opposite of what I wanted to achieve.


> What I wanted to do was reaching the tech committee *members* only
> (and

Now thats missing one word, -private.

> It was never my intention to make the communication worse with the FTP
> Masters,

You haven't. You got called a few choice names. Now, lets go on.

> Now, I'm seeing that, as this mail went public when it should never have
> been, it's making the situation worse... :(

Nope.

> I hope that the original issue can be solved never the less, and that
> the communication with the FTP masters can be restored in a sane way.

We are always happy with sanity. We don't see it often enough.

------------------------------------------------------------------------

Now, as we have it here anyways: I stay by what I said. The amount of
splitting you did is nothing that the Debian archive should get. It's
all nice that upstream may like it, but we are talking about Debian, not
Upstream. And we do consider a bit more here. Each and every package
takes extra space in the various metadata places, like Packages (times
number of architectures), our database, our various handling scripts of
archive/testing/pts/bugs/whatnot. So we have to decide between an
excessive split and something that makes sense.

The nova packages consist[1] mostly of one file in /usr/bin with the size
between 1500 and 3000 bytes, or worse - one file in /etc between 45 and
222 bytes - or even nothing (nova-volume).

Lets pick one set out here. nova-compute-*. Those seem to ship config
files for compute nodes of different types. lxc, kvm, qemu, whatever.
We question two things here: That it is neccessary to split them into
one <100byte file per package ones, and that they all have to conflict
with each other. The second part is something for a important bugreport
- why do you presume to tell me I might not want qemu and uml, or
qemu/kvm or whatever on one machine? I may not be able to run it at same
time, but why may I not install them?
But as said, thats a bug. What kicks it out of NEW is the split. One
nova package delivering the configs[2] and the admin select what he
wants with a simple ln. Or cp. Or, modern world and so, debconf
questions. Like, err, all our *dm do, as an example.


Now, lets have one technical point too. Why are you doing a chmod +x
unconditionally in postinst on all the plugin files you just shipped
with the nova-xcp package? And similar in the -network?
 

[1] Leaving out /usr/share/doc. And all of the package have a (sometimes
    =) dependency on nova-common, from the same source package. So you
    can even leave out the doc dir and symlink it to the one in
    nova-common.
[2] why does the xen one put its config into /usr/share/nova-compute-xen
    while all the others use /etc/nova for it?

-- 
bye, Joerg
Television! Teacher, mother, secret lover.