On 9/14/07, Johannes Stezenbach <js@linuxtv.org> wrote:
quoted text
> On Fri, Sep 14, 2007, Markus Rechberger wrote:
> > On 9/14/07, Steven Toth <stoth@hauppauge.com> wrote:
> > >
> > > If you care about LinuxTV you'll work with the core subsystem developers
> > > to bring your em28xx tree inline. If you don't care then why are you
> here?
> >
> > It doesn't really work out to work with those 3-5 "core" people who are
> active
> > there.
> > It starts at the point where RFCs are submitted and not answered,
> > discussions are avoided and finally some people start to complain.
> > In case of pointing people to wrong or bad solutions, one "Maintainer"
> > pointed out it would be like manipulating others work ... this exactly
> > happened with the em28xx project. It's not only about the current
> > implementation, as from my side I also take upcoming products into
> > account and how long it would take to get something which isn't
> > supported by the API fixed.. it's just something that is too hard and
> > I don't want to debate about things where I know that the outcome
> > is that I have to wait till someone of those 3-5 "core" people come up
> > with an own idea.
>
> Maybe you still don't realize how tiresome it is to talk to you.
> What you present as "linuxtv people block my contributions" is
> IMHO "linuxtv people got fed up talking to you". Because when
> people disagree with you, you keep rambling on and on instead
> of just accepting it. See, working with an Open source community
> requires that you don't piss everyone off, but instead find
> ways to _motivate_ them to help you fix the problems which
> prevent your code from being merged. When people are doing
> software development _for fun_, then it should be a _pleasure_
> for them to work with you, and not a pain in the ass.
>

Johannes,

people do contribute to the em28xx project.
If noone keeps finding solutions for requirements I will of course
go on to find my own way.
Although upcoming and even the current requirements are not met
by the existing API.
It's worth nothing to merge what's available now since I'm not even
ok with how several issues are solved with the driver itself at the
moment.
I'm going forward step by step with it now.

there's also an active and even problem solving oriented ML available:
http://mcentral.de/pipermail/em28xx/

Also if you look at the mercurial code you'll see several people
contributing to that project.

Markus
-
unsubscribe notice
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/