0.12
Jeroen Ruigrok van der Werven
the focus for 0.12 a bit?
What I see on the roadmap seems a bit excessive in terms of planning a new
release (notes inline are mine, comments from others very much welcomed to get
an idea of the scope):
* Enhanced underlying data model (GenericTrac)
* Basic support for multiple projects (TracMultipleProjects/SingleEnvironment)
* Vastly improved versioncontrol subsystem (see VcRefactoring)
* Wiki Engine refactoring (WikiEngine)
* Better user/session system
o Optional form-based login
o Pluggable user-directory provider (#2456)
o Nicer CC-list / "ticket monitoring" (#1459)
* Improved notification architecture (TracDev/Proposals/Journaling, #1890)
* Improved ticket query system (so that it can be used instead of SQL reports
system in 99% of the use cases)
* Improved API for request handlers (see sandbox/controller and the newer
VcRefactoring/Controller)
* Internationalization
Most of the internationalization framework is already in place in the i18n
sandbox and kept up to date with trunk. I'm working on setting up something
like Pootle locally to get an idea of the current translation coverage.
* Better help/documentation system (#2656)
Eventually:
* Migrate to SQLAlchemy for database interfacing and connection pooling (see
sandbox/sqlalchemy)
Wouldn't this be a better target for 0.13? Given how SQLAlchemy is currently
revamping a lot of its internals and the SQLAlchemy branch has been dormant
for a long while it seems a bit difficult to correctly shove this inside
Trac at this point in time.
What date did we have in mind for 0.12? I sincerely doubt we want to have as
long a wait as we had for 0.11.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
Learn from the past -- don't wear it like a yoke around your neck...
Manuzhai
into the release and shove the rest, to prevent another 0.11-like
fiasco.
Cheers,
Manuzhai
On Nov 21, 2007 4:42 PM, Jeroen Ruigrok van der Werven
Alec Thomas
> I think the list should decide on one or two overarching ideas that go
> into the release and shove the rest, to prevent another 0.11-like
> fiasco.
Agreed.
My top votes interleaved below.
> On Nov 21, 2007 4:42 PM, Jeroen Ruigrok van der Werven
> > * Basic support for multiple projects (TracMultipleProjects/SingleEnvironment)
This is long overdue and still one of the most requested features.
However, we don't want to do a half-arsed job so we should *really*
*really* think about what we're going to do and how. This could also
break a lot of plugins and we've already done that for 0.11 so it might
be an idea to hold off on this for a while.
> > * Better user/session system
> > o Optional form-based login
> > o Pluggable user-directory provider (#2456)
> > o Nicer CC-list / "ticket monitoring" (#1459)
+1
> > * Improved ticket query system (so that it can be used instead of SQL reports
> > system in 99% of the use cases)
+1
> > What date did we have in mind for 0.12? I sincerely doubt we want to have as
> > long a wait as we had for 0.11.
As we've discussed recently, I think we should be aiming for a 6
month-ish cycle.
To that end perhaps we should be sticking to one, two, maybe three
"significant" improvements, as well as the usual bug-fixes.
--
Evolution: Taking care of those too stupid to take care of themselves.
Jeroen Ruigrok van der Werven
* Basic support for multiple projects (TracMultipleProjects/SingleEnvironment)
>
>This is long overdue and still one of the most requested features.
>However, we don't want to do a half-arsed job so we should *really*
>*really* think about what we're going to do and how. This could also
>break a lot of plugins and we've already done that for 0.11 so it might
>be an idea to hold off on this for a while.
Mmm, you could argue it two ways unfortunately.
From what I understand from Noah we have a page detailing what changes needed
to be made for the plugins. Odd Simon pointed me towards the direction of
http://trac.edgewall.org/wiki/TracDev/ApiChanges/0.11 So that would take away
most of the pain. I do not think there's much escaping maintaining separate
versions of plugins currently. The quicker we get the multiple projects code
done the sooner we can leave the 'instability' behind. Otherwise the soonest
we will support multiple projects will be around early 2009. (Right now a
feature voting feature sounds nice. ;))
At work we are currently using Jira since we needed multiple project support.
Jira's way of dealing with this is not bad from my first impressions.
I'd say +1 for multiple projects in 0.12.
* Better user/session system
o Optional form-based login
Should I see this as a page before the entire Trac installation that requires
you to authenticate before you can proceed?
If so, that should not be too much work. +1
o Pluggable user-directory provider (#2456)
To summarize: LDAP and like-wise directory backends. Quite nice to have
indeed. This would make deploying Trac in Windows environments with AD even
more easier. (Unless I of course misunderstood the ticket.)
Currently I am indifferent to it, +0.
o Nicer CC-list / "ticket monitoring" (#1459)
Indeed, +1.
I guess it will boil down to: only authenticated users can add themselves to
the cc: list. Otherwise I would see no solution to solve the anyone can edit
the field problem.
* Improved ticket query system (so that it can be used instead of SQL reports
system in 99% of the use cases)
I remember that at one point we had the desire to deprecate /report and use
/query instead. Is this related to making that move, finally?
Right now I am at +0 for it. It is needed, yes, but it is not teethgrinding
bad right now that would make it a high priority target for 0.12.
>As we've discussed recently, I think we should be aiming for a 6
>month-ish cycle.
>
>To that end perhaps we should be sticking to one, two, maybe three
>"significant" improvements, as well as the usual bug-fixes.
I agree. We need to focus on a few things. I will be clearer towards
everybody. I think it will also limit the source code churn that got 0.11 in
trouble.
* Enhanced underlying data model
If we decide to do multiple projects for 0.12 we will tackle this at the same
time. So I would say +1 for 0.12.
* Vastly improved versioncontrol subsystem
Looking at this work it seems that it is worthwhile to have support for
multiple projects in place first, using Subversion as our base. And from there
we can make the next version of Trac (0.13 or 0.20 or so) target refactoring
the version control backend. To me that seems like a more logical step from an
architectural point of view.
I'd be -1 for 0.12.
* Wiki Engine refactoring
-1 for 0.12.
* Improved notification architecture
Not sure right now what I think of this.
* Improved API for request handlers
Seems to be tied in with 'Vastly improved versioncontrol subsystem', so -1.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
Things are not what they seem; Nor are they otherwise...
Christopher Allan Webber
multiple projects bit. It's the thing most lacking from Trac for
us...
Noah Kantrowitz
Jeroen Ruigrok van der Werven wrote:
> Given how Christian is coordinating 0.11's release now can we already discuss
> the focus for 0.12 a bit?
>
> What I see on the roadmap seems a bit excessive in terms of planning a new
> release (notes inline are mine, comments from others very much welcomed to get
> an idea of the scope):
>
> * Enhanced underlying data model (GenericTrac)
>
-INT_MAX, not in 0.12 or ever until someone convinces me this is
possible while not making things far too complex.
> * Basic support for multiple projects (TracMultipleProjects/SingleEnvironment)
>
-1. I think we should come up with some recipes to handle this better,
maybe adding a custom "project" field and some example reports. Full
support is going to need more time than 0.12 should take.
> * Vastly improved versioncontrol subsystem (see VcRefactoring)
>
+0 don't know what needs doing.
> * Wiki Engine refactoring (WikiEngine)
>
-0 if it is ready in time, sure. Don't think we should delay for it though.
> * Better user/session system
> o Optional form-based login
>
-1, AccountManager does a good job of this already.
> o Pluggable user-directory provider (#2456)
>
+0. Nice to have, shouldn't block.
> o Nicer CC-list / "ticket monitoring" (#1459)
>
-1. Too many possible permutation of this I think. I would rather see it
handled by plugins for a while, if it becomes clear that one approach is
liked much more, then discuss integration.
> * Improved notification architecture (TracDev/Proposals/Journaling, #1890)
>
+1. This whole system needs to be revamped.
> * Improved ticket query system (so that it can be used instead of SQL reports
> system in 99% of the use cases)
>
-1. I am all for adding a bit more (like support for OR), but I would
rather keep queries simple and move reports into an external plugin to
be installed if the users need more control.
> * Improved API for request handlers (see sandbox/controller and the newer
> VcRefactoring/Controller)
>
-0 unfamiliar with these branches. Doesn't sound like it should be a
blocker.
> * Internationalization
>
+10. I think this will be a good flagship feature for 0.12, and much
work has already been done.
> Most of the internationalization framework is already in place in the i18n
> sandbox and kept up to date with trunk. I'm working on setting up something
> like Pootle locally to get an idea of the current translation coverage.
>
> * Better help/documentation system (#2656)
>
-0. I still don't see why people dislike this so much. Namespace-ish
support for the wiki seems like a good solution if someone wants to find
a nice way to do it.
--Noah
Samuel Vandamme
+ 1
...well, I'm no Trac developer but as a user I'm going to +1 the
multiple projects bit. It's the thing most lacking from Trac for
us...
> Jeroen Ruigrok van der Werven <asmodai(-at-)in- nomine.org> / asmodai
> イェルーン ラウフロック ヴァン デル ウェルヴェン
> http://www.in-nomine.org/ | http://www.rangaku.org/
> Things are not what they seem; Nor are they otherwise...
>
>
--
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door MailScanner en lijkt schoon te zijn.
--
Met vriendelijke groeten
Vandamme Samuel
http://www.sava.be
Christopher Lenz
> Given how Christian is coordinating 0.11's release now can we
> already discuss
> the focus for 0.12 a bit?
>
> What I see on the roadmap seems a bit excessive in terms of planning
> a new
> release (notes inline are mine, comments from others very much
> welcomed to get
> an idea of the scope):
"Excessive" indeed. This kind of milestone planning should really be
going on on this list rather than on the milestone pages. I hadn't
realized what the current milestone items were until you started this
thread…
> * Enhanced underlying data model (GenericTrac)
-1. There isn't even consensus on whether that's a viable direction.
(Personally, I'm not a fan.)
> * Basic support for multiple projects (TracMultipleProjects/
> SingleEnvironment)
-1. Multiple project support has been on the list for Trac2 since day
one. We should try to get the 1.0 line in solid shape sooner rather
than later, and use that as a basis for moving towards multiple
projects. Not move multi-project to 0.x because we can't even get 1.x
shipped.
> * Vastly improved versioncontrol subsystem (see VcRefactoring)
-0. I'd prefer to see this limited in scope, the proposal is very
broad as is.
> * Wiki Engine refactoring (WikiEngine)
+1. This refactoring is needed for getting the wiki content into the
genshi output system in a clean way. We currently employ rather ugly
hacks to make it work (for example when it comes to white-space/line-
break preserving blocks). If that hasn't changed since I last looked,
that is.
> * Better user/session system
> o Optional form-based login
> o Pluggable user-directory provider (#2456)
> o Nicer CC-list / "ticket monitoring" (#1459)
> * Improved notification architecture (TracDev/Proposals/Journaling,
> #1890)
-1. This proposal rubs me the wrong way, rather similar to
GenericTrac. I also don't see a clear/strong benefit in this change.
> * Improved ticket query system (so that it can be used instead of
> SQL reports
> system in 99% of the use cases)
+1. I'd really like to make the query system the default for "View
Tickets" for 0.12, and it'd be nice if the query system was more
powerful, supporting things like date-based queries.
> * Improved API for request handlers (see sandbox/controller and the
> newer
> VcRefactoring/Controller)
-0. This could easily be postponed, and I'm not convinced of either my
own old proposal or Christian's.
> * Internationalization
>
> Most of the internationalization framework is already in place in
> the i18n
> sandbox and kept up to date with trunk. I'm working on setting up
> something
> like Pootle locally to get an idea of the current translation
> coverage.
+1. I18n will need more work on both Genshi and Babel, but in general
it's rather far along, and would be possible to release in the 0.12
timeframe even if not 100% complete.
> * Better help/documentation system (#2656)
+1. Personally, I think this one is desperately needed. Let's stop
polluting the wiki of every Trac-using project with documentation, and
implement a proper, scalable solution, which also allows plugins to
add help-style documentation.
> Eventually:
>
> * Migrate to SQLAlchemy for database interfacing and connection
> pooling (see
> sandbox/sqlalchemy)
>
> Wouldn't this be a better target for 0.13? Given how SQLAlchemy is
> currently
> revamping a lot of its internals and the SQLAlchemy branch has been
> dormant
> for a long while it seems a bit difficult to correctly shove this
> inside
> Trac at this point in time.
-0. It'd be awesome if we could get rid of the Trac connection pooling
code by using SA, but otherwise unless someone picks up this branch
pretty darn soon, it should not be on the table for 0.12.
> What date did we have in mind for 0.12? I sincerely doubt we want to
> have as
> long a wait as we had for 0.11.
Depends on when 0.11 is released, and on this thread and related
discussions in the future. I don't think anyone actually thinks that
this kind of release cycle is a good idea. We just need to agree on
limiting the scope, and find a consensus on the subset to limit it to.
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Christopher Lenz
Am 21.11.2007 um 22:42 schrieb Christopher Lenz:
>> * Better user/session system
>> o Optional form-based login
>> o Pluggable user-directory provider (#2456)
>> o Nicer CC-list / "ticket monitoring" (#1459)
We should look into the user-directory thing, there have been multiple
patches, and the later ones look rather good AFAICT.
For form-based login, AccountManager seems to be working okay for now.
About an all-new CC mechanism, I'm all for it, but haven't seen enough
substance in proposals so far as to believe it's a realistic goal for
0.12. In my opinion, the whole notification/monitoring needs to a
proper rethinking pretty much from the ground up.
Thomas Moschny
> * Vastly improved versioncontrol subsystem (see VcRefactoring)
Naturally [*], I am +1 for this. While the majority of people use trac
together with subversion repositories, importance of other version control
systems increases. I don't think support for those should be postponed after
a 1.0 release.
Main points are:
- better support for vc systems with dag-like revision and file history
- support for vc neutral cache
Support for multiple repositories seems like an orthogonal and
not-that-important enhancement to me.
Regards,
Thomas
[*] being the author of a (somewhat prototypical) vc backend for Monotone.
--
Thomas Moschny <thomas....@gmx.de>
Jani Tiainen
> Am 21.11.2007 um 16:42 schrieb Jeroen Ruigrok van der Werven:
>> Given how Christian is coordinating 0.11's release now can we
>> already discuss
>> the focus for 0.12 a bit?
>>
>> What I see on the roadmap seems a bit excessive in terms of planning
>> a new
>> release (notes inline are mine, comments from others very much
>> welcomed to get
>> an idea of the scope):
>
> "Excessive" indeed. This kind of milestone planning should really be
> going on on this list rather than on the milestone pages. I hadn't
> realized what the current milestone items were until you started this
> thread…
>
>> * Enhanced underlying data model (GenericTrac)
>
> -1. There isn't even consensus on whether that's a viable direction.
> (Personally, I'm not a fan.)
I feel same. Trac is quite highly specialized to do certain things, and
it does it pretty well. I don't see point to push "generic". Rather I
would see usage of some ORM (Alchemy) but as said somwhere there has
>> * Basic support for multiple projects (TracMultipleProjects/
>> SingleEnvironment)
>
> -1. Multiple project support has been on the list for Trac2 since day
> one. We should try to get the 1.0 line in solid shape sooner rather
> than later, and use that as a basis for moving towards multiple
> projects. Not move multi-project to 0.x because we can't even get 1.x
> shipped.
I think it's ticket #130 in t.e.o and last time I checked it was still
on list for 1.0 not for 2.0. I might be wrong though.
This is two sided thing. It has very high demand and thus people are
finding a ways to overcome this - even plugins. There lies danger that
someone succeeds to make widely accepted solution by community.
>> * Vastly improved versioncontrol subsystem (see VcRefactoring)
>
> -0. I'd prefer to see this limited in scope, the proposal is very
> broad as is.
Very broad and seems to be concentrating to fix problems with Mercurial...
Also wonder how upcoming 1.5 merge changes tracking would affect Trac
SCM backend(s)...
>> * Better user/session system
>> o Optional form-based login
>> o Pluggable user-directory provider (#2456)
>> o Nicer CC-list / "ticket monitoring" (#1459)
>> * Improved notification architecture (TracDev/Proposals/Journaling,
>> #1890)
>
> -1. This proposal rubs me the wrong way, rather similar to
> GenericTrac. I also don't see a clear/strong benefit in this change.
Well few points: I'm using AD to authenticate my users, I have e-mails
etc. in AD (ldap that is)
There is no way to push that existing information to Trac. I had to do
rather ugly SQL scripts to import e-mail data to make "assign-to" field
as dropdown. And since there is no generic user data repository, I had
to repeat that action for all my 50+ projects. Now when new developer
steps in someone need to reproduce steps by hand.
CC-list is well.. A list. It works but it causes enormous change noise,
it's error prone (it's easy to delete someone other email from that too)
and hard to edit if list grows as has happened to some tickets in t.e.o.
I would see this being user property (Ticket/Wiki I want to follow)
rather than ticket property.
>> * Improved ticket query system (so that it can be used instead of
>> SQL reports
>> system in 99% of the use cases)
>
> +1. I'd really like to make the query system the default for "View
> Tickets" for 0.12, and it'd be nice if the query system was more
> powerful, supporting things like date-based queries.
+1 And multiple groups and such. Specially if SA implementation takes
place this might come more feasible/important thing..?
>> * Internationalization
>>
>> Most of the internationalization framework is already in place in
>> the i18n
>> sandbox and kept up to date with trunk. I'm working on setting up
>> something
>> like Pootle locally to get an idea of the current translation
>> coverage.
>
> +1. I18n will need more work on both Genshi and Babel, but in general
> it's rather far along, and would be possible to release in the 0.12
> timeframe even if not 100% complete.
+1, of course Depends on timeframe... :)
>> * Better help/documentation system (#2656)
>
> +1. Personally, I think this one is desperately needed. Let's stop
> polluting the wiki of every Trac-using project with documentation, and
> implement a proper, scalable solution, which also allows plugins to
> add help-style documentation.
+1, this is something that bothers me too. Specially when you upgrade
Trac all upgraded help information is not visible if you don't
explicitly upgrade your wiki, which is IMO very bad option.
>> Eventually:
>>
>> * Migrate to SQLAlchemy for database interfacing and connection
>> pooling (see
>> sandbox/sqlalchemy)
>>
>> Wouldn't this be a better target for 0.13? Given how SQLAlchemy is
>> currently
>> revamping a lot of its internals and the SQLAlchemy branch has been
>> dormant
>> for a long while it seems a bit difficult to correctly shove this
>> inside
>> Trac at this point in time.
>
> -0. It'd be awesome if we could get rid of the Trac connection pooling
> code by using SA, but otherwise unless someone picks up this branch
> pretty darn soon, it should not be on the table for 0.12.
+1 This is something I have some personal interest and maybe some extra
spare-time to work on. It should also enable me to use my favourite DB
backend - Oracle :)
>> What date did we have in mind for 0.12? I sincerely doubt we want to
>> have as
>> long a wait as we had for 0.11.
>
> Depends on when 0.11 is released, and on this thread and related
> discussions in the future. I don't think anyone actually thinks that
> this kind of release cycle is a good idea. We just need to agree on
> limiting the scope, and find a consensus on the subset to limit it to.
I think that way too. Well it could so that there is intention to
release new versions about every 6 months, so feature set won't grow too
large. I rather would see that each release would contain few key
features not any gigantic blob. Being for example only i18n for 0.13. I
don't see point to restrict releases to any certain time frame. At least
upto version 1.0 which in theory is considered to be "stable" release
cycles can be very short if needed.
--
Jani Tiainen
Christian Boos
I apologize for the somewhat longish mail, even if I tried my best to
stay concise, that didn't work out so well, as I had plenty of things to
say :-)
Christopher Lenz wrote:
> Am 21.11.2007 um 16:42 schrieb Jeroen Ruigrok van der Werven:
>
>> Given how Christian is coordinating 0.11's release now can we
>> already discuss the focus for 0.12 a bit?
>>
>> What I see on the roadmap seems a bit excessive in terms of planning
>> a new
>> release (notes inline are mine, comments from others very much
>> welcomed to get
>> an idea of the scope):
>>
>
> "Excessive" indeed. This kind of milestone planning should really be
> going on on this list rather than on the milestone pages. I hadn't
> realized what the current milestone items were until you started this
> thread…
>
I propose to move all those topics to 1.0, then selectively move them
back either to 0.12, 0.13 or forward to 1.1, 2.0, as some consensus or
progress emerges.
But that feature list is only partial, here are some additional topics
I'd like to introduce:
* improve the rendering layer: currently, the infrastructure for
rendering is split between the trac.mimeview package and the trac.web
package. There really need to be some clean-up on both sides, targeting
the removal of all rendering related functionality located on the
Request object itself on one side, reviving the #3332 patch on the other
side. I think this is a natural follow-up to 0.11 and seems better done
sooner than later, so I think it should be done for 0.12.
* go on with the fine-grained permissions work:
- the browser svn_authz should be transformed into a permission
policy (maybe even a 0.11.x thing, as this will be transparent to the user)
- the permission checks could be performed also in the data model layer
- fix the implementation of group providers, as outlined in the
"[RFC] get_user_groups" thread
* improve the search feature: I'm not talking about that grand redesign
that keep being postponed, just about some incremental improvements that
have a very good benefit/effort ratio:
- sorting by relevance in addition to sorting by date,
- "send ticket matches to custom query" feature.
The code is mostly there, it just needs to be adapted to the same
style as the one of the latest timeline-refactoring.
Then, there's the very important topic of all the known tickets already
scheduled for 0.10.x and 0.11.x maintenance lines.
That is a really /huge/ amount of work there:
- there are still *80* open tickets for 0.10, some of them quite
critical. We should g through that list and retarget some of those to
0.11.x and 0.12, as I don't think they'll ever get fixed on the 0.10.x
line at this point.
- there are already *192* tickets for 0.11.1 tickets. Last week, I made
a copy of that list and annotated it with a more realistic estimate,
planning to move most of them to 0.12 and beyond.
- among the 130 un-triaged tickets, a good deal of them are probably
worth addressing as well.
Some of those bugs are just little things, some are indicative of deeper
issues that would probably benefit from a more radical approach for
fixing them. Take for example all the issues related to database
backends. Would a move to SQLAlchemy be a radical progress for fixing
all the issues we're seeing? If so, the time invested in that area seems
to be worth it. But of course it might as well introduce other
unexpected issues. Only an actual experiment could really tell (as I was
writing those lines, I saw that asmodai just restarted a sandbox for
that - very good). Another example is the wiki engine refactoring - lots
of benefits in one go, if done well.
>> * Enhanced underlying data model (GenericTrac)
>>
>
> -1. There isn't even consensus on whether that's a viable direction.
> (Personally, I'm not a fan.)
>
The "generic" Trac proposal is partly there to address known problems
and simplify the current code, partly for enabling (lots) of new
features. I certainly did a poor job so far at explaining what I have in
mind there and maybe the "generic" term was badly chosen, as I don't
want to "uniformize" the Trac interface, only rationalize what we
currently have and make that infrastructure more reusable. A better
image of what I'm aiming at is a "versioncontrol API" for the resources.
I'll try to explain it better next time, with some supportive code. I
don't want necessarily to make this a 0.12 thing, though, as there are
plenty of other things to do...
>> * Basic support for multiple projects (TracMultipleProjects/
>> SingleEnvironment)
>>
>
> -1. Multiple project support has been on the list for Trac2 since day
> one. We should try to get the 1.0 line in solid shape sooner rather
> than later, and use that as a basis for moving towards multiple
> projects. Not move multi-project to 0.x because we can't even get 1.x
> shipped.
Well, I have another point of view on this. For one, I think I see how
to implement this on top of the data model refactoring. Plus it's a very
highly anticipated feature, and most people will certainly be
disappointed if we ship a 1.0 release without support for multiple
projects. Also, when I said "Basic support for multiple project", I was
thinking about the minimal infrastructure needed to have project
specific data in the same db, accessing the different Trac projects in
the same way as we currently access different Trac environments. The
only connections between them would be InterTrac links. On top of that,
as a /second/ step, it would be possible to add more features like a
project summary module, a project directory, a common timeline and
search, etc. Again, I'll favor doing some incremental steps that we can
do relatively soon rather than a grand big design that'll never happen
(remember we've been talking about that for 4 years... I don't want this
to that takes another 4 years).
>> * Vastly improved versioncontrol subsystem (see VcRefactoring)
>>
>
> -0. I'd prefer to see this limited in scope, the proposal is very
> broad as is.
>
Yes, broad and quite vague at this point, I admit. There is a lot of
design work left to be done there. This is something that slipped from
0.11 to 0.12 and is probably going to have to wait a bit longer. But
this is also something that I consider to be parallel development, as it
doesn't require anything to be done in Trac core (well, besides that
little generic trac thing that would allow me to implement a repository
resource more easily) and it doesn't block anything to happen in Trac core.
>> * Wiki Engine refactoring (WikiEngine)
>>
>
> +1. This refactoring is needed for getting the wiki content into the
> genshi output system in a clean way. We currently employ rather ugly
> hacks to make it work (for example when it comes to white-space/line-
> break preserving blocks). If that hasn't changed since I last looked,
> that is.
>
+1 of course. This is something I definitely would like to put my
principal efforts for 0.12.
>> * Improved notification architecture (TracDev/Proposals/Journaling,
>> #1890)
>>
>
> -1. This proposal rubs me the wrong way, rather similar to
> GenericTrac. I also don't see a clear/strong benefit in this change.
>
No worries here, this is also something I'm not satisfied with. For the
journaling part, there's probably something simpler to do so that we can
invalidate the various caches when needed (a bit similar to the env
reloading after an .ini change, we just have to find the appropriate
trigger). For fixing #1890, this is more related to the generic trac
proposal and having changesets for resources.
>> * Improved ticket query system (so that it can be used instead of
>> SQL reports
>> system in 99% of the use cases)
>>
>
> +1. I'd really like to make the query system the default for "View
> Tickets" for 0.12, and it'd be nice if the query system was more
> powerful, supporting things like date-based queries.
>
+1 as well, those are minor improvements.
Besides, I'd also very much welcome coderanger to go on with his ninja
branch, as this could also well be /the/ killer feature for 0.12 ...
>
>> * Improved API for request handlers (see sandbox/controller and the
>> newer
>> VcRefactoring/Controller)
>>
>
> -0. This could easily be postponed, and I'm not convinced of either my
> own old proposal or Christian's.
>
+0, that can be post-poned, but there are some parts of it that can be
done during the rendering refactoring, like building up the chrome data
independently of the Request object.
>> * Internationalization
>>
>> Most of the internationalization framework is already in place in
>> the i18n
>> sandbox and kept up to date with trunk. I'm working on setting up
>> something
>> like Pootle locally to get an idea of the current translation
>> coverage.
>>
>
> +1. I18n will need more work on both Genshi and Babel, but in general
> it's rather far along, and would be possible to release in the 0.12
> timeframe even if not 100% complete.
>
+0. If this can be done for 0.12, all the better, but that shouldn't
block a 0.12 release.
>> * Better help/documentation system (#2656)
>>
>
> +1. Personally, I think this one is desperately needed. Let's stop
> polluting the wiki of every Trac-using project with documentation, and
> implement a proper, scalable solution, which also allows plugins to
> add help-style documentation.
>
+1, I'm interested to see that happen as well. Not a blocker feature either.
>> Eventually:
>>
>> * Migrate to SQLAlchemy for database interfacing and connection
>> pooling (see
>> sandbox/sqlalchemy)
>>
>> Wouldn't this be a better target for 0.13? Given how SQLAlchemy is
>> currently
>> revamping a lot of its internals and the SQLAlchemy branch has been
>> dormant
>> for a long while it seems a bit difficult to correctly shove this
>> inside
>> Trac at this point in time.
>>
>
> -0. It'd be awesome if we could get rid of the Trac connection pooling
> code by using SA, but otherwise unless someone picks up this branch
> pretty darn soon, it should not be on the table for 0.12.
>
+1. As I said above, if this can improve things, I'm all for it.
>> What date did we have in mind for 0.12? I sincerely doubt we want to
>> have as
>> long a wait as we had for 0.11.
>>
>
> Depends on when 0.11 is released, and on this thread and related
> discussions in the future. I don't think anyone actually thinks that
> this kind of release cycle is a good idea. We just need to agree on
> limiting the scope, and find a consensus on the subset to limit it to.
>
So here's a summary of the future steps as I see them.
Main features for Trac 0.12:
- rendering refactoring (cboos, cmlenz?)
- wiki engine refactoring (cboos)
- SQLAlchemy, if it proves to be successful (jruigrok, cboos)
- i18n, even partially (cmlenz, jruigrok)
Secondary features for Trac 0.12:
- minor improvements for the search (cboos)
- enhancements to the query (cboos)
- fine-grained permissions improvements (cboos)
- better help/documentation system (cmlenz?)
I have no problem in splitting the above feature list in two (0.12/0.13)
if it becomes clear that it can't be achieved in, say, a 6 months time
frame.
The developer lists above are open, it's just indicative of the people
that I know will (eventually?) contribute to the feature. Feel free to
enlist yourself or remove the question mark ;-)
Later steps (beyond or started parallel to 0.12):
- data model refactoring (cboos)
- multi-project support (cboos)
- multi-repository support and support for DAG-based vc backends (cboos)
- advanced search (aat?)
- alien technology (jonas?)
There would also be lots of other things to discuss relative to the way
we could improve the development process of Trac: what ticket workflow
should we use on t.e.o, do we need to restructure the components and
keep/discard component owners, do we split sub-systems like
versioncontrol refactoring into a plugin, bundle "blessed" plugins like
trac-ini, account mgr, svn and mercurial plugin, etc.
But that mail is already too long, so let's keep those topics for later ;-)
-- Christian
Jeroen Ruigrok van der Werven
>Take for example all the issues related to database backends. Would a move to
>SQLAlchemy be a radical progress for fixing all the issues we're seeing?
Next to the i18n work I'm doing SA work on the sandbox/sqlalchemy-ng branch. I
took mgood's (I think he was the main instigator?) diff and applied it to
trunk. I am now in the process of converting the other queries.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
Anything becomes possible, after you find the courage to admit that
nothing is certain.
Christian Boos
Jani Tiainen wrote:
> Christopher Lenz kirjoitti:
>
>> Am 21.11.2007 um 16:42 schrieb Jeroen Ruigrok van der Werven:
>>
>>> * Enhanced underlying data model (GenericTrac)
>>>
>> -1. There isn't even consensus on whether that's a viable direction.
>> (Personally, I'm not a fan.)
>>
>
> I feel same. Trac is quite highly specialized to do certain things, and
> it does it pretty well. I don't see point to push "generic". Rather I
> would see usage of some ORM (Alchemy) but as said somwhere there has
>
I think there's a misconception coming from the term "generic", here.
That proposal has nothing to do about making Trac look and behave the
same for every resource it handles. It doesn't even necessarily imply
that all the data models have to follow the same structure.
The idea here is more fixing the (many) shortcomings of the current data
model, and by doing that, take benefit of the potential reuse
opportunities (+ introduce a project field, "en passant").
Think about the data model for attachment: there's no reason attachment
data has to be hard-wired into the ticket data model or the wiki data
model. The fact that the attachment data model was rather "generic" (by
containing a "realm" field) made it independent of a specific resource
and it was possible at a little cost to reuse the attachment
functionality in more modules than the wiki and ticket modules, like I
did for the milestone module in 0.11 or like osimons did for his
fullblog plugin.
Now the same can be said for the ticket comments. Currently, the way
ticket comment information is stored (or any ticket change information
for that matter) is 1/ rather messy, 2/ can't be reused for other
modules. Having a more "changeset oriented" way of storing the ticket
changes would greatly simplify the ticket module code. I think that
there are ways to have the comments stored independently, in a way
similar to the attachments (messages, like in Roundup?), and that will
make it possible to have comments on other resources as well. This does
*not* at all mean that having the possibility to comment on wiki pages
will make them look like a ticket. Not at all. For example, it could
take the form of a discussion page, like with mediawiki, only more
structured. Same for changeset commenting, it could take any form that
seems the best adapted for code review tasks.
Having some sort of common API inspired by the versioncontrol API for
dealing with the resource content will be very useful to provide the
possibility to look at the history of changes (or diffs or annotation of
content, cf. wiki blame) for any resources. This could be done for wiki
pages since the beginning and since 0.11 for tickets. But doing that for
e.g. milestone changes is simply impossible with the current data model.
This is particularly important I believe in every project where it's
important to have full audit abilities on every change made in the
system, or just out of curiosity (like in "who the hell did add all
those features to the 0.12 milestone" ;-) ).
So please, don't make any hasty judgment on this topic, and believe me
when I say there's /plenty/ of room for possible improvements to the
current data model, as I know its quirks quite well...
Finally, note that this data model refactoring discussion is mostly
orthogonal to the SQLAlchemy proposal. SQLAlchemy helps you to define
and access your data, it doesn't tell you or impose any constraint on
*what* the data model should be. So SA will work with the current model
as well as with any other. That being said, it probably won't hurt to be
more familiar with the strengths/weaknesses of SA before designing a new
data model.
>>> * Basic support for multiple projects (TracMultipleProjects/
>>> SingleEnvironment)
>>>
>> -1. Multiple project support has been on the list for Trac2 since day
>> one. We should try to get the 1.0 line in solid shape sooner rather
>> than later, and use that as a basis for moving towards multiple
>> projects. Not move multi-project to 0.x because we can't even get 1.x
>> shipped.
>>
>
> I think it's ticket #130 in t.e.o and last time I checked it was still
> on list for 1.0 not for 2.0. I might be wrong though.
>
> This is two sided thing. It has very high demand and thus people are
> finding a ways to overcome this - even plugins. There lies danger that
> someone succeeds to make widely accepted solution by community.
>
Well, I moved it to 1.0, in a way to acknowledge the pressing demand for
that major feature, as soon as I had a rather clear view about how to
implement it. Also, I don't see how plugins could do anything here. For
multiple project with different environment plugins can help, take
TracForge as an example. But certainly not for multiple project support
within a single environment, as support for that needs to be added to
every core module.
>
>>> * Vastly improved versioncontrol subsystem (see VcRefactoring)
>>>
>> -0. I'd prefer to see this limited in scope, the proposal is very
>> broad as is.
>>
>
> Very broad and seems to be concentrating to fix problems with Mercurial...
>
Mercurial, Git, Bazaar, Monotone, anything branch oriented.
> Also wonder how upcoming 1.5 merge changes tracking would affect Trac
> SCM backend(s)...
>
None at all. We don't support merge tracking, although svnmerge.py
support was on one of my TODO list (I've fortunately lost /that/ list).
>
>>> * Better user/session system
>>> o Optional form-based login
>>> o Pluggable user-directory provider (#2456)
>>> o Nicer CC-list / "ticket monitoring" (#1459)
>>> * Improved notification architecture (TracDev/Proposals/Journaling,
>>> #1890)
>>>
>> -1. This proposal rubs me the wrong way, rather similar to
>> GenericTrac. I also don't see a clear/strong benefit in this change.
>>
>
> Well few points: I'm using AD to authenticate my users, I have e-mails
> etc. in AD (ldap that is)
>
> There is no way to push that existing information to Trac. I had to do
> rather ugly SQL scripts to import e-mail data to make "assign-to" field
> as dropdown. And since there is no generic user data repository, I had
> to repeat that action for all my 50+ projects. Now when new developer
> steps in someone need to reproduce steps by hand.
>
Improvements on those aspects are worth considering for 0.12, if possible.
+0, as I don't feel like contributing lots in this area myself, besides
eventually fixing the IGroupProvider issue already mentioned.
> CC-list is well.. A list. It works but it causes enormous change noise,
> it's error prone (it's easy to delete someone other email from that too)
> and hard to edit if list grows as has happened to some tickets in t.e.o.
>
The "change noise" issue was fixed a while ago (on trunk), and the
"error prone" and "hard to edit" aspects are dealt with my latest patch
on the ticket. It's only a UI change though, the data model issues
remain unchanged.
> I would see this being user property (Ticket/Wiki I want to follow)
> rather than ticket property.
>
Yes, that's an idea as well. Did you realize that you just promoted some
"generic" Trac idea? (Ticket/Wiki I want to follow) ;-)
>>> * Better help/documentation system (#2656)
>>>
>> +1. Personally, I think this one is desperately needed. Let's stop
>> polluting the wiki of every Trac-using project with documentation, and
>> implement a proper, scalable solution, which also allows plugins to
>> add help-style documentation.
>>
>
> +1, this is something that bothers me too. Specially when you upgrade
> Trac all upgraded help information is not visible if you don't
> explicitly upgrade your wiki, which is IMO very bad option.
>
>
What do you suggest here, trigger a wiki upgrade automatically along a
normal upgrade?
I think it's probably better to leave a message reminding about this at
the end of an upgrade.
>>> Eventually:
>>>
>>> * Migrate to SQLAlchemy for database interfacing and connection
>>> pooling (see
>>> sandbox/sqlalchemy)
>>>
>>> Wouldn't this be a better target for 0.13? Given how SQLAlchemy is
>>> currently
>>> revamping a lot of its internals and the SQLAlchemy branch has been
>>> dormant
>>> for a long while it seems a bit difficult to correctly shove this
>>> inside
>>> Trac at this point in time.
>>>
>> -0. It'd be awesome if we could get rid of the Trac connection pooling
>> code by using SA, but otherwise unless someone picks up this branch
>> pretty darn soon, it should not be on the table for 0.12.
>>
>
> +1 This is something I have some personal interest and maybe some extra
> spare-time to work on. It should also enable me to use my favourite DB
> backend - Oracle :)
>
Great!
For Oracle, I'm a bit concerned how we will be able to handle text
fields of arbitrary length, but I'm looking forward to that as well.
>>> What date did we have in mind for 0.12? I sincerely doubt we want to
>>> have as
>>> long a wait as we had for 0.11.
>>>
>> Depends on when 0.11 is released, and on this thread and related
>> discussions in the future. I don't think anyone actually thinks that
>> this kind of release cycle is a good idea. We just need to agree on
>> limiting the scope, and find a consensus on the subset to limit it to.
>>
>
> I think that way too. Well it could so that there is intention to
> release new versions about every 6 months, so feature set won't grow too
> large. I rather would see that each release would contain few key
> features not any gigantic blob. Being for example only i18n for 0.13. I
> don't see point to restrict releases to any certain time frame. At least
> upto version 1.0 which in theory is considered to be "stable" release
> cycles can be very short if needed
Well, a too fast release cycle has its inconvenient as well. Ideally
we'd like to support as few line of developments as possible (e.g. drop
0.10.x support as soon as, say, 0.11.1 is out). I have the feeling that
a 6 months time frame is the minimum for enabling that.
-- Christian
Alec Thomas
> * go on with the fine-grained permissions work:
> - the browser svn_authz should be transformed into a permission
> policy (maybe even a 0.11.x thing, as this will be transparent to the user)
I always envisaged this being the case. It makes sense. However perhaps
we should wait until we move to the "next" stage of the permission
system? Then we can have a single policy that does everything. Perhaps
authz for all of Trac.
> - the permission checks could be performed also in the data model layer
We've discussed this quite a bit on IRC. Enforcing permissions at the
data layer seems a bit wrong for some reason, but it certainly offers
consistency as an advantage. Perhaps it wouldn't be too bad if you could
pass an optional perm object to the model object, or abstract it further
by adding a filtering system on top of models - views, effectively.
I'd be happy to look into this.
> - fix the implementation of group providers, as outlined in the
> "[RFC] get_user_groups" thread
> * improve the search feature: I'm not talking about that grand redesign
> that keep being postponed, just about some incremental improvements that
> have a very good benefit/effort ratio:
> - sorting by relevance in addition to sorting by date,
> - "send ticket matches to custom query" feature.
+1. I'd be happy to take a look at this.
> Then, there's the very important topic of all the known tickets already
> scheduled for 0.10.x and 0.11.x maintenance lines.
>
> That is a really /huge/ amount of work there:
> - there are still *80* open tickets for 0.10, some of them quite
> critical. We should g through that list and retarget some of those to
> 0.11.x and 0.12, as I don't think they'll ever get fixed on the 0.10.x
> line at this point.
> - there are already *192* tickets for 0.11.1 tickets. Last week, I made
> a copy of that list and annotated it with a more realistic estimate,
> planning to move most of them to 0.12 and beyond.
> - among the 130 un-triaged tickets, a good deal of them are probably
> worth addressing as well.
You're right, that's many, many tickets :(. I just had a quick look, and
the majority of them certainly warrant attention of some sort.
> So here's a summary of the future steps as I see them.
>
> Main features for Trac 0.12:
> - rendering refactoring (cboos, cmlenz?)
> - wiki engine refactoring (cboos)
> - SQLAlchemy, if it proves to be successful (jruigrok, cboos)
> - i18n, even partially (cmlenz, jruigrok)
>
> Later steps (beyond or started parallel to 0.12):
> - advanced search (aat?)
I'm absolutely still planning on this.
> - alien technology (jonas?)
+1!
osimons
On Nov 21, 4:42 pm, Jeroen Ruigrok van der Werven <asmo...@in-
> Given how Christian is coordinating 0.11's release now can we already discuss
> the focus for 0.12 a bit?
>
classes and supporting code - I don't see it getting more generic than
that. Reworking notifications would be a prime candidate for the
required supporting infrastructure, and I hope to be involved in that.
+1 on notification w/ supporting infrastructure.
> * Better user/session system
> o Optional form-based login
> o Pluggable user-directory provider (#2456)
> o Nicer CC-list / "ticket monitoring" (#1459)
better model for users and user data other than preferences. Taking
care not to entangle 'users' and 'notification' too tightly, but
useful to deal with in same release as they will demand much of each
other. Demanding use-cases makes for better solutions.
> * Basic support for multiple projects (TracMultipleProjects/SingleEnvironment)
issues just yet. AFAIK there is not even a consensus on what model(s)
of multiproject to support. That said, even though not building this
for the coming version, actually reaching a consensus on how to one
day do multiproject support should be on the to-do list. It would
provide much needed direction on this and other issues.
> * Better help/documentation system (#2656)
is my idea for a sandbox branch on this once 0.12 gets underway:
- move help pages to a /docs inside the egg, and install them as part
of the egg and keep them there on disk (docs follow active version),
structured to support versions for various languages.
- make all links for help into [help:] and req.href.help() links
- a default help implementation that knows how to a) ask implementors
for structured page lists for building a permanent help menu, and b)
hand off wiki content fetching, rendering and searching to modules
supporting the interface
- default implementation that ships with trac fetches from wiki if
page exists there, or else reads the source off disk instead. basic
idea: If you want a custom help page, then make it into a wiki page.
Could even be a switch, that unless enabled it reads from disk only.
Default install should only create WikiStart and a few supporting
pages for TitleIndex and so on.
- it would also allow each module to provide its own help pages to the
common help menu, and many larger plugins on trac-hacks could well
need a few help pages in the common Help menu.
- by doing help through an interface, others can make alternative
implementations based on InterTrac/Wiki, master-project-help-page-
fetching, or even ping coderanger on #trac and return the result :-)
As there are so many other possible tasks for 0.12, I've left
everything else out this time in order to focus on some larger issues
that are close to me. More to follow in coming discussions, no doubt.
:::simon
https://www.coderesort.com
David Abrahams
on Fri Nov 23 2007, Jani Tiainen <redetin-AT-gmail.com> wrote:
>>> * Basic support for multiple projects (TracMultipleProjects/
>>> SingleEnvironment)
>>
>> -1. Multiple project support has been on the list for Trac2 since day
>> one. We should try to get the 1.0 line in solid shape sooner rather
>> than later, and use that as a basis for moving towards multiple
>> projects. Not move multi-project to 0.x because we can't even get 1.x
>> shipped.
>
> I think it's ticket #130 in t.e.o and last time I checked it was still
> on list for 1.0 not for 2.0. I might be wrong though.
>
> This is two sided thing. It has very high demand and thus people are
> finding a ways to overcome this - even plugins.
It's a very important feature, I agree. But I think the best thing
you can do in the near term is to make the Trac framework
incrementally more friendly to such solutions.
> There lies danger that someone succeeds to make widely accepted
> solution by community.
I don't understand why that's viewed as a bad thing. If it happens,
you will have everything you need to know how to handle the problem in
the Trac core, and to improve on the accepted solution in all the ways
that only a core solution can. In the C++ standardization world we
aim (though we sometimes fail) to "standardize existing practice,"
with the goal that what goes in the standard is proven to be
conceptually accessible with useful semantics. Seems like a good idea
to take advantage of such an opportunity in Trac when it comes along.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
David Abrahams
on Wed Nov 21 2007, Thomas Moschny <thomas.moschny-AT-gmx.de> wrote:
>> * Vastly improved versioncontrol subsystem (see VcRefactoring)
>
> Naturally [*], I am +1 for this. While the majority of people use trac
> together with subversion repositories, importance of other version control
> systems increases. I don't think support for those should be postponed after
> a 1.0 release.
>
> Main points are:
> - better support for vc systems with dag-like revision and file history
That'll become even more important when SVN 1.5 comes out (it's
supposed to be imminent).
Christian Boos
> on Wed Nov 21 2007, Thomas Moschny <thomas.moschny-AT-gmx.de> wrote:
>
>
>>> * Vastly improved versioncontrol subsystem (see VcRefactoring)
>>>
>> Naturally [*], I am +1 for this. While the majority of people use trac
>> together with subversion repositories, importance of other version control
>> systems increases. I don't think support for those should be postponed after
>> a 1.0 release.
>>
>> Main points are:
>> - better support for vc systems with dag-like revision and file history
>>
>
> That'll become even more important when SVN 1.5 comes out (it's
> supposed to be imminent).
>
I think you're referring to the new merge tracking features of 1.5. By
following Subversion-devel, I can tell you that it's not even clear at
this point what kind of merge support should be expected in 1.5 and what
will be deferred to 1.6 or even later. Speaking from a Trac-centric
p.o.v. I would rather like to see memory, performance and stability
improvements (not to mention the new ctypes bindings!) instead of
limited merge features...
That being said, the support for the future Subversion merge tracking
features will probably be doable without the need for any big change in
the API. I think all we need are some special property renderers, much
like it's already done for e.g. the svn:externals in 0.11.
The changes needed for supporting fully the dag-like revision systems
are much more challenging, and that's why it's harder to assign a
milestone for those (#1492 - support for non-linear changeset sequences
for monotone-like VCS). Targeting 1.0 seems fair, it can always be put
back to an earlier milestone like 0.13 once the code is there. Deferring
it to 2.0 has this bad "blue sky" connotation, though it's probably in
this area that alien technology would be the most beneficial for us ;-)
The single small incremental API change I want to make for 0.12 at this
point is the one documented in #4900 (see
http://trac.edgewall.org/ticket/4900#comment:4).
As a side note, the support for merging in Subversion is probably best
found /outside/ of Subversion itself. Mercurial or Git can be used
locally to sync the changes from the t.e.o. trunk, merge the upstream
changesets in feature or bug fixes branches, and merge those branches
back to trunk, with full history if needed.
See for example [6177:6182], the implementation for div/span wiki
processors, which was developed in a mercurial clone of trunk and
maintained there as a patch queue until it was ready to push to t.e.o. A
similar workflow can probably be achieved with git, git-svn and
git-rebase as well.
-- Christian
Manuzhai
> The single small incremental API change I want to make for 0.12 at this
> point is the one documented in #4900 (see
> http://trac.edgewall.org/ticket/4900#comment:4).
We were just discussing this in IRC. I have been thinking about how to
move the Trac UI more towards making it sensibly support both
Subversion and Mercurial (and by extension, at least Bazaar and git).
I have some ideas about this that need some more fleshing out, I
think. Will see what I can do with the idea.
Cheers,
Manuzhai
rupert....@gmail.com
> Jeroen Ruigrok van der Werven wrote:
>
> > * Vastly improved versioncontrol subsystem (see VcRefactoring)
>
> Naturally [*], I am +1 for this. While the majority of people use trac
> together with subversion repositories, importance of other version control
down diffs, renames, tags, branches a lot, we would love to use it
with git / mercurial if it would be useable for multi-repository, with
admin interface for easy repository creating / branching ...
rupert.