You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Gary <ga...@wandisco.com> on 2012/01/06 19:06:06 UTC
Fwd: Re: [Trac-dev] Bloodhound / Trac Approach
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<ch...@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.
Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Jim Callahan <ji...@statefarm.com>.
Our setup is probably unique. We've implemented various solutions in the
past, among them, large, integrated third-party solutions as well as
one-off things that teams supported themselves.
Currently, we're working under the assumption that teams will manage their
products and defects/tasks under a small Trac instance on a single server.
However, when aggregated up, it turns out that there are lots of servers
associated with a single area, or large team.
I'm not sure how much I can legally tell you based on our policies, but
suffice it to say that the 10,000 ft view is very disconnected and
disjointed. However, the Multiple SVN to one Trac implemented in 0.12 was
a godsend now users can apply individual auth to their repos and they like
it!
Currently, we're working on a way to split SVN repos and Trac Projects
associated to those repos as some are getting quite large.
In addition, we're working on a plugin to copy Trac tickets from one
project to another. A task which has turned out to be a quite interesting
problem.
Anyway, we'll be looking to contribute that plugin in the future (when
legal says it's ok)
Jim Callahan
On 1/10/12 3:37 PM, "Gary" <ga...@wandisco.com> wrote:
>Hi Jim,
>
>On 10/01/12 19:33, Jim Callahan wrote:
>> Thanks for the symantic clarification :) I'll have to do some more
>> thinking (that's the understatement of the year) and hopefully be able
>>to
>> weigh in when I have a clearer understanding.
>>
>>
>>
>> Jim Callahan
>
>Yes, Olemis is completely correct. Our solution is not likely to be as
>general as providing the scaffolding for working across multiple servers
>but I think it should make it cover most needs.
>
>Because of your talk of multiple servers with multiple instances, I am
>interested in your setup. Have you found it necessary to use multiple
>servers? If you really do mean multiple instances of Trac have you
>considered multiple environments on a single Trac instance?
>
>Basically I am interested in the performance of large Trac installations
>and so I hope it can't hurt to ask. I can't guarantee that it will help
>you but, if you haven't had the chance to try alternative setups then
>you never know! Of course, if there is any chance that if Trac can be
>installed and run fast on a single Trac installation then the solution
>that we are going for would also become viable for you, which would be
>fantastic.
>
>Cheers,
> Gary
Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Gary <ga...@wandisco.com>.
Hi Jim,
On 10/01/12 19:33, Jim Callahan wrote:
> Thanks for the symantic clarification :) I'll have to do some more
> thinking (that's the understatement of the year) and hopefully be able to
> weigh in when I have a clearer understanding.
>
>
>
> Jim Callahan
Yes, Olemis is completely correct. Our solution is not likely to be as
general as providing the scaffolding for working across multiple servers
but I think it should make it cover most needs.
Because of your talk of multiple servers with multiple instances, I am
interested in your setup. Have you found it necessary to use multiple
servers? If you really do mean multiple instances of Trac have you
considered multiple environments on a single Trac instance?
Basically I am interested in the performance of large Trac installations
and so I hope it can't hurt to ask. I can't guarantee that it will help
you but, if you haven't had the chance to try alternative setups then
you never know! Of course, if there is any chance that if Trac can be
installed and run fast on a single Trac installation then the solution
that we are going for would also become viable for you, which would be
fantastic.
Cheers,
Gary
Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Jim Callahan <ji...@statefarm.com>.
Thanks for the symantic clarification :) I'll have to do some more
thinking (that's the understatement of the year) and hopefully be able to
weigh in when I have a clearer understanding.
Jim Callahan
On 1/10/12 1:26 PM, "Olemis Lang" <ol...@gmail.com> wrote:
>On Tue, Jan 10, 2012 at 9:01 AM, Jim Callahan <
>jim.callahan.hsqe@statefarm.com> wrote:
>> On 1/10/12 7:13 AM, "Gary" <ga...@wandisco.com> wrote:
>>>
>>>the first one of those plugins will be support for multiple projects
>>>in a single environment . I've put pieces together and it seems to be
>>>possible to build it on top of 0.12-stable without hacking core "too
>>>much "<= TBD ;)
>>
>> Hi guys!
>>
>> I assume when you say single environment, you mean on a single server.
>
>Not exactly . When we mention single environment we refer to one of the
>following specifications
>
>http://trac.edgewall.org/wiki/TracMultipleProjects/SingleEnvironment
>http://trac.edgewall.org/wiki/TracDev/Proposals/MultipleProject
>
>... especially the later which is based on the former . There are other
>similar proposals to get similar configurations possible , but using
>multiple Trac environments instead . Nonetheless these are not considered
>by trac-dev at the moment (neither do we ... afaik ;)
>
>> The real issue comes in when folks have to navigate from one server to
>> another to search, copy, update, etc. I'd like to put in my vote for
>> support across multiple environments :)
>>
>
>good to know you are interested on this subject
>:)
>
>--
>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>
>[image: Twitter] <http://twitter.com/olemislc>Tweet: El SPDY de #Google no
>es tan malo como el Internet Explorer (IMO) http://t.co/AqNoHXFj #Simelo
>#blog #fb #windows
>Follow @olemislc <http://twitter.com/olemislc> Reply
><http://twitter.com/?status=@olemislc%20&in_reply_to_status_id=15499107194
>6997760&in_reply_to=olemislc>
> Retweet
><http://twitter.com/?status=RT%20%40olemislc%3A%20El%20SPDY%20de%20%23Goog
>le%20no%20es%20tan%20malo%20como%20el%20Internet%20Explorer%20(IMO)%20http
>%3A%2F%2Ft.co%2FAqNoHXFj%20%23Simelo%20%23blog%20%23fb%20%23windows>
> 13:22
>Jan-05 <http://twitter.com/olemislc/statuses/154991071946997760>
> Get this email app!
><http://www.wisestamp.com/apps/twitter?utm_source=extension&utm_medium=ema
>il&utm_term=twitter&utm_campaign=apps>
>
>Get a signature like this.
><http://r1.wisestamp.com/r/landing?promo=17&dest=http%3A%2F%2Fwww.wisestam
>p.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_
>campaign%3Dpromo_17>CLICK
>HERE.<http://r1.wisestamp.com/r/landing?promo=17&dest=http%3A%2F%2Fwww.wis
>estamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%2
>6utm_campaign%3Dpromo_17>
Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Olemis Lang <ol...@gmail.com>.
On Tue, Jan 10, 2012 at 9:01 AM, Jim Callahan <
jim.callahan.hsqe@statefarm.com> wrote:
> On 1/10/12 7:13 AM, "Gary" <ga...@wandisco.com> wrote:
>>
>>the first one of those plugins will be support for multiple projects
>>in a single environment . I've put pieces together and it seems to be
>>possible to build it on top of 0.12-stable without hacking core "too
>>much "<= TBD ;)
>
> Hi guys!
>
> I assume when you say single environment, you mean on a single server.
Not exactly . When we mention single environment we refer to one of the
following specifications
http://trac.edgewall.org/wiki/TracMultipleProjects/SingleEnvironment
http://trac.edgewall.org/wiki/TracDev/Proposals/MultipleProject
... especially the later which is based on the former . There are other
similar proposals to get similar configurations possible , but using
multiple Trac environments instead . Nonetheless these are not considered
by trac-dev at the moment (neither do we ... afaik ;)
> The real issue comes in when folks have to navigate from one server to
> another to search, copy, update, etc. I'd like to put in my vote for
> support across multiple environments :)
>
good to know you are interested on this subject
:)
--
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>
[image: Twitter] <http://twitter.com/olemislc>Tweet: El SPDY de #Google no
es tan malo como el Internet Explorer (IMO) http://t.co/AqNoHXFj #Simelo
#blog #fb #windows
Follow @olemislc <http://twitter.com/olemislc> Reply
<http://twitter.com/?status=@olemislc%20&in_reply_to_status_id=154991071946997760&in_reply_to=olemislc>
Retweet <http://twitter.com/?status=RT%20%40olemislc%3A%20El%20SPDY%20de%20%23Google%20no%20es%20tan%20malo%20como%20el%20Internet%20Explorer%20(IMO)%20http%3A%2F%2Ft.co%2FAqNoHXFj%20%23Simelo%20%23blog%20%23fb%20%23windows>
13:22
Jan-05 <http://twitter.com/olemislc/statuses/154991071946997760>
Get this email app!
<http://www.wisestamp.com/apps/twitter?utm_source=extension&utm_medium=email&utm_term=twitter&utm_campaign=apps>
Get a signature like this.
<http://r1.wisestamp.com/r/landing?promo=17&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_17>CLICK
HERE.<http://r1.wisestamp.com/r/landing?promo=17&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_17>
Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Jim Callahan <ji...@statefarm.com>.
Hi guys!
I assume when you say single environment, you mean on a single server. In
our infrastructure, we've built out a bunch of individual servers with
multiple Trac Projects on each.
The real issue comes in when folks have to navigate from one server to
another to search, copy, update, etc. I'd like to put in my vote for
support across multiple environments :)
Jim Callahan
On 1/10/12 7:13 AM, "Gary" <ga...@wandisco.com> wrote:
>
>the first one of those plugins will be support for multiple projects
>in a single environment . I've put pieces together and it seems to be
>possible to build it on top of 0.12-stable without hacking core "too
>much "<= TBD ;)
Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Olemis Lang <ol...@gmail.com>.
On Wed, Jan 11, 2012 at 10:04 AM, Gary <ga...@wandisco.com> wrote:
>
> On 01/10/2012 04:06 PM, Olemis Lang wrote:
>>
>>
>>> and we might be able to avoid changing existing tables by also providing a
>>> table that maps resources to their project.
>>
>>
>>
>> exactly !
>> Even if I didn't mention this before it seems we are in sync (as that's a
>> bit straightforward reasoning ;)
>> In fact I was thinking of considering projects as yet another Trac resource
>> and therefore try to implement such mapping as similar to TracRelations
>> spec [1]_ as possible / needed .
>
> I am not sure of how much work it would be to go with that. TracRelations is not claimed to be a complete specification and so it might be better to avoid until it is implemented in Trac. It is a similar feeling that I get with talk of GenericTrac. I don't particularly like having to specify that we should write our solution with the expectation of refactoring but, then again, a move to GenericTrac would result in a refactor of everything else so I don't see quite so much harm.
Well ... my idea was not to do it *exactly* like in that spec but *as
close as possible* so that when all this will be available in Trac
it'd be easier to incorporate those into Bloodhound (e.g. similar
reports SQL definition , at least not completely different ;)
>>
>>> Or we could just add the extra project field to the appropriate tables.
>>> There is something appealing to me about the latter no-nonsense approach :)
>>>
>>>
>> What'd be the pros& cons of (1 - project to resource mapping table) vs (2
>>
>> - extra project field) ?
>> IMO #1 is in sound with the more generic TracRelations proposal (as far as
>> DB is concerned , project-specific behavior is another $0.02 ;) whereas #2
>> breaks the more generic resource relations framework @ the DB level .
>
> Well, in a sense, anything that should belong to a project does belong to a project, even if it is the null project (or whatever). That suggests to me that it is a property of the object rather than a mapping.
ok . I get it.
>
> However, the resource table would allow for a resource belonging to multiple projects. I am not sure that is appropriate yet.
That depends on table structure , if resource id field(s) is(are) the
primary key and project ID is a foreign key then there's no chance for
this to happen . Like I said before , similar != exactly .
Nonetheless there are cases to pay attention to as it should be
possible to have CamelCaseName wiki page for both project 1 and
project 2 . AFAICS that's not possible with #1 ...
> On the other hand, it would allow for independent database versioning and upgrades.
... now I recall «practically beats purity» ...
;)
>>
>> ... question may also be reformulated this way : Considering TracRelations
>> is out there , what makes projects so special so as to make an exception
>> with them at the DB-level ?
>>
>> Either way I was thinking of providing projects with at least the following
>>>
>>> details
>>>
>>> * name
>>> * short_name (unique and fixed)
>>> * description
>>>
>>> where the short_name acts as a label in any referencing between projects.
>>>
>>>
>> +1
>> ... once I submitted project labels proposal [2]_ to trac-dev it was noted
>> (with strong arguments IMO) that resource history may be important to be
>> tracked as well . For project labels it makes sense . Maybe we should
>> consider whether history meta-data might be appropriate for projects& what
>>
>> events exactly will be tracked during project lifetime .
>
> I thought that the arguments around that were about changes in name. I should probably look closer at that but the reason that I want short_name to be fixed is to reduce ambiguity. That said, a history does not seem unreasonable.
>
For project labels changes include modification to label-specific
fields + project membership actions (add, remove , ...) which makes
sense (to me) considering the use case provided by Chris Nelson in
trac-dev ...
>>
>>
>> Personally I would also like to see independent ticket numbering per
>>>
>>> project but this may be too ambitious.
>>
>>
>> maybe possible with #2 above but definitely not with #1 ; but even if #2
>> allows to do so ...
>
> Just to check..
>
> #1 = project to resource mapping?
> #2 = extra project field?
>
yes
>
> Well, I sort of disagree :) Only in the sense that it would should require an extra bit of information for both (the ticket number associated with the project).
>
JFTR
- #1 implies that ticket number will be the primary key of Ticket
table (just like now) and (project , ticket) association will be
stored in a separate table . Therefore there's no chance to have
ticket 1 in both project 1 and 2 .
- In #2 it's maybe possible i.e. if (projectid , ticketid) is the
primary key of Ticket table .
Nonetheless , consider #2 is the way to go . I just mention an example
. Suppose ticket 1 belongs to project «prj» . References in e.g. wiki
pages should look like ticket:prj:1 . If that ticket is moved onto
another project e.g. then all those references will be invalid .
Nonetheless if ticket ID is unique in the context of the environment
(not the project) then ticket:1 makes reference to that ticket and
reference will be valid even if it suddenly belongs to a different
project .
;)
>>
>>> If we manage this, however, it should simplify the combining of multiple
>>> existing environments into a single project from the user's perspective:
>>> existing commit messages and internal ticket links within a project would
>>> be able to remain consistent.
>>>
>>>
>> ... maybe it's not a good idea considering your comment above . If ticket
>> has its own identity (like it happens right now as opposite to project ID +
>> ticket ID) references will always be valid (just like it happens right now)
>> , no matter what relations it has with other resources (e.g. projects) and
>> how they change with time . IMO going for #2 + independent ticket numbering
>> may lead to over-complicating a system that just works right now . In any
>> case that doesn't mean that visually e.g. project ID (e.g. short_name)
>> might be displayed in ticket link text.
>
> That is definitely a good argument and, for the initial work, it might be worth sticking to that. My reasoning was based on the idea of people wanting to combine existing environments. Existing references would become invalid if we were to expect to be able to do this.
>
oh ! maybe I mentioned the same subject once again above ...
:-/
--
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 : Identificando números primos con expresión regular en Perl
http://feedproxy.google.com/~r/simelo-news/~3/BHr859OSndo/identificando-numeros-primos-con.html
Get a signature like this. CLICK HERE.
Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Gary <ga...@wandisco.com>.
On 01/10/2012 04:06 PM, Olemis Lang wrote:
>
>> and we might be able to avoid changing existing tables by also providing a
>> table that maps resources to their project.
>
>
> exactly !
> Even if I didn't mention this before it seems we are in sync (as that's a
> bit straightforward reasoning ;)
> In fact I was thinking of considering projects as yet another Trac resource
> and therefore try to implement such mapping as similar to TracRelations
> spec [1]_ as possible / needed .
I am not sure of how much work it would be to go with that.
TracRelations is not claimed to be a complete specification and so it
might be better to avoid until it is implemented in Trac. It is a
similar feeling that I get with talk of GenericTrac. I don't
particularly like having to specify that we should write our solution
with the expectation of refactoring but, then again, a move to
GenericTrac would result in a refactor of everything else so I don't see
quite so much harm.
>
>> Or we could just add the extra project field to the appropriate tables.
>> There is something appealing to me about the latter no-nonsense approach :)
>>
>>
> What'd be the pros& cons of (1 - project to resource mapping table) vs (2
> - extra project field) ?
> IMO #1 is in sound with the more generic TracRelations proposal (as far as
> DB is concerned , project-specific behavior is another $0.02 ;) whereas #2
> breaks the more generic resource relations framework @ the DB level .
Well, in a sense, anything that should belong to a project does belong
to a project, even if it is the null project (or whatever). That
suggests to me that it is a property of the object rather than a
mapping. However, the resource table would allow for a resource
belonging to multiple projects. I am not sure that is appropriate yet.
On the other hand, it would allow for independent database versioning
and upgrades.
> ... question may also be reformulated this way : Considering TracRelations
> is out there , what makes projects so special so as to make an exception
> with them at the DB-level ?
>
> Either way I was thinking of providing projects with at least the following
>> details
>>
>> * name
>> * short_name (unique and fixed)
>> * description
>>
>> where the short_name acts as a label in any referencing between projects.
>>
>>
> +1
> ... once I submitted project labels proposal [2]_ to trac-dev it was noted
> (with strong arguments IMO) that resource history may be important to be
> tracked as well . For project labels it makes sense . Maybe we should
> consider whether history meta-data might be appropriate for projects& what
> events exactly will be tracked during project lifetime .
I thought that the arguments around that were about changes in name. I
should probably look closer at that but the reason that I want
short_name to be fixed is to reduce ambiguity. That said, a history does
not seem unreasonable.
> Isn't the Trac-ky thingy just lovely ?
> I hope we all can make it better ...
> :)
>
> Personally I would also like to see independent ticket numbering per
>> project but this may be too ambitious.
>
> maybe possible with #2 above but definitely not with #1 ; but even if #2
> allows to do so ...
Just to check..
#1 = project to resource mapping?
#2 = extra project field?
Well, I sort of disagree :) Only in the sense that it would should
require an extra bit of information for both (the ticket number
associated with the project).
>
>> If we manage this, however, it should simplify the combining of multiple
>> existing environments into a single project from the user's perspective:
>> existing commit messages and internal ticket links within a project would
>> be able to remain consistent.
>>
>>
> ... maybe it's not a good idea considering your comment above . If ticket
> has its own identity (like it happens right now as opposite to project ID +
> ticket ID) references will always be valid (just like it happens right now)
> , no matter what relations it has with other resources (e.g. projects) and
> how they change with time . IMO going for #2 + independent ticket numbering
> may lead to over-complicating a system that just works right now . In any
> case that doesn't mean that visually e.g. project ID (e.g. short_name)
> might be displayed in ticket link text.
That is definitely a good argument and, for the initial work, it might
be worth sticking to that. My reasoning was based on the idea of people
wanting to combine existing environments. Existing references would
become invalid if we were to expect to be able to do this.
While there is no route to import tickets or environments, we can defer
a decision and see what others make of it.
Cheers,
Gary
Configuration (Was: Re: [Trac-dev] Bloodhound / Trac Approach)
Posted by Gary <ga...@wandisco.com>.
On 10/01/12 19:11, Olemis Lang wrote:
> On Tue, Jan 10, 2012 at 2:08 PM, Olemis Lang<ol...@gmail.com> wrote:
>> On Tue, Jan 10, 2012 at 11:06 AM, Olemis Lang<ol...@gmail.com> wrote:
>> [...]
>>> maybe a few fields like creation time , owner , project logo (i.e. project fields used in trac.ini ;) should also be considered for inclusion in there . I like the idea of being able to consider projects just like if they were yet another Trac environment inside an environment . That way e.g. external environment may be merged within another and become a project located at a given level of project hierarchy . All that metadata should be kept and reused in new project living (<= oh ! I really wanted to say that ... life is beautiful :) inside target environment . Another goal might be to have all this implemented causing the least impact over existing plugins , preferably no side-effects .
>>>
>>> This makes me wonder whether it would be appropriate to have :
>>>
>>> - project_config table : basically a mirror of trac.ini inside
>>> database (fields TBD ;)
>> ... or maybe separate project config files in trac.ini ?
> sorry my mistake . I wanted to say :
>
> ... or maybe separate project config files similar to trac.ini in conf folder ?
I think split configuration files might well make sense at some point
but I probably wouldn't go with that straight away. For now, assuming
that we are going to make use of the trac.ini file, I would argue that
we have a reasonable example of how to describe different projects in
the form of the repositories section. Does a "short_name.property =
value" form make sense to others?
If we do go with splitting configs at some point, would it be complete
madness to have some mechanism to include other files so that
administrators can split their configuration files as they wish?
Cheers,
Gary
Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Olemis Lang <ol...@gmail.com>.
On Tue, Jan 10, 2012 at 2:08 PM, Olemis Lang <ol...@gmail.com> wrote:
> On Tue, Jan 10, 2012 at 11:06 AM, Olemis Lang <ol...@gmail.com> wrote:
>>
> [...]
>>
>> maybe a few fields like creation time , owner , project logo (i.e. project fields used in trac.ini ;) should also be considered for inclusion in there . I like the idea of being able to consider projects just like if they were yet another Trac environment inside an environment . That way e.g. external environment may be merged within another and become a project located at a given level of project hierarchy . All that metadata should be kept and reused in new project living (<= oh ! I really wanted to say that ... life is beautiful :) inside target environment . Another goal might be to have all this implemented causing the least impact over existing plugins , preferably no side-effects .
>>
>> This makes me wonder whether it would be appropriate to have :
>>
>> - project_config table : basically a mirror of trac.ini inside
>> database (fields TBD ;)
>
> ... or maybe separate project config files in trac.ini ?
sorry my mistake . I wanted to say :
... or maybe separate project config files similar to trac.ini in conf folder ?
--
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)
Get a signature like this. CLICK HERE.
Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Olemis Lang <ol...@gmail.com>.
On Tue, Jan 10, 2012 at 11:06 AM, Olemis Lang <ol...@gmail.com> wrote:
>
[...]
>
> maybe a few fields like creation time , owner , project logo (i.e. project fields used in trac.ini ;) should also be considered for inclusion in there . I like the idea of being able to consider projects just like if they were yet another Trac environment inside an environment . That way e.g. external environment may be merged within another and become a project located at a given level of project hierarchy . All that metadata should be kept and reused in new project living (<= oh ! I really wanted to say that ... life is beautiful :) inside target environment . Another goal might be to have all this implemented causing the least impact over existing plugins , preferably no side-effects .
>
> This makes me wonder whether it would be appropriate to have :
>
> - project_config table : basically a mirror of trac.ini inside
> database (fields TBD ;)
... or maybe separate project config files in trac.ini ?
--
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)
Get a signature like this. CLICK HERE.
Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Olemis Lang <ol...@gmail.com>.
On Tue, Jan 10, 2012 at 8:13 AM, Gary <ga...@wandisco.com> wrote:
> On 01/09/2012 05:38 PM, Olemis Lang wrote:
>
>>
>> one or more Apache licensed Bloodhound plugins and possibly other
>>> pre-existing plugins from track-hacks.
>>>
>>> the first one of those plugins will be support for multiple projects
>> in a single environment . I've put pieces together and it seems to be
>> possible to build it on top of 0.12-stable without hacking core "too
>> much "<= TBD ;)
>>
> Yes, this is an interesting area and I have been looking at it quite
> carefully. I am not yet certain of how little we can get away with changing
> the schema and behaviour.
me neither , but there's still a chance to «be nice» ;)
> I think we certainly need a project table
+1
> and we might be able to avoid changing existing tables by also providing a
> table that maps resources to their project.
exactly !
Even if I didn't mention this before it seems we are in sync (as that's a
bit straightforward reasoning ;)
In fact I was thinking of considering projects as yet another Trac resource
and therefore try to implement such mapping as similar to TracRelations
spec [1]_ as possible / needed .
> Or we could just add the extra project field to the appropriate tables.
> There is something appealing to me about the latter no-nonsense approach :)
>
>
What'd be the pros & cons of (1 - project to resource mapping table) vs (2
- extra project field) ?
IMO #1 is in sound with the more generic TracRelations proposal (as far as
DB is concerned , project-specific behavior is another $0.02 ;) whereas #2
breaks the more generic resource relations framework @ the DB level .
... question may also be reformulated this way : Considering TracRelations
is out there , what makes projects so special so as to make an exception
with them at the DB-level ?
Either way I was thinking of providing projects with at least the following
> details
>
> * name
> * short_name (unique and fixed)
> * description
>
> where the short_name acts as a label in any referencing between projects.
>
>
+1
... once I submitted project labels proposal [2]_ to trac-dev it was noted
(with strong arguments IMO) that resource history may be important to be
tracked as well . For project labels it makes sense . Maybe we should
consider whether history meta-data might be appropriate for projects & what
events exactly will be tracked during project lifetime .
maybe a few fields like creation time , owner , project logo (i.e. project
fields used in trac.ini ;) should also be considered for inclusion in there
. I like the idea of being able to consider projects just like if they were
yet another Trac environment inside an environment . That way e.g. external
environment may be merged within another and become a project located at a
given level of project hierarchy . All that metadata should be kept and
reused in new project living (<= oh ! I really wanted to say that ... life
is beautiful :) inside target environment . Another goal might be to have
all this implemented causing the least impact over existing plugins ,
preferably no side-effects .
This makes me wonder whether it would be appropriate to have :
- project_config table : basically a mirror of trac.ini inside
database (fields TBD ;)
- trac.config classes implemented on top of database backend
- environment wrapper class so as to include in there
project specific features (e.g. DB-aware config objects) .
This will be necessary so as to make plugins auto-magically
compatible with the new architectural changes . I mean as
far as plugins (request handlers, filters , ...) are concerned
they'll see an environment (i.e. object) looking exactly like
environments used to look like , but with some methods
aware of multi-project context e.g. project-specific config in DB
- Semantics of DB-specific config components should be exactly the
same as if DB config fields were in yet another trac.ini file
inheriting [3]_ from "real" environment trac.ini file (maybe config
inheritance across project hierarchy is also good to have ,
but definitely a bit more difficult to implement)
- Components in Bloodhound (e.g. like TracIniAdmin plugin) to
customize project specific settings stored in the DB
... all this for single project requests . Request involving multiple
projects (e.g. labels [1]_ ) should not consider all this (should they ?
CMIIW)
Maybe project_config proposal is a bit ambitious to include it in the short
term but I'd rather keep it under my pillow at least for review.
Isn't the Trac-ky thingy just lovely ?
I hope we all can make it better ...
:)
Personally I would also like to see independent ticket numbering per
> project but this may be too ambitious.
maybe possible with #2 above but definitely not with #1 ; but even if #2
allows to do so ...
> If we manage this, however, it should simplify the combining of multiple
> existing environments into a single project from the user's perspective:
> existing commit messages and internal ticket links within a project would
> be able to remain consistent.
>
>
... maybe it's not a good idea considering your comment above . If ticket
has its own identity (like it happens right now as opposite to project ID +
ticket ID) references will always be valid (just like it happens right now)
, no matter what relations it has with other resources (e.g. projects) and
how they change with time . IMO going for #2 + independent ticket numbering
may lead to over-complicating a system that just works right now . In any
case that doesn't mean that visually e.g. project ID (e.g. short_name)
might be displayed in ticket link text.
>
> Although we do want to be coming up with something soon, I think it makes
>>> sense to be looking at 0.13.
>>>
>>> [...]
>
>> So, if Bloodhound as a whole is implemented so as to be distributed as
>> a Trac plugin ; it will be easier for users to migrate Trac
>> installations to Bloodhound (just like using any other plugin ;) ; and
>> still it may be distributed as an standalone application package .
>>
> That would of course be possible for Bloodhound plugins that are not
> dependant on a Bloodhound core.
>
>
;)
>
> Yes, I think that we probably want to have an official Bloodhound
>>> repository
>>> for this work and it would be good to be using Bloodhound as our issue
>>> tracker.
>>>
>> +1
>> Just a comment : I was thinking of using both Trac + BH running on top
>> of the same environment so as to ensure both web apps coexist
>> peacefully. This should be possible mainly if Bloodhound is available
>> as yet another plugin running on top of Trac, and DB schema remains
>> compatible with Trac's , ... but that's just a comment and kind of
>> academic experiment instead of a suggestion for the project itself
>> ;)
>>
> That could be interesting. I was about to say that it should be possible
> but, with the changes to the database, I think we will have to deal with
> some interesting issues if I remember correctly.
>
>
If a decision is made to adopt #1 approach (i.e. project to resource
mapping table) mentioned above and keep schema of Trac tables just like it
is nowadays then it would possible to have both a Trac instance and a
Bloodhound instance (with e.g. multi-project support ;) running on top of
the same environment . Ok, some decisions may jeopardize success , but that
only means that Bloodhound is not compatible with Trac at some point .
.. [1] Trac Relations
(http://trac.edgewall.org/wiki/TracDev/Proposals/TracRelations)
.. [2] Project classifiers (aka labels)
(http://trac.edgewall.org/wiki/TracDev/Proposals/ProjectLabels)
.. [3] Global configuration
(http://trac.edgewall.org/wiki/TracIni#GlobalConfiguration)
--
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>
http://feedproxy.google.com/~r/simelo-news/~3/Uu6Ez9Qc5vQ/el-spdy-de-google-no-es-tan-malo-como.html
Get a signature like this.
<http://r1.wisestamp.com/r/landing?promo=17&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_17>
CLICK
HERE.<http://r1.wisestamp.com/r/landing?promo=17&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_17>
Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Gary <ga...@wandisco.com>.
Hi Grzegorz,
On 10/01/12 13:58, Grzegorz Sobanski wrote:
> * Gary<ga...@wandisco.com> [2012-01-10 14:52]:
>> Does anyone have any reason to consider 0.13 particularly unstable?
>> I assume that there is a relative lack of 0.13 user base to judge
>> stability with of course.
> AFAIK 0.12 and 0.13 do not differ much.
> I am running 0.13dev in production for some time, and do not have any
> problems.
>
> greets
>
Thank you very much for letting us know. That is good to know.
More voices regarding this are welcome of course!
Cheers,
Gary
SV: [Trac-dev] Bloodhound / Trac Approach
Posted by Mikael Relbe <mi...@relbe.se>.
Grzegorz Sobanski <si...@boktor.net> 10 jan 2012 14:58 wrote:
> * Gary <ga...@wandisco.com> [2012-01-10 14:52]:
> > Does anyone have any reason to consider 0.13 particularly unstable?
> > I assume that there is a relative lack of 0.13 user base to judge
> > stability with of course.
>
> AFAIK 0.12 and 0.13 do not differ much.
> I am running 0.13dev in production for some time, and do not have any
> problems.
>
Same experience here, using 0.13dev r10691 for a very long time in
production environment without any problems (though it's due for an update).
Note that trac.edgewall.org (t.e.o.) also uses 0.13dev, actual rev is
disclosed at the bottom of the following page (currently 0.13dev-r10723):
http://trac.edgewall.org/milestone/0.13
Extremely stable, I would say.
/Mikael Relbe (mrelbe on t.e.o.)
Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Grzegorz Sobanski <si...@boktor.net>.
* Gary <ga...@wandisco.com> [2012-01-10 14:52]:
> Does anyone have any reason to consider 0.13 particularly unstable?
> I assume that there is a relative lack of 0.13 user base to judge
> stability with of course.
AFAIK 0.12 and 0.13 do not differ much.
I am running 0.13dev in production for some time, and do not have any
problems.
greets
--
silk
Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Gary <ga...@wandisco.com>.
On 01/09/2012 05:38 PM, Olemis Lang wrote:
>
>> one or more Apache licensed Bloodhound plugins and possibly other
>> pre-existing plugins from track-hacks.
>>
> the first one of those plugins will be support for multiple projects
> in a single environment . I've put pieces together and it seems to be
> possible to build it on top of 0.12-stable without hacking core "too
> much "<= TBD ;)
Yes, this is an interesting area and I have been looking at it quite
carefully. I am not yet certain of how little we can get away with
changing the schema and behaviour. I think we certainly need a project
table and we might be able to avoid changing existing tables by also
providing a table that maps resources to their project. Or we could just
add the extra project field to the appropriate tables. There is
something appealing to me about the latter no-nonsense approach :)
Either way I was thinking of providing projects with at least the
following details
* name
* short_name (unique and fixed)
* description
where the short_name acts as a label in any referencing between projects.
Personally I would also like to see independent ticket numbering per
project but this may be too ambitious. If we manage this, however, it
should simplify the combining of multiple existing environments into a
single project from the user's perspective: existing commit messages and
internal ticket links within a project would be able to remain consistent.
>> Although we do want to be coming up with something soon, I think it makes
>> sense to be looking at 0.13. There are two good reasons to do this: if Trac
>> are going to take our code then I would expect them to want it to be
>> developed against trunk; we probably want all the improvements that have
>> gone into the latest code, including the latest changes to the Trac API.
>>
> I agree . I mentioned 0.12 due to the fact that during development
> 0.12 will be stable and everything may be developed on top of it .
> From a product perspective this will "ensure" something stable will be
> ready in a "relatively" short time , and the ground will not move
> underneath ;) . Once 0.12 solution will be ready then it may be
> updated to work with 0.13 (quite probably this will be necessary ...
> afaics some parts will need some update ;)
>
> So, if Bloodhound as a whole is implemented so as to be distributed as
> a Trac plugin ; it will be easier for users to migrate Trac
> installations to Bloodhound (just like using any other plugin ;) ; and
> still it may be distributed as an standalone application package .
That would of course be possible for Bloodhound plugins that are not
dependant on a Bloodhound core.
> If 0.13 is to be considered then development will need (at the same
> time) to focus on developing the functional features + updating
> against trunk . Most of the time what I use to do in these situations
> (CMIIW) is to choose a somehow stable changeset and build features on
> top of it , once finished then catch the rabbit and update to trunk .
That is not unreasonable. Deciding how to distinguish stable revisions
will be interesting of course :).
Does anyone have any reason to consider 0.13 particularly unstable? I
assume that there is a relative lack of 0.13 user base to judge
stability with of course.
> - What should happen with Bloodhound version numbers ?
> - Should they match Trac's ?
> - How will we handle tickets (may be some duplicates @ trac-dev) ?
> Maybe it would nice to have a BH plugin to forward tickets to trac-dev ,
> trac-hacks (for plugins) ...
I have no particularly strong feelings about how version numbers should
match or otherwise.
I think that some kind of duplication of tickets is to be expected but
any effort that goes into bloodhound should be documented on Bloodhound
appropriately. As much as possible I would like to see our tickets
referencing the Trac site properly with InterTrac links to reduce real
duplication.
>> - I have already
>> noted that some existing trac-hacks do not install properly without code
>> changes.
> the same happens for 0.12 . Many plugins are built for 0.11 and some
> of them have not been updated for 0.12 . Sometimes they are not broken
> as 0.12 did not change 0.11 in a totally backwards incompatible manner
There is definitely a potential problem in the 0.12->0.13 change with
database handling when a plugin expects methods on the db object that
have been removed but I only spotted a few cases so far (at least one of
which may have been fixed already).
>> Yes, I think that we probably want to have an official Bloodhound repository
>> for this work and it would be good to be using Bloodhound as our issue
>> tracker.
> +1
> Just a comment : I was thinking of using both Trac + BH running on top
> of the same environment so as to ensure both web apps coexist
> peacefully. This should be possible mainly if Bloodhound is available
> as yet another plugin running on top of Trac, and DB schema remains
> compatible with Trac's , ... but that's just a comment and kind of
> academic experiment instead of a suggestion for the project itself
> ;)
That could be interesting. I was about to say that it should be possible
but, with the changes to the database, I think we will have to deal with
some interesting issues if I remember correctly.
Cheers,
Gary
RE: [Trac-dev] Bloodhound / Trac Approach
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: Tuesday, 10 January 2012 4:13 AM
> To: bloodhound-dev@incubator.apache.org
> Subject: Re: [Trac-dev] Bloodhound / Trac Approach
>
> On Mon, Jan 9, 2012 at 12:44, Olemis Lang <ol...@gmail.com> wrote:
> > On Mon, Jan 9, 2012 at 12:38 PM, Olemis Lang <ol...@gmail.com> wrote:
> >> On Sat, Jan 7, 2012 at 7:30 PM, Gary <ga...@wandisco.com> wrote:
> >>> On 06/01/12 22:11, Hyrum K Wright wrote:
> > [...]
> >>
> >> Another important subject to discuss should be CI setup . My proposal
> >> initially is to have
> >>
> >> - Bitbucket mirror of Trac repos
> >> - Bitbucket patch queues (to work on tickets)
> >> - Bitbucket central patch queue archive (incorporating changes to
> >> accepted patches)
> >> - Jenkins CI @ testrun.org . In there I created once upon a time a
> >> build job for
> >> Trac XmlRpcPlugin so as to run tests on its Bitbucket patch queue .
> >> - ...
> >>
> >
> > but if course that's TBD . other alternatives like central SVN
> > repository , ... can work together with this one way or another .
> > ;)
>
> The ASF has a fully-supported set of Jenkins and Buildbot servers. I would
> recommend using those rather than external servers, due to their better
> support level. In fact, I suspect that Bloodhound will get even
> *better* support since Gavin signed on to help with BH (he is the Infra
> person who manages the build servers).
Sorry that I will be slightly late, due to a personal matter it will be
about 2 weeks
or so before I can join you all, rest assured I will catch up.
Gav...
>
> Cheers,
> -g
Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Olemis Lang <ol...@gmail.com>.
On Mon, Jan 9, 2012 at 1:13 PM, Greg Stein <gs...@gmail.com> wrote:
> On Mon, Jan 9, 2012 at 12:44, Olemis Lang <ol...@gmail.com> wrote:
> > On Mon, Jan 9, 2012 at 12:38 PM, Olemis Lang <ol...@gmail.com> wrote:
> >> On Sat, Jan 7, 2012 at 7:30 PM, Gary <ga...@wandisco.com> wrote:
> >>> On 06/01/12 22:11, Hyrum K Wright wrote:
> > [...]
> >>
> >> Another important subject to discuss should be CI setup . My proposal
> >> initially is to have
> >>
> >> - Bitbucket mirror of Trac repos
> >> - Bitbucket patch queues (to work on tickets)
> >> - Bitbucket central patch queue archive (incorporating changes to
> >> accepted patches)
> >> - Jenkins CI @ testrun.org . In there I created once upon a time a
> >> build job for
> >> Trac XmlRpcPlugin so as to run tests on its Bitbucket patch queue .
> >> - ...
> >>
> >
> > but if course that's TBD . other alternatives like central SVN
> > repository , ... can work together with this one way or another .
> > ;)
>
> The ASF has a fully-supported set of Jenkins and Buildbot servers. I
> would recommend using those rather than external servers, due to their
> better support level. In fact, I suspect that Bloodhound will get even
> *better* support since Gavin signed on to help with BH (he is the
> Infra person who manages the build servers).
>
much better then !
:)
I just didn't know .
:$
--
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.
Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Jan 9, 2012 at 12:44, Olemis Lang <ol...@gmail.com> wrote:
> On Mon, Jan 9, 2012 at 12:38 PM, Olemis Lang <ol...@gmail.com> wrote:
>> On Sat, Jan 7, 2012 at 7:30 PM, Gary <ga...@wandisco.com> wrote:
>>> On 06/01/12 22:11, Hyrum K Wright wrote:
> [...]
>>
>> Another important subject to discuss should be CI setup . My proposal
>> initially is to have
>>
>> - Bitbucket mirror of Trac repos
>> - Bitbucket patch queues (to work on tickets)
>> - Bitbucket central patch queue archive (incorporating changes to
>> accepted patches)
>> - Jenkins CI @ testrun.org . In there I created once upon a time a
>> build job for
>> Trac XmlRpcPlugin so as to run tests on its Bitbucket patch queue .
>> - ...
>>
>
> but if course that's TBD . other alternatives like central SVN
> repository , ... can work together with this one way or another .
> ;)
The ASF has a fully-supported set of Jenkins and Buildbot servers. I
would recommend using those rather than external servers, due to their
better support level. In fact, I suspect that Bloodhound will get even
*better* support since Gavin signed on to help with BH (he is the
Infra person who manages the build servers).
Cheers,
-g
Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Olemis Lang <ol...@gmail.com>.
On Mon, Jan 9, 2012 at 12:38 PM, Olemis Lang <ol...@gmail.com> wrote:
> On Sat, Jan 7, 2012 at 7:30 PM, Gary <ga...@wandisco.com> wrote:
>> On 06/01/12 22:11, Hyrum K Wright wrote:
[...]
>
> Another important subject to discuss should be CI setup . My proposal
> initially is to have
>
> - Bitbucket mirror of Trac repos
> - Bitbucket patch queues (to work on tickets)
> - Bitbucket central patch queue archive (incorporating changes to
> accepted patches)
> - Jenkins CI @ testrun.org . In there I created once upon a time a
> build job for
> Trac XmlRpcPlugin so as to run tests on its Bitbucket patch queue .
> - ...
>
but if course that's TBD . other alternatives like central SVN
repository , ... can work together with this one way or another .
;)
--
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.
Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Olemis Lang <ol...@gmail.com>.
On Sat, Jan 7, 2012 at 7:30 PM, Gary <ga...@wandisco.com> wrote:
> On 06/01/12 22:11, Hyrum K Wright wrote:
>>
[...]
>>
>> I'll let folks with more technical knowledge than myself chime in
>> here, but I'm interested to see what progresses.
>>
>> -Hyrum
>
> Well, I had best get some of my ideas noted down then :)
>
... and I'll follow
> Just to be clear, I would like to ensure that changes to core Bloodhound are
> minimised so as to keep close compatibility with Trac. Clearly there is an
> advantage to the plugin developer community if they can expect their plugins
> to work on both systems with little or no changes. It will also mean that
> any improvements made to plugins for use in Bloodhound should automatically
> benefit Trac.
>
and improvements made to plugins for use in Trac should automatically
benefit Bloodhound ... ;)
that's a nice strategic decision afaics .
> Apache Bloodhound as a whole would therefore be the sum of the Bloodhound
> branch/fork of the Trac code (and so I expect this part to be under a BSD
> license),
+1 ... time will tell what goes where , btw .
> one or more Apache licensed Bloodhound plugins and possibly other
> pre-existing plugins from track-hacks.
>
the first one of those plugins will be support for multiple projects
in a single environment . I've put pieces together and it seems to be
possible to build it on top of 0.12-stable without hacking core "too
much " <= TBD ;)
> On 06/01/12 16:32, Olemis Lang wrote:
>>
>> 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 .
>> ;)
>
> Although we do want to be coming up with something soon, I think it makes
> sense to be looking at 0.13. There are two good reasons to do this: if Trac
> are going to take our code then I would expect them to want it to be
> developed against trunk; we probably want all the improvements that have
> gone into the latest code, including the latest changes to the Trac API.
>
I agree . I mentioned 0.12 due to the fact that during development
0.12 will be stable and everything may be developed on top of it .
>From a product perspective this will "ensure" something stable will be
ready in a "relatively" short time , and the ground will not move
underneath ;) . Once 0.12 solution will be ready then it may be
updated to work with 0.13 (quite probably this will be necessary ...
afaics some parts will need some update ;)
So, if Bloodhound as a whole is implemented so as to be distributed as
a Trac plugin ; it will be easier for users to migrate Trac
installations to Bloodhound (just like using any other plugin ;) ; and
still it may be distributed as an standalone application package .
If 0.13 is to be considered then development will need (at the same
time) to focus on developing the functional features + updating
against trunk . Most of the time what I use to do in these situations
(CMIIW) is to choose a somehow stable changeset and build features on
top of it , once finished then catch the rabbit and update to trunk .
Nonetheless both approaches are ok , afaics .
BTW , when will 0.13 be released ? I should check trac-dev schedule ;)
=======
Before I forget , I mention now something else for us to discuss :
- What should happen with Bloodhound version numbers ?
- Should they match Trac's ?
- How will we handle tickets (may be some duplicates @ trac-dev) ?
Maybe it would nice to have a BH plugin to forward tickets to trac-dev ,
trac-hacks (for plugins) ...
> Obviously there are some implications for plugins there
yes
> - I have already
> noted that some existing trac-hacks do not install properly without code
> changes.
the same happens for 0.12 . Many plugins are built for 0.11 and some
of them have not been updated for 0.12 . Sometimes they are not broken
as 0.12 did not change 0.11 in a totally backwards incompatible manner
.
> With luck plugin authors will either be interested in updating
> their work for the latest Trac or perhaps they might welcome a patch from
> us.
>
;)
>
> On 06/01/12 16:32, Olemis Lang also wrote:
>>
>> 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 ... ;)
>
>
> Yes, I think that we probably want to have an official Bloodhound repository
> for this work and it would be good to be using Bloodhound as our issue
> tracker.
+1
Just a comment : I was thinking of using both Trac + BH running on top
of the same environment so as to ensure both web apps coexist
peacefully. This should be possible mainly if Bloodhound is available
as yet another plugin running on top of Trac, and DB schema remains
compatible with Trac's , ... but that's just a comment and kind of
academic experiment instead of a suggestion for the project itself
;)
> Do we want this to be an svn repository?
0-
> Have we got enough voices
> in favour of the hg patch queue to attempt that on bitbucket or has anyone
jftr , considering the fact that Bitbucket is not required so as to
use MQ there's always a chance to create the Hg repository (if any) in
project's servers, and manage everything directly . However Bitbucket
makes everything simple, provides support, simplifies CI setup
(triggers) , socializes the coding experience , and ... things like
that
;)
Another important subject to discuss should be CI setup . My proposal
initially is to have
- Bitbucket mirror of Trac repos
- Bitbucket patch queues (to work on tickets)
- Bitbucket central patch queue archive (incorporating changes to
accepted patches)
- Jenkins CI @ testrun.org . In there I created once upon a time a
build job for
Trac XmlRpcPlugin so as to run tests on its Bitbucket patch queue .
- ...
--
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.
Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Gary <ga...@wandisco.com>.
On 06/01/12 22:11, Hyrum K Wright wrote:
> 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
Well, I had best get some of my ideas noted down then :)
Just to be clear, I would like to ensure that changes to core Bloodhound
are minimised so as to keep close compatibility with Trac. Clearly there
is an advantage to the plugin developer community if they can expect
their plugins to work on both systems with little or no changes. It will
also mean that any improvements made to plugins for use in Bloodhound
should automatically benefit Trac.
Apache Bloodhound as a whole would therefore be the sum of the
Bloodhound branch/fork of the Trac code (and so I expect this part to be
under a BSD license), one or more Apache licensed Bloodhound plugins and
possibly other pre-existing plugins from track-hacks.
On 06/01/12 16:32, Olemis Lang wrote:
> 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 .
> ;)
Although we do want to be coming up with something soon, I think it
makes sense to be looking at 0.13. There are two good reasons to do
this: if Trac are going to take our code then I would expect them to
want it to be developed against trunk; we probably want all the
improvements that have gone into the latest code, including the latest
changes to the Trac API.
Obviously there are some implications for plugins there - I have already
noted that some existing trac-hacks do not install properly without code
changes. With luck plugin authors will either be interested in updating
their work for the latest Trac or perhaps they might welcome a patch
from us.
On 06/01/12 16:32, Olemis Lang also wrote:
> 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 ... ;)
Yes, I think that we probably want to have an official Bloodhound
repository for this work and it would be good to be using Bloodhound as
our issue tracker. Do we want this to be an svn repository? Have we got
enough voices in favour of the hg patch queue to attempt that on
bitbucket or has anyone got any opposing views?
Cheers,
Gary
--
Best wishes,
Gary Martin
Lead Developer
WANdisco, Inc.
http://www.wandisco.com
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Everything you need to deploy Subversion in the Enterprise
http://www.wandisco.com/subversion
Subversion community
http://www.svnforum.org
Read our blogs
http://blogs.wandisco.com/
Follow us on Twitter
http://www.twitter.com/wandisco
Re: Re: [Trac-dev] Bloodhound / Trac Approach
Posted by Hyrum K Wright <hy...@wandisco.com>.
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 <ga...@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<ch...@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/