On 05/15/2011 04:21 PM, Vincent van Ravesteijn wrote:
> In this mail I collect all topics that are under development in
> the current trunk.
>
> Some of the topics that are obvious and/or truly cosmetic will merge
> into 'trunk-stable' soon. The other topics will be tested in the
> 'development' branch for a while. Comments indicating that a topic
> has been tested or has been reviewed will speed up its promotion
> into trunk-stable.
>
> Below the topics that are current in 'development' you'll find some
> of the new experimental topics. When these are finished, they will
> get merged in 'development'.
>
It seems to me I must have missed something. Was a decision made (by
you, as 2.1 release manager) about the development model we are
following, how it will be managed, and where? If so, could you explain
it for me?

Are all these various branches collected somewhere, e.g., gitorious?

Note that many of these are already in branch.

> * rgheck/recalculate-citation-labels
>   - rgheck: Fix bug #7499. The problem here is that there was no way for the 
> inset to know that the
>
>   Is this related to the bibitem label mess ?
>
No, separate issue.

> * rgheck/update-local-layouts
>   - rgheck: Fix bug #7500: There is presently no way in the GUI to update 
> local layout to the curre
>
Trunk only.

> * rgheck/update-macros-fix
>   - rgheck: Initial work to fix bug involving embedded macros and XHTML 
> output.
>   - rgheck: Fix bug #7525: We need to make sure we have an up to date list of 
> macros before we try
>
>   This is probably only the beginning of the large updateMacros/updateBuffer 
> cleanup.
>
These two are just bug fixes. The first one got committed with the wrong
log message (due to dcommit's taking the message from the merge without
my changing it). Both are related to cloning. The first had to do with
our not recursing into complex macros except when doing the metrics. The
second has to do with a missing updateMacros() call. Both are in branch.

>   - rgheck: Start the clean up of the updateMacros() calls by moving the 
> necessary calls into the f
>
This really is cleanup, and there will be more of the same.

Richard

Reply via email to