Re: Bazaar workflow for GRUB

[BVK Chaitanya]

On Mon, Jan 18, 2010 at 11:19 PM, Colin D Bennett <address@hidden> wrote:
>>
>> * For Occasional Contributors
>>
>> This workflow is recommended for users/developers who want to fix
>> just-one GRUB issue.  This involves a trunk checkout, some local
>> commits (as necessary for fixing the issue) and sending the patch to
>> [[http://lists.gnu.org/archive/html/grub-devel][grub-devel]] mailing
>> list.  GRUB maintainers would take care of committing it to the trunk.
>
> I would avoid using the word “checkout” except when an actual Bazaar
> checkout (heavyweight or lightweight) is being used.  I think the
> workflow you describe (avoiding checkouts) keeps things simpler since
> checkouts behave differently than branches in some cases, and branches
> with the “pull” command can do everything that a regular checkout can.


Yes, I will replace checkout with "copy" or something.

Yes, I wanted to keep it simple so I suggested bzr branch (instead of
bzr checkout) everywhere.  GRUB branch is small (about 15MB), so IMO
there is not much to gain in checkout than a branch.


>>
>> # create a patch and send to mailing list
>> grub$ bzr diff -r submit: > ~/my-issue-fix.diff
>
> Why not use “bzr send -o ~/my-issue-fix.patch” to create a merge
> directive+patch+revision bundle?  The benefit of bzr send over plain bzr
> diff is that individual revisions within the change are preserved,
> which can provide richer history.  Merge directives can simply be
> applied with “bzr merge my-issue-fix.patch”.
>

I haven't seen anybody sending "bzr send" patches in the ML, so I
didn't want to introduce something new.  Is its format compatible with
regular patch tool?

>
> It is also easy to discard sub-revisions when merging a revision bundle
> into mainline, if for some reason the committer so desires.


bzr revert --forget-merges?


>
> I would recommend or at least mention the option of creating a shared
> repository before branching the remote branch.  Whenever a branch is
> downloaded to a directory underneath a shared repository in the
> directory hierarchy, its revisions are stored in the shared repository
> instead of directly in the branch directory.  This means the you can
> cheaply clone the branch (or download other remote branches related to
> it, for instance) and the common revisions will not be duplicated on
> your hard disk or re-transferred across the network.
>
> Before executing the “bzr branch” command, run “bzr init-repo .” in a
> directory under which you wish to put your branches.  After this, all
> other commands will be the same whether a shared repository is in use
> or not.


I will add an entry for this.


>
> Do you want to mention how GRUB committers should merge features to the
> official trunk branch?


Yeah, I completely forgot about this one.  I need to add a new section.


thanks,
-- 
bvk.chaitanya