incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hyrum K Wright <hyrum.wri...@wandisco.com>
Subject Re: Re: [Trac-dev] Bloodhound / Trac Approach
Date Fri, 06 Jan 2012 22:11:17 GMT
Agreed.  Even with all the ideas being thrown around regarding Trac
and the ASF and Bloodhound and everything else, I don't yet know what
the concrete plan is for organizing and distributing Bloodhound.  We
should hash that out here.

I'll let folks with more technical knowledge than myself chime in
here, but I'm interested to see what progresses.

-Hyrum

On Fri, Jan 6, 2012 at 12:06 PM, Gary <gary.martin@wandisco.com> wrote:
> 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.
>
> Cheers,
>    Gary
>
>
> -------- 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<christian.boos@free.fr>
>  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
>>    (http://trac.edgewall.org/wiki/HowToContribute#CodeContributions)
>>
>>
>
> 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 .
>
> --
> Regards,
>
> Olemis
>
> Facebook =>  http://www.facebook.com/olemis
> Twitter =>  http://www.twitter.com/olemislc (@olemislc)
> Blog ES =>  http://simelo-es.blogspot.com
> Blog EN =>  http://simelo-en.blogspot.com
> Quora =>  http://www.quora.com/olemis
> Youtube =>  http://youtube.com/user/greatsoftw
>
> Featured article : El SPDY de Google no es tan malo como el Internet
> Explorer (IMO)
> http://feedproxy.google.com/~r/simelo-news/~3/Uu6Ez9Qc5vQ/el-spdy-de-google-no-es-tan-malo-como.html
> Tweet: El SPDY de #Google no es tan malo como el Internet Explorer
> (IMO) http://t.co/AqNoHXFj #Simelo #blog #fb #windows
> Follow @olemislc Reply Retweet   13:22 Jan-05
>  Get this email app!
> Get a signature like this. CLICK HERE.
>



-- 

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/

Mime
View raw message