Re: Experimental branch for GRUB

[Bean]

On Fri, Oct 23, 2009 at 6:17 AM, Robert Millan <address@hidden> wrote:
> On Thu, Oct 22, 2009 at 05:17:55PM +0800, Bean wrote:
>> Hi,
>>
>> I think it could be beneficial to have a experimental branch for GRUB.
>> Minor bug fixes can be applied to mainstream directly. But for big and
>> intrusive changes, such as the new menu system, we can place it in the
>> experimental branch first. Users interested in the latest fancy
>> feature can use the experimental branch, while more conservative users
>> can use mainstream code. When the code in experimental branch become
>> stable enough, we can integrate it back to the main repository.
>
> Sometimes I find myself in need of that too.
>
> As you probably noticed, I recently got started with GNU Bazaar (initially
> as part of my involvement with gNewSense).  There's now a Bazaar mirror of
> GRUB SVN, and I'm beginning to use it to manage my own patchsets.
>
> I think it is natural that, since it's part of the GNU system, Bazaar is the
> first option to be taken into consideration for this task.  I think we all
> agree that while SVN is (and will continue to be) a good consensus solution
> for managing a trunk, it doesn't excel when it comes to branching.
>
> My experience with it is limited, but it seems to be capable of dealing
> with the workflow you're proposing (branching, resyncing, etc), and I have
> observed that its UI is quite simple and easy to figure out.
>
> Perhaps someone who's more seasoned than me in using Bazaar can provide
> his/her insight, or perhaps you'd like to play with it (if you haven't
> already) by branching off the mirror I just finished setting up (see my
> other mail).

Hi,

I take a quick look at bazaar, it seems to be working fine. However,
if we are to use bazaar, I suggest we host the project at launchpad,
for several reasons:

Launchpad have a nice web interface.

Launchpad can build ubuntu package from source code.

Like GITHUB, launchpad allows users to fork the project and work on
user branch. This is important for big patch as it usually go through
several few steps before completion.

We might want to create a unified repo for grub and grub-extra. As
grub doesn't  support external module building, split it in two parts
is not convenient for both developer and user. Therefore, we can
maintain an unified source tree in the experimental repo, and push
patch to the corresponding project when applied upstream.

We don't want to mix bug report for experiential feature with official
grub2. Launchpad has its own bug tracking system, we can use it to
process bug report concerning the experimental branch.

-- 
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/