0.12 Release Schedule - updates
Christian Boos
A few updates about the progresses towards a 0.12 release...
First, the good news. There's been a good deal of activity recently,
some of the changes in the custom query and ticket interface are really
nice, you might want to give them a try. Many small tickets have been
fixed, others have been moved to later releases, so the path toward
milestone completion becomes visible (we have only 31 tickets left [1]).
Also, Christopher has merged the advanced-i18n branch of Genshi into
trunk, which means that Trac trunk is now again easy to install
('easy_install'able, I suppose). This version is fairly solid for Trac
usage at least, and I would welcome a 0.6 release on that basis.
The multirepos branch has also seen some progresses, but is still not
yet ready to merge on trunk. I've started to work on the few remaining
bits (all "authz" related), so I'm pretty confident this will happen
this week.
The #7851 branch (with_transaction refactoring) is also progressing
well, and it looks like we will be able to integrate that after
multirepos merge. We can even still integrate #1106 (wiki rename) after
that.
Other stuff that will likely happen after the multirepos merge are a few
more db schema changes, notably #6466 (int => bigint for timestamps) and
storing 0-padded revision numbers in the repository cache (#6654).
Now for i18n, the situation is a bit mixed: we have a fairly good
coverage, a few tickets (i18 component) indicate the remaining
translations, nothing critical. What is more involved on the i18n side
are the following two tickets:
- #2182, configurable date and time formats; it would really be bad to
be able to select one's language, time zone, but not see the dates in
the way the user prefers them (note that we can't make that stick to the
user's "locale", as many people would prefer to have e.g. the ISO8601
format) [2]
- #6353, translation of javascript texts; Jonas started something one
year ago, but that was not using the "Babel" support for javascript; I
think we should also have a different catalog for the Javascript texts,
so that the relevant messages can be easily obtained [3]
And, yes, some documentation is still needed, in particular for plugin
translations.
Concerning the translations themselves, the situation is a bit mixed.
With the exception of the fr_FR translation which is quite good and
up-to-date (kudos to Stéphane Raimbault, btw!), and maybe a handful of
others, the others are certainly fairly out of date. We could urge the
translators to finish the translations once we're in code freeze i.e.
the testing period, somewhen in December, but it would be better if they
start working on it as soon as possible, given the huge amount of work
this represents. More likely will we get partial translations in 0.12
proper and only start to get better translations once people start to
use it and would like to contribute fixes for their languages. To
facilitate that, we should have a string freeze during the 0.12 - 0.12.1
period.
Ah, yes, some words about 0.11.6, hm, no that will be a separate mail.
Let me just say that I think we'll do it soon and that a 0.11.7 release
will probably still be needed.
To sum up, the tentative release schedule now looks like:
- end of this week: merge multirepos
- end of November / early December: release 0.12beta1
- December: bug fixes, last few features
- Mid-December: 0.12rc1
- End of December: 0.12
- End of February 2010: 0.12.1
A bit tighter than the previous tentative schedule ;-)
-- Christian
[1] -
http://trac.edgewall.org/query?status=!closed&milestone=0.12&type=!task
[2] - http://trac.edgewall.org/ticket/2182#comment:62
[3] - http://trac.edgewall.org/ticket/6353#comment:6
Andrea Tomasini
On 12 Nov, 2009, at 20:06 , Christian Boos wrote:
> Hi list,
Hi Christian,
> First, the good news. There's been a good deal of activity recently,
> some of the changes in the custom query and ticket interface are really
> nice, you might want to give them a try. Many small tickets have been
> fixed, others have been moved to later releases, so the path toward
> milestone completion becomes visible (we have only 31 tickets left [1]).
> Also, Christopher has merged the advanced-i18n branch of Genshi into
> trunk, which means that Trac trunk is now again easy to install
> ('easy_install'able, I suppose). This version is fairly solid for Trac
> usage at least, and I would welcome a 0.6 release on that basis.
Cool, I'll have a look if the duplication bug has been also fixed... we are still runtime-patching that... very annoying :-(
> The multirepos branch has also seen some progresses, but is still not
> yet ready to merge on trunk. I've started to work on the few remaining
> bits (all "authz" related), so I'm pretty confident this will happen
> this week.
Great, so I'll try that out
> Ah, yes, some words about 0.11.6, hm, no that will be a separate mail.
> Let me just say that I think we'll do it soon and that a 0.11.7 release
> will probably still be needed.
Ok, so we will have more time to adapt to 0.12, that is good news, a lot of innovation coming, requiring time also from plugin developers...
> To sum up, the tentative release schedule now looks like:
>
> - end of this week: merge multirepos
> - end of November / early December: release 0.12beta1
> - December: bug fixes, last few features
> - Mid-December: 0.12rc1
> - End of December: 0.12
Ok, not that much time than...
> - End of February 2010: 0.12.1
>
> A bit tighter than the previous tentative schedule ;-)
Indeed :-)
I know it might be a bit late, and out of plan, but I am looking right now into the Milestone object, and I would like to add an extension point to that as well, as there is none now. At least in Agilo, and other plugins do that as well, would be nice to know when a Milestone is renamed, so that we can react to that event. Is someone objecting if I had extension points similar to the ticket ones? (E.g.: milestone_created, milestone_changed, milestone_deleted) ?
Thanks
> -- Christian
ANdreaT
Remy Blank
> I know it might be a bit late, and out of plan, but I am looking
> right now into the Milestone object, and I would like to add an
> extension point to that as well, as there is none now. At least in
> Agilo, and other plugins do that as well, would be nice to know
> when a Milestone is renamed, so that we can react to that event.
> Is someone objecting if I had extension points similar to the
> ticket ones? (E.g.: milestone_created, milestone_changed,
> milestone_deleted) ?
This has been discussed here:
http://trac.edgewall.org/ticket/6543
but AFAICR we haven't reached a decision there about the "generic"
notification interface.
FWIW, I'd be ok with including a specialized notification interface for
milestones, as first suggested by Erik Bray in the ticket above, in
0.12, and leave the generic interface for later.
What do others think?
-- Remy
Andrea Tomasini
> Andrea Tomasini wrote:
>> I know it might be a bit late, and out of plan, but I am looking
>> right now into the Milestone object, and I would like to add an
>> extension point to that as well, as there is none now. At least in
>> Agilo, and other plugins do that as well, would be nice to know
>> when a Milestone is renamed, so that we can react to that event.
>> Is someone objecting if I had extension points similar to the
>> ticket ones? (E.g.: milestone_created, milestone_changed,
>> milestone_deleted) ?
>
> This has been discussed here:
>
> http://trac.edgewall.org/ticket/6543
>
> but AFAICR we haven't reached a decision there about the "generic"
> notification interface.
That would be good :-)
> FWIW, I'd be ok with including a specialized notification interface for
> milestones, as first suggested by Erik Bray in the ticket above, in
> 0.12, and leave the generic interface for later.
Right, I can do that, I also found a kind of "bug" that is the following:
The milestone object assumes to be created, and used in two different requests, that might not always be the case:
- In the initialization the Milestone checks the "name" parameter and stores it - or not - as a copy in _old_name
- Once I insert a new Milestone, the insert method currently doesn't update the _old_name upon success...
- You can't update successfully a milestone after creation, unless you reload it again :-(
Index: trac/ticket/model.py
===================================================================
--- trac/ticket/model.py (revision 8744)
+++ trac/ticket/model.py (working copy)
@@ -693,7 +693,8 @@
"VALUES (%s,%s,%s,%s)",
(self.name, to_timestamp(self.due), to_timestamp(self.completed),
self.description))
-
+ self._old_name = self.name
+
if handle_ta:
db.commit()
TicketSystem(self.env).reset_ticket_fields()
Should I send all the patches always in here? Is there a sandbox where to check this in?
Thanks
ANdreaT
Remy Blank
> On 13 Nov, 2009, at 14:12 , Remy Blank wrote:
>> FWIW, I'd be ok with including a specialized notification interface for
>> milestones, as first suggested by Erik Bray in the ticket above, in
>> 0.12, and leave the generic interface for later.
> Right, I can do that, I also found a kind of "bug" that is the following:
There's actually already a patch attached to that ticket, that
implements the interface you want for milestones. What I'm interested to
know if other developers think this is a good idea to include that patch
in 0.12. If yes, I'll apply it.
For the other issue, please open a new ticket, they are much easier to
track than mailing list messages :-)
-- Remy
Andrea Tomasini
> Andrea Tomasini wrote:
>> On 13 Nov, 2009, at 14:12 , Remy Blank wrote:
>>> FWIW, I'd be ok with including a specialized notification interface for
>>> milestones, as first suggested by Erik Bray in the ticket above, in
>>> 0.12, and leave the generic interface for later.
>> Right, I can do that, I also found a kind of "bug" that is the following:
>
> There's actually already a patch attached to that ticket, that
> implements the interface you want for milestones. What I'm interested to
> know if other developers think this is a good idea to include that patch
> in 0.12. If yes, I'll apply it.
Ah, you mean the ExtensionPoint here... ok...
> For the other issue, please open a new ticket, they are much easier to
> track than mailing list messages :-)
I was thinking this might be good enough also for 0.11.6 it is not changing anything serious, and it is an extension, so shouldn't harm ;-)
there you go: http://trac.edgewall.org/ticket/8817
Ciao
ANdreaT