Re: [oe-commits] Marco Cavallini : Added linux version recipes/linux/linux-2.6. 29 for taskit Stamp9G20 Evaluation Board

[Denys Dmytriyenko <denis@denix.org>]

On Mon, Jul 13, 2009 at 10:19:30PM +0200, Marco Cavallini wrote:
> Cliff Brake ha scritto:
> > On Mon, Jul 13, 2009 at 2:52 PM, Denys Dmytriyenko<denis@denix.org> wrote:
> >> On Mon, Jul 13, 2009 at 08:05:08PM +0200, Marcin Juszkiewicz wrote:
> >>> Dnia poniedzia??ek, 13 lipca 2009 o 17:13:22 git version control
> >>> napisa??(a):
> >>>
> >>> Please read CommitPolicy in wiki - first line of commit is summary and
> >>> should fit in 7x chars (weekly changelog script cuts at 78 chars) and
> >>> next lines are used for description. Also those two changes should be
> >>> squashed into one ("git rebase -i origin" would be useful command for
> >>> next patch set).
> >> Aren't policies required to be read by new developers when git access is
> >> granted? There used to be a welcome message sent by Mickey with helpful links
> >> to the Wiki. Is it still the case? Just wondering...
> > 
> > I have not seen such a message, but I suggest that
> > http://wiki.openembedded.net/index.php/New_commit_rights be updated to
> > contain any relevant information.  I'll start sending a link to this
> > page with new commit rights that I add.
> 
> Yes, if there are so many rules, would be a good idea to document all
> them in a signle place :-)
> I did my best updating what is editable :
> http://wiki.openembedded.net/index.php/Commit_log_example

Thanks. Taking into consideration the policies and common practices of 
other git-based projects, especially kernel.org ones, there are some 
small changes/nitpicks to consider:

- separate the short one-line description and the long description (if 
present) with an empty line. That would help with extracting and applying 
patches using git (git-format-patch/git-am), because the short decription 
becomes the Subject of the patch/email and if there is no emtpy line after it, 
the long description may get lost when the patch is sent over the email.

- don't start every line of the long description with a star "*" - this one is 
not technical but aestetical...

Everything else seems fine and corresponds to the common practices of the Open 
Source Community. :)

-- 
Denys