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 USING THE TRUNK AS YOUR PERSONAL DEVELOPMENT SANDBOX. These changes 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. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
