Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4F07380E.7060505@wandisco.com>
References: 
 <CAGMZAuPFVp84AossEOva_-GtrD2q5yBqZ48hbX9gGFgsOpKhyA@mail.gmail.com>
	<4F07380E.7060505@wandisco.com>
Date: Fri, 6 Jan 2012 16:11:17 -0600
Message-ID: 
 <CAJjMeYMQTdhLaDwv8YMP43nu0g3MrEfKpaWYGCZd_FXFZT7L7Q@mail.gmail.com>
Subject: Re: Re: [Trac-dev] Bloodhound / Trac Approach
From: Hyrum K Wright <hyrum.wright@wandisco.com>
To: bloodhound-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 question=
s
> do relate to trac-dev but we should probably kick some discussion off her=
e
> relating to how we meet their suggestions and the more specific details o=
f
> how we track our code and issues.
>
> Cheers,
> =C2=A0 =C2=A0Gary
>
>
> -------- 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>
> =C2=A0wrote:
>>
>> =C2=A0On 1/5/2012 12:56 PM, Gary wrote:
>> =C2=A0> =C2=A0Hi everyone,
>> =C2=A0>
>> =C2=A0>> =C2=A0Thanks David. I'm looking forward to seeing how Bloodhoun=
d
>> progresses.
>> =C2=A0>>
>> =C2=A0>> =C2=A0-Ethan
>> =C2=A0>
>> =C2=A0> =C2=A0Obviously I am looking forward to this too! Thanks for all=
 the views
>> =C2=A0> =C2=A0expressed about this.
>> =C2=A0>
>> =C2=A0> =C2=A0To get things moving a little I would like to check if the=
re are any
>> =C2=A0> =C2=A0preferences for where we branch or fork to the BSD license=
d Bloodhound
>> =C2=A0> =C2=A0core code. As previously noted, Ethan's suggestions were a=
 Mercurial
>> =C2=A0> =C2=A0patch queue or a Git fork. I have spotted the mirror of Tr=
ac on github
>> =C2=A0> =C2=A0which might be a relatively easy route to work from. Is th=
ere anything
>> =C2=A0> =C2=A0else that would be preferred?
>> =C2=A0>
>>
>> =C2=A0We can deal with both. My personal preference would be git, these
>> =C2=A0days.
>>
>> =C2=A0In any case, the following generic advice should apply:
>>
>> =C2=A0 - we prefer series of fixes or features focused on one topic
>> =C2=A0 =C2=A0(if there are some clean-ups or unrelated changes done whil=
e
>> =C2=A0 =C2=A0working on the topic, then at least split those changes in =
a
>> =C2=A0 =C2=A0separate changeset)
>>
>> =C2=A0 - clearly indicate the purpose of the branch in its name (see
>> =C2=A0 =C2=A0suggestions later) and fork these branches from the relevan=
t
>> =C2=A0 =C2=A0upstream 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 .
> ;)
>
>>
>> =C2=A0 - be sure to follow the general code contributions guidelines
>> =C2=A0 =C2=A0(http://trac.edgewall.org/wiki/HowToContribute#CodeContribu=
tions)
>>
>>
>
> those above definitely should be considered .
>
> Nonetheless *IMO* it would be nice to consider approach I mention
> below in order to make Trac-dev& =C2=A0Bloodhound 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 .
>
>> =C2=A0Now some further advices you may want to follow or not...
>>
>> =C2=A0Actually, I think you may end up with 3 kind of branches:
>>
>> =C2=A01. fix/feature branches; be sure to relate this to a ticket number
>> =C2=A0 =C2=A0(e.g. T123 for a ticket on t.e.o, issue123 for an issue in
>> =C2=A0 =C2=A0your github if you use the tracker there, BH123 for the fut=
ure
>> =C2=A0 =C2=A0Apache-hosted Bloodhound instance?)
>>
>> =C2=A0 =C2=A0 =C2=A0Example 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 .
>
>>
>> =C2=A0 =C2=A0These branches are best kept linear, for easier integration
>> =C2=A0 =C2=A0upstream. =C2=A0If after a while, the changes don't apply a=
nymore
>> =C2=A0 =C2=A0on latest code from upstream, then you should rather rebase
>> =C2=A0 =C2=A0the changes instead of merging with upstream, as it's more
>> =C2=A0 =C2=A0difficult to examine and reintegrate a branch if it contain=
s
>> =C2=A0 =C2=A0merge changesets.
>>
>> =C2=A0 =C2=A0Note that rather than rebasing the branch itself, you shoul=
d
>> =C2=A0 =C2=A0create a "rebasing branch", i.e. leave the original branch
>> =C2=A0 =C2=A0alone and create a new rebased one with a related name whic=
h
>> =C2=A0 =C2=A0shows clearly that it's a rebased branch
>> =C2=A0 =C2=A0(e.g. in this case fix-T10485-image-unicode-bug.2)
>>
>> =C2=A0 =C2=A0This approach has the following advantages:
>>
>> =C2=A0 =C2=A0 - the previous branch is not modified, so if anything else
>> =C2=A0 =C2=A0 =C2=A0 depends on it (possibly someone somewhere clone it!=
)
>> =C2=A0 =C2=A0 =C2=A0 there will be no surprises downstream
>>
>> =C2=A0 =C2=A0 - it's easy to //compare// the two versions of the branche=
s
>> =C2=A0 =C2=A0 =C2=A0 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 mu=
ch
> ;)
>
>>
>> =C2=A0 =C2=A0Btw, the very same procedure can be used for a "second
>> =C2=A0 =C2=A0version" of the branch, for example if after review and
>> =C2=A0 =C2=A0discussion, it's easier to actually rework some of the chan=
ges
>> =C2=A0 =C2=A0rather than to add more changes to take the feedback into
>> =C2=A0 =C2=A0account.
>>
>> =C2=A0 =C2=A0In practice, creating such a "rebasing branch" is very easy
>> =C2=A0 =C2=A0with git:
>>
>> =C2=A0 =C2=A0{{{
>> =C2=A0 =C2=A0$ git checkout -b fix-T10485-image-unicode-bug.2
>> fix-T10485-image-unicode-bug
>> =C2=A0 =C2=A0$ git rebase trunk fix-T10485-image-unicode-bug.2
>> =C2=A0 =C2=A0}}}
>>
>> =C2=A0 =C2=A0And with Mercurial (assuming you're using bookmarks - which=
 you
>> =C2=A0 =C2=A0should, as in Mercurial, branches are best used for naming =
the
>> =C2=A0 =C2=A0maintenance branches):
>>
>> =C2=A0 =C2=A0{{{
>> =C2=A0 =C2=A0$ hg rebase -b fix_T10485_image_unicode_bug -d trunk --keep
>> =C2=A0 =C2=A0$ hg bookmark fix_T10485_image_unicode_bug.2
>> =C2=A0 =C2=A0}}}
>>
>> =C2=A0 =C2=A0(for hg, I use '_' in the bookmark names, as '-' tends to
>> =C2=A0 =C2=A0 recognized as a revset operator...)
>>
>
> using patch queues this should not be big problem anymore .
>
>>
>> =C2=A02. Throw-away integration branches (a.k.a. "next")
>>
>> =C2=A0 =C2=A0You may want to use volatile branches where you test
>> =C2=A0 =C2=A0integration of several new features. =C2=A0Typically a blee=
ding
>> =C2=A0 =C2=A0edge version you'd use for testing all the topic branches
>> =C2=A0 =C2=A0together.
>>
>> =C2=A0 =C2=A0From time to time, the `next` branch is wiped out
>> =C2=A0 =C2=A0and recreated from the latest maintenance branch,
>> =C2=A0 =C2=A0then all the pending feature and fix branches
>> =C2=A0 =C2=A0are merged in.
>>
>
> patches in patch queue repositories are throw-away by design so ...
>
>>
>>
>> =C2=A03. Long term integration branches ("bloodhound" branch?)
>>
>> =C2=A0 =C2=A0This is where the diverging changes are maintained (e.g. a
>> =C2=A0 =C2=A0feature branch which didn't get accepted upstream but is
>> =C2=A0 =C2=A0nevertheless deemed important for you to keep) and in which
>> =C2=A0 =C2=A0the changes from upstream are regularly merged in. =C2=A0Th=
at
>> =C2=A0 =C2=A0branch 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)
>
>>
>>
>> =C2=A0Voila ;-) If people find these advices useful (especially 1.),
>> =C2=A0I'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 /
> =C2=A0 =C2=A0merged , ...
> 4- if patch is updated , reviewed and ok then it's applied
> =C2=A0 =C2=A0and 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 =3D> =C2=A0http://www.facebook.com/olemis
> Twitter =3D> =C2=A0http://www.twitter.com/olemislc (@olemislc)
> Blog ES =3D> =C2=A0http://simelo-es.blogspot.com
> Blog EN =3D> =C2=A0http://simelo-en.blogspot.com
> Quora =3D> =C2=A0http://www.quora.com/olemis
> Youtube =3D> =C2=A0http://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-goog=
le-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 =C2=A0 13:22 Jan-05
> =C2=A0Get this email app!
> Get a signature like this. CLICK HERE.
>


--=20

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