bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrej Golcov <>
Subject Re: svn commit: r1455438 - in /incubator/bloodhound/branches/bep_0003_multiproduct: ./ bloodhound_theme/bhtheme/ bloodhound_theme/bhtheme/templates/ trac/ trac/trac/ trac/trac/tests/ trac/trac/ticket/ trac/trac/ticket/tests/ trac/trac/wiki/ trac/trac/wiki/...
Date Wed, 13 Mar 2013 10:43:26 GMT
The mail contains reply to the several mails from Olemis.

>>> incubator/bloodhound/branches/bep_0003_multiproduct/trac/trac/
>>> incubator/bloodhound/branches/bep_0003_multiproduct/trac/trac/tests/
>>> incubator/bloodhound/branches/bep_0003_multiproduct/trac/trac/tests/
>> [...]
>>> incubator/bloodhound/branches/bep_0003_multiproduct/trac/trac/ticket/tests/
>> [...]
>>> incubator/bloodhound/branches/bep_0003_multiproduct/trac/trac/wiki/tests/
>> @andrej : in theory all the changes applied to these files are in the
>> right place . Nevertheless from a practical
> ... PoV it seems to me that changes to files listed above might
> unnecessarily over-complicate vendor branch merging process .
> What d'u think ?
We have to find balance between merge simplicity and code quality.
Given that there is theoretical possibility to push changes to Trac
upstream, I would leave code as it is and change it later (if needed)
based on Trac community feedback.

>> PS: notice that this is about enhancements in and the
>> test suite . There is no hope in worrying too much when it comes to
>> other changes related to IResourceChangeListener behavior as those
>> seem to be too much entangled around other core features .
>> PS: PS: is there a patch already proposed to Trac upstream ?
My idea is to see how the new IResourceChangeListener will cover our
needs for bhsearch and than propose patch to Trac upstream.
In short, my suggestion is to stabilize our code, wait until release 6
or even 1.0 and than suggest changes to Trac.

>> +class ResourceToAttachmentChangeListenerAdapter(Component):
>> +    """
>> +    The class provides backward compatibility for components implementing
>> +    IAttachmentChangeListener interface.
>> +    """
> -1
> Move these into AttachmentModule itself , so that legacy notification
> will always be enabled if the module is enabled .
> PS: The same applies to all other backwards compatibility interface adapters .
Agree, that can potentially bring a backward incompatibility. I will
move this functionality back as it was before the patch. That will
also decrease number of changes and simplify future merges. The code
will be ugly but alas.

Cheers, Andrej

View raw message