Re: [linux-dvb] dst customization patchset

Re: [linux-dvb] dst customization patchset

[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), 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

* 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_.

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

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.

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.

Markus

Re: [linux-dvb] dst customization patchset

[hermann pitton]

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

Re: [linux-dvb] dst customization patchset

[Bill Eldridge]

Sounds good, Markus - do you have a list of known bugs that need to be 
handled?
Is this something that can go up on the Wiki, or are there enough that a 
bug tracking
system is required?

While timelines won't be enforceable for people doing things in their 
spare time, it's
still useful to put up time goals and priority lists on projects, both 
new development and
bug fixes, to keep momentum going and gauge progress, including seeing 
that something
that should have been fixed isn't getting handled.

Can people accept Markus as a reasonable, informed arbiter of what will 
go into the main tree
even if there are disagreements? It also sounds like new programmers 
here  need more startup
instructions/assistance/advice and ground rules than on many open source 
projects.

Regards,
Bill

Markus Rechberger wrote:
>
> Some developers are also sick of contributing since the whole
> community is flawed at the moment. I propose a few ways to go
>
> * 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_.
>
> * 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.
>
> 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.
>
> 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.
>
> Markus
>   

Re: [linux-dvb] dst customization patchset

[Markus Rechberger]

On 6/1/07, Bill Eldridge <dcbill@volny.cz> wrote:
>
> Sounds good, Markus - do you have a list of known bugs that need to be
> handled?

Yes, I put together a few things that came into mind:
http://mcentral.de/wiki/index.php/Bugtracker

> Is this something that can go up on the Wiki, or are there enough that a
> bug tracking
> system is required?
>

Wiki/ML should be fine, people use to avoid the bugzilla on kernel.org
although I'd be fine with it (at least for the em28xx project) but
people prefer to add bugreports to the wiki or send mails.

> While timelines won't be enforceable for people doing things in their
> spare time, it's
> still useful to put up time goals and priority lists on projects, both
> new development and
> bug fixes, to keep momentum going and gauge progress, including seeing
> that something
> that should have been fixed isn't getting handled.
>
> Can people accept Markus as a reasonable, informed arbiter of what will
> go into the main tree
> even if there are disagreements? It also sounds like new programmers
> here  need more startup
> instructions/assistance/advice and ground rules than on many open source
> projects.
>

I would appreciate to get more people involved with that project,
VDR/mythTV/mplayer/ffmpeg etc. projects use the outcoming work.
While the v4l and dvb project is doing really hard at the moment and
improvements are handled in a snail speed (if ever handled) this
should really change.

cheers,
Markus

> Regards,
> Bill
>
> Markus Rechberger wrote:
> >
> > Some developers are also sick of contributing since the whole
> > community is flawed at the moment. I propose a few ways to go
> >
> > * 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_.
> >
> > * 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.
> >
> > 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.
> >
> > 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.
> >
> > Markus
> >
>
>
>
>


-- 
Markus Rechberger