* Felipe Contreras <felipe.contreras@xxxxxxxxx> [090305 06:06]: > On Thu, Mar 5, 2009 at 3:56 PM, Kanigeri, Hari <h-kanigeri2@xxxxxx> wrote: > > Nishant, > > > >> Yeah it gets real confusing. How about following the same > >> rules for the OMAPZOOM kernel here too: any patch w.r.t > >> OMAPZOOM comes: > >> Subj: RE: [OMAPZOOM PATCH 0/5] DSPBRIDGE: blah blah blah. > >> > > > > -- I agree with your suggestion. The subject should have OMAPZOOM to differentiate. > > Nishanth has kindly explained me that this patch, sent to the l-o > mailing list, is not meant for the l-o tree. > > A better way to differentiate patches specific for o-z is to send them > to the o-z mailing list, instead of l-o, right? > > Tony: Or have you agreed with TI that these [OMAPZOOM] patches that > don't apply on top of l-o are ok here? Well as long as they're clearly tagged as OMAPZOOM, things don't get too confusing, so I'm OK with that. But in general I'm worried as it looks like the zoom tree is just piling up more and more hacks and ifdefs with no serious attempt to merge that code upstream. Everybody, we need to get the infrastructure pieces done properly and into the mainline tree so we can use that for all our omap needs. Sure some board specific hacks will be still needed here and there, and tons of the omap and driver patches already apply against the mainline kernel code. It's up to each developer to submit their patches through the right mailing lists to the mainline kernel. Piling up code into some other trees only increases the diff against the mainline tree. Everybody, when you see a piece of omap code that's not in the mainline kernel yet, whine and complain until the code gets integrated. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
