CONTRIBUTION - Would like to do some work on the Genshi Migration
Ilias Lazaridis
some work in the ongoing Clearsilver to Genshi migration.
My intrest is to migrate some of the templates, getting this way an
insight to Genshi.
Is there any documentation specific to this?
How could I proceed?
Noah Kantrowitz
system we are moving to in 0.11 is called Markup
(markup.edgewall.org). From what I understand, most of the render
system has been reworked to allow for using both clearsilver and
markup, and they are porting most of the templates right now.
--Noah
Ilias Lazaridis
> I am not sure what you mean by "Genshi", but the new templating
> system we are moving to in 0.11 is called Markup
> (markup.edgewall.org). From what I understand, most of the render
> system has been reworked to allow for using both clearsilver and
> markup, and they are porting most of the templates right now.
Genshi!
(for product-identity reasons, it's better to just forget the other
word. thus i've not mentioned it)
Christopher Lenz
> I am not sure what you mean by "Genshi", but the new templating
> system we are moving to in 0.11 is called Markup
> (markup.edgewall.org).
Nah, it's been renamed just yesterday :-)
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Christian Boos
> In order to come a little closer in touch with trac, I would like to do
> some work in the ongoing Clearsilver to Genshi migration.
>
> My intrest is to migrate some of the templates, getting this way an
> insight to Genshi.
>
> Is there any documentation specific to this?
>
I initially thought it was a bit early to write a TracDev/ApiChanges/0.11,
but when I started to write the mail, the lack of wiki formatting was
annoying...
So there it goes ;)
-- Christian
Christian Boos
Ok, the first version of the "porting away guide" is done:
http://trac.edgewall.org/wiki/TracDev/ApiChanges/0.11
Enjoy ;)
-- Christian
Ilias Lazaridis
I have one question to the Genshi migration.
Must the "merge" be done in one chunk, or can the subsystems (wiki,
timeline etc.) be merged one after the other?
I mean if the 2 template-systems could exist in paralell for some time,
then it would be easier to start with merging the simpler subsystems
into the 0.11 (or even 0.10.1, to reduces parallel development)
Again - just thoughts!
.
Noah Kantrowitz
migration of plugins.
--Noah
Ilias Lazaridis
Noah Kantrowitz wrote:
> Ilias Lazaridis wrote:
> > Christian Boos wrote:
> >> Ok, the first version of the "porting away guide" is done:
> >> http://trac.edgewall.org/wiki/TracDev/ApiChanges/0.11
> >>
> >> Enjoy ;)
> >
> > I have one question to the Genshi migration.
> >
> > Must the "merge" be done in one chunk, or can the subsystems (wiki,
> > timeline etc.) be merged one after the other?
> >
> > I mean if the 2 template-systems could exist in paralell for some time,
> > then it would be easier to start with merging the simpler subsystems
> > into the 0.11 (or even 0.10.1, to reduces parallel development)
> >
> > Again - just thoughts!
>
> migration of plugins.
"The current setup" referes to 0.10.1 or 0.11 ?
Christian Boos
None of the above. It refers to the sandbox/genshi branch, which will
become 0.11 at some unspecified point in the future ;)
Note also that since a few revs, you can install Trac from that branch
without having to have Clearsilver installed.
-- Christian
Ilias Lazaridis
ok, very nice.
I am highly interested that genshi finds his way soon into the 0.10
stream (possibly 0.10.1 or 0.10.2).
would it be possible, to refactor (or decouple) the genshi-core
(without modified templates of trac) in a way, that they could be added
in a simple manner to 0.10.1 (enabling this way a step-by-step
migration of the templates)?
I thinks this could simplify the further development work and avoid
redundant efforts on the 0.11 stream.
I could provide the necessary analytical / abstraction work for doing
this.
.
Christopher Lenz
> I am highly interested that genshi finds his way soon into the 0.10
> stream (possibly 0.10.1 or 0.10.2).
>
> would it be possible, to refactor (or decouple) the genshi-core
> (without modified templates of trac) in a way, that they could be
> added
> in a simple manner to 0.10.1 (enabling this way a step-by-step
> migration of the templates)?
The Genshi migration will not be backported to 0.10.x. Genshi will
only be available in versions of Trac >= 0.11.
Once 0.11 is available (even in unreleased form), and the Genshi
branch has been merged, plugins can start using Genshi, but they will
not work in Trac 0.9 or 0.10. Plugins still using ClearSilver will
continue to work as long as ClearSilver is installed.
Backporting the changes required for Genshi would (IMHO) be too much
work, and we can really find better uses of developer time.
Ilias Lazaridis
...like developing in paralell for 0.10 and 0.11 ?
If I understand your releases right, 0.10.X will be for long time (6 to
12 months) the official "latest stable release".
If I develope plugins, I need to develop them twice (0.10, then porting
to 0.11). Most possibly, developers will develope with CS, to run under
both, 0.10 and 0.11 (which will delay the "total" Genshi migration).
So, wouldn't it be better to integrate the Genshi modifications in an
non-intrusive way into 0.10, thus developers migrate immediately to
Genshi? 0.11 would then be able to _remove_ clearsilver dependency (as
everything relevant will have been ported until then).
So, ideally, the "Genshi Enabling Additions" should find their way soon
into 0.10.x - I think everyone will agree here.
As to the effort:
[REQUOTE]
I could provide the necessary analytical / abstraction work for doing
this.
[?REQUOTE]
But of course I will depend on some input from the domain experts.
.
Jeroen Ruigrok/asmodai
>If I develope plugins, I need to develop them twice (0.10, then porting
>to 0.11). Most possibly, developers will develope with CS, to run under
>both, 0.10 and 0.11 (which will delay the "total" Genshi migration).
>
>So, wouldn't it be better to integrate the Genshi modifications in an
>non-intrusive way into 0.10, thus developers migrate immediately to
>Genshi? 0.11 would then be able to _remove_ clearsilver dependency (as
>everything relevant will have been ported until then).
>
>So, ideally, the "Genshi Enabling Additions" should find their way soon
>into 0.10.x - I think everyone will agree here.
No, people have disagreed with that idea.
Christopher also pointed out that while 0.11 will focus on Genshi, if you
still have Clearsilver installed you can still use Clearsilver plugins.
So they are already following a nice deprecation route, keeping functionality
in 0.11 for CS, adding in Genshi, and in a subsequent release start taking CS
out.
Your way of deprecation c.q. ripping out CS from 0.11 already and introducing
Genshi into a running 0.10.x branch quite frankly appals from me a design
perspective.
>As to the effort:
>
>[REQUOTE]
>I could provide the necessary analytical / abstraction work for doing
>this.
>[?REQUOTE]
I think they are not interested in anything commercial, which is what you seem
to be hinting at.
And when it comes to abstraction and analysis work I've become quite impressed
by the main Trac developers and various contributors.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/
Yet each man kills the thing he loves...
Ilias Lazaridis
> -On [20060922 20:26], Ilias Lazaridis (il...@lazaridis.com) wrote:
> >If I develope plugins, I need to develop them twice (0.10, then porting
> >to 0.11). Most possibly, developers will develope with CS, to run under
> >both, 0.10 and 0.11 (which will delay the "total" Genshi migration).
> >
> >So, wouldn't it be better to integrate the Genshi modifications in an
> >non-intrusive way into 0.10, thus developers migrate immediately to
> >Genshi? 0.11 would then be able to _remove_ clearsilver dependency (as
> >everything relevant will have been ported until then).
> >
> >So, ideally, the "Genshi Enabling Additions" should find their way soon
> >into 0.10.x - I think everyone will agree here.
>
> No, people have disagreed with that idea.
There is nothing to disagree.
The idea is correct - another thing is the workload.
> Christopher also pointed out that while 0.11 will focus on Genshi, if you
> still have Clearsilver installed you can still use Clearsilver plugins.
As said, I like to avoid parallel development effort (and I like to
avoid clearsilver).
> So they are already following a nice deprecation route, keeping functionality
> in 0.11 for CS, adding in Genshi, and in a subsequent release start taking CS
> out.
I've given the rationales above, why this route is not nice.
> Your way of deprecation c.q. ripping out CS from 0.11 already and introducing
> Genshi into a running 0.10.x branch quite frankly appals from me a design
> perspective.
Clearsilver can stay until trac 6.17, I've no problem with this.
My interest is to get Genshi into 0.10.
If Genshi is integrated carefully, it will not affect the 0.10 version.
> >As to the effort:
> >
> >[REQUOTE]
> >I could provide the necessary analytical / abstraction work for doing
> >this.
> >[?REQUOTE]
>
> I think they are not interested in anything commercial, which is what you seem
> to be hinting at.
Sorry, but this is completely nonsense.
> And when it comes to abstraction and analysis work I've become quite impressed
> by the main Trac developers and various contributors.
This is not about abilities, but about workload.
I simply like to estimate the effort - and this conversation is not
very helpful.
.
Noah Kantrowitz
to respect them all as very talented programmers and system
architects. I think they have chosen a good path to follow, and
personally I trust them to continue to do what is best for Trac.
Developer time is an issue, but adding more people is not a solution
to that. If you disagree with any of those base statements I would
urge you to look into using other software to meet you needs,
possibly even a fork of Trac.
--Noah
Christian Boos
> Christopher Lenz wrote:
>
>> ...
>> The Genshi migration will not be backported to 0.10.x. Genshi will
>> only be available in versions of Trac >= 0.11.
>>
>> Once 0.11 is available (even in unreleased form), and the Genshi
>> branch has been merged, plugins can start using Genshi, but they will
>> not work in Trac 0.9 or 0.10. Plugins still using ClearSilver will
>> continue to work as long as ClearSilver is installed.
>>
>> Backporting the changes required for Genshi would (IMHO) be too much
>> work, and we can really find better uses of developer time.
>>
>
> ...like developing in paralell for 0.10 and 0.11 ?
>
> If I understand your releases right, 0.10.X will be for long time (6 to
> 12 months) the official "latest stable release".
>
That's a valid point IMHO. I really don't want to have to work on 0.10
(Clearsilver) and 0.11 (Genshi) in parallel for about a year. If it
nevertheless goes that way, I personally won't spend much time on
0.10-stable (not that there would be necessarily a need for, as 0.10 is
"almost perfect" as we all now ;) ).
My take would be to make the coexistence period of Clearsilver and
Genshi *as short as possible*, by having a 0.11 release feature-wise
more or less equivalent to 0.10, but using Genshi. If we want to
implement all the features currently scheduled for 0.11, I guess it'll
take us another 10 months (approx.).
Now, rather than post-pone all the 0.11 features to 0.12, we could
think about creating intermediate milestones, 0.11pre1, 0.11pre2 etc.
which will be "feature" milestones, e.g. 0.11pre1 would be "0.10 +
genshi", 0.11pre2 would be the integration of WorkFlow, 0.11pre3
migration to setuptools, etc.
I think this will improve on the current situation.
During 0.10dev, a lot of people ended up using it by following 'trunk',
because trunk remained mostly usable during a large part of the
development. That's fine of course, and we don't want to change that.
However, a lot of people could have been "scared" of using the latest
development version, and even if they were interested in, didn't
necessarily know which changeset to use, or what was the state of
affairs on the trunk. Having "preX" milestones would help clarify that
(we close a "pre" milestone and tag it when we now that the trunk is
stable), and potentially gain us more beta testers.
> If I develope plugins, I need to develop them twice (0.10, then porting
> to 0.11). Most possibly, developers will develope with CS, to run under
> both, 0.10 and 0.11 (which will delay the "total" Genshi migration).
>
New plugins should be written for Genshi, I think and old ones could be
ported right now.
Having new "Genshi-only" plugins will motivate users to upgrade.
(he, I'm talking as if 0.10 was dead old, it's not even released yet ;) )
> So, wouldn't it be better to integrate the Genshi modifications in an
> non-intrusive way into 0.10, thus developers migrate immediately to
> Genshi? 0.11 would then be able to _remove_ clearsilver dependency (as
> everything relevant will have been ported until then).
>
> So, ideally, the "Genshi Enabling Additions" should find their way soon
> into 0.10.x - I think everyone will agree here.
>
No, I'm afraid that this would only make the 0.10 development line last
longer, which I think would be counter-productive.
Again, if people have enough motivation to go for 0.11 and if we make
that possible by having very early "pre" releases, then the coexistence
period will be short.
-- Christian
[1] - http://groups.google.com/group/trac-dev/msg/feea22fb61b06cc6
Ilias Lazaridis
> In the time that I have been working with the Trac devs, I have come
> to respect them all as very talented programmers and system
> architects. I think they have chosen a good path to follow, and
> personally I trust them to continue to do what is best for Trac.
> Developer time is an issue, but adding more people is not a solution
> to that. If you disagree with any of those base statements I would
> urge you to look into using other software to meet you needs,
> possibly even a fork of Trac.
I respect your feelings, but I like to continue this discussion facts
oriented.
.
Jeroen Ruigrok/asmodai
>Now, rather than post-pone all the 0.11 features to 0.12, we could
>think about creating intermediate milestones, 0.11pre1, 0.11pre2 etc.
>which will be "feature" milestones, e.g. 0.11pre1 would be "0.10 +
>genshi", 0.11pre2 would be the integration of WorkFlow, 0.11pre3
>migration to setuptools, etc.
>
>I think this will improve on the current situation.
Personally I think this will only add confusion to the entire ballgame.
What's against just naming the integration of Genshi 0.11, the workflow
integration 0.12, the setuptools fixing and whatnot 0.13. Numbers are cheap
and in this case less confusing than arbitrary suffixes like pre1, pre2, pre3,
undsoweiter.
Clear and unambiguous from my point of view. You only get a few faster
releases, which I don't see as a problem at all.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/
When we have not what we like, we must like what we have...
Emmanuel Blot
I fully agree.
I think we should avoid going towards an overly complex naming scheme.
I can't imaging the support emails about which release a user is in
trouble with ;-)
Meanwhile, the current situation is that it took about 1 year to
release this new version of Trac, and I think this is the most
important point to focus on: shorter release time.
I personally don't mind about which feature is released first.
As I understand the various requests on the ML and in the ticket, the
new workflow IS the most expected feature, and I think the next
release should focus on this feature (and maybe on this feature
*only*).
Most users who already have a working Trac environment don't care
about the templating engine (ClearSilver or Genshi), and I think many
people have been waiting for a (very) long time for the workflow
features. If the move to Genshi delays the introduction of the
workflow branch, I think the workflow should get there first.
I'm not sure to understand why Ilias wants the Genshi branch to be
merged as soon as possible. Is it 'only' about developing/maitaining
plugins ?
My 2 (euro) cents.
Cheers,
Manu
Christopher Lenz
> -On [20060923 14:36], Christian Boos (cb...@neuf.fr) wrote:
>> Now, rather than post-pone all the 0.11 features to 0.12, we could
>> think about creating intermediate milestones, 0.11pre1, 0.11pre2 etc.
>> which will be "feature" milestones, e.g. 0.11pre1 would be "0.10 +
>> genshi", 0.11pre2 would be the integration of WorkFlow, 0.11pre3
>> migration to setuptools, etc.
>>
>> I think this will improve on the current situation.
>
> Personally I think this will only add confusion to the entire
> ballgame.
>
> What's against just naming the integration of Genshi 0.11, the
> workflow
> integration 0.12, the setuptools fixing and whatnot 0.13. Numbers
> are cheap
> and in this case less confusing than arbitrary suffixes like pre1,
> pre2, pre3,
> undsoweiter.
Agreed. Undoubtedly the plate is pretty full for 0.11, and it
probably makes sense to move some work items to 0.12 or later.
This is the list of work items I would personally like to see in
0.11, if we view 0.11 as "The-Migration-to-Genshi-Release":
* datetime, because using datetime objects from templates is much
nicer and more powerful than getting passed opaque strings and
timestamp ints
* setuptools, because then you'll be able to easy_install Trac and
Genshi will be installed automatically, and also because plugins can
finally specify which version of Trac they're compatible with and use
the "trac.ext" namespace package instead of polluting the root
package namespace
* webadmin, because if we keep it separate we may need to maintain
two versions (see sandbox/webadmin vs sandbox/webadmin-genshi)
I would also really like to see workflow in 0.11. Seeing how it's
been worked on quite a bit, updating/polishing the branch and moving
it to Genshi should be possible in a relatively short time frame.
What I'd also *like* to see in 0.11 is I18N and the refactored Wiki
formatting (so that the wiki formatters can take advantage of the
streaming in Genshi). However, those efforts haven't even been
started yet, so their inclusion is highly unlikely.
Ilias Lazaridis
...
> Most users who already have a working Trac environment don't care
> about the templating engine (ClearSilver or Genshi), and I think many
> people have been waiting for a (very) long time for the workflow
> features. If the move to Genshi delays the introduction of the
> workflow branch, I think the workflow should get there first.
I don't know which of the 2 subsystems (Workflow / Genshi) introduces
more changes to the other one.
which would be less effort, first Genshi then Workflow, or first
Workflow then Genshi?
A 0.11 targeted for end of 2006 could possibly contain both systems
(Workflow and Genshi).
> I'm not sure to understand why Ilias wants the Genshi branch to be
> merged as soon as possible. Is it 'only' about developing/maitaining
> plugins ?
I like to use trac in the way it is intended to be used (that's why trac
is release under the very liberal BSD2 license).
I implement an Open Source Project Infrastructure based on python, and
use trac as the fundamental part:
As you can see from my technical topics within the list: I ask many
times for information, but share always the resulting solutions which I
produce / find.
-
Genshi will simplify the trac-customization, which means that I can
build my custom trac version mainly plugin-based, without altering the
main trac source code base.
I make contributions to the main source-code, whenever it makes sense
(patches / additions which add flexibility useful for everyone etc.).
I've identified Genshi as the most critical part in context of
development efforts and trac-source-code clarity. Thus I like to have
Genshi active, before I dive deeper into the trac source-codes and
development.
Beside simplified development, there are a few more benefits:
* Genshi will simplify the trac setup
* Genshi will help to identify the most actively maintained plugins (as
those will migrate first to genshi).
* Early integration will reduce parallel development efforts.
Hope I've clarified things a little.
.
ML Philip Instadia
> about the templating engine (ClearSilver or Genshi), and I think many
> people have been waiting for a (very) long time for the workflow
> features. If the move to Genshi delays the introduction of the
> workflow branch, I think the workflow should get there first.
>
> Manu
HEAR HEAR! :)
As a developer I know you will hate me for pointing this out, but: a
successful community project is not driven by developers. The users
of the product drives it. The more 'real' business users you can get,
the more successful your project will be.
I am pretty sure that the majority of business users that are holding
off on trac do this because the workflow is too rigid. Instead they
are using a myriad of home-brews and bugzilla combos. (They fear
using the sandbox/workflow because it is experimental).
Which brings me to the next point: Workflow is fully functional and
working. Probably a lot more stable than the various mock-ups used
instead. Why not release it? How would that complicate Genshi
transmogriffing? Get it out the door and you'll have one less branch
to worry about.
My 0.02DKK.
Cordially,
Philip Bergen
Alec Thomas
>
> > Most users who already have a working Trac environment don't care
> > about the templating engine (ClearSilver or Genshi), and I think many
> > people have been waiting for a (very) long time for the workflow
> > features. If the move to Genshi delays the introduction of the
> > workflow branch, I think the workflow should get there first.
>
>
> As a developer I know you will hate me for pointing this out, but: a
> successful community project is not driven by developers. The users
> of the product drives it. The more 'real' business users you can get,
> the more successful your project will be.
>
> I am pretty sure that the majority of business users that are holding
> off on trac do this because the workflow is too rigid. Instead they
> are using a myriad of home-brews and bugzilla combos. (They fear
> using the sandbox/workflow because it is experimental).
>
> Which brings me to the next point: Workflow is fully functional and
> working. Probably a lot more stable than the various mock-ups used
> instead. Why not release it? How would that complicate Genshi
> transmogriffing? Get it out the door and you'll have one less branch
> to worry about.
There are a couple of wartish things that should be redesigned in
Workflow before merging: the trac.ticket.field objects are a bit ugly;
I think the way actions are controlled can be made cleaner; I'd like to
add custom form control support to ticket changes; etc. Not to mention
the number of changes that have occurred to the ticket system since the
last Workflow merge. So basically, while Workflow works, there is still
a fair bit of work to be done.
Also, because I expect workflow will be used a lot, getting the overall
design as clean and usable as possible up front is critical IMO. We
don't want to rush it in.
Another factor is that the Genshi merge will make certain things about
workflow easier. For one thing, I will get a chance to redo the ticket
templates and clean them up in the process. And I won't have to use CS
to do it.
Finally, I think Genshi won't take long at all? cboos, mgood and cmlenz
have all been working furiously on the sandbox so if we go with the
"launch Genshi quickly" approach, I don't think it will be far off at
all. Particularly if compared to the 0.10 release period ;)
My vote is for Genshi first to motivate people to start porting their
plugins and so we can ditch CS as quickly as possible, Workflow for
0.12.
Emmanuel Blot
> plugins and so we can ditch CS as quickly as possible, Workflow for
> 0.12.
So what's the final status about this point?
I guess that if the main author of the Workflow (Alec, if I'm right)
votes for postponing it after Genshi, maybe we should stick to this
schedule. As the new Workflow is still the most expected feature, it
may be interesting to restrict 0.11 to Genshi only (i.e. not adding
new feature to 0.11 but Genshi) ? When/If this is ok, I think the
roadmap page should be udpated to reflect the changes.
Cheers,
Manu
Christian Boos
0.11 should be "Genshi-oriented" instead of strictly Genshi, I would say.
As cmlenz pointed out, the setuptools merge should be done together, as
this would make it possible to easy_install both Trac and Genshi in one
move.
I think merging the jquery branch would be a no-brainer and low risk change.
The datetime branch story is a little bit different, though.
If you look at the actual diffs between that branch and trunk, you'll
see a few things that were not correctly merged so far. Also, in the
genshi branch, I already moved the calls to the date rendering utilities
in the templates, so that the data model only contains the timestamps.
Those should be easily converted to datetime objects. So my point is
that the datetime should probably be reworked on top of genshi after the
merge, instead of being simply "svn merge"d.
What's mainly left to be done on the Genshi branch is:
- migrate the report module; I started this last WE, but couldn't
finish it, so nothing was committed so far.
- find a clean way for plugins to associate filters to the templates
(a.k.a. the "Genshi holy grail")
With mostly the above tasks in mind (genshi, setuptools, jquery,
datetime), we could probably get 0.11 out rather quickly.
After that, we can focus on making 0.12 feature-oriented, with all the
nice new things on a sane basis.
Forgot about webadmin: I also think it should be integrated in trunk
after the setuptools branch merge, but maybe in two steps: first simply
"as is", by moving the sandbox/webadmin-genshi/webadmin to
trunk/trac/admin, then, in a second step, a refactoring along the lines
cmlenz suggested (and that could eventually wait 0.12, depending on the
schedule).
-- Christian
Ilias Lazaridis
...
> What's mainly left to be done on the Genshi branch is:
> - migrate the report module; I started this last WE, but couldn't
> finish it, so nothing was committed so far.
> - find a clean way for plugins to associate filters to the templates
> (a.k.a. the "Genshi holy grail")
Possibly you can provide a compact problem description on the wiki, thus
I can join to find a solution.
...
> Forgot about webadmin: I also think it should be integrated in trunk
> after the setuptools branch merge, but maybe in two steps: first simply
> "as is", by moving the sandbox/webadmin-genshi/webadmin to
> trunk/trac/admin,
...
"as is" movement is very positive!
> then, in a second step, a refactoring along the lines
> cmlenz suggested (and that could eventually wait 0.12, depending on the
> schedule).
.
Jonas Borgström
*snip*
> The datetime branch story is a little bit different, though.
> If you look at the actual diffs between that branch and trunk, you'll
> see a few things that were not correctly merged so far.
What do you mean by "not correctly merged"?
> Also, in the
> genshi branch, I already moved the calls to the date rendering utilities
> in the templates, so that the data model only contains the timestamps.
> Those should be easily converted to datetime objects. So my point is
> that the datetime should probably be reworked on top of genshi after the
> merge, instead of being simply "svn merge"d.
On the datetime branch I on purpose tried to make as few changes as
possible, in order to simplify the merge, we can always refactor
things later...
But I agree that it might be a good idea to merge genshi before
datetime since it would probably require less work and as you say, an
opportunity to (re)do things "genshi"-style.
Cheers,
Jonas
Christian Boos
> Christian Boos wrote:
> *snip*
>
>> The datetime branch story is a little bit different, though.
>> If you look at the actual diffs between that branch and trunk, you'll
>> see a few things that were not correctly merged so far.
>>
>
> What do you mean by "not correctly merged"?
When I had a look at the diffs just after the last merge (r3782), I
spotted that the 'req' was still in the tn.notify() argument, in
trac.ticket.web_ui.py, the ticket notification and related tests.
I just checked once again, and this seems to be all, so apparently only
r3550 has not been merged for some reason.
-- Christian
Jonas Borgström
Christian Boos wrote:
> When I had a look at the diffs just after the last merge (r3782), I
> spotted that the 'req' was still in the tn.notify() argument, in
> trac.ticket.web_ui.py, the ticket notification and related tests.
>
> I just checked once again, and this seems to be all, so apparently only
> r3550 has not been merged for some reason.
I actually added it back since the selected timezone is currently
stored in "req.tz".
It's a bit unfortunate, but that's the only option I found that didn't
require major surgery.
/ Jonas
Christian Boos
Oh, ok, in TicketModule.grouped_changelog_entries(), I didn't see that!
But then the tz used for the mail will end up to be the one of the
author of the change...
We should probably use instead either the tz of the server (then we can
use the same mail content for everyone) or the tz of the recipient, if
it is known (but then the mail content would have to be generated
specifically).
-- Christian
Jonas Borgström
Christian Boos wrote:
> Oh, ok, in TicketModule.grouped_changelog_entries(), I didn't see that!
> But then the tz used for the mail will end up to be the one of the
> author of the change...
> We should probably use instead either the tz of the server (then we can
> use the same mail content for everyone) or the tz of the recipient, if
> it is known (but then the mail content would have to be generated
> specifically).
Yeah, but fortunately the mails doesn't actually contain any timestamps
at all so we're fine. But in the future it will probably be a good idea
to move the timezone stuff away from "grouped_changelog_entries"
anyway...
/ Jonas