Caglar Akyuz wrote:
Dirk Behme wrote:
While discussing with Michael [1] we found that DaVinci patch submission
rules are not written down somewhere.
So I did it:
http://wiki.davincidsp.com/index.php?title=Patch_upstream_sending
Most of this is stolen from rules on OMAP list ;)
Opinions?
Thanks for your effort on collecting all these in one place. Given that
you are the submitter/reviewer of most of the patches hitting this
mailing list, this effort is two times valuable.
Since I don't have any experience about patch creation, I can't give any
opinions but more questions if they are welcome.
They are welcome!
1) I wonder why patches are not submitted to LAK also. Sometimes I read
some complaints on LAK about there being many platform specific
development lists around. Some people insist that LAK should be the
central place for *any* kind of arm-linux development. While I agree
that LAK is not the place to talk DaVinci specific development, isn't it
reasonable to CC LAK while submitting patches? I really don't have any
intention while asking this. I'm just wondering the reason behind
current methodology.
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?
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?
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.
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
