bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary <>
Subject Fwd: Re: [Trac-dev] Bloodhound / Trac Approach
Date Fri, 06 Jan 2012 18:06:06 GMT
I think that this is more appropriate here for the moment. These 
questions do relate to trac-dev but we should probably kick some 
discussion off here relating to how we meet their suggestions and the 
more specific details of how we track our code and issues.


-------- Original Message --------

Private message , please forward to trac-dev if you think it's more appropriate

On Fri, Jan 6, 2012 at 10:28 AM, Christian Boos<>  wrote:
>  On 1/5/2012 12:56 PM, Gary wrote:
>  >  Hi everyone,
>  >
>  >>  Thanks David. I'm looking forward to seeing how Bloodhound progresses.
>  >>
>  >>  -Ethan
>  >
>  >  Obviously I am looking forward to this too! Thanks for all the views
>  >  expressed about this.
>  >
>  >  To get things moving a little I would like to check if there are any
>  >  preferences for where we branch or fork to the BSD licensed Bloodhound
>  >  core code. As previously noted, Ethan's suggestions were a Mercurial
>  >  patch queue or a Git fork. I have spotted the mirror of Trac on github
>  >  which might be a relatively easy route to work from. Is there anything
>  >  else that would be preferred?
>  >
>  We can deal with both. My personal preference would be git, these
>  days.
>  In any case, the following generic advice should apply:
>    - we prefer series of fixes or features focused on one topic
>     (if there are some clean-ups or unrelated changes done while
>     working on the topic, then at least split those changes in a
>     separate changeset)
>    - clearly indicate the purpose of the branch in its name (see
>     suggestions later) and fork these branches from the relevant
>     upstream branch (0.12-stable or trunk)

a decision needs to be made about this .
IMO start this from 0.12-stable is convenient so as to ensure
something will be ready in the next few months .

>    - be sure to follow the general code contributions guidelines
>     (

those above definitely should be considered .

Nonetheless *IMO* it would be nice to consider approach I mention
below in order to make Trac-dev&  Bloodhound coexist *peacefully* .

- Develop so much as possible just like if it was an independent ALv2
Trac plugin .
- In case core will need to be patched so as to make *Bloodhound
plugin* run ; I suggest to develop them in an Hg patch queue and
submit the patch(es) to them . Patch queues allow a much cleaner
development experience AFAICT as changes are committed to main
repository once review / test / requirements / ... is ready to go ;
and in the mean time that doesn't stop anybody from committing
"experimental" changes in the patch queue repository just like if
those were normal changesets .

>  Now some further advices you may want to follow or not...
>  Actually, I think you may end up with 3 kind of branches:
>  1. fix/feature branches; be sure to relate this to a ticket number
>     (e.g. T123 for a ticket on t.e.o, issue123 for an issue in
>     your github if you use the tracker there, BH123 for the future
>     Apache-hosted Bloodhound instance?)
>       Example name: fix-T10485-image-unicode-bug

in the case of Hg MQ these should be translated into either separate
patch queue repositories (for totally unrelated features) or multiple
patches stacked one on top of the other .
Something important we used to do before was to put patches inside a
folder named like cboos mentioned above . This way it was possible to
have some kind of traceability from tickets to patches (and changesets
in patch queue repository) implementing it . The same may be achieved
by using Hg branches in PQ repos , one for each ticket . Both options
may be even used at the same time .

>     These branches are best kept linear, for easier integration
>     upstream.  If after a while, the changes don't apply anymore
>     on latest code from upstream, then you should rather rebase
>     the changes instead of merging with upstream, as it's more
>     difficult to examine and reintegrate a branch if it contains
>     merge changesets.
>     Note that rather than rebasing the branch itself, you should
>     create a "rebasing branch", i.e. leave the original branch
>     alone and create a new rebased one with a related name which
>     shows clearly that it's a rebased branch
>     (e.g. in this case fix-T10485-image-unicode-bug.2)
>     This approach has the following advantages:
>      - the previous branch is not modified, so if anything else
>        depends on it (possibly someone somewhere clone it!)
>        there will be no surprises downstream
>      - it's easy to //compare// the two versions of the branches
>        to see what was has changed at the occasion of the rebase

In the case of patch queue , patches should look like yet another
changeset so regular merge ops may be used to update them whereas the
repos itself remains untouched until patch is approved and committed .

Then there's no need for merge vs rebase nightmare ... at least not so much

>     Btw, the very same procedure can be used for a "second
>     version" of the branch, for example if after review and
>     discussion, it's easier to actually rework some of the changes
>     rather than to add more changes to take the feedback into
>     account.
>     In practice, creating such a "rebasing branch" is very easy
>     with git:
>     {{{
>     $ git checkout -b fix-T10485-image-unicode-bug.2 fix-T10485-image-unicode-bug
>     $ git rebase trunk fix-T10485-image-unicode-bug.2
>     }}}
>     And with Mercurial (assuming you're using bookmarks - which you
>     should, as in Mercurial, branches are best used for naming the
>     maintenance branches):
>     {{{
>     $ hg rebase -b fix_T10485_image_unicode_bug -d trunk --keep
>     $ hg bookmark fix_T10485_image_unicode_bug.2
>     }}}
>     (for hg, I use '_' in the bookmark names, as '-' tends to
>      recognized as a revset operator...)

using patch queues this should not be big problem anymore .

>  2. Throw-away integration branches (a.k.a. "next")
>     You may want to use volatile branches where you test
>     integration of several new features.  Typically a bleeding
>     edge version you'd use for testing all the topic branches
>     together.
>     From time to time, the `next` branch is wiped out
>     and recreated from the latest maintenance branch,
>     then all the pending feature and fix branches
>     are merged in.

patches in patch queue repositories are throw-away by design so ...

>  3. Long term integration branches ("bloodhound" branch?)
>     This is where the diverging changes are maintained (e.g. a
>     feature branch which didn't get accepted upstream but is
>     nevertheless deemed important for you to keep) and in which
>     the changes from upstream are regularly merged in.  That
>     branch will never be rebased and will only ever see merges.

If development is to be done like I mentioned before (i.e. like if
Bloodhound was yet another standalone "Trac" plugin) then even a
separate repos should be ok (new branch may be as well)

>  Voila ;-) If people find these advices useful (especially 1.),
>  I'll integrate them in the Wiki.

My last $0.02 is that everything I mentioned before works with a
central Subversion repository . We have been doing this in
TracXmlRpcPlugin having :

- central official svn repos @ trac-hacks
- hg mirror @ Bitbucket
- patch queue @ Bitbucket as well

in this case workflow (simplified) is as follows :

1- hg mirror is updated (using hgsvn afaicr ...)
2- pending patches are updated to work with tip (optional)
3- new patches are created / stacked one of top of another /
     merged , ...
4- if patch is updated , reviewed and ok then it's applied
     and committed into central svn repos ...
5- go to step 1 ... ;)

PS: my intention is just to translate cboos message considering a
scenario where MQ is used . I'm not an expert on the subject and some
of my comments above may be inaccurate .



Facebook =>
Twitter => (@olemislc)
Blog ES =>
Blog EN =>
Quora =>
Youtube =>

Featured article : El SPDY de Google no es tan malo como el Internet
Explorer (IMO)
Tweet: El SPDY de #Google no es tan malo como el Internet Explorer
(IMO) #Simelo #blog #fb #windows
Follow @olemislc Reply Retweet   13:22 Jan-05
   Get this email app!
Get a signature like this. CLICK HERE.

View raw message