Re: [linux-dvb] dst customization patchset

[hermann pitton <hermann-pitton@arcor.de>]

Am Freitag, den 01.06.2007, 00:03 +0200 schrieb Markus Rechberger:
> On 5/31/07, Uwe Bugla <uwe.bugla@gmx.de> wrote:
> > Am Donnerstag, 31. Mai 2007 07:01 schrieb Bill Eldridge:
> > > timecop wrote:
> > > >>  Guys, it's GPL code. Fork the project and stop your bitching.
> > > >>  If you do a better job, people will use and contribute to your
> > version.
> > > >>  If you do a worse job, people will use and contribute to Manu's.
> > > >>  Some will use and contribute to both. Life's good, eh?
> > > >
> > > > This is exactly why Linux is shit.
> > > > You have 100s of "forked projects" because some guy named Uwe thought
> > > > he could do better than some guy named Manu and now you have two
> > > > projects to contribute to, both suck in various ways, of course some
> > > > idiot is going to be "backporting" from one to another, introducing
> > > > weird bugs, etc etc etc.
> > > >
> > > > Make a fucking decision and stick with it. Stop wasting everyone's
> > > > time. It's no secret that current Linux-DVB/V4L/whatever system is a
> > > > pile of steaming feces. Every one of you admitted to it on this list
> > > > at some point in the past. So get to it, make a fucking decision,
> > > > "fire" (loool) retards who are slowing the project down, and get shit
> > > > moving. I vote for Uwe as Linux-DVB maintainer.
> > > > Regards,
> > > > tc
> > >
> > > I nominate Timecop to be maintainer/top cop to figure out which version
> > > sucks in which area
> > > and do his best to get the best approach used. Sometimes a good strong
> > > and outspoken
> > > manager is more important than technical prowess (and I have no idea as
> > > to your technical
> > > abilities, just saying it looks like a management issue).
> >
> > I am not a fan of "strong men" or "strong managers" of whatever kind. We in
> > Germany have very bad experiences concerning this kind of human desire /
> > call
> > regarding our history.
> > Instead there should be one responsible code reviewer for v4l stuff, and at
> > least one responsible code reviewer for DVB stuff.
> > This is a minimum adequate demand to make things work.
> >
> > Inactivity on future projects in connection with Nacks of activities to
> > optimize the stock kernel are no fair play or helpful behaviour at all, but
> > they are just counterproductive. Who likes small kings? Well, I do not!
> >
> > >
> > > For Uwe, it's not that I don't "want" to understand anything - I just
> > > showed up 2 days ago and
> > > simply want a workable driver for my machine, and instead had to switch
> > > cards to something
> > > else. Usually I assume if the code was forked the fork would be
> > > somewhere else and you wouldn't
> > > be complaining to this list, but I understand there are different ways.
> > > (Samba did it this way for
> > > quite some time).
> >
> > Forking may be OK for different Linux distros. But v4l-DVB is not a distro,
> > it
> > should be a common project instead.
> >
> > What you find is some 20 developers with a multiplicity of repositories.
> > You do not even know who is maintainer and who is not.
> > What you also find is the blocking gesture of that person who once threw his
> > hat into the ring wanting to become maintainer.
> > As the whole situation is one big mess you do not even know whether becoming
> > a
> > maintainer or not is product of a democtratic vote.
> >
> > Above that there is no team structure at all, but instead there is a big
> > chaos, mess.
> > And if some code, may it be humble or mature, is not even pulled into the
> > mm-tree (its basic role has always been testing, nothing else) I would call
> > that a catastrophe.
> >
> 
> Uwe writes alot insulting crap (which is a fact), 

YES.

> even if the DVB
> subsystem has no maintainer the code should be managed appropriately
> and stopping the development is no way to do it.
> At the moment we have __tonns of critical bugs__ in the drivers and
> the video4linux and dvb framework; both frameworks are incomplete and
> don't provide the necessary flexibility to support an infrastructure
> for devices which could already be supported at the moment.
> 
> We have several (technical) good people which which work on the
> framework on different parts but who don't cooperate at all and who
> cannot work together at all.
> We have alot code which is managed in separated repositories where
> different developers spent several years of development (including
> reverse engineering, hacking and so on) it's a shame that the whole
> project is stuck where it is. New developers who fundamentally want to
> change something are not welcome at all, even if they have valuable
> ideas.
> 
> Some developers are also sick of contributing since the whole
> community is flawed at the moment. I propose a few ways to go

YES.

> * stopping that signed off by madness that every driver developer has
> to sign off changes which happened at the core which will definitelly
> never happen because people _do not like each other_.

We are forced to it.

> * change the maintainership and push it over to me, even if it sounds
> selfish at the moment _every_ code which provides additional features
> and where noone expects further improvements within the next few weeks
> (without throwing away alot of work or generating useless extra work
> by telling someone to rewrite the core of his work); everyone still
> can try to write better code - but then he _has to do it completly_
> and get in peace with the projects by supporting them to get further.

There are still gatekeepers, and they have to pay the full bill.

> The problem I have with this project is that many more things are
> upcoming at the moment (including bug fixing) but there are certain
> developers which first weren't experienced enough, afterwards started
> to think about the issues which were tried to discuss at the beginning
> already and who don't have an overview about the requirements, neither
> do they want to discuss the requirements.
> I can name numerous of bugs of this project which can be solved but
> which just get ignored. Some known bugs dont even get explained to
> people who are interested in fixing them, so this is what I consider
> that it's a major problem.

Start to name the endless bugs, align them to persons, but don't keep
them for something else you try. Get others your work done.

> I'm looking for a serious discussion about it, if anyone wants to know
> about the history I can point out to many logfiles/older emails which
> deeply explain the whole video4linux/dvb issues - the project should
> turn back to a real community.

Yes, but when the first breakage happened, I don't even know ...

Cheers,
Hermann


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/