On Wed, Jan 13, 2010 at 9:00 AM, Mauro Carvalho Chehab
<mche...@infradead.org> wrote:
> Michael Krufky wrote:
>> The same tree is also available using http instead of https:
>> http://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2
>> This should work for you without issue.
> Ok. Applied, thanks!

Sorry about that.  I typically cut/paste the link from my browser (and
we support both http and https for the HG repo).  I will be sure that
future PULL requests are http only.

Also, I haven't had a chance to rebase this tree against the tip yet,
as I burned too much time over the weekend tracking down the
regression you introduced into the with the ir-sysfs rework.  Did that
one line patch get merged yet?  It's pretty embarrassing to have a
situation for nearly a month where the mainline v4l-dvb causes an OOPS
just because they happen to have IR support.  In my case, I couldn't
even get my PC to boot until I pulled the card from the machine.

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


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