Experimental branch for GRUB

Experimental branch for GRUB

[Bean]

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.

-- 
Bean

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

Re: Experimental branch for GRUB

[Robert Millan]

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).

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Experimental branch for GRUB

[Bean]

On Fri, Oct 23, 2009 at 6:17 AM, Robert Millan <rmh@aybabtu.com> 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/

Re: Experimental branch for GRUB

[Robert Millan]

On Fri, Oct 23, 2009 at 03:06:02PM +0800, Bean wrote:
> 
> 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.

I've to go soon and can go in more detail later, but user branches work
fine.  I put two of my local patchsets there just a few minutes ago,
check http://bzr.savannah.gnu.org/lh/grub/people/robertmh/.

I think building deb from snapshots of this experimental branch is a good
idea, and it can be done in any place you see fit, BUT if a proprietary
solution is used, the GNU project can't endorse those (e.g. we wouldn't
link to them).  I haven't followed the latest developments on which parts
of Launchpad have been liberated.  In any case, if this turns out to be a
problem I can assist with the deb-building process (I got almost a decade of
experience with it).

GRUB does support external module building, but it's very impractical.  This
is why in Debian we opted for integrating grub-extras at source level, which
is also more solid (no need for ABI checks).  I intend to make it easier for
external source modules to be integrated into GRUB without need for patching
anything, but I haven't found the time to do this (maybe later this weekend).

As for bug reports, due to the nature of an experimental branch I don't
expect they will be very common.  Anyhow, I'll have a look at Savannah
BTS' versioning capabilities.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Experimental branch for GRUB

[Colin Watson]

On Fri, Oct 23, 2009 at 03:45:28PM +0200, Robert Millan wrote:
> I've to go soon and can go in more detail later, but user branches work
> fine.  I put two of my local patchsets there just a few minutes ago,
> check http://bzr.savannah.gnu.org/lh/grub/people/robertmh/.
> 
> I think building deb from snapshots of this experimental branch is a good
> idea, and it can be done in any place you see fit, BUT if a proprietary
> solution is used, the GNU project can't endorse those (e.g. we wouldn't
> link to them).  I haven't followed the latest developments on which parts
> of Launchpad have been liberated.

Launchpad is entirely free software now (contrary to an earlier plan you
may have heard of which involved holding back a couple of components;
that plan was later discarded). I haven't thought much about whether it
would be actively better for GRUB development, but I don't think there's
an ideological reason preventing it nowadays.

I'd be overjoyed to make use of Bazaar for GRUB development; I use it
for as many Ubuntu projects as possible, and these days for most of my
personal projects too since it generally does a good job of not getting
in my way. It would be easiest to do so if the Debian source package
were maintained in it too, as a straightforward branch of the
appropriate upstream revision; that way, it would be possible to simply
'bzr merge' changes.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: Experimental branch for GRUB

[Vladimir 'phcoder' Serbinenko]

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.
>
>   
I'm for this idea but we should ensure that features propagate
reasonably fast from experimental to main trunk. I propose to use
experimental only for features which are invasive and which may break
other features or big patches which needs several stages before being
usable or big patches which take too long to review. New non-intrusive
developement should get quite fast to normal trunk.
For experimental branches to be useful developpers should feel free to
commit the code even which wasn't reviewed the only 2 rules for
experimental branch should be:
-No commitment of non-FSF-copyrighted code without explicit maintainer
approval
-Respect of others

I also propose to have some kind of version string which would identify
from which experimental branch the grub was compiled and putting a
warning at the end of configure script so users would exercise
additional care

-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

Re: Experimental branch for GRUB

[Vladimir 'phcoder' Serbinenko]

> 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.
>
>   
GNU has the goal of creating software with solid legal grounds. It's the
whole reason for grub-extras to be separated. If we merge them in
experimental we have a risk of having more of non-FSF-copyrighted code
in main repository



-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: Experimental branch for GRUB

[Robert Millan]

On Fri, Oct 23, 2009 at 03:08:37PM +0100, Colin Watson wrote:
> On Fri, Oct 23, 2009 at 03:45:28PM +0200, Robert Millan wrote:
> > 
> > I think building deb from snapshots of this experimental branch is a good
> > idea, and it can be done in any place you see fit, BUT if a proprietary
> > solution is used, the GNU project can't endorse those (e.g. we wouldn't
> > link to them).  I haven't followed the latest developments on which parts
> > of Launchpad have been liberated.
> 
> Launchpad is entirely free software now (contrary to an earlier plan you
> may have heard of which involved holding back a couple of components;
> that plan was later discarded). I haven't thought much about whether it
> would be actively better for GRUB development, but I don't think there's
> an ideological reason preventing it nowadays.

Thank you Colin for clarifiing this.  Then I have no objection with endorsing
binary packages built with this service.

(A different question is whether we would consider them official; but this
depends on whether they originate from an official source tree, not on which
facility was used to build them)

> I'd be overjoyed to make use of Bazaar for GRUB development; I use it
> for as many Ubuntu projects as possible, and these days for most of my
> personal projects too since it generally does a good job of not getting
> in my way. It would be easiest to do so if the Debian source package
> were maintained in it too, as a straightforward branch of the
> appropriate upstream revision; that way, it would be possible to simply
> 'bzr merge' changes.

Slightly off-topic, but let's ignore that just this time ;-)

Speaking as Debian maintainer, I have no objection to it.  However, Felix
would have to agree as well.  I'm fine with staying with SVN in the Debian
package too.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Experimental branch for GRUB

[Robert Millan]

On Fri, Oct 23, 2009 at 04:35:32PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> 
> I also propose to have some kind of version string which would identify
> from which experimental branch the grub was compiled and putting a
> warning at the end of configure script so users would exercise
> additional care

Sounds good (both things).

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."