Am Freitag, den 15.01.2010, 17:22 -0500 schrieb Devin Heitmueller: > 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 > Oh my. Sometimes it is good to allow breakages for a while. At least after such, you know who really is or can still be around. Nice to see you there. But I also still wait for some Pinnacle LNA explanations ... Cheers, Hermann -- 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
