On 6/28/07, Christian Boos <[EMAIL PROTECTED]> wrote:
>
> Hello manu, all,
>
> Emmanuel Blot wrote:
> > I'm afraid about the number of tickets scheduled for 0.11, not
> > mentioning the ever-growing number of tickets that are marked as
> > "tentative" for 0.11.
> >
>
> Ok, as all the other replies suggest, it seems like it's time to think
> about getting the release done, so I've moved the 0.11 tickets to
> 0.11.1, as you suggested.
>
> Now the problem as usual is deciding what really needs to go in 0.11 vs.
> 0.11.1, and which tickets to set back to 0.11.
> I've already put a "short list" up on
> http://trac.edgewall.org/wiki/TracDev/ToDo, which I've updated today.
> As you can see there, one of the main concern is about documentation.
>
> Among the few tickets I've already selected as important: #5572 (work in
> progress), #2048 (work started but not finished), #5025.
> If one moves back a ticket to 0.11, please either volunteer to fix it or
> make a strong case why it should be fixed for 0.11 as opposed to 0.11.1
> (or 0.10.5 ;-) ).
> Of course, new tickets for immediate problems found while testing the
> current trunk can still be scheduled for 0.11.
Taking a look at a couple of them:
#2048
| {{{
| ...
| }}}.urgent
-1...do we really need more Wiki syntax? My favourite of the options was:
[[div(class)]]
Some text
[[/div]]
[[span(class)]]Some text[[/span]]
or [[block]], [[inline]]. I think the main point is:
- Keep it simple and just let the user specify a class (they can add
the class styling in their site CSS)
- Use existing syntax: macros.
#4686
I personally think cloning is unnecessary clutter in stock Trac and
would be better implemented as a plugin. I suspect the percentage of
people who use this feature is a very small percentage of the user base.
#5010
I'm not really against it, I guess I'm just not sold on its usefulness
or its reliability. Can we guarantee that shutdown() is going to be
called with the correct arguments, or at all, in all cases? What about
when Apache is using a forking/non-threaded MPM? Does each forked
process get called with shutdown(None)?
#3833
Has reloading ever been solved reliably in a Python program? I've never
seen it, and particularly not in something as complex as Trac. What
about plugins that cache/store config values at startup? What about
plugins deactivated in the config but with active database connections
or open sockets, or whatever? Even if the component is disabled it's
still going to have resources that aren't cleaned up.
I think it would be spectacularly hard to do this reliably and we
shouldn't try.
I really suggest closing as wontfix.
> For the Trac API itself, there are a few big changes I'm working on that
> I think would be better to finish before 0.11. Of course, if I don't
> manage to finish them in the (2 or 3) coming weeks, they'll have to wait
> for 0.11.1 or later.
>
> Those changes are:
> 1) do the ResourceDescriptor / RenderingContext "split" of the Context.
+999
> 2) fix the refactored search API (in SearchRefactoring)
-0.5
I don't think search is that badly broken TBH, and this could easily
wait for 0.12 when we can "do it right" and give the search a thorough
redesign.
> 3) fix the timeline API along the same lines as 2.
This code is already in trunk, so I guess this is the best option.
> 2) was discussed on #IRC and the good suggestions I got there apply to
> the Timeline module as well. If I implement them, this will make the
> brand new 0.11 Timeline API obsolete (stillborn?), so if possible, it
> would be better to complete 3) before the 0.11 release. 2) can
> eventually wait for 0.11.1.
+1 on fixing 3) before 0.11, -1 on adding 2) to 0.11.1 - stable versions
are not for new features or API changes unless required, right?
> 1) should be doable in a way that stays compatible with the Context
> class introduced during the 0.11dev period, so it could also eventually
> wait for 0.11.1.
-1 on waiting. The Context stuff is one of the major warts in Trac at the moment
IMO, and I don't think the cleanup should wait.
-1 on maintaining compatibility with an in-development branch. I'd much
prefer to see the ResourceDescriptor / RenderingContext split done
cleanly before it makes it into a stable release.
> The stuff currently in FieldRefactoring can be merged right away, as for
> now it mainly consists of code cleanups plus a few useful enhancements
> (#449 and #5126). The main change planned there (introduction of a
> Property class) will be postponed.
I haven't looked at these changes at all TBH, how about Eli?
> Lastly, before making the release itself, t.e.o. itself should be
> upgraded to 0.11dev, and used for a few weeks as well.
+1 definitely. I'd do the same on TH but with the aforementioned API
changes, I have to do a lot of work porting plugins before this is
possible :(
> Before doing that, #5025 should be fixed (support for semi-automatic bug
+1 ... The best option for maintaining "backwards compatibility" seems
to be mapping the "old" field names to the new names inside the new
ticket request handler. I'm not convinced it's necessary for users
wanting to type the URL in (seems quite unlikely), but it's probable
that some macros, plugins etc. are using the old field names.
> report). Also, what about the TicketDelete plugin, has that been ported
> already?
IIRC Noah was waiting until there were "real" API exposed controls in
the ticket code, but I could be mistaken. However, this could now be
implemented server-side with the ITemplateStreamFilter, removing the JS
that adds the buttons.
--
Evolution: Taking care of those too stupid to take care of themselves.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
