Greg KH had written, on 10/22/2010 11:48 AM, the following:
On Fri, Oct 22, 2010 at 11:23:49AM -0500, Nishanth Menon wrote:
It would be great if Greg, Alan or Arjan could do a quick technical review
just to catch any possible typos in the technical instructions.
Looking back at the wiki, we probably need to add more stuff to it -
examples of how not to post patches, contents should not contain
mixed up changes etc.. dunno exactly how we'd go about it, but I
guess we'd all need some help sometime :)
All of this information is already included in the kernel Documentation/
directory, why duplicate it again?
Look at Documentation/SubmittingPatches for all of what you need. Is
there anything in that file that does not cover what you are trying to
express here?
Arrgh.. finally some time to reply.
Good point, and true to a large extent. Few of my reasons for why this wiki:
a) A supplementary training material that directs people with context to
the kernel doc: The original document I wrote internally came out of the
fact that few of my team members who had worked in non-Linux OS
transitioned to Linux and started submitting patches - this after
multitude trainings, guidance (including pointers to Documentation/...)
etc just did not make the mark - I then realized that in their shoes,
I'd have felt lost in the sudden delta in lingo. Some folks finally "get
it", while some folks eventually drop off due to the learning curve. Not
because the any of these engineers were any less smart, but only because
RTFM does'nt always help in getting a new contributor's interest. Hope
was to ease that pain by starting a document by the starters for the
starters. IMHO your video [1] is an excellent supplementary material
collating information from various sources to train folks.
b) MeeGo specific evolution of kernel standards: MeeGo kernel may
eventually evolve into having specific patch acceptance norms which are
slightly different from mainline acceptance criteria due to the nature
of the community involved:
Just an example: maybe we might evolve into a distro who'd require:
i) Have inline patches (such as those from git-send-email for main kernel)
AND
ii) Have the patches attached as well.
Reason being - many of the organizations use m$xchange (for what ever
reason) and m$xchange is kinda notorious (at least in my organization)
to mangle patches inline to the extent where they cannot be applied
directly without manual modification, making maintainer's life difficult.
The Spirit of MeeGo's "upstream first" is not lost here, just we evolve
to ease development perhaps a little differently..
c) Speed of evolution of material: kernel documentation changes have a
review process(good), but should'nt tricks and tips that budding kernel
developers learn be shared much faster? wiki is a nice way to do it..
Overall, kinda found this useful for my team, so I guess I had no reason
why not to share it with wider folks to choose if we (as a community)
need something like this or remove it if we choose we don't need it.
Ref:
[1] http://www.youtube.com/watch?v=LLBrBBImJt4
--
Regards,
Nishanth Menon
_______________________________________________
Meego-kernel mailing list
[email protected]
http://lists.meego.com/listinfo/meego-kernel
