On Fri, Jan 15, 2010 at 3:00 PM, Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> wrote: >> 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. 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 -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
