Devin Heitmueller wrote: > On Wed, Jan 13, 2010 at 9:00 AM, Mauro Carvalho Chehab > <mchehab@xxxxxxxxxxxxx> 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. No problem. > 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. Yes, it were applied already. > 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. 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. 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. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
