Final tickets for 0.12.3

14 views
Skip to first unread message

Remy Blank

unread,
Oct 16, 2011, 3:07:50 PM10/16/11
to trac...@googlegroups.com
I would like to release 0.12.3 in the very near future, as we have quite
a lot of fixes in there that I would like to push to our users.

We are currently down to 10 open tickets, some already containing
patches that just need to be applied, others that still require a bit of
work. They are currently assigned as follows:

cboos:
------
http://trac.edgewall.org/ticket/8459

This is a performance issue when rendering svn:mergeinfo properties when
merging from many branches (hundreds). The special rendering can be
disabled easily, so it's not a critical issue.

http://trac.edgewall.org/ticket/9976

This is an issue with authz checks and intra-repository copies.
Christian, what's the way forward?

http://trac.edgewall.org/ticket/10048

This is actually already fixed. One question is pending, whether or not
`Href` should prevent from generating URLs with empty segments. We don't
currently use empty segments, but we do use an empty trailing segment,
leading to a trailing /. I would suggest leaving the code as-is.

http://trac.edgewall.org/ticket/10121

This is an issue with the timeline and repository browser with
repository names containing non-ASCII characters. This requires some
more work. I may try to look into this.


fschwarz:
---------
http://trac.edgewall.org/ticket/10137
http://trac.edgewall.org/ticket/10400

Both tickets are minor translation issues. Felix, could you please make
a decision for each and apply any remaining changes?


jomae:
------
http://trac.edgewall.org/ticket/10275

Patch is ready and seems to work fine. Jun, could you please apply?


unassigned:
-----------
http://trac.edgewall.org/ticket/9980

Kept open by cboos to improve the trac-admin doc. Christian, I'm not
sure what the improvement should be, so could you please either update
the doc or explain so that I can do it?

http://trac.edgewall.org/ticket/10287

Pending feedback from the OP. It looks like MySQLdb sometimes returns a
string for BIGINT columns. I can't reproduce the issue, so if we don't
get any feedback, I'm going to close the ticket as "worksforme".

http://trac.edgewall.org/ticket/10382

This is a weird issue with IE, where the page refreshes when it
shouldn't. It's arguably a (known) bug in IE, but it's very annoying. I
haven't found a good workaround, so *I need some new ideas here*!


I would like to ask each of the ticket owners to either apply their
patches, or to comment on their tickets how they want to move forward
(and possibly move tickets to later milestones if necessary). The goal
would be to be down to zero tickets within one or two weeks, so that we
can do a string freeze, followed by a week of testing and translation,
and finally a nice 0.12.3 release.

I would also like to push 0.13 closer to a release, but that's a subject
for another e-mail :)

-- Remy

signature.asc

anatoly techtonik

unread,
Oct 25, 2011, 11:04:18 AM10/25/11
to trac...@googlegroups.com
I would really like to see cleanup fix in http://trac.edgewall.org/ticket/10418#comment:1 applied as well - as it will help me to get rid of patching Trac source code in - https://bitbucket.org/techtonik/trac-bootstrap-script

Remy Blank

unread,
Oct 25, 2011, 2:59:56 PM10/25/11
to trac...@googlegroups.com

Sorry, no enhancements on 0.12-stable, only defects.

Did you try the suggestion I made on that ticket? You wouldn't need to
patch in that case, and you would have a more robust installation.

-- Remy

signature.asc

Christian Boos

unread,
Oct 28, 2011, 2:22:44 PM10/28/11
to trac...@googlegroups.com
On 10/16/2011 9:07 PM, Remy Blank wrote:
> I would like to release 0.12.3 in the very near future, as we have quite
> a lot of fixes in there that I would like to push to our users.
>
> We are currently down to 10 open tickets, some already containing
> patches that just need to be applied,

Down to 6...

I also think we should enter string freeze by now and make a call to the
translators.

I tried to look at the stats on Transifex, but somehow the interface has
changed and I didn't find yet a way to trigger an update of the stats,
as they seem quite out of date.

The translation stats from 0.12-stable at r10856,
as obtained via `make summary` and sorted:

----------------------------------------
l10n/sv: translations updated (99%)
l10n/ja: translations updated (99%)
l10n/fr: translations updated (99%)
l10n/en_GB: translations updated (99%)
l10n/de: translations updated (99%)
l10n/ru: translations updated (98%)
l10n/pt_BR: translations updated (98%)
l10n/hu: translations updated (98%)
l10n/es_AR: translations updated (98%)
l10n/ca: translations updated (98%)
l10n/tr: translations updated (97%)
l10n/it: translations updated (97%)
l10n/he: translations updated (97%)
l10n/zh_TW: translations updated (95%)
l10n/zh_CN: translations updated (95%)
l10n/sl: translations updated (95%)
l10n/nl: translations updated (95%)
l10n/hy: translations updated (95%)
l10n/es: translations updated (95%)
l10n/eo: translations updated (95%)
l10n/cs: translations updated (95%)
l10n/nb: translations updated (94%)
l10n/fi: translations updated (87%)
l10n/pl: translations updated (76%)
l10n/ko: translations updated (62%)
l10n/gl: translations updated (58%)
l10n/vi: translations updated (40%)
l10n/el: translations updated (39%)
l10n/fa: translations updated (35%)
l10n/pt: translations updated (34%)
l10n/ro: translations updated (29%)
----------------------------------------

(well r10856 actually added a message ;-) )

> others that still require a bit of
> work. They are currently assigned as follows:
>
> cboos:
> ------

> http://trac.edgewall.org/ticket/9976
>
> This is an issue with authz checks and intra-repository copies.
> Christian, what's the way forward?

So the idea is now to keep the semantic of the checks as close as
possible as Subversion does. Basically this means giving up on checking
the create_path/rev. I've not looked yet at the code change implied.


>
> http://trac.edgewall.org/ticket/10048
>
> This is actually already fixed. One question is pending, whether or not
> `Href` should prevent from generating URLs with empty segments. We don't
> currently use empty segments, but we do use an empty trailing segment,
> leading to a trailing /. I would suggest leaving the code as-is.

We should be more conservative about the kind of links we generate.
If some are known to be problematic, better be restrictive and not
generate them. This means applying Remy's patch.


>
> http://trac.edgewall.org/ticket/10121
>
> This is an issue with the timeline and repository browser with
> repository names containing non-ASCII characters. This requires some
> more work. I may try to look into this.
>

I suspect this is related to the above to the extent the generated links
are not seen in the browser the same way they're generated, but I can be
wrong as I didn't take the time yet to work on that one. So feel free to
look into this.

>
> fschwarz:
> ---------
> http://trac.edgewall.org/ticket/10137
> http://trac.edgewall.org/ticket/10400
>
> Both tickets are minor translation issues. Felix, could you please make
> a decision for each and apply any remaining changes?
>

Not a blocker but still would be nice if done during the string freeze.


>
> jomae:
> ------

There's now http://trac.edgewall.org/ticket/7821
which is on the way to be fixed again.

> I would like to ask each of the ticket owners to either apply their
> patches, or to comment on their tickets how they want to move forward
> (and possibly move tickets to later milestones if necessary). The goal
> would be to be down to zero tickets within one or two weeks, so that we
> can do a string freeze, followed by a week of testing and translation,
> and finally a nice 0.12.3 release.

Testing! Testing! We want testing!

>
> I would also like to push 0.13 closer to a release, but that's a subject
> for another e-mail :)

0.13, the unlucky release ;-)

-- Christian

Remy Blank

unread,
Oct 28, 2011, 2:36:01 PM10/28/11
to trac...@googlegroups.com
Christian Boos wrote:
> We should be more conservative about the kind of links we generate.
> If some are known to be problematic, better be restrictive and not
> generate them. This means applying Remy's patch.

Simon has raised some concerns about this. I do think it makes sense not
to generate links that cannot be handled in certain configurations, but
changing Href is a behavior change, which may be undesirable in a stable
release. So I don't mind moving it to 0.13 if requested.

-- Remy

signature.asc
Reply all
Reply to author
Forward
0 new messages