Am Freitag, den 15.01.2010, 17:22 -0500 schrieb Devin Heitmueller:
> On Fri, Jan 15, 2010 at 3:00 PM, Mauro Carvalho Chehab
> <> wrote:
> >> I've tried to tactfully point this out in the past, but PLEASE STOP
> >> should have gone into a branch, and you should have solicited testers
> >> for that branch before any of this stuff went into the mainline.
> >>
> >> I know you're the maintainer so the "rules don't apply to you", but
> >> the reality is that when talking about new development (not fixing
> >> merge conflicts), you should really be adhering to the same rules that
> >> all the other developers use.  These rules are there for a reason - to
> >> provide an opportunity to catch regressions in new code before they
> >> hit the mainline.
> >>
> >> I know that you have made quite clear that you disagree that you
> >> should have to use branches for new development/refactoring.  My only
> >> hope is that by pointing out every time one of your actions in the
> >> trunk causes a nasty regression, perhaps you will rethink your
> >> approach.
> >
> > What you call trunk, it not, really a trunk, but a tree where all patches
> > got merged. I've been pointing it several times, but people doesn't seem
> > to listen: that tree is were we'll expect problems to happen, since it is
> > just an alpha staging before submitting things to linux-next, where all
> > patches got merged.
> >
> > The bad thing is that people use it as if they were stable, when it weren't
> > meant to be stable at all.
> This is your *opinion* that you are stating.  I think many (if not
> most) would disagree with you, in that the v4l-dvb tree should not be
> treated as "alpha" quality.  It should be generally stable, and things
> should not be merged into it until they are of releasable quality.
> Every other developer operates this way *except you*.  Every other
> developer does his work in a separate tree, and that tree is merged
> once the code is stable.  You are the only one who is directly
> checking things into the trunk that are "alpha quality".
> Many people rely on installing the v4l-dvb tree as a path to get new
> device support without having to wait for a full kernel to be released
> and for their distribution to incorporate that kernel.  Your failure
> to work on a branch until code is stable like every other developer
> contributing to this project is damaging the project's reputation.
> As a project, we should be embarrassed when our trunk doesn't compile
> on every kernel version except one.  And we should be embarrassed when
> for nearly a month it is in a state where every board that has IR
> support causes an OOPS on insertion.
> > That's why I decided to deprecate it.
> >
> > On the next few days, I intend to stop adding patches at -hg tree, passing 
> > its
> > maintainance to another person. Douglas already offered to do it for us.
> >
> > The idea is that I'll apply patches directly into my git trees. And then, 
> > the
> > hg maintainer will backport the patches into -hg.
> >
> > This also means that patch backports will need to be sent in separate, as 
> > those
> > patches won't fit into -git.
> >
> > I'm finishing the details and I'll post an official announce about that 
> > soon.
> Rather than making any "announcement", I would strongly encourage you
> to consider actually soliciting the feedback on your proposed approach
> from all of the developers who are actually contributing the code to
> the project.  There are many developers who have very strong feelings
> on how this project should operate, and would likely take considerable
> exception to any unilateral decision being thrust upon them that has
> serious implications to how developers will be expected to work in
> this project.
> Let's not forget that this is a community of volunteer developers
> working towards a common cause, and not a dictatorship.
> Devin

Oh my.

Sometimes it is good to allow breakages for a while.

At least after such, you know who really is or can still be around.

Nice to see you there.

But I also still wait for some Pinnacle LNA explanations ...


To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to
More majordomo info at

Reply via email to