On 10 May 2003, Robert Collins wrote:
> Potential benefits (not given by the separation, but enabled by it).
>
> * Decoupled releases for helpers. (Release updates when fixes occur).
Good.
> * Ditto for errors.
Not as sure about this.. almost all error page changes done during the
lifetime of Squid has been due to Squid changes. Only exception is when a
new translation is added in which case it is usually supplied by a
thirt-party.
> * Syncronised patch management - apply to helpers/HEAD and tag for 2.5
> and 3.0 syncronously.
Not sure this is actually wanted. As I said previously some kind of review
process is used for helper updates in STABLE, while for HEAD mostly
anything is allowed.
The review process for helper updates in STABLE is not as strict as for
the main Squid sources, but still is there.
> * Start making some of the monolithic package a little more modular: we
> could make the errors and helpers subprojects and have them built
> optionally. (Regarding the dependent libraries - they too could be split
> out)
This needs to be done before splitting into separate modules in my
opinion.
Splitting into modules before it is ensured the modules can live on their
own only increases the complexity with no benefits.
I do not see a big need of this. What is more needed is to allow for
independent helpers with their own configure etc in the structure,
allowing a separately maintained helper to be directly imported into a
Squid release, and reversedly to change helpers which deserves a life on
their own to be self contained allowing releases outside Squid.
As the amount of "library" code neede by the helpers is fairly minimal it
is OK to have this duplicated in the self-contained helpers in my opinion.
Regards
Henrik
Received on Sat May 10 2003 - 05:20:18 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:19:53 MST