grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Improving the website about GRUB 2 development


From: Vesa Jääskeläinen
Subject: Re: Improving the website about GRUB 2 development
Date: Sat, 10 Nov 2007 21:06:28 +0200
User-agent: Thunderbird 2.0.0.6 (Windows/20070728)

Marco Gerards wrote:
> Hi,
> 
> On the website there is no information about how to send in patches
> (so improving in the title is a bit of an understatement ;)).  I think
> we should add a page with information about patches that are sent in.
> That saves us some times to comment on obvious problems with a patch.
> But more importantly, this will save much time for the developer
> sending in the patch.
> 
> There are several things I would like to mention on this page:
> 
> 1) GCS/Changelogs/Coding Style
> 
> We can even duplicate some things from the GCS that are the most
> important.  I can't blame anyone for sending in a patch that doesn't
> match our coding style.  It isn't obvious from the website.  On the
> other hand, we have a coding style and I think we should use it.

Perhaps add a link to GCS and then pinpoint most important rules with
examples.

> 2) Copyrights
> 
> We might want to mention that we ask people to assign their copyrights
> or sign a disclaimer.  If people know it will be asked, it won't scare
> them away.  Or if it is a serious problem for them, people won't waste
> time writing a patch that can't be included.  I am willing to put my
> address there as a contact person in case people would like to ask
> questions about this privately.
> 
> We should also write something about code from 3rd parties and about
> looking at code from other parties and thus cause copyright issues.

It should also describe why. When reason is known it is much easier to
accept that.

> 3) How to send in patches.
> 
> At the moment patches will be sent to the mailinglist.  We have to
> mention we like a Changelog and an inlined patch, as attachment is
> ok.  No generated files, big patches are ok.
> 
> 4) Reviewing
> 
> Reality is that we do not have the manpower to review the patch in a
> few days.  If we mention this, it won't come as a surprise.

Perhaps patch processing process should be documented and as a note on
reviewing phase note about this.

> 5) Focus
> 
> Url to the todo list, bug list and an url to a site which states the
> priorities for the next release.

Ah... and those should then be also up-to-date :). I think we had
discussion some time about TODO file. These files should contain a note
to URL to wiki.

> If we put this on a website in a friendly and attractive way, we might
> get more contributions.  I think the current lack of information
> causes problems to us.  What do you guys think?  Did I miss something,
> or am I over enthusiastic?

I think it would be beneficial to have page that describes how to report
bugs and how to send patches. Especially the bug reporting page should
be targeting people that are not familiar on how to report bugs.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]