About next versions (0.11.6 and 0.12)
Christian Boos
Now that 0.11.5 is out, I'd like to share my views concerning the next
releases.
First, let's see where we stand with respect to opened tickets (1):
- 43 untriaged tickets -- not that bad
- 18 tickets for which we're waiting for feedback -- good!
- 913 valid tickets to work on... -- hm...
Looking at the tickets by milestone, we have the current dispatching of
opened tickets (2):
|| Milestone || Enhancements || Defects ||
|| 0.11.6 || 4 || 32 ||
|| 0.12 || 71 || 55 ||
|| 0.12.1 || 22 || 88 ||
|| 0.13 || 207 || 91 ||
|| 1.0 || 85 || 39 ||
|| 2.0 || 92 || 14 ||
|| experimental || 11 || 0 ||
|| not applicable || 20 || 41 ||
I think we have too many opened tickets for the next versions 0.11.6 and
0.12.
Reducing the number of tickets is important in order to be able to get a
release out. As usual, this doesn't mean that tickets which are not (or
no longer) scheduled for these releases can't be finished earlier if
someone is willing to work on them, but at least having a low count help
us to visualize what we'd really like to see implemented next.
For the 0.11-stable release line, I think we should really start
freezing it now, only considering serious bug fixes and eventually
performance tweaks. On my side, I'd like to fix #8459 ("svn:mergeinfo
performance") and eventually #8349 ("Older Revisions link with revision
list is wrong" - also related to svn:mergeinfo).
There's also #8443 that we discussed earlier ("postgres and IDLE in
transaction status"), most of the rest should probably be moved to 0.12.1.
For 0.12, we should also consider moving a good deal of tickets to
0.12.1 (defects) or even 0.13 (enhancements).
The list of tickets and tasks I'd really like to get done for 0.12 is
there:
http://trac.edgewall.org/wiki/TracDev/ToDo#Release0.12
I'd like to make the list of 0.12 tickets match the above.
Even as a shortlist, this still represents quite a lot of work, I'm
afraid ;-)
Other developers are welcomed to list their favorite items as well,
either in the TracDev/ToDo page or in the tickets. Please understand
that those places are intended to be used as a way to coordinate actual
work, so if you simply want to give your opinion on what should be done,
the mailing list is enough.
The main idea here is that by doing less work on 0.11-stable, we can get
trunk a bit more active. Also, by making the list of 0.12 tickets
smaller, we can make this release happen sooner and have a better
visibility of the things left to be done.
Let me know what you think!
-- Christian
(1) - http://trac.edgewall.org/wiki/TracTicketTriage
(2) - http://trac.edgewall.org/report/37
sho...@email.de
So, if anyone gives me a nod to start doing this, then I'll start. If there is any info that I might need that isn't online ... I mean, there is an existing branch, but that seems to be pretty idle.
Regards
Jan Schukat
Christian Boos
> Hello, if it is ok, I would like to contribute, especially to version 0.12. I'm mostly familiar with the wiki code, so I guess the Rename stuff would be most appropriate for me, especially since I did a little related work in #8453 (something that will never get included and no one but me will probably use).
>
Great! Your help would be welcome.
> So, if anyone gives me a nod to start doing this, then I'll start. If there is any info that I might need that isn't online ... I mean, there is an existing branch, but that seems to be pretty idle.
>
Well, it's idle because it's finished ;-) When I was done with that
branch, the wiki rename feature was working quite well, in a robust way.
There was some negative reactions at the time I proposed it for
integration into trunk, because some people didn't like the
`transaction` helper function I mixed in there (note in passing that by
using such a helper consistently for performing commit/rollback on SQL
transactions instead of relying on the gc for the eventual rollback, we
wouldn't have the occasional "current transaction is aborted" error).
So the idea would be to redo the changes on current trunk, minus the
transaction code if people are still adverse to it (i.e. omitting
http://trac.edgewall.org/changeset/7333). This means redoing r7334 using
the current style (with a handle_ta flag), then adapt r7335, r7336,
r7337, r7738 and r7339 (r7340 and r7941 will be skipped as well). Best
would be a sequence of cumulative patches for each of the above changes.
Don't hesitate to ask for more details, as you need them.
Depending how well this first phase go, we could even push things a bit
further (like the batch rename idea in
http://trac.edgewall.org/ticket/4412#comment:8). But if you're OK with
that approach, let's focus on the above rebasing and simplifying first.
-- Christian
sho...@email.de
The tracdeveloperplugin suddenly doesn't work anymore (I even did a complete fresh install of genshi and trac and the plugin itself). Crashes with an IndexError.
File "build/bdist.macosx-10.5-i386/egg/tracdeveloper/log.py", line 64, in fn
first_time = req._tracdeveloper_hdlr.buf[0].created
IndexError: list index out of range
Can this be related to the recent performance patches?
I guess I need to disable it for now.
Regards
Jan Schukat
Remy Blank
> For the 0.11-stable release line, I think we should really start
> freezing it now, only considering serious bug fixes and eventually
> performance tweaks.
I agree. I have been found guilty of adding new features to 0.11-stable
too many times, so I'll refrain in the future ;-)
On my side, I have nothing urgent that should go into 0.11-stable, so my
current 0.11.6 tickets could be moved to 0.12 or 0.12.1.
> I'd like to make the list of 0.12 tickets match the above.
> Even as a shortlist, this still represents quite a lot of work, I'm
> afraid ;-)
I'd like to add:
- #8159: req.href can generate empty URLs
- #7731: IWikiPageManipulator.validate_wiki_page not called with the
correct data
- #8204: Unify wiki processors and macros
as all three represent interface changes, which I think are better done
in 0.12 than later.
> Let me know what you think!
Good initiative, I'd also like to see 0.12 out sooner than later.
-- Remy
Remy Blank
> There was some negative reactions at the time I proposed it for
> integration into trunk, because some people didn't like the
> `transaction` helper function I mixed in there (note in passing that by
> using such a helper consistently for performing commit/rollback on SQL
> transactions instead of relying on the gc for the eventual rollback, we
> wouldn't have the occasional "current transaction is aborted" error).
FWIW, I rather liked the transaction() idea, but I would have
implemented it as a function decorator, and used an inner function for
the DB code (example from attachment.py):
def delete(self, db=None):
assert self.filename, 'Cannot delete non-existent attachment'
@as_transaction(self.env, db)
def execute(db):
cursor = db.cursor()
cursor.execute("DELETE FROM attachment WHERE type=%s "
"AND id=%s AND filename=%s",
(self.parent_realm, self.parent_id,
self.filename))
if os.path.isfile(self.path):
try:
os.unlink(self.path)
except OSError, e:
self.env.log.error('Failed to delete attachment '
'file %s: %s', self.path,
exception_to_unicode(e, traceback=True))
raise TracError(_('Could not delete attachment'))
self.env.log.info('Attachment removed: %s' % self.title)
for listener in AttachmentModule(self.env).change_listeners:
listener.attachment_deleted(self)
The as_transaction decorator would set up the database connection if
necessary, call the decorated function and commit or rollback if necessary.
This would also have the additional benefit that it becomes easy to move
to context managers once we drop support for Python 2.4, by replacing:
@as_transaction(self.env, db)
def execute(db):
with:
with transaction(self.env, db) as db:
Just my EUR 0.02.
-- Remy
Leonardo Santagada
On Jul 23, 2009, at 12:07 PM, Christian Boos wrote:
> For 0.12, we should also consider moving a good deal of tickets to
> 0.12.1 (defects) or even 0.13 (enhancements).
>
> The list of tickets and tasks I'd really like to get done for 0.12 is
> there:
> http://trac.edgewall.org/wiki/TracDev/ToDo#Release0.12
> I'd like to make the list of 0.12 tickets match the above.
> Even as a shortlist, this still represents quite a lot of work, I'm
> afraid ;-)
>
> Other developers are welcomed to list their favorite items as well,
> either in the TracDev/ToDo page or in the tickets. Please understand
> that those places are intended to be used as a way to coordinate
> actual
> work, so if you simply want to give your opinion on what should be
> done,
> the mailing list is enough.
>
> The main idea here is that by doing less work on 0.11-stable, we can
> get
> trunk a bit more active. Also, by making the list of 0.12 tickets
> smaller, we can make this release happen sooner and have a better
> visibility of the things left to be done.
>
> Let me know what you think!
How can I help with the SQLAlchemy port? Is it scheduled for any
particular Trac version or even been discussed about including it in
trunk?
And what about account manager/ldap support?
Those are to me the two things that bug me about trac (besides
multiple repos that are being worked on and some cosmetic changes
regarding the UI).
--
Leonardo Santagada
santagada at gmail.com
Jeroen Ruigrok van der Werven
>I think we have too many opened tickets for the next versions 0.11.6 and
>0.12.
[snip]
>For 0.12, we should also consider moving a good deal of tickets to
>0.12.1 (defects) or even 0.13 (enhancements).
A large part of the tickets for 0.12 are place holder tickets for the
translations. These are easily juggled back and forth between releases. The
ones that have fairly substantive content in the translation will be closed
near release. The others moved. That should cut +/- 30 tickets away.
Since I have time the coming 2 weeks I am going to focus on the Babel/Genshi
issues and clear those out of the way.
The multirepos part seems ok to me, but isn't the Mercurial plugin outside
of the main repository? So it seems no prerequisite to release 0.12.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
The great man is he who does not lose his childlike heart...
Christian Boos
> -On [20090723 17:08], Christian Boos (cb...@neuf.fr) wrote:
>
>> I think we have too many opened tickets for the next versions 0.11.6 and
>> 0.12.
>>
>
> [snip]
>
>
>> For 0.12, we should also consider moving a good deal of tickets to
>> 0.12.1 (defects) or even 0.13 (enhancements).
>>
>
> A large part of the tickets for 0.12 are place holder tickets for the
> translations.
Those tickets are categorized as "task" tickets and were not included in
the numbers from my original mail.
> These are easily juggled back and forth between releases. The
> ones that have fairly substantive content in the translation will be closed
> near release. The others moved. That should cut +/- 30 tickets away.
>
I'm fine with this. At release time, those who grew "big enough" could
be closed and new ones targeting the next release could be created. The
TracTerms* wiki pages could also contain a query listing those
translation tickets.
e.g. TracTermsFr ->
[[TicketQuery(keywords=~l10n,summary=~fr_FR,group=status,format=table)]]
> Since I have time the coming 2 weeks I am going to focus on the Babel/Genshi
> issues and clear those out of the way.
>
Those would be the tickets with the 'i18n' keyword:
http://trac.edgewall.org/query?status=!closed&keywords=~i18n
> The multirepos part seems ok to me, but isn't the Mercurial plugin outside
> of the main repository? So it seems no prerequisite to release 0.12.
>
The multirepos feature is not targeted specially at TracMercurial. The
vc backends for svn, darcs (1) and even git (2) also support the
multirepos feature.
-- Christian
(1) - http://trac.edgewall.org/wiki/TracDarcs
(2) - http://trac-hacks.org/ticket/1040
Jeroen Ruigrok van der Werven
>I'm fine with this. At release time, those who grew "big enough" could
>be closed and new ones targeting the next release could be created. The
>TracTerms* wiki pages could also contain a query listing those
>translation tickets.
>
>e.g. TracTermsFr ->
>[[TicketQuery(keywords=~l10n,summary=~fr_FR,group=status,format=table)]]
I am not entirely sure if the TracTerm pages as they are now should continue
to exist. They would need some rework to become more of a repository of
accepted terminology translations instead under appropriate lockdown instead
of the current free for all change. Only then will we maintain a sufficient
consistent translation base.
>The multirepos feature is not targeted specially at TracMercurial. The
>vc backends for svn, darcs (1) and even git (2) also support the
>multirepos feature.
What I meant was that that URL you gave for 0.12 has an entry for
MultiRepos. Under this entry there were some specifics for the Mercurial
plugin, which seems to be out of scope for 0.12.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
May God stand between you and harm, in all the empty places where you must
walk.
Christian Boos
Even better!
Great, so I would suggest adopting the above pattern for 0.12.
It's just not a cosmetic thing, we have plenty of evidence now that
leaving connections in a non-rollbacked state after an error leads to
problems (I'm writing this while triaging
http://trac.edgewall.org/ticket/8379).
Other opinions?
-- Christian
sho...@email.de
Regards
Jan Schukat
Christian Boos
> Ok, so I try my hand at that decorator implementation, if that is the preferred way.
>
>
Your mailer has definitely a problem with message threading ;-)
See
http://groups.google.com/group/trac-dev/browse_frm/thread/6f6fb445b07867d7
and look at how your messages appear in the tree...
Besides, before investing too much time on this, you should wait a bit
to see if we actually reach a consensus on this, unless you want to
contribute a working "proof-of-concept", which would indeed be a good thing.
-- Christian
sho...@email.de
So in the interest of progress, I'll make an implementation ;)
Regards
Jan Schukat
Jeroen Ruigrok van der Werven
>Those tickets are categorized as "task" tickets and were not included in
>the numbers from my original mail.
Nonetheless, I started moving a bunch of them to 0.12.1.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Into each life some rain must fall, some days must be dark and dreary...
Christian Boos
That port was proposed several times, but it's still not obvious yet if
this will bring any improvement to the current situation. It's a lot of
work to do the conversion. So this is a kind of chicken-egg situation:
it's not really possible to commit ourselves to do the switch without
knowing more about the impact it would have, it's hard for someone to
invest time on this knowing that all that work can eventually be thrown
away...
Put it differently: what do you expect from this switch?
> And what about account manager/ldap support?
>
John started an integration effort, the last changeset says:
Initial merge working. Removal of registration and email verification
needed. Lots of other cleanup needed
So I guess that's a start ;-)
See http://trac.edgewall.org/log/sandbox/accountmanager
> Those are to me the two things that bug me about trac (besides
> multiple repos that are being worked on and some cosmetic changes
> regarding the UI).
>
#2086 is certainly one of the most anticipated feature, it's progressing
well, though we're not there yet. Testing and feedback welcomed ;-)
About the cosmetic changes, they count as real tickets as well. We're
definitely in need for some CSS expertise and there are lots of
usability and layout tickets awaiting contributors, don't hesitate to
help there as well.
-- Christian
Jeroen Ruigrok van der Werven
>How can I help with the SQLAlchemy port? Is it scheduled for any
>particular Trac version or even been discussed about including it in
>trunk?
I have it on my plate to kickstart it again soon. Having gotten more
experience with SQLAlchemy at work I can now better apply this to Trac.
Personally I do not anticipate much of a speed difference and it will make
supporting various database way easier.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
And the sun rises, and reflects in my eyes, as the tear hits the ground
with the rain...
Leonardo Santagada
On Jul 28, 2009, at 6:25 PM, Jeroen Ruigrok van der Werven wrote:
>
> -On [20090725 01:35], Leonardo Santagada (sant...@gmail.com) wrote:
>> How can I help with the SQLAlchemy port? Is it scheduled for any
>> particular Trac version or even been discussed about including it in
>> trunk?
>
> I have it on my plate to kickstart it again soon. Having gotten more
> experience with SQLAlchemy at work I can now better apply this to
> Trac.
>
> Personally I do not anticipate much of a speed difference and it
> will make
> supporting various database way easier.
Support for other databases and specially support for using SQLAlchemy
in the reports and on plugins so they are not tied to one specific
database is very interesting. Better pooling for all databases is even
more interesting. But for me what I would like to see is another way
to customize Trac, adding field to the ticket database and not using
ticket-custom.
Leonardo Santagada
On Jul 28, 2009, at 3:44 PM, Christian Boos wrote:
>
> Leonardo Santagada wrote:
>> How can I help with the SQLAlchemy port? Is it scheduled for any
>> particular Trac version or even been discussed about including it in
>> trunk?
>
> That port was proposed several times, but it's still not obvious yet
> if
> this will bring any improvement to the current situation. It's a lot
> of
> work to do the conversion. So this is a kind of chicken-egg situation:
> it's not really possible to commit ourselves to do the switch without
> knowing more about the impact it would have, it's hard for someone to
> invest time on this knowing that all that work can eventually be
> thrown
> away...
>
> Put it differently: what do you expect from this switch?
I answered that on another email (just seconds ago) but the idea is
better and easier interoperability with other databases and better
support for pooling is a start. For the future, being able to extend
trac by extending the models directly more like Roundup than by ticket-
custom seems interesting. One example would be how easy it would be to
express that the values of a combo on the ticket come from SQLAlchemy.
>> And what about account manager/ldap support?
>>
>
> John started an integration effort, the last changeset says:
>
> Initial merge working. Removal of registration and email verification
> needed. Lots of other cleanup needed
>
> So I guess that's a start ;-)
> See http://trac.edgewall.org/log/sandbox/accountmanager
Cool I will look at that branch.
>> Those are to me the two things that bug me about trac (besides
>> multiple repos that are being worked on and some cosmetic changes
>> regarding the UI).
>>
>
> #2086 is certainly one of the most anticipated feature, it's
> progressing
> well, though we're not there yet. Testing and feedback welcomed ;-)
> About the cosmetic changes, they count as real tickets as well. We're
> definitely in need for some CSS expertise and there are lots of
> usability and layout tickets awaiting contributors, don't hesitate to
> help there as well.
This is what I'm really interested in Usability both of trac itself
but also of the API for people extending it. Sometimes I find it a
little hard to find what is the best way to extend trac, and the users
of my deployment (+/- 200 employees) find trac confusing to use at
parts (specially the query/reports part).
I will look at tickets and see if I can find a place to start :).
Thanks a lot for answering my mail.
rupert.thurner
trac.edgewall.org/query?
status=closed&group=resolution&milestone=0.12), including very nice
features like autoquery (http://trac.edgewall.org/ticket/7562) which
is now implemented for nearly a year i wonder what prevents releasing
0.12 now ? the milestone was due two weeks ago :)
rupert.
Remy Blank
> looking at the huge list of closed tickets for 0.12 (http://
> trac.edgewall.org/query?
> status=closed&group=resolution&milestone=0.12), including very nice
> features like autoquery (http://trac.edgewall.org/ticket/7562) which
> is now implemented for nearly a year
Yes, 0.12 will be great :-)
> i wonder what prevents releasing
> 0.12 now ? the milestone was due two weeks ago :)
For one, we are working hard towards merging the multirepos branch.
We're almost there, but it still needs a bit of work. And I assume the
i18n stuff will need a final pass over the translations to ensure that
the ones that will be included are complete.
-- Remy
Shane Caraveo
i don't know how stable things are in .12, but...
sounds like a good milestone to release .12 on, sooner than later. I
also think .12 would be good to get out, since it will take a chunk of
time for all the plugins to catch up as well.
Emmanuel Blot
> About the cosmetic changes, they count as real tickets as well. We're
> definitely in need for some CSS expertise and there are lots of
> usability and layout tickets awaiting contributors, don't hesitate to
> help there as well.
BTW, it might be worth having a look at Less (http://lesscss.org/), as
it ''could'' be a way to factorize CSS definitions in Trac
(which would make stylesheet customization easier, among other
advantages). Too bad the compiler is written in Ruby ;-)
--
Manu
Christian Boos
This looks interesting, but I think we can achieve something similar by
generating the CSS using Genshi Text templates. This doesn't have
necessarily to be done dynamically, we could probably generate them at
installation time.
Nevertheless having an option to do that dynamically would make
development and testing easier, and that's something which couldn't be
achieved by using Less.
-- Christian
Emmanuel Blot
> generating the CSS using Genshi Text templates.
I don't mind about the tool.
If Genshi could be *easily* used for generating CSS from template
files, that would be great: the fewer dependencies the better.
Cheers,
Manu