Re: [cooker-amd64] Re: Re: using and compiling rpms not specifically put together for amd64

[Stefan van der Eijk]

> > Even if you *do* find a way to sneak one by them, you'll get your arse 
> > toasted in the mailinglist. Blaming you for everyhting that ever went 
> > wrong even though the *technical* truth is different. But that doesn't 
> > matter for them, even though the package was already broken, you 
> > uploaded it a 2nd time, and get blamed for everything.
> >    
> []
>  
>
> > Conclusion: just forget KDE, for now.
> >    
>
> Saving the rest to reply to later, but thought I'd reply to this.
>
> It's easy to get impatient and call names and blame.. but it doesn't
> really help.
>  
True, I agree with you.

Getting down to the stuff below. I spend most of my day-time job as a 
consultant in what we call "political arena's". My customers are multi 
nationals, you can't get worse than that :-) All the different interests 
people have and how that plays out. At the end of the day it all boils 
down to the following: you have three types of relationships:
1/ conflicting interests and not dependent on each other
2/ conflicting interests and dependent on each other
3/ common interests.

Looking at the MDK, the relation between most contributors can be 
described as "3".

For the kernel, glibc and gcc packages I'm dependant on those packagers 
for the ports, although some of them may have some conflicting interests 
(-> "2"). For the KDE packages, since they are higher up in the 
depenency tree, I could make myself dependant, but since they are not 
really needed for the ports (and may come later) I've decided to put the 
KDE team in category "1" for now. Once the time is right, I'll put them 
into "2" and then it's time to find the win-win.

For "2" it's in everybodies interest to achieve a win-win situation. I 
beleive with the glibc, gcc, kernel and rpm packagers we are getting there.

I'm still looking for a way to get the whole MDK process more 
professionalized. Get more things documented, get service management 
processes in place and accessible for contributors. Get more of a line 
into things, you'll see quite some e-mails on cooker from people 
complaining about the cluttered way MDK is setup, some things 
duplicated, maintained poorly (club), lack of a real business model, etc.

> Along about my 8th grade year, my dad (a teacher and school administrator)
> took over directorship of a Navajo mission in New Mexico.  The stories I
> could tell.. but what relates to this discussion is one of the words of
> wisdom the departing director left with my dad, as the three of us toured
> the mission, thus, in my hearing.  He said that the most difficult part of
> being director wasn't the money, or the regulations, or the kids, or any
> of that.  Rather, it was getting all the staff to work together, and the
> job of having to KEEP them working together, even amongst personal
> dislikes and sometimes outright hostility.
>
> That was many years ago, but obviously, it left a big impression on me. 
> At times like this, I remember it.  Us geek types may be harder than most
> to keep working together, because we tend to be used to being the smartest
> and most technically inclined of most of our social groups, in many cases.
> Thus, we tend to have a way of believing that what we think about
> something is THE way it must be done.  This sort of gut belief obviously
> can tend to lead to friction.
>
> I'm not specifically defending Laurent, the person who is, after all, the
> Mdk KDE team, basically.  However, he's the one they've got, at this
> point, and we work with him on KDE or don't work at all, basically,
> regardless of his social or personal qualities, good or bad.  Also, he's
> pretty good technically,
Sure, he's good with the kde internal things. But other people are good 
at other things. MDK needs to combine all of those skils to make a good 
product. What's happening at this point is that only Laurent's skils may 
be applied to the kde packages, rejecting the rest.

I personally suck at KDE, I wouldn't know how it works internally. What 
I do see is that tonnes of kde packages are not rebuilding by default 
and with the addition of some BuildRequires they would (not only on 
i586, but on the other ports too). 
http://eijk.homelinux.org/build/i586/cooker/BO/problem/ What I could do 
is bring in some changes to help those packages rebuild on the other 
ports. This would no affect Laurent's work, but I guess he must see it 
as a threat. So that's where the conflicting interest comes from...

> it would appear, and that we are lucky to have,
> regardless of his ability to work with the team.  Perhaps we'd be better
> off with a different person with a bit better team skills, regardless of
> technical ability.  That could be argued.  However, right now, we have
> what we have, it comes with the Mandrake KDE packages, and as long as we
> choose Mandrake and KDE, we choose to work with him, like it or not.
I'm just wondering what role management could play to improve the 
product by getting people to work together a bit better. In the end 
being a manager is all about taking care of your people. Not getting 
people to work together, or not making things clear isn't in Laurent's 
interest either.

> Thus, my attitude is.. make the best of the situation.  If it eventually
> proves unworkable, either I will move on, or he will, but for now, we've
> both chosen Mandrake, he as employee assigned to those packages, me as
> user of them, so I either learn to live with it, or move elsewhere, and at
> this point, living with it is easier than pulling up and moving elsewhere,
> so I might as well enjoy it as best I can.
>  
Exactly. I've talked to him back in 2001, we agreed to cooperate, but of 
course, that never happened (typical for a PA: say yes, do no). So I've 
chosen to not be dependent on him and continue doing other stuff.

> Truth is, I know *I'M" not ready to take on the position, and tho there
> are others that might be, I can't say how well they'd work converting
> KDE's packages to Mandrake's policies either, if they were stuck with the
> ENTIRE job, so I'm not ready to say I'd prefer someone else in the
> position, teamwork or no teamwork.  Besides, it's not MY call.  So, I'll
> let the Mdk administrative team do what it does, and get back to this task
> that seems I'm ever-so-slow at getting anywhere with, that of learning
> enough about Linux, and here RPM and Mandrake specifically, to be of more
> than occasional help from the sidelines, as seems to be the case, now.
>
> I'm learning, but it's EVER so slow a process!  I guess that's why I've
> been a bit hesitant to get an account on the wiki or with Mdk, as you
> suggested elsewhere in the reply.  I don't understand even HALF of the
> RPM packaging process, yet, and really don't know what I could DO at that
> level, yet.
>  
:-)

> On the bright side, that's one of the good things about this whole AMD64
> thing, despite the frustration.  I'm HAVING to learn a bit, in ordered to
> get stuff to work, which is why I deliberately decided to jump into it so
> early, after all, rather than waiting another upgrade cycle.  It has
> FORCED the learning process, sometimes a bit faster than I'd like, but
> that's what I WANTED, after all, and why I got into it.  I don't
> understand packaging yet, but I'm  closer now, than I was even when I
> wrote that frustrated message a week or whatever it was ago, thanks to
> your pointing out to me your logs, and what I was able to learn browsing
> through them. and FAR closer now, than I was before I switched to AMD64,
> when I'd seen you guys discussing RPM macros, but hadn't ever actually
> SEEN one yet.  <g>
>
> It's coming.  It's just TAKING forever, or seems to be, sometimes.  <g> 
> Then again, I realize how far I've come in the two years on
> Linux-Mandrake, and that I'm roughly where I was after a decade on
> MSWormOS, and I realize I'm making progress AFTER all.  It's just that
> Linux is such a **BIG** subject!  <g>
>
> (I did get a bit more time this week, and have spent a good share of it
> learning more about kernels, and looking at upgrading to 2.6 here.  I
> wasn't aware of the 2.6 Mdk kernels for amd64 you mentioned, so was
> getting back into compiling my own 2.4 kernel, in prep for doing the same
> with 2.6.  However, it's back to work again later this afternoon, but
> hopefully I'll have some extra time again next week.)
Duncan, as a relatively new person to all of this it's easy to analyze 
stuff and saying how it should be done (dutch saying: "de beste stuurlui 
staan aan wal" --> "the best captains are always on shore"). Getting in 
the middle of it and getting things to "work" is whole different 
ballgame. I started as a contributor in 1999. I'm one of the only 
contributors with an account on kenobi (klama didn't exist back then). 
Since then a lot has been accomplished, but there's so much more todo. 
I'd be delighted to have your personal skills helping to improve the 
situation.

regards,

Stefan

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature