On Fri, Jan 15, 2010 at 3:00 PM, Mauro Carvalho Chehab
<mche...@infradead.org> 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 J. Heitmueller - Kernel Labs
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to