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

[Thomas Goirand]

Dear ctte, dear (new) DPL,

After I had almost all of my packages approved just right before the
Openstack summit which starts in few hours now, the FTP masters decided
that it was wise to block my Nova package just 5 days before the summit,
for a reason which IMO isn't good enough. Please read this thread:

http://lists.alioth.debian.org/pipermail/openstack-devel/2013-April/002257.html

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.

The following DDs have already agreed with my view on the mater:
- Ola Lundqvist
- Julien Danjou
- Mehdi Abaakouk

They are all involved in the packaging of OpenStack and are OpenStack
users, and therefore have a good understanding of the project.

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.

So, before I summit a bug to the ctte and escalate this issue, I would
like some advices from both the new DPL and the ctte.

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?

Note that I am already very upset about what happened because it puts me
in a less good position to discuss with Canonical folks about a joined
effort for the packaging of OpenStack, here at the summit in Portland. I
have expressed this concern publicly on the OpenStack packaging list,
and to the FTP master themselves, with absolutely no reaction from them.
It seems they don't care, or are willingly ignoring my repeated requests.

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.

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

To the ctte: What would be considered a reasonable delay before
submitting a bug to the ctte?

To the DPL: could the role of the FTP masters be clarified? I have
discussed multiple times with other DDs, and it seems that I'm not alone
thinking they are doing more than their mandates allows, when rejecting
packages on technical grounds (while their role is only validating the
licensing part of packages). Is this as well the view of the DPL?
Whatever the DPL thinks, could we have somewhere clear roles defined and
written on a simple document?

To all of you: what advice can you give to escalate this issue in the
best way possible?

Cheers (from my hotel room in Portland),

Thomas Goirand (zigo)

P.S: Congrats to Lucas. I'm truly satisfied you are our new DPL, and I
feel sorry that the first interaction I have with you as DPL is for
bringing this kind of shitty problem.

[Adam D. Barratt]

Post by Thomas Goirand
I would
also like to point that the tone from Ganneff isn't acceptable. From
someone who is both DSA, FTP Master and DAM

I'm sure both DSA and Joerg will be surprised to discover you've
appointed him to the team...

Regards,

Adam

[Adam D. Barratt]

[...]

Post by Thomas Goirand
- Mehdi Abaakouk

I may be missing something here, but Mehdi doesn't appear to be a DD
according to db.d.o.

Regards,

Adam

[Thomas Goirand]

Post by Adam D. Barratt
[...]

Post by Thomas Goirand
- Mehdi Abaakouk

I may be missing something here, but Mehdi doesn't appear to be a DD
according to db.d.o.
Regards,
Adam

My bad indeed.

Thomas

[Steve McIntyre]

Post by Thomas Goirand
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.

Thus turning a technical disagreement with the ftp team into a
personal attack on Joerg. Well done. :-(

Adam has already pointed out your factual mistakes.

[Thomas Goirand]

I would prefer it
if you stopped throwing around public accusations of ill will unless

Hi,

This is a *mistake* which I just did. I was intending to send a mail to
the ctte memebers, and not to the list. I feel truly sorry for that.

I was in fact, trying to ask for advices, precisely to avoid any public
laundry washing. :(

Please everyone, excuse me for that big mistake.

Thomas

[Ian Jackson]

Post by Thomas Goirand
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?

The ftpmasters are entitled to reject packages for technical reasons.
For example, see the TC decision on ia32-libs-tools:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535645#162

If you feel you need to escalate such a decision you are indeed
entitled to do so by referring the matter to the TC.

Post by Thomas Goirand
To the ctte: What would be considered a reasonable delay before
submitting a bug to the ctte?

The question isn't how long to wait. You should make a constructive
effort to engage with the ftpmasters' objections, to try to convince
them. That work wouldn't be wasted even if you don't convince the
ftpmasters, because most of the work is in figuring out what the
issues are and putting your case together.

You should refer to the TC when it becomes clear that neither you nor
the ftpmasters are going to be convinced, or if you feel that the
ftpmasters aren't engaging sufficiently constructively in the
conversation.

Ian.

[Thomas Goirand]

Hi,

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

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
not the public list) and Lucas, then ask how I could manage the
emotional situation. Which is why I wrote about what my feelings were
with Ganneff, and how the exchange turned out. I thought I would get
valuable advices about how to deal with it.

It was never my intention to bring this publicly, and even less to do
public accusations. The fact that I wrote this mail while being
jet-laged, woken up in the middle of the night by it, is probably linked
to writing to the wrong address (eg: a public list, instead of only
reaching the CTTE members).

It was never my intention to make the communication worse with the FTP
Masters, or even harm the Debian project as a whole by opening some ctte
bugs which would have been public (we are much better of solving things
without it). I wanted to try everything possible before turning back to
such extreme ways of solving things.

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

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.

Finally, I hope that all parties involved will accept my apologies.

Thomas

[Bdale Garbee]

Post by Thomas Goirand
The fact that I wrote this mail while being
jet-laged, woken up in the middle of the night by it, is probably linked
to writing to the wrong address ...

This is probably the most useful thing we can all take from this
discussion... any time you are emotionally wound-up, go ahead and type
the text of the email you want to send, because it's a great way to
"clear your head" and get all your frustrations out... just don't hit
"send" until after you've slept on it and come back with a clearer head!

Bdale

[Goswin von Brederlow]

Post by Ian Jackson

Post by Thomas Goirand
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?

The ftpmasters are entitled to reject packages for technical reasons.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535645#162

Note that the discussion around that issue would rather support his
cause. What I got from that issue was that the ftp team had no reason
to remove the package but they did it anyway. On the other hand the
TC had no reason to override that decision even if it was wrong. Try
finding a technical justification why a package MUST be in debian.

Further the ftp team has never followed the committees
recommendations. All requests, by me, by other DDs, even by members of
the TC, for an accounting have been met by silence. I asked the TC
to help get to such an accounting and the TC has uterly failed me in
that. Summariced in one sentence the result was "The ftp team has the
right to remove packages from the archive, we don't know why and we
can't force them to tell us why."

It's that appearance of "the ftp team is above everyone else" that
rubs the wrong way.

Post by Ian Jackson
If you feel you need to escalate such a decision you are indeed
entitled to do so by referring the matter to the TC.

Luckily this issue doesn't seem to have become a black hole, as seen
in Joergs reply. His explanation makes a good case for why it was
rejected, even recommends superior solutions that reduce the package
count while improving the user experience.

So I hope Thomas bad experience with the ftp team was only temporary
and can be repaired.

Post by Ian Jackson

Post by Thomas Goirand
To the TC: What would be considered a reasonable delay before
submitting a bug to the TC?

The question isn't how long to wait. You should make a constructive
effort to engage with the ftpmasters' objections, to try to convince
them. That work wouldn't be wasted even if you don't convince the
ftpmasters, because most of the work is in figuring out what the
issues are and putting your case together.
You should refer to the TC when it becomes clear that neither you nor
the ftpmasters are going to be convinced, or if you feel that the
ftpmasters aren't engaging sufficiently constructively in the
conversation.
Ian.

Unfortunately even the TC can't force the ftp team to engage in any
conversation. Basically they can overrule a conversation but they
can't overrule silence. They can overrule a bad reason given but they
can't overrule when no reason is given.

As you say "most of the work is in figuring out what the issues are".
Which only works if there actualy is an issue. Which Joergs answere
luckily explains. Now this issue can be put behind and a solution can
be worked on.

Thomas: Rejoice. You seem to have gotten your answere and a way out of
the problem. I wasn't so lucky.

MfG
Goswin

[Ian Jackson]

Post by Goswin von Brederlow

Post by Ian Jackson
You should refer to the TC when it becomes clear that neither you nor
the ftpmasters are going to be convinced, or if you feel that the
ftpmasters aren't engaging sufficiently constructively in the
conversation.

...

Post by Goswin von Brederlow
Unfortunately even the TC can't force the ftp team to engage in any
conversation. Basically they can overrule a conversation but they
can't overrule silence. They can overrule a bad reason given but they
can't overrule when no reason is given.

For the record, this is not how I would approach such a question.

In the absence of a coherent rationale for a decision we're asked to
review (whether made by a maintainer, ftpmasters, or whoever), I would
vote to overrule.

Such a rationale might be provided by the parties to the dispute, or
by others, or might be evident to, and explained by, some or all of
the committee members. In the case of #535645 I think the decision
was taken based on a rationale most clearly enunciated by Andi and
Steve.

Regards,
Ian.

[Andreas Barth]

Post by Ian Jackson

Post by Goswin von Brederlow

Post by Ian Jackson
You should refer to the TC when it becomes clear that neither you nor
the ftpmasters are going to be convinced, or if you feel that the
ftpmasters aren't engaging sufficiently constructively in the
conversation.

...

Post by Goswin von Brederlow
Unfortunately even the TC can't force the ftp team to engage in any
conversation. Basically they can overrule a conversation but they
can't overrule silence. They can overrule a bad reason given but they
can't overrule when no reason is given.

For the record, this is not how I would approach such a question.
In the absence of a coherent rationale for a decision we're asked to
review (whether made by a maintainer, ftpmasters, or whoever), I would
vote to overrule.
Such a rationale might be provided by the parties to the dispute, or
by others, or might be evident to, and explained by, some or all of
the committee members. In the case of #535645 I think the decision
was taken based on a rationale most clearly enunciated by Andi and
Steve.

To see an example where we overrule, see #698556 where we decided to
overrule a maintainer *because* there was no sufficient cause
communicated for a decision. I would have been more happy with more
communication, but in the end, we had to decide with what we got.


Andi

[Goswin von Brederlow]

Post by Ian Jackson

Post by Goswin von Brederlow

Post by Ian Jackson
You should refer to the TC when it becomes clear that neither you nor
the ftpmasters are going to be convinced, or if you feel that the
ftpmasters aren't engaging sufficiently constructively in the
conversation.

...

Post by Goswin von Brederlow
Unfortunately even the TC can't force the ftp team to engage in any
conversation. Basically they can overrule a conversation but they
can't overrule silence. They can overrule a bad reason given but they
can't overrule when no reason is given.

For the record, this is not how I would approach such a question.
In the absence of a coherent rationale for a decision we're asked to
review (whether made by a maintainer, ftpmasters, or whoever), I would
vote to overrule.
Such a rationale might be provided by the parties to the dispute, or
by others, or might be evident to, and explained by, some or all of
the committee members. In the case of #535645 I think the decision
was taken based on a rationale most clearly enunciated by Andi and
Steve.
Regards,
Ian.

Neither of whom was ftp-master and could only speculate about the
reason why ia32-libs-tools was removed. Andi even personally asked
ftp-master for clarification but never got a reply.

Note that 95% of what Andi and Steve said (basically anything past the
first mail) was related to the future plans for ia32-libs-tools and
how it would transition itself to pure multiarch. Something that was
at that time still years away and still in flux.


But water under the bridge. A short while ago i updated my last system
using ia32-libs-tools to testing and transitioned fully to multiarch
and removed my apt repository for ia32-libs-tools as access had
stopped basically for some time. All users seem to have transitioned
successfully to multiarch or stoped using 32bit legacy cruft.

I'm just sad that this option wasn't in Debian and most squeeze users
had to suffer ia32-libs/ia32-libs-gtk and its security (and other)
bugs and will have a hard time upgrading to wheezy.

MfG
Goswin

[Stefano Zacchiroli]

Post by Thomas Goirand
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

Then I strongly recommend that you refrain from suggesting something
like the above in the future.

I don't think that anyone in our community should go around spreading
that kind of accusations, unless they're backed by *very* convincing
evidence. I believe that the negative side-effects of doing so are far
worse than anything that could possibly be be gained (technically or
otherwise).

FWIW I'm in charge as DPL for only 1.5 more days so I'll leave this up
to Lucas to pick, in case something DPL-ish is actually needed.

Cheers.

[Raphael Hertzog]

Hi Thomas,

Post by Thomas Goirand
So, before I summit a bug to the ctte and escalate this issue, I would
like some advices from both the new DPL and the ctte.

I'm part of neither and I can understand your frustration but your mail
has been written too quickly while the emotion level was still too high.

It results in multiple inaccuracies and reflects badly on you (at least to
my eyes).

Post by Thomas Goirand
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?

The project has implictly granted powers to ftpmasters to apply some level
of technical review, they have even documented some of them:
http://ftp-master.debian.org/REJECT-FAQ.html

Post by Thomas Goirand
As a consequence, I am questioning the motivation behind all this, and

This is the part where you cross the line that you should not have
crossed. You got a reject mail from Ansgar Burchardt, not from Ganneff
(and Ganneff is not DSA).

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

If I were in the openstack team, I would personally query ansgar
privately, saying that I'm sorry for the harsh tone that got used and ask
him whether he will approve the packages now that the changelog has been
factorized in the -common package or if there's any other remaining issue
beside the multiple binary package for which multiple persons voiced their
support.

Post by Thomas Goirand
To the ctte: What would be considered a reasonable delay before
submitting a bug to the ctte?

It entirely depends on the kind of interactions that you manage to have
with ftpmasters.

But I would advise you to not bring the issue to the -ctte as long as
communication with ftpmasters is happening and as long as forward progress
is being made.

I would also suggest you to step down in the communication with ftpmasters
and leave it up to someone else on the Openstack team, someone that is
less emotionnaly engaged than you.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

[Thomas Goirand]

Post by Raphael Hertzog

Post by Thomas Goirand
As a consequence, I am questioning the motivation behind all this, and

This is the part where you cross the line that you should not have
crossed.

Yeah, publicly, I shouldn't have. Yet, I was trying to ask friends for
help, because I could feel some big tensions which was hard to handle
alone. To Ganneff, sorry.

Post by Raphael Hertzog

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

If I were in the openstack team, I would personally query ansgar
privately, saying that I'm sorry for the harsh tone that got used and ask
him whether he will approve the packages now that the changelog has been
factorized in the -common package or if there's any other remaining issue
beside the multiple binary package for which multiple persons voiced their
support.

I did ask Ansgar on IRC, but got no answer. Though not recently, after
others have voiced their support.

Post by Raphael Hertzog

Post by Thomas Goirand
To the ctte: What would be considered a reasonable delay before
submitting a bug to the ctte?

It entirely depends on the kind of interactions that you manage to have
with ftpmasters.
But I would advise you to not bring the issue to the -ctte as long as
communication with ftpmasters is happening and as long as forward progress
is being made.

I believe it was stalled, which is why I asked for advices.

Post by Raphael Hertzog
I would also suggest you to step down in the communication with ftpmasters
and leave it up to someone else on the Openstack team, someone that is
less emotionnaly engaged than you.

That is probably a good advice, though I'm the one who does most of the
work and who need to upload.

Thomas

[Ian Jackson]

Post by Thomas Goirand
I did ask Ansgar on IRC, but got no answer. Though not recently, after
others have voiced their support.

I don't think "others ... [voicing] their support" is really the key
thing here. Technical decisions like this will be made for technical
reasons, not by counting supporters etc.

Post by Thomas Goirand

Post by Raphael Hertzog
But I would advise you to not bring the issue to the -ctte as long as
communication with ftpmasters is happening and as long as forward progress
is being made.

I believe it was stalled, which is why I asked for advices.

If you think the conversation is stalled and cannot be restarted then
a referral to the TC is appropriate.

Post by Thomas Goirand

Post by Raphael Hertzog
I would also suggest you to step down in the communication with ftpmasters
and leave it up to someone else on the Openstack team, someone that is
less emotionnaly engaged than you.

That is probably a good advice, though I'm the one who does most of the
work and who need to upload.

Yes, please, get someone else to act as driver for this issue if you
can. You are of course entitled yourself to escalate to the TC, but
we'll probably get a more constructive discussion if you try to keep
out of it.

If you and your collaborators think the conversation with ftpmaster is
essentially over, and want to escalate to the TC, we'd appreciate it
if you could follow the process here:
http://www.debian.org/devel/tech-ctte
That will make it easier to keep track of the discussion (and if you
follow that process we won't have to do the bug gardening and
forum-shifting ourselves).

Thanks,
Ian.

[Thomas Goirand]

Post by Ian Jackson
If you and your collaborators think the conversation with ftpmaster is
essentially over, and want to escalate to the TC

I hope it's not, and that the TC thing can be avoided.

Thomas

[Lucas Nussbaum]

Hi,

Post by Thomas Goirand
Dear ctte, dear (new) DPL,

First, note that my term starts on the 17th.

Post by Thomas Goirand
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.

What deadline are you talking about?
Missing a self-imposed deadline is not a good thing, I agree. But
isn't escalating an issue to meet a self-imposed deadline a bit
excessive?

Post by Thomas Goirand
Note that I am already very upset about what happened because it puts me
in a less good position to discuss with Canonical folks about a joined
effort for the packaging of OpenStack, here at the summit in Portland. I
have expressed this concern publicly on the OpenStack packaging list,
and to the FTP master themselves, with absolutely no reaction from them.
It seems they don't care, or are willingly ignoring my repeated requests.

I agree with the importance of working with other OpenStack packagers.
I agree that it could be easier when packages are in Debian (though
it's not really clear to me why).
But in that case, couldn't you just use an unofficial repo in the
meantime, or point to a VCS?

Post by Thomas Goirand
To all of you: what advice can you give to escalate this issue in the
best way possible?

Avoiding ad hominem attacks would be a good start.

In the specific case of the split in several binary packages (which
seems to be the only remaining issue blocking the acceptance of the
package), the TC is probably a much more suitable body to rule on this
(once, as Ian said, it is clear that other solutions have failed).

Lucas

[Thomas Goirand]

Post by Lucas Nussbaum
But in that case, couldn't you just use an unofficial repo in the
meantime, or point to a VCS?

This has already been done.

Post by Lucas Nussbaum

Post by Thomas Goirand
To all of you: what advice can you give to escalate this issue in the
best way possible?

Avoiding ad hominem attacks would be a good start.

As I just wrote, I wanted to ask for advices to a few people, my message
would have been different if I wanted to write to a public list.

Again, sorry for this.

Thomas

[Kurt Roeckx]

Post by Lucas Nussbaum
the TC is probably a much more suitable body to rule on this

I'd like to point out that if the DPL delegated that decision to
ftp-master, and ftp-master made a decission, the DPL can't
override that.


Kurt

[Lucas Nussbaum]

Post by Kurt Roeckx

Post by Lucas Nussbaum
the TC is probably a much more suitable body to rule on this

I'd like to point out that if the DPL delegated that decision to
ftp-master, and ftp-master made a decission, the DPL can't
override that.

Sure, I was just pointing out that, if Thomas was seeking more opinions,
it's a much better idea to consult the TC than the DPL on such a
technical matter. (s/rule/consult/ would have been better)

Lucas

[Goswin von Brederlow]

Post by Kurt Roeckx

Post by Lucas Nussbaum
the TC is probably a much more suitable body to rule on this

I'd like to point out that if the DPL delegated that decision to
ftp-master, and ftp-master made a decission, the DPL can't
override that.
Kurt

He can't? What about undelegating ftp-master so the job reverts back
to the DPL and then reversing the decision? The DPL could then even
redelegate the job to the old team and they could play ping-pong for a
while.

Right?

MfG
Goswin

[Neil McGovern]

Post by Goswin von Brederlow

Post by Kurt Roeckx

Post by Lucas Nussbaum
the TC is probably a much more suitable body to rule on this

I'd like to point out that if the DPL delegated that decision to
ftp-master, and ftp-master made a decission, the DPL can't
override that.
Kurt

He can't? What about undelegating ftp-master so the job reverts back
to the DPL and then reversing the decision? The DPL could then even
redelegate the job to the old team and they could play ping-pong for a
while.
Right?

Um, nope. See Debian Constitution 8.2

Neil
--

[Joerg Jaspert]

Post by Thomas Goirand
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.

Post by Thomas Goirand
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.

Post by Thomas Goirand
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.

Post by Thomas Goirand
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. :)

Post by Thomas Goirand
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.

Post by Thomas Goirand
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!

Post by Thomas Goirand
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.

Post by Thomas Goirand
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.

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

Nope.

Post by Thomas Goirand
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?

[Thomas Goirand]

Post by Joerg Jaspert

Post by Thomas Goirand
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.

Post by Thomas Goirand
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 do that already since last autumn. Here's the latest build:

deb ftp://archive.gplhost.com/debian grizzly main
deb ftp://archive.gplhost.com/debian grizzly-backports main

This things uses Jenkins CI: on every git push, packages gets rebuilt
and pushed (on a more private URL which I don't advertize about, it only
show on the IRC channel). Once I'm satisfied with the packages (after
installation tests of all of them), I start a script to publish all
packages on the above repositories. This workflow is also very
convenient for testing things, and helped me to avoid uploading crap to
Debian.

So yes, I'm doing that already. Yet I would still prefer to have things
in the Debian repositories.

Post by Joerg Jaspert
Now, lets go on.

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

Nope.

Post by Thomas Goirand
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.

Thanks.

Post by Joerg Jaspert
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.

Not just upstream. Integrators and users as well. They are my priority,
just like for everyone in Debian.

Post by Joerg Jaspert
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).

I am on the side of Russ Allbery here. Ideally, as a developer, I
shouldn't have to worry about this, too much, and here is IMHO too much.
The infrastructure problems which Debian runs into shouldn't clash with
the convenience users either, to the point where Debian would be a very
special case with packaging different from other distro, and breaking
existing puppet scripts others are already maintaining (for Debian
and/or Ubuntu).

Post by Joerg Jaspert
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.

As you know, a package isn't only made with what files it holds. It also
contains precious dependencies. By asking to switch to a single package,
you are removing the possibility to have dependencies that make sense.

Package: nova-compute-kvm
Depends: python-libvirt, libvirt-bin, kvm

I don't want to just document this, OpenStack is complicated enough
already, adding installation of dependencies as a manual thing matching
configuration files or debconf values would be annoying.

Post by Joerg Jaspert
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?

For testing, I would understand. But for going on production, it doesn't
make sense to install things for more than one hypervisor in a single
system.

Post by Joerg Jaspert
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?

Because otherwise it doesn't work (if I remember well, it took me a full
month last year to find this out). Or are you pointing out that I could
ship these files already with the +x bit? Though, if that is your view,
how much would you rate this seriousness? IMO, not more than wishlist.

Post by Joerg Jaspert
[2] why does the xen one put its config into /usr/share/nova-compute-xen
while all the others use /etc/nova for it?

If I remember well (it's been more than a year now...), this is a
problem upstream code, which searches from this location. XCP in Debian
was made as an adaptation from XCP in CentOS, and there are still lots
of things that needs to be fixed upstream. As you may (or not) have seen
on the BTS, I spent the whole year either working on fixing lots of such
issues myself, or trying to push upstream to do so (when it is located
in the Ocaml code which I don't understand). I believe I pointed that
one out to upstream, but it hasn't been addressed yet. I will file a bug
on the BTS to remember it. This kind of things is rather low on both my
priority (see the remaining issues on the BTS), and the one of upstream,
unfortunately. It isn't a policy violation, and AFAIK (correct me if I'm
wrong), it is just not very standard, and annoys me a but with
dh_python2 calls in debian/rules. So I agree shall be fixed at some
point (upstream), though I think it's not that important / urgent.

Thomas

[Russ Allbery]

Post by Thomas Goirand

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).

I am on the side of Russ Allbery here. Ideally, as a developer, I
shouldn't have to worry about this, too much, and here is IMHO too much.
The infrastructure problems which Debian runs into shouldn't clash with
the convenience users either, to the point where Debian would be a very
special case with packaging different from other distro, and breaking
existing puppet scripts others are already maintaining (for Debian
and/or Ubuntu).

I should probably be clearer here, since that's not actually my "side". :)

I feel like this is a technical constraint, and I would always prefer to
solve technical constraints instead of making people work around them.
But as mentioned I don't have a good solution, and in the absence of a
good solution, I think it's reasonable for packagers to work within that
constraint or at least present a strong case (which I know you're trying
to do later in your message) for why it shouldn't apply to their
situation.

This is typical of the sort of "fuzzy" kind of constraint where each
additional package, in isolation, doesn't add significantly to the
problem, and everyone can always make a case about why they're different,
but if we accepted everyone's argument, we could get ourselves into
increasing amounts of annoying trouble due to the size of the metadata.

That said, I think one reasonable approach would be to find other big wins
to significantly reduce the number of packages so that we don't have to
worry as much about this. For example, finding a different way of
handling debugging information would save enough space in the metadata to
allow for quite a few sets of micropackages.

It's unlikely that anyone actually disagrees with the ideal that the
Debian infrastructure should be transparent to the users and packagers and
just cope with whatever makes the most sense for them. The issue isn't
disagreement over that ideal, but rather the decision of what to do when
we don't have a technical solution that is currently fully capable of that
ideal.

Post by Thomas Goirand

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?

For testing, I would understand. But for going on production, it doesn't
make sense to install things for more than one hypervisor in a single
system.

FWIW, I think the testing use case is important. This is the sort of
constraint that I, as a Debian user, find really frustrating. I want to
always be able to install a package to look at it, read the documentation,
etc., even if the collection of packages I have installed doesn't make
"sense," provided that there's no technical reason why those packages
CANNOT be installed together.

[Goswin von Brederlow]

Post by Russ Allbery

Post by Thomas Goirand

Post by Joerg Jaspert
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?

For testing, I would understand. But for going on production, it doesn't
make sense to install things for more than one hypervisor in a single
system.

FWIW, I think the testing use case is important. This is the sort of
constraint that I, as a Debian user, find really frustrating. I want to
always be able to install a package to look at it, read the documentation,
etc., even if the collection of packages I have installed doesn't make
"sense," provided that there's no technical reason why those packages
CANNOT be installed together.

I'm using unionfs-fuse with its example boot script to nfs-root boot
any number of hosts from a single disk based system. As such some of
the systems booted that way may need qemu because they don't support
kvm while others should use kvm because they can.

The single server would need to have both qemu and kvm installed
and decide at boot time which to use based on cpu capabilities.

So there is your production use case that needs both installed. It's
not just for short term testing.

MfG
Goswin

PS: Given one installed Debian unionfs-fuse lets you configure and
boot a 1000 node cluster in 5 minutes.
/usr/share/doc/unionfs-fuse/examples/unionfs-fuse-nfs-root realy is
the best.

[Tollef Fog Heen]

]] Thomas Goirand

Post by Thomas Goirand
For testing, I would understand. But for going on production, it doesn't
make sense to install things for more than one hypervisor in a single
system.

I think it does: I might be interested in running less trusted code in
KVM, since it provides more isolation, and more trusted code in lxc,
which provides less isolation, so running both lxc and kvm at the same
time certainly makes a ton of sense to me.

Post by Thomas Goirand

Post by Joerg Jaspert
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?

Because otherwise it doesn't work (if I remember well, it took me a full
month last year to find this out). Or are you pointing out that I could
ship these files already with the +x bit? Though, if that is your view,
how much would you rate this seriousness? IMO, not more than wishlist.

You should ship them with the +x bit already. I'd rate it serious or
important, since you're breaking dpkg-statoverride.

(I'd love for Lintian to grow a check for changing permissions of
shipped files so we could get rid of that completely. I don't think it
has it yet.)

[Thomas Goirand]

Post by Tollef Fog Heen

Post by Thomas Goirand
For testing, I would understand. But for going on production, it doesn't
make sense to install things for more than one hypervisor in a single
system.

I think it does: I might be interested in running less trusted code in
KVM, since it provides more isolation, and more trusted code in lxc,
which provides less isolation, so running both lxc and kvm at the same
time certainly makes a ton of sense to me.

You guys are writing this as if it was impossible to switch from one
hypervisor to another. Yet this is simply not the case. You can easily
switch from one type of hypervisor to another with the current packages
(by editing /etc/nova/nova-compute.conf manually and installing the
dependencies manually as well). My point is just that multiple packages
make it possible to automate the switch in the config file and
dependencies by simply doing apt-get. I think this is an important
feature and I don't want to see it go.

If we consider that I'm requesting 5 more binary packages, and that we
have 30 000 packages in Debian, we are talking about 0.016% more binary
packages in Debian. I can't believe that only for 0.016% more binaries
is so unbearable for the archive.

Post by Tollef Fog Heen

Post by Thomas Goirand
Because otherwise it doesn't work (if I remember well, it took me a full
month last year to find this out). Or are you pointing out that I could
ship these files already with the +x bit? Though, if that is your view,
how much would you rate this seriousness? IMO, not more than wishlist.

You should ship them with the +x bit already. I'd rate it serious or
important, since you're breaking dpkg-statoverride.

Indeed. I never wrote it shouldn't be fixed. Though in my view it
shouldn't be a blocker for approving nova 2013.1, first because the bug
is already in the older versions of the package, and because nova 2013.1
fixes #700620. I believe it is a lot more annoying than just this
dpkg-statoverride thing, which I will not have time to fix until next
week when I'm back at home anyway.

Post by Tollef Fog Heen
(I'd love for Lintian to grow a check for changing permissions of
shipped files so we could get rid of that completely. I don't think it
has it yet.)

Agreed. I think I would have spot the remaining hack from last year
when I was trying to have OpenStack + XCP work together.

Thomas

[Russ Allbery]

Post by Thomas Goirand

Post by Tollef Fog Heen
I think it does: I might be interested in running less trusted code in
KVM, since it provides more isolation, and more trusted code in lxc,
which provides less isolation, so running both lxc and kvm at the same
time certainly makes a ton of sense to me.

You guys are writing this as if it was impossible to switch from one
hypervisor to another. Yet this is simply not the case.

I don't think you understood what Tollef said. He's not talking about
switching from one to another. He's talking about running both at the
same time. Other people have commented similarly.

Post by Thomas Goirand
If we consider that I'm requesting 5 more binary packages, and that we
have 30 000 packages in Debian, we are talking about 0.016% more binary
packages in Debian. I can't believe that only for 0.016% more binaries
is so unbearable for the archive.

I addressed this point in a previous message. Briefly, this is one of
those fuzzy creeping problems. Each individual case looks reasonable in
isolation, but the cumulative impact can be significant, so ftp-master is
in the unenviable position of having to apply a general policy that makes
each individual packager unhappy. (And which prompts arguments that
*their* individual package won't cause an *immediate* problem, which have
indeed predictably been raised in every discussion I've seen of this
particular problem.)

[Tollef Fog Heen]

]] Thomas Goirand

(Cc-ing you, since I don't know if you're subscribed. Apologies for the
extra copy if you are.)

Post by Thomas Goirand
You guys are writing this as if it was impossible to switch from one
hypervisor to another. Yet this is simply not the case. You can easily
switch from one type of hypervisor to another with the current packages
(by editing /etc/nova/nova-compute.conf manually and installing the
dependencies manually as well). My point is just that multiple packages
make it possible to automate the switch in the config file and
dependencies by simply doing apt-get. I think this is an important
feature and I don't want to see it go.

It sounds wrong to use dependencies where dpkg-reconfigure will do.

Post by Thomas Goirand
If we consider that I'm requesting 5 more binary packages, and that we
have 30 000 packages in Debian, we are talking about 0.016% more binary
packages in Debian. I can't believe that only for 0.016% more binaries
is so unbearable for the archive.

It's pushing the knife ever so slightly deeper into the wound. The
problem, as Russ has pointed out isn't your five extra packages or
somebody else in particular's packages. It's the cumulative weight of
all of them. Yes, in an ideal world this shouldn't be a problem, but
until somebody comes up with a fix, that's what we have to work with.

[Thomas Goirand]

Post by Tollef Fog Heen
]] Thomas Goirand
(Cc-ing you, since I don't know if you're subscribed. Apologies for the
extra copy if you are.)

I am not subscribed indeed, thanks.

Post by Tollef Fog Heen

Post by Thomas Goirand
You guys are writing this as if it was impossible to switch from one
hypervisor to another. Yet this is simply not the case. You can easily
switch from one type of hypervisor to another with the current packages
(by editing /etc/nova/nova-compute.conf manually and installing the
dependencies manually as well). My point is just that multiple packages
make it possible to automate the switch in the config file and
dependencies by simply doing apt-get. I think this is an important
feature and I don't want to see it go.

It sounds wrong to use dependencies where dpkg-reconfigure will do.

You don't get it (I may have explain badly...).

If one installs nova-compute-kvm, he will be expecting it to have kvm
installed, and work out of the box. If there was only dpkg-reconfigure,
then I would have to actually *remove* the dependencies on kvm, and let
our users solve the dependencies manually. I don't want to do that. I
think dependencies are important and help our users. I think that
integrators who run puppet scripts also don't want things to suddenly
change and break their scripts, or have the setup very different in
Debian vs other distro. I think it's worth the added 0.016% binaries.

Though having dependencies doesn't mean you cannot edit the config file
and use nova-compute-kvm to run the XCP flavor of Nova if you apt-get
manually the correct dependencies and edit the configuration files. It's
weird to do that, I personally wouldn't and I don't see any use case for
it. But it seems that it's what you want to do, and I'm just saying that
it is possible, if you like to mess with things.

Post by Tollef Fog Heen

Post by Thomas Goirand
If we consider that I'm requesting 5 more binary packages, and that we
have 30 000 packages in Debian, we are talking about 0.016% more binary
packages in Debian. I can't believe that only for 0.016% more binaries
is so unbearable for the archive.

It's pushing the knife ever so slightly deeper into the wound. The
problem, as Russ has pointed out isn't your five extra packages or
somebody else in particular's packages. It's the cumulative weight of
all of them. Yes, in an ideal world this shouldn't be a problem, but
until somebody comes up with a fix, that's what we have to work with.

You are missing the hole point of why I was unhappy with the FTP masters
to block my package before the OpenStack summit. Since the very
beginning, I asked about having my package accepted, then we can discuss
later. That unless you still think that adding 0.016% more binary
packages *temporarily* until we have an agreement, is adding too much
load on the infrastructure in the short term.

I still think all these binary packages are needed, but if we could not
agree, at least I think it wasn't too much to ask to solve the problem
later. Especially when absolutely all the other packages were approved.
I'm talking about 48 source packages here, plus many other python module
which I updated during the last 6 months release cycle of OpenStack.

It is sad that it is impossible to ask for a bit of teamwork, so that we
meet some political goals helping Debian adoption.

Thomas

[Goswin von Brederlow]

Post by Thomas Goirand

Post by Tollef Fog Heen
]] Thomas Goirand
(Cc-ing you, since I don't know if you're subscribed. Apologies for the
extra copy if you are.)

I am not subscribed indeed, thanks.

Post by Tollef Fog Heen

Post by Thomas Goirand
You guys are writing this as if it was impossible to switch from one
hypervisor to another. Yet this is simply not the case. You can easily
switch from one type of hypervisor to another with the current packages
(by editing /etc/nova/nova-compute.conf manually and installing the
dependencies manually as well). My point is just that multiple packages
make it possible to automate the switch in the config file and
dependencies by simply doing apt-get. I think this is an important
feature and I don't want to see it go.

It sounds wrong to use dependencies where dpkg-reconfigure will do.

You don't get it (I may have explain badly...).
If one installs nova-compute-kvm, he will be expecting it to have kvm
installed, and work out of the box. If there was only dpkg-reconfigure,
then I would have to actually *remove* the dependencies on kvm, and let
our users solve the dependencies manually. I don't want to do that. I
think dependencies are important and help our users. I think that
integrators who run puppet scripts also don't want things to suddenly
change and break their scripts, or have the setup very different in
Debian vs other distro. I think it's worth the added 0.016% binaries.
Though having dependencies doesn't mean you cannot edit the config file
and use nova-compute-kvm to run the XCP flavor of Nova if you apt-get
manually the correct dependencies and edit the configuration files. It's
weird to do that, I personally wouldn't and I don't see any use case for
it. But it seems that it's what you want to do, and I'm just saying that
it is possible, if you like to mess with things.

But what is stopping you from allowing nova-compute-kvm and
nova-compute-lcx to both be installed? The user could then choose via
debconf which of the two to use. The debconf question would only list
those options for which nova-compute-* is installed. Or it might not
even be debconf. Maybe alternatives work better there?

Post by Thomas Goirand

Post by Tollef Fog Heen

Post by Thomas Goirand
If we consider that I'm requesting 5 more binary packages, and that we
have 30 000 packages in Debian, we are talking about 0.016% more binary
packages in Debian. I can't believe that only for 0.016% more binaries
is so unbearable for the archive.

It's pushing the knife ever so slightly deeper into the wound. The
problem, as Russ has pointed out isn't your five extra packages or
somebody else in particular's packages. It's the cumulative weight of
all of them. Yes, in an ideal world this shouldn't be a problem, but
until somebody comes up with a fix, that's what we have to work with.

You are missing the hole point of why I was unhappy with the FTP masters
to block my package before the OpenStack summit. Since the very
beginning, I asked about having my package accepted, then we can discuss
later. That unless you still think that adding 0.016% more binary
packages *temporarily* until we have an agreement, is adding too much
load on the infrastructure in the short term.

Nothing remains as long as a temporary exception. Point in case look
at ia32-libs. Which was added temporarily till multiarch was ready.
Took >12 years to get to the point where we can remove it.

Post by Thomas Goirand
I still think all these binary packages are needed, but if we could not
agree, at least I think it wasn't too much to ask to solve the problem
later. Especially when absolutely all the other packages were approved.

At which point ftp-master has to invest more time to clean up. I can
see why they would rather fix the problem before accepting the
packages.

Post by Thomas Goirand
I'm talking about 48 source packages here, plus many other python module
which I updated during the last 6 months release cycle of OpenStack.
It is sad that it is impossible to ask for a bit of teamwork, so that we
meet some political goals helping Debian adoption.
Thomas

MfG
Goswin

[Thomas Goirand]

Oh, also, it seems that some people seem to believe that it may be
possible to run with more than one hypervisor *at the same time* with
nova. Tollef Fog Heen wrote that. Well, it would be a nice feature, but
no, it's not possible with Nova, AFAIK.

Could we avoid this? It doesn't help the discussion.

Thomas

[Ian Jackson]

AFAICT Thomas has not yet referred this issue to the committee.
Please therefore don't CC the TC mailing list in your discussions.

It is fine to informally ask the TC a preliminary or procedural
question, just by sending to the list. But we are having a
substantive discussion here.

If the matter _is_ to be dealt with by the committee, it should be
sent to a topic-specific bug report as described here:
http://www.debian.org/devel/tech-ctte#referquestions

Thomas, in particular, as the potential complainant: if you are still
discussing the matter with just Goswin, ftpmasters, etc., please do so
on an another appropriate list.

If you now want the Committee to actually help mediate/decide, we
should have that topic-specific bug report. Otherwise it's hard to
later find the history and rationale behind TC decisions. (And of
course a bug means we are less likely to drop the work item.)

Thanks,
Ian.

[Thijs Kinkhorst]

Post by Tollef Fog Heen
You should ship them with the +x bit already. I'd rate it serious or
important, since you're breaking dpkg-statoverride.
(I'd love for Lintian to grow a check for changing permissions of
shipped files so we could get rid of that completely. I don't think it
has it yet.)

As this would concern the installed package, perhaps 'adequate' would be a
better place to check for this. Cc'ing its maintainer.


Cheers,
Thijs

[Ansgar Burchardt]

Post by Thomas Goirand

Post by Joerg Jaspert
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).

I am on the side of Russ Allbery here. Ideally, as a developer, I
shouldn't have to worry about this, too much, and here is IMHO too much.
The infrastructure problems which Debian runs into shouldn't clash with
the convenience users either, to the point where Debian would be a very
special case with packaging different from other distro, and breaking
existing puppet scripts others are already maintaining (for Debian
and/or Ubuntu).

Note that every distribution does package nova in a different way:

- In Fedora binary packages are named "openstack-nova-*" (except for
python-nova).
- Fedora has only 13 binary packages, compared to ~30 binaries in
Ubuntu.
- Gentoo, Arch only have a single package (though Gentoo doesn't have
a concept of "binary packages" as far as I know).
- All of Fedora, Gentoo, Arch bundle multiple daemons in a single
package.

So things already work differently on different distribution.

I also don't think having less binary packages means less convenience:
people who decide to host their own cloud infrastructure most likely
already use a configuration management system such as puppet. Having to
enable some service via a configuration file (or other means) instead of
installing additional packages shouldn't really make a difference. Note
that there already seems to be a configuration file that must be changed[1].

[1]
<http://lists.alioth.debian.org/pipermail/openstack-devel/2013-April/002259.html>

Post by Thomas Goirand

Post by Joerg Jaspert
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.

As you know, a package isn't only made with what files it holds. It also
contains precious dependencies. By asking to switch to a single package,
you are removing the possibility to have dependencies that make sense.

Most binary packages don't have additional dependencies as mentioned in
my initial rejection[2].

[2]
<http://lists.alioth.debian.org/pipermail/openstack-devel/2013-April/002257.html>

Post by Thomas Goirand
Package: nova-compute-kvm
Depends: python-libvirt, libvirt-bin, kvm
I don't want to just document this, OpenStack is complicated enough
already, adding installation of dependencies as a manual thing matching
configuration files or debconf values would be annoying.

There are many packages that require this. A random example: mediawiki
depends on php5-mysql | php5-pgsql | php5-sqlite | php5-mysqlnd. Which
one is right depends on the configuration.

Having mediawiki-mysql, mediawiki-pgsql, mediawiki-sqlite, ... instead
would not scale well. It gets really bad if you have more than one
option (mediawiki-{apache2,lighttpd,...}-{mysql,pgsql,...}?).

Ansgar

PS: Maybe it's time to move the discussion back somewhere else?

[Russ Allbery]

It's probably also worth noting that large numbers of tiny packages have
been a point of significant controversy in terms of archive management and
the archive acceptance policy for many years. I've seen several packages
rejected before, at least initially, for being split into too many tiny
packages or packaging something that would be better included in another
package.

I haven't reviewed the details of these specific packages, but I can
reassure you that you're not being singled out here. This is something
that ftp-master does routinely check for, and lots of other people's
packages have been rejected for the same reason in the past.

This has always felt to me like a technical flaw -- it would be nice to
make adding new packages cheap and find some way of not worrying so much
about metadata bloat -- but I have no technical solution.