[Fedora-packaging] Complaints about censoring and kmdl IRC session (resend)

[Axel Thimm]

Hi,

IMHO the IRC session today was a pure catastrophe.

Some - especially people not following the discussion closely - were
given the wrong picture and even accused me of being arrogant and what
not. I'd like to file in my view, since the IRC session turned that
badly.

Upon request I compiled a tabular list of pros and cons of kmods vs
kmdls derived from the longer writeup in the wiki. I've added all
points mentioned even the ones I personally do not pay that much
importance on and more importantly also these points that my proposal
isn't good at including negative personal ratings for kmdls! I
considered this a necessity out of fairness to everyone's
contributions.

W/o notice someone changed that list in a way I consider heavily
censoring and very biased. I complained to him in PM, but his spam
filter ate my mail and I didn't get a reply before the session (or by
now either FWIW). In any case at the end of this mail I summarize the
main changes [3].

Of course that new list wasn't really what I would consider a neutral,
unbiased approach. There were many errors either accidentially or due
to different understanding [1] which by happenstance *all* were
turning against kmdls, even typos and cut&paste errors. Also important
items were scratched (not the rating, but features and comparisons).

Later in the session it was told that the omitted items were dumped
because they were considered irrelevant, something which IMHO the
people in the session should be allowed to judge for themselves.

When the first difference was brought on discussion - namely that rpm
-i supposedly works with kmod - I objected and gave examples why this
is not the case. Independent of whether I were right or wrong [2], the
following "definition of rpm -i works for kmods" was topping the
censoring by itself.

I can understand that people are not as deep into kernel modules as
others, and that therefore some issues may look different. But
shouldn't these people be open to discussion in case they are missing
something (which in this case they are)?

Or is this just a fake discussion where the end result is already in
stone and we're just trying to justify it?

ATM I really disappointed as to how things evolve. I've put lots of
efforts and sweat over the last weeks into this with the target to fix
something broken for the benefits of all and I don't consider this the
proper reaction.

Please note that I'm very far from escalating this. I wrote this mail
with very careful wording, omitting on purpose all names and
refraining from any direct accusations, even though I'm extremely
alergic to censoring and misquoting in general. And I didn't reply on
personal insults either to avoid any flaming.

To get to the positive side: At least it was discussed at all (or an
attempt was made) and I'd like to thank all for their participation
and patience.

=====================================================================

[1] I use "different" as a very neutral wording of what I personally
    consider "wrong".

[2] IMHO I was and am correct in the statement that the kmod scheme
    can neither be used with rpm -U, nor rpm -i.

[3] Changes between original and censored list of items

http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance?...

By order of importance:

o rpm & kmods:
  "breaks on rpm level" removed
  "rpm -i does not work" suddenly "works" ???

o kmod's need for further yum developend removed!!!

o yum w/ full plugin support
  kmod's "only one kernel supportable [...]" becomes "possible"
???
  kmdl's "full suport" becomes "possible" ???

  The difference is a working kmdl plugin today vs the shown issues of
  the fedorakmod.py, which were even admited by pro-kmod participants.

o kmods: kernel's evr "merged with the modules" becomes "available as
  provides"
  It is very important that the 2-dimensional evr space is mapped
  that way, it is in fact the root of most evil. Replacing it as done
  hides the issue.

o kmdls and low maintenance: "specfile/src.rpm/userland invariant"
  becomes "every new kernel/flavour needs full rebuild"

o kmdl's design flexibility/abstraction of interface/implementation removed

o infrastructure (bugzilla/cvs/owners) benefits removed

o custom kernel support removed

o other distribution benefits of kmdls removed

o cross-distribution standard benefits of kmdls removed

o Removed column rating (that by itself I would consider OK)

-- 
Axel.Thimm at ATrpms.net