On Tue, Mar 17, 2009 at 11:40 AM, Menon, Nishanth <nm@xxxxxx> wrote: > Hi Felipe, >> -----Original Message----- >> From: Felipe Contreras [mailto:felipe.contreras@xxxxxxxxx] >> Sent: Tuesday, March 17, 2009 11:17 AM >> To: Menon, Nishanth >> Cc: linux-omap@xxxxxxxxxxxxxxx; Kanigeri, Hari; Hiroshi DOYU; Ameya >> Palande; Guzman Lugo, Fernando >> Subject: Re: [PATCH] tidspbridge: remove revision history >> >> >> - *! Revision History: >> >> - *! ================ >> >> - *! 24-Feb-2003 vp: Code Review Updates. >> >> - *! 18-Oct-2002 sb: Ported to Linux platform. >> >> - *! 03-Jul-2001 rr: Removed kfuncs.h because of build errors. >> >> - *! 07-Dec-1999 ag: Fxn error now causes a WinCE DebugBreak; >> >> - *! 30-Aug-1999 ag: Now uses GP_printf for printf and error. >> >> - *! >> > But we did not have git history 1999-2003. we planning on loosing these >> contribs? >> >> Only if you want dspbridge to be merged which as time passes it's >> becoming more clear that you don't. I'm not a kernel developer, but I > Errr.. Not my attempt at a flame war ;).. But then, I am not sure if my comment meant anything of the sort :)... Contrary to what it might seem I'm not attempting a flame war either. It's not because of your comment, it's because TI has been very slow cleaning up the driver and reluctant of integrating clean-up patches. It seems to me as if TI thinks this driver is just fine, which is clearly not the case. >> would challenge you to find a diver that has 1000 lines of revision >> history in the source code. > <snip> >> >> >> - *! 30-Aug-1999 ag: Now uses GP_printf for printf and error. >> >> Not printk? I assume this is not related to Linux then. >> >> >> Are we going to find an issue at some point in time that we'll say: oh >> crap! if only we had the revision history log we could solve it! > Errr... in the old times of cvs kernel, before we shifted to bitkeeper and later to git, rev history was unfortunately necessary to maintain some sort of acknowledgement of contributions. Just greping linux-omap master branch " grep -Ri "Revision History" drivers/|cut -d ":" -f1|wc -l" shows me 227 files of similar drivers- legacy - agreed. I think bridge is in such a legacy driver. That shows me 31 files, none of which have more than a couple hundred lines, that is of course on linux mainline. BTW this is faster: git grep -i -l "Revision History" -- drivers/ | wc -l > If any new changes are done, it makes no sense to introduce an entry in the revision history - agreed. These driver files have a history and folks have done some work to make it useful, to remove their contributions would be, IMHO, our disregard for what ever they did (good or bad).. ;) But then, that is just my opinion.. > > Note: There are folks whose contributions are reduced to "vp" "rr" "sp" etc.. I personally have no clue who they are but I guess they would rather be in git log than in anonymous initials if given a choice today.. Contributors can be specified as such: a contributors section at the top. No need to keep the revision history just for that. >> I doubt that, the revision history is useless without the actual >> changes. These lines are just introducing noise. >> > > DSPBridge has definitely a long way to go before being merged into mainline kernel. Coding standard is one part of the story. Is this part of a code cleanup effort to prep the code for merge to kernel? I think I have seen tons of discussion on this previously.. If we are planning on prepping this driver for mainline integration that is another discussion and this patch probably is a tiny fragment to that. The bunch of history starts at [1] though.. I'm interested on getting this into the mainline so I took the simplest of my cleanup patches and the one I thought would be less controversial. If TI does not intend to submit this to mainline it would be nice to say so, that way the people interested can stop waiting and take action. I myself am tired of waiting. -- Felipe Contreras -- 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
