[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bazaar workflow for GRUB
Re: Bazaar workflow for GRUB
Tue, 19 Jan 2010 09:51:21 +0530
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.