Dirk Behme wrote: > On this list we mainly go the OMAP way. I don't know if it is good or > bad, though. > > The OMAP way is to send core architecture patches to OMAP (DaVinci) list > and subsystem patches (e.g. sound, ide etc.) to subsystem lists and CC > OMAP (DaVinci) list. Talking about core OMAP (DaVinci) patches, they are > reviewed on the list and then applied to OMAP (DaVinci) git. > > Then from time to time, if patches are ready for mainline, git > maintainer sends a patch series to LAK for review and at the same time > prepares a git branch (e.g. "mainline merge") with only these patches in > it. So speaking for OMAP, the patches on the LAK list and in RMKs patch > system are only there for review. If they are okay, RMK directly pulls > them from git. > > A short note from Kevin regarding this (thanks Kevin!): > > -- cut -- > I prefer that DaVinci patches first go to the davinci list and get > applied to DaVinici git. I will then organize and submit to RMK. > > ... > > I have no objections to other driver/subsystem patches going directly to > the maintainers (with me and/or davinci list in Cc) ... That is my > preference. However, for ARM core stuff, I prefer it goes through myself > and via DaVinci git where I can organize and re-order for submission via > RMK. > -- cut -- > > CCing LAK is an option. But, please, please, don't send DaVinci related > patches to other lists (e.g LAK or subsystem related) and don't CC this > DaVinci list! > >> 2) How can we track down submitted patches' status? For example I'm >> compiling my git kernel at the moment and I don't know if I should apply >> anything else on top of it. I think I should check git history and >> compare it with the mailing list messages? > > Is > > http://wiki.davincidsp.com/index.php?title=Linux_patches#Pending_patches > > what you want? >
Exactly, thanks for the pointer. > I try to keep it up to date, and if you look in history of this page, it > just decreased as with Kevins update to 2.6.25-rc6 :) > >> 3) I know that there is no one maintaining this tree currently and Kevin >> Hilman is performing this task at his own will. However, I wonder if >> there is a way to track what is supported on the git kernel. For >> example, you prepared a list on this a while ago. Then some patches >> submitted, mostly by Troy Kisky, and now I'm not sure about the latest >> status. I would maintain a wiki page on this if I were competent. Of >> course kernel source is the main place to look for answers, but some >> kind of double checking would be more than helpful. > > Yes, you are right, there is currently no place that lists what is > supported. Except the kernel source ;) > > But I would do it the other way around: List what is broken/unsupported. > As we did already in the past. Not what is supported, this will become > longer and longer over time ;) > > Looking at Kevin's old list [1], the status is (as I know): > > - I2C works > > - IDE has a new driver, probe fails [2] > > - NAND works > > - Video: Don't know, still broken? Neuros is working on it? > > http://git.neurostechnology.com/git/kernels > > - Audio: There is a DaVinci ASoC patch [3]. Nobody commented on it though. > > - Network / NFS: Works > > - MMC is fixed > > - Powermanagment: There is a patch > > - DM355 unsupported > > With this list I will start > > http://wiki.davincidsp.com/index.php?title=Linux_patches#Broken.2Funsupported_parts > > > Do you think this is okay? > Yes, this will be more than enough. >> 4) Even though you wrote patch attachments are accepted, I think inlines >> are still prefered. Right? > > Yes, you are right. For a lot of people attachments are easier, though > ;) I will note this in wiki. > >> 5) Do you think acking or replying with "reviewed by:" statements to the >> submitted patches is a good practice or not? I'm not asking for myself >> of course. > > I'm not so familiar with "reviewed by:". What do people think? > > We have "reviewed by:" in e.g. > > http://source.mvista.com/git/?p=linux-davinci-2.6.git;a=commitdiff;h=7c7e92a9268965e08bba853ecdb94fa55e886741 > > > from Alan Cox, so it can't be wrong at all ;) > > But Documentation/SubmittingPatches tells us: > > -- cut -- > ... > Acked-by: is not as formal as Signed-off-by:. It is a record that the > acker > has at least reviewed the patch and has indicated acceptance. Hence patch > mergers will sometimes manually convert an acker's "yep, looks good to me" > into an Acked-by:. > ... > -- cut -- > > So I think acking is the more official way and good practice. "reviewed > by:" isn't mentioned anywhere in kernel documentation. > Thanks again for all the explanations. Caglar > Cheers > > Dirk > > [1] > http://linux.omap.com/pipermail/davinci-linux-open-source/2008-February/005182.html > > > [2] > http://linux.omap.com/pipermail/davinci-linux-open-source/2008-March/005782.html > > > [3] > http://linux.omap.com/pipermail/davinci-linux-open-source/2008-March/005578.html > > _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
