Hi Ruediger,
Rüdiger Timm wrote:
That's a joke, isn't it?
From my point of view of course it has to be (according to your
numeration)
1.
4.
5.
2.
3.
Why would you copy additional stuff into binfilter? We did enormous
efforts to get that monster stripped, and you plan to blow it up
Hi Mathias,
Mathias Bauer wrote:
I think the problem is that you can't give a fixed order for 2,3 and 4.
This must be checked for every single case. Perhaps Kay should point
this out in the wiki.
I disagree here. Actually the right order is 2,3,4: 3 certainly comes
after two, as copying parts
Hi Heiner,
Jens-Heiner Rechtien wrote:
Thorsten Behrens wrote:
b) move _all_ modules below binfilter into that module, possibly after
stripping them to the necessary minimum. Build it once, and tuck it
into a safe place (comes close to a, but is smaller integrates
with OOo3).
Ruediger,
Rüdiger Timm wrote:
Sorry, now I see your other mails. Looks loke a mail server problem.
I saw the mails appearing in reverse order as well, did not expect you
to answer sooo fast :-)
Rüdiger
Kay
-
To
Hi Kay,
Kay Ramme - Sun Germany - Hamburg wrote:
FYI
Matthias Huetsch, Malte Timmermann, Michael Brauer and I recently had a
discussions regarding how to deal with binfilter in case of incompatible
changes of modules used by binfilter.
I am still wondering why nobody invited me to
Armin,
Armin Le Grand wrote:
I do, but what about the suggestion? Repeating here:
Comparing the costs spent up to now by all and that will be spent until
the goal is reached, i again have to suggest (as years ago) to do it
once, by one person and for the next public release. The resulting
Armin Le Grand wrote, On 02/07/07 11:40:
Freeze means: Add all still missing and urgently necessary C++
dependencies methodically: Link without the standard modules and add
missing code. Yes, this might take a while and is not easy but might
have been done by one person
Hi Rüdiger,
Rüdiger Timm wrote:
Armin Le Grand wrote:
[...]
I haven't read that restriction anywhere. Kays proposal was about any
incompatible change below binfilter.
It's not a restriction, it's logic. Why else should code be moved to
binfilter ATM? Kay is right because
Hi Malte and Kay,
i will also answer Kay's reply here, he was just asking for the amount
of work, too...
Malte Timmermann wrote:
I also prefer making binfilters completely independent from any other
OOo code.
Constrain is to keep it as small as possible.
It might be difficult to
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Rüdiger,
being late to the thread, and being the one who implicitly initiated
this ...
Why would you copy additional stuff into binfilter?
Because binfilter has a code base which lives several years in the past,
whilst the current code
Hi Rüdiger,
Thanks for the details. Yes, I totally understand your problem, I think.
But, what you did is what I proposed, not what was written here as
recipe. You first evaluated to adapt binfilter to the incompatible
changes. After spotting all the difficulties you searched for an
Mathias Bauer [EMAIL PROTECTED] writes:
As long as no must changes are due the only disadvantage of binfilter
in its current form is that it must be rebuilt sometimes. That's bearable.
That reads each time for almost everybody outside Sun. But OTOH, it
would prolly only shave off 3 minutes on
Jens-Heiner Rechtien [EMAIL PROTECTED] writes:
Thorsten Behrens wrote:
Hm - hard to estimate how many of those binary documents are still in
active use. And it would be interesting if they are kept just because
of laziness, or for good reasons (I clearly suspect the former).
Laziness is
Hi Rüdiger,
being late to the thread, and being the one who implicitly initiated
this ...
Why would you copy additional stuff into binfilter?
Because binfilter has a code base which lives several years in the past,
whilst the current code base moves forward constantly. At some point,
you
FYI
Matthias Huetsch, Malte Timmermann, Michael Brauer and I recently had a
discussions regarding how to deal with binfilter in case of incompatible
changes of modules used by binfilter.
We came up with the following recipe: For every request of an additional
module for / change of
Hi Kay,
Kay Ramme - Sun Germany - Hamburg schrieb:
We came up with the following recipe: For every request of an additional
module for / change of binfilter the following steps are to be tried in
the following order:
1. Check if the dependency could not be removed / avoided
Kay Ramme - Sun Germany - Hamburg wrote:
FYI
Matthias Huetsch, Malte Timmermann, Michael Brauer and I recently had a
discussions regarding how to deal with binfilter in case of incompatible
changes of modules used by binfilter.
We came up with the following recipe: For every request of an
On 2.2.2007, at 14:11, Rüdiger Timm wrote:
Kay Ramme - Sun Germany - Hamburg wrote:
FYI
Matthias Huetsch, Malte Timmermann, Michael Brauer and I recently
had a discussions regarding how to deal with binfilter in case of
incompatible changes of modules used by binfilter.
We came up with
On Fri, 2007-02-02 at 14:18 +0100, Pavel Janík wrote:
What about making binfilter SO only module? ;-)
-1
Unfortunately .sdw etc documents exist and are a fact of life, we do
still need to import them. e.g. my performance review still comes
in .sdw format, we wouldn't want to drop importing
Rüdiger Timm schrieb:
Kay Ramme - Sun Germany - Hamburg wrote:
FYI
Matthias Huetsch, Malte Timmermann, Michael Brauer and I recently had a
discussions regarding how to deal with binfilter in case of incompatible
changes of modules used by binfilter.
We came up with the following
Thorsten Behrens schrieb:
There are at least three possible ways to do this gracefully:
a) drop binfilter for the next major release, telling users to convert
their documents using OOo2.x. Can even implement a tiny filter
replacement, that says so in a message box.
IMHO OOo3.0 would
Thorsten Behrens wrote:
Caolan McNamara [EMAIL PROTECTED] writes:
On Fri, 2007-02-02 at 14:18 +0100, Pavel Janík wrote:
What about making binfilter SO only module? ;-)
-1
Unfortunately .sdw etc documents exist and are a fact of life, we do
still need to import them. e.g. my performance
Thorsten Behrens wrote:
Caolan McNamara [EMAIL PROTECTED] writes:
On Fri, 2007-02-02 at 14:18 +0100, Pavel Janík wrote:
What about making binfilter SO only module? ;-)
-1
Unfortunately .sdw etc documents exist and are a fact of life, we do
still need to import them. e.g. my performance
Rüdiger Timm schrieb:
binfilter isn't static. During the last months even more code has been
moved from f.e. sw into binfilter.
Yes. Because we discovered even more filters we don't want to maintain
anymore. :-)
I think the problem is that you can't give a fixed order for 2,3 and 4.
This
24 matches
Mail list logo
