You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Ryan Ollos <ry...@wandisco.com> on 2014/01/15 03:26:16 UTC
Developing against Trac 1.0-stable
I would like to propose, that following Release 8 of Bloodhound, we start
developing against Trac 1.0-stable rather than waiting for minor releases
of Trac before upgrading (e.g. Trac 1.0.2). I propose that we frequently
merge changes from Trac 1.0-stable to our copy of Trac.
To give provide some immediate justification for why this would be
beneficial, consider the changes on-going in #695 [1]. In #695 it has been
proposed to port at least 3 changes to Trac, and those changes are being
integrated into Trac in #11440 [2]. The current situation is, in order to
close #695 for Release 8 we will end up patching our copy of Trac, and then
we must roll-back those changes (or resolve merge conflicts) when Trac
1.0.2 is merged into . At that point, we need to do additional testing, and
it will likely be some time since the changes have been implemented in
Bloodhound so the changes won't be as fresh in our minds. All of this leads
to a more time-consuming and error-prone situation.
If we move to developing from 1.0-stable, we can push changes to Trac and
immediately merge them back into Bloodhound.
A few concerns may come to mind, such as how stable is Trac 1.0-stable? In
my experience, it is very stable. The Trac developers stage proposed
changes for code-review rather than immediately pushing the changes, which
leads to fewer defects on the stable branches. I can only think of a few
situations in which a regression was introduced, and in almost all of those
cases the issue was caught and fixed within a few days.
Another concern could be that the major releases of Bloodhound should be
based on an official release of Trac. It has previously been proposed that
Trac would aim for a shorter release cycle, and I raised this again
recently, with the suggestion that we aim for a 3 month release cycle [3].
A shorter release cycle for Trac will allow us, with some planning, to
align the Bloodhound releases with those of Trac. The more frequent release
cycle may be possible once a few of the newer Trac developers are brought
up to speed on how to do the release management.
In a previous email [4], I mentioned that I planned to do work in Release 9
or Release 10 to integrate changes from Trac 1.0.2. In addition to merging
in the Trac codebase, changes to the Trac templates and CSS that we wish to
mirror in Bloodhound usually require manual edits to the BloodhoundTheme
templates. Trac 1.0.2 has turned out to be a fairly big milestone in terms
of number of fixes and minor enhancements. The number of tickets closed
will be 147 [4] by the end of the week, and since there isn't yet a
definite date for the release, it could grow larger.
I've been creating tickets in Bloodhound for changes that will be needed to
keep pace with Trac. For the Trac 1.0.2 release, the tickets are tagged
with trac-1.0.2 [6], and there is a "master ticket" [7]. This is a lot of
changes, and it will take weeks to integrate them all. As mentioned, it
would have been faster to make these changes in Bloodhound concurrent with
the changes that I made to Trac. Therefore I think it will be more
efficient in the future to have a shorter integration cycle.
Please let me know if you have any thoughts or concerns.
[1] http://issues.apache.org/bloodhound/ticket/695
[2] http://trac.edgewall.org/ticket/11440
[3] https://groups.google.com/d/msg/trac-dev/l5YuG7DysOE/sAEQeSufJYMJ
[4] http://markmail.org/message/j7juyper6vhocq64
[5]
http://trac.edgewall.org/query?milestone=1.0.2&milestone=0.12.6&group=status&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority
[6]
https://issues.apache.org/bloodhound/query?status=accepted&status=assigned&status=closed&status=needinfo&status=needinfo(new)&status=needinfo(review)&status=new&status=review&keywords=~trac-1.0.2&desc=1&order=status
[7] https://issues.apache.org/bloodhound/ticket/660
Re: Developing against Trac 1.0-stable
Posted by Ryan Ollos <ry...@wandisco.com>.
On Wed, Jan 15, 2014 at 8:49 AM, Ryan Ollos <ry...@wandisco.com> wrote:
> On Wed, Jan 15, 2014 at 7:26 AM, Ryan Ollos <ry...@wandisco.com>wrote:
>
>> On Tue, Jan 14, 2014 at 8:48 PM, Olemis Lang <ol...@gmail.com> wrote:
>>
>>> On 1/14/14, Ryan Ollos <ry...@wandisco.com> wrote:
>>> > I would like to propose, that following Release 8 of Bloodhound, we
>>> start
>>> > developing against Trac 1.0-stable rather than waiting for minor
>>> releases
>>> > of Trac before upgrading (e.g. Trac 1.0.2). I propose that we
>>> frequently
>>> > merge changes from Trac 1.0-stable to our copy of Trac.
>>> >
>>>
>>> 1.0-stable is a branch name , isn't it ? or is it a fixed changeset e.g.
>>> tag ?
>>>
>>> > To give provide some immediate justification for why this would be
>>> > beneficial, consider the changes on-going in #695 [1]. In #695 it has
>>> been
>>> > proposed to port at least 3 changes to Trac, and those changes are
>>> being
>>> > integrated into Trac in #11440 [2]. The current situation is, in order
>>> to
>>> > close #695 for Release 8 we will end up patching our copy of Trac, and
>>> then
>>> > we must roll-back those changes (or resolve merge conflicts) when Trac
>>> > 1.0.2 is merged into . At that point, we need to do additional
>>> testing, and
>>> > it will likely be some time since the changes have been implemented in
>>> > Bloodhound so the changes won't be as fresh in our minds. All of this
>>> leads
>>> > to a more time-consuming and error-prone situation.
>>> >
>>>
>>> I see your point ...
>>>
>>> [...]
>>> >
>>> > Another concern could be that the major releases of Bloodhound should
>>> be
>>> > based on an official release of Trac. It has previously been proposed
>>> that
>>> > Trac would aim for a shorter release cycle, and I raised this again
>>> > recently, with the suggestion that we aim for a 3 month release cycle
>>> [3].
>>>
>>> +1
>>>
>>> > A shorter release cycle for Trac will allow us, with some planning, to
>>> > align the Bloodhound releases with those of Trac.
>>>
>>> that would be awesome !
>>> :)
>>>
>>> > The more frequent release
>>> > cycle may be possible once a few of the newer Trac developers are
>>> brought
>>> > up to speed on how to do the release management.
>>> >
>>>
>>> I'd definitely like to join the trac-dev team , if possible, to help
>>> you with doing so ... but I guess this is not in your hands .
>>>
>>> > In a previous email [4], I mentioned that I planned to do work in
>>> Release 9
>>> > or Release 10 to integrate changes from Trac 1.0.2. In addition to
>>> merging
>>> > in the Trac codebase, changes to the Trac templates and CSS that we
>>> wish to
>>> > mirror in Bloodhound usually require manual edits to the
>>> BloodhoundTheme
>>> > templates. Trac 1.0.2 has turned out to be a fairly big milestone in
>>> terms
>>> > of number of fixes and minor enhancements. The number of tickets closed
>>> > will be 147 [4] by the end of the week, and since there isn't yet a
>>> > definite date for the release, it could grow larger.
>>> >
>>>
>>> overall that's good news
>>>
>>> [...]
>>
>>
>>
>> Yes, 1.0-stable is a branch name. Revisions from this branch are tagged
>> as the releases are made: 1.0.1, 1.0.2, ....
>>
>
>
> One additional link for reference - here is the most recent discussion
> that I'm aware of on the release cycle for Trac, suggesting 3 month cycle
> for minor releases:
> https://groups.google.com/d/msg/trac-dev/17DO_N1MM-A/uu8Z1brd4LMJ
>
I dropped 1.0-stable at r12502 to
https://svn.apache.org/repos/asf/bloodhound/vendor/trac/1.0-stable
I propose to periodically drop the latest from trac 1.0-stable on this
branch and then merge to bloodhound trunk.
Re: Developing against Trac 1.0-stable
Posted by Ryan Ollos <ry...@wandisco.com>.
On Wed, Jan 15, 2014 at 7:26 AM, Ryan Ollos <ry...@wandisco.com> wrote:
> On Tue, Jan 14, 2014 at 8:48 PM, Olemis Lang <ol...@gmail.com> wrote:
>
>> On 1/14/14, Ryan Ollos <ry...@wandisco.com> wrote:
>> > I would like to propose, that following Release 8 of Bloodhound, we
>> start
>> > developing against Trac 1.0-stable rather than waiting for minor
>> releases
>> > of Trac before upgrading (e.g. Trac 1.0.2). I propose that we frequently
>> > merge changes from Trac 1.0-stable to our copy of Trac.
>> >
>>
>> 1.0-stable is a branch name , isn't it ? or is it a fixed changeset e.g.
>> tag ?
>>
>> > To give provide some immediate justification for why this would be
>> > beneficial, consider the changes on-going in #695 [1]. In #695 it has
>> been
>> > proposed to port at least 3 changes to Trac, and those changes are being
>> > integrated into Trac in #11440 [2]. The current situation is, in order
>> to
>> > close #695 for Release 8 we will end up patching our copy of Trac, and
>> then
>> > we must roll-back those changes (or resolve merge conflicts) when Trac
>> > 1.0.2 is merged into . At that point, we need to do additional testing,
>> and
>> > it will likely be some time since the changes have been implemented in
>> > Bloodhound so the changes won't be as fresh in our minds. All of this
>> leads
>> > to a more time-consuming and error-prone situation.
>> >
>>
>> I see your point ...
>>
>> [...]
>> >
>> > Another concern could be that the major releases of Bloodhound should be
>> > based on an official release of Trac. It has previously been proposed
>> that
>> > Trac would aim for a shorter release cycle, and I raised this again
>> > recently, with the suggestion that we aim for a 3 month release cycle
>> [3].
>>
>> +1
>>
>> > A shorter release cycle for Trac will allow us, with some planning, to
>> > align the Bloodhound releases with those of Trac.
>>
>> that would be awesome !
>> :)
>>
>> > The more frequent release
>> > cycle may be possible once a few of the newer Trac developers are
>> brought
>> > up to speed on how to do the release management.
>> >
>>
>> I'd definitely like to join the trac-dev team , if possible, to help
>> you with doing so ... but I guess this is not in your hands .
>>
>> > In a previous email [4], I mentioned that I planned to do work in
>> Release 9
>> > or Release 10 to integrate changes from Trac 1.0.2. In addition to
>> merging
>> > in the Trac codebase, changes to the Trac templates and CSS that we
>> wish to
>> > mirror in Bloodhound usually require manual edits to the BloodhoundTheme
>> > templates. Trac 1.0.2 has turned out to be a fairly big milestone in
>> terms
>> > of number of fixes and minor enhancements. The number of tickets closed
>> > will be 147 [4] by the end of the week, and since there isn't yet a
>> > definite date for the release, it could grow larger.
>> >
>>
>> overall that's good news
>>
>> [...]
>
>
>
> Yes, 1.0-stable is a branch name. Revisions from this branch are tagged as
> the releases are made: 1.0.1, 1.0.2, ....
>
One additional link for reference - here is the most recent discussion that
I'm aware of on the release cycle for Trac, suggesting 3 month cycle for
minor releases:
https://groups.google.com/d/msg/trac-dev/17DO_N1MM-A/uu8Z1brd4LMJ
Re: Developing against Trac 1.0-stable
Posted by Ryan Ollos <ry...@wandisco.com>.
On Tue, Jan 14, 2014 at 8:48 PM, Olemis Lang <ol...@gmail.com> wrote:
> On 1/14/14, Ryan Ollos <ry...@wandisco.com> wrote:
> > I would like to propose, that following Release 8 of Bloodhound, we start
> > developing against Trac 1.0-stable rather than waiting for minor releases
> > of Trac before upgrading (e.g. Trac 1.0.2). I propose that we frequently
> > merge changes from Trac 1.0-stable to our copy of Trac.
> >
>
> 1.0-stable is a branch name , isn't it ? or is it a fixed changeset e.g.
> tag ?
>
> > To give provide some immediate justification for why this would be
> > beneficial, consider the changes on-going in #695 [1]. In #695 it has
> been
> > proposed to port at least 3 changes to Trac, and those changes are being
> > integrated into Trac in #11440 [2]. The current situation is, in order to
> > close #695 for Release 8 we will end up patching our copy of Trac, and
> then
> > we must roll-back those changes (or resolve merge conflicts) when Trac
> > 1.0.2 is merged into . At that point, we need to do additional testing,
> and
> > it will likely be some time since the changes have been implemented in
> > Bloodhound so the changes won't be as fresh in our minds. All of this
> leads
> > to a more time-consuming and error-prone situation.
> >
>
> I see your point ...
>
> [...]
> >
> > Another concern could be that the major releases of Bloodhound should be
> > based on an official release of Trac. It has previously been proposed
> that
> > Trac would aim for a shorter release cycle, and I raised this again
> > recently, with the suggestion that we aim for a 3 month release cycle
> [3].
>
> +1
>
> > A shorter release cycle for Trac will allow us, with some planning, to
> > align the Bloodhound releases with those of Trac.
>
> that would be awesome !
> :)
>
> > The more frequent release
> > cycle may be possible once a few of the newer Trac developers are
> brought
> > up to speed on how to do the release management.
> >
>
> I'd definitely like to join the trac-dev team , if possible, to help
> you with doing so ... but I guess this is not in your hands .
>
> > In a previous email [4], I mentioned that I planned to do work in
> Release 9
> > or Release 10 to integrate changes from Trac 1.0.2. In addition to
> merging
> > in the Trac codebase, changes to the Trac templates and CSS that we wish
> to
> > mirror in Bloodhound usually require manual edits to the BloodhoundTheme
> > templates. Trac 1.0.2 has turned out to be a fairly big milestone in
> terms
> > of number of fixes and minor enhancements. The number of tickets closed
> > will be 147 [4] by the end of the week, and since there isn't yet a
> > definite date for the release, it could grow larger.
> >
>
> overall that's good news
>
> [...]
Yes, 1.0-stable is a branch name. Revisions from this branch are tagged as
the releases are made: 1.0.1, 1.0.2, ....
Re: Developing against Trac 1.0-stable
Posted by Olemis Lang <ol...@gmail.com>.
On 1/14/14, Ryan Ollos <ry...@wandisco.com> wrote:
> I would like to propose, that following Release 8 of Bloodhound, we start
> developing against Trac 1.0-stable rather than waiting for minor releases
> of Trac before upgrading (e.g. Trac 1.0.2). I propose that we frequently
> merge changes from Trac 1.0-stable to our copy of Trac.
>
1.0-stable is a branch name , isn't it ? or is it a fixed changeset e.g. tag ?
> To give provide some immediate justification for why this would be
> beneficial, consider the changes on-going in #695 [1]. In #695 it has been
> proposed to port at least 3 changes to Trac, and those changes are being
> integrated into Trac in #11440 [2]. The current situation is, in order to
> close #695 for Release 8 we will end up patching our copy of Trac, and then
> we must roll-back those changes (or resolve merge conflicts) when Trac
> 1.0.2 is merged into . At that point, we need to do additional testing, and
> it will likely be some time since the changes have been implemented in
> Bloodhound so the changes won't be as fresh in our minds. All of this leads
> to a more time-consuming and error-prone situation.
>
I see your point ...
[...]
>
> Another concern could be that the major releases of Bloodhound should be
> based on an official release of Trac. It has previously been proposed that
> Trac would aim for a shorter release cycle, and I raised this again
> recently, with the suggestion that we aim for a 3 month release cycle [3].
+1
> A shorter release cycle for Trac will allow us, with some planning, to
> align the Bloodhound releases with those of Trac.
that would be awesome !
:)
> The more frequent release
> cycle may be possible once a few of the newer Trac developers are brought
> up to speed on how to do the release management.
>
I'd definitely like to join the trac-dev team , if possible, to help
you with doing so ... but I guess this is not in your hands .
> In a previous email [4], I mentioned that I planned to do work in Release 9
> or Release 10 to integrate changes from Trac 1.0.2. In addition to merging
> in the Trac codebase, changes to the Trac templates and CSS that we wish to
> mirror in Bloodhound usually require manual edits to the BloodhoundTheme
> templates. Trac 1.0.2 has turned out to be a fairly big milestone in terms
> of number of fixes and minor enhancements. The number of tickets closed
> will be 147 [4] by the end of the week, and since there isn't yet a
> definite date for the release, it could grow larger.
>
overall that's good news
[...]
--
Regards,
Olemis - @olemislc