[discussion] refactoring OpenOffice

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[discussion] refactoring OpenOffice

Peter Kovacs-3
Hello all,


I am really annoyed by the Code. I see repentance and to me a code
concept is totally lacking.

What I would like to do is a general cleanup / refactoring pass.

I would like to start with similar features and move them together in
the same module, maybe even merge them.

As a process I suggest I post a mail with [refactor] in the subject. The
Mail will contain what will be moved merged, I collect all references in
the mail.

If there is no objection within 3+ days I conduct the move. (+ because I
need to find time to move and test the change.)


Is this a process feasible?


All the Best

Peter




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] refactoring OpenOffice

Marcus (OOo)
Am 01.03.19 um 20:05 schrieb Peter Kovacs:

> I am really annoyed by the Code. I see repentance and to me a code
> concept is totally lacking.
>
> What I would like to do is a general cleanup / refactoring pass.
>
> I would like to start with similar features and move them together in
> the same module, maybe even merge them.
>
> As a process I suggest I post a mail with [refactor] in the subject. The
> Mail will contain what will be moved merged, I collect all references in
> the mail.
>
> If there is no objection within 3+ days I conduct the move. (+ because I
> need to find time to move and test the change.)
>
> Is this a process feasible?

depends on how many time you want to invest and how many developers are
with you. I've always understood that you haven't much time for
developing. ;-)

But in any case I strongly recommend not to merge back to trunk any code
that hasn't seen very detailed testing.

When you have code that you don't know how to test (e.g., because any
other hardware/software is needed that you don't have), then please
don't touch this code.

Marcus


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] refactoring OpenOffice

Patricia Shanahan
In reply to this post by Peter Kovacs-3
The OpenOffice build system is both complicated and fragile. If you do
move things around, you MUST test the ability to build and install for
each supported OS.

To me, this change seems high risk for low benefit. I would far rather
see any available cycles put into replacing ad-hoc data structures with
STL structures.

On 3/1/2019 11:05 AM, Peter Kovacs wrote:

> Hello all,
>
>
> I am really annoyed by the Code. I see repentance and to me a code
> concept is totally lacking.
>
> What I would like to do is a general cleanup / refactoring pass.
>
> I would like to start with similar features and move them together in
> the same module, maybe even merge them.
>
> As a process I suggest I post a mail with [refactor] in the subject. The
> Mail will contain what will be moved merged, I collect all references in
> the mail.
>
> If there is no objection within 3+ days I conduct the move. (+ because I
> need to find time to move and test the change.)
>
>
> Is this a process feasible?
>
>
> All the Best
>
> Peter
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] refactoring OpenOffice

Peter Kovacs-3
In reply to this post by Marcus (OOo)

On 01.03.19 23:53, Marcus wrote:
>
> depends on how many time you want to invest and how many developers
> are with you. I've always understood that you haven't much time for
> developing. ;-)

I always did a lot of talking, since I felt it is necessary. I still
believe we should do more talking. But I came originally to support
development and not to do the managing talking stuff.

So I try now to grow more to the development part, and do less talking,
managing. Maybe some of you need todo more talking then. ;)

>
> But in any case I strongly recommend not to merge back to trunk any
> code that hasn't seen very detailed testing.
> When you have code that you don't know how to test (e.g., because any
> other hardware/software is needed that you don't have), then please
> don't touch this code.

sure, I agree with you if we talk about commits. I reserve the right to
break my copy as much as I want. ;)



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] refactoring OpenOffice

Peter Kovacs-3
In reply to this post by Patricia Shanahan
Do you have an example or can you explain how to find these. I'll have a
look.

On 02.03.19 04:31, Patricia Shanahan wrote:

> The OpenOffice build system is both complicated and fragile. If you do
> move things around, you MUST test the ability to build and install for
> each supported OS.
>
> To me, this change seems high risk for low benefit. I would far rather
> see any available cycles put into replacing ad-hoc data structures
> with STL structures.
>
> On 3/1/2019 11:05 AM, Peter Kovacs wrote:
>> Hello all,
>>
>>
>> I am really annoyed by the Code. I see repentance and to me a code
>> concept is totally lacking.
>>
>> What I would like to do is a general cleanup / refactoring pass.
>>
>> I would like to start with similar features and move them together in
>> the same module, maybe even merge them.
>>
>> As a process I suggest I post a mail with [refactor] in the subject. The
>> Mail will contain what will be moved merged, I collect all references in
>> the mail.
>>
>> If there is no objection within 3+ days I conduct the move. (+ because I
>> need to find time to move and test the change.)
>>
>>
>> Is this a process feasible?
>>
>>
>> All the Best
>>
>> Peter
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] refactoring OpenOffice

Patricia Shanahan
One starting point is my last few patches, which involved a bug in one
of the string implementations, and buffer overflows.

On 3/1/2019 11:58 PM, Peter Kovacs wrote:

> Do you have an example or can you explain how to find these. I'll have a
> look.
>
> On 02.03.19 04:31, Patricia Shanahan wrote:
>> The OpenOffice build system is both complicated and fragile. If you do
>> move things around, you MUST test the ability to build and install for
>> each supported OS.
>>
>> To me, this change seems high risk for low benefit. I would far rather
>> see any available cycles put into replacing ad-hoc data structures
>> with STL structures.
>>
>> On 3/1/2019 11:05 AM, Peter Kovacs wrote:
>>> Hello all,
>>>
>>>
>>> I am really annoyed by the Code. I see repentance and to me a code
>>> concept is totally lacking.
>>>
>>> What I would like to do is a general cleanup / refactoring pass.
>>>
>>> I would like to start with similar features and move them together in
>>> the same module, maybe even merge them.
>>>
>>> As a process I suggest I post a mail with [refactor] in the subject. The
>>> Mail will contain what will be moved merged, I collect all references in
>>> the mail.
>>>
>>> If there is no objection within 3+ days I conduct the move. (+ because I
>>> need to find time to move and test the change.)
>>>
>>>
>>> Is this a process feasible?
>>>
>>>
>>> All the Best
>>>
>>> Peter
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] refactoring OpenOffice

Jim Jagielski
In reply to this post by Patricia Shanahan
FWIW, I agree. We've already seen how simple, obvious changes have a nasty ripple effect. Having a major restructure "now" would, from what I can see, have a major impact on us being able to release 4.2.0 in anything close to "soon"...

I also have issues w/ fixing/restructuring things that work... dmake is weird, but it does seem to work, and unless we can completely rework the entire build system, I'd prefer to see us work on closing bugs and making releases and port to gbuild those parts that must be updated.

Of course, this is a volunteer project and no one can, or should, force someone to work on stuff they don't want to or prevent someone from scratching an itch. I'd just like the project to be working together with a more unified vision...

> On Mar 1, 2019, at 10:31 PM, Patricia Shanahan <[hidden email]> wrote:
>
> The OpenOffice build system is both complicated and fragile. If you do move things around, you MUST test the ability to build and install for each supported OS.
>
> To me, this change seems high risk for low benefit. I would far rather see any available cycles put into replacing ad-hoc data structures with STL structures.
>
> On 3/1/2019 11:05 AM, Peter Kovacs wrote:
>> Hello all,
>> I am really annoyed by the Code. I see repentance and to me a code
>> concept is totally lacking.
>> What I would like to do is a general cleanup / refactoring pass.
>> I would like to start with similar features and move them together in
>> the same module, maybe even merge them.
>> As a process I suggest I post a mail with [refactor] in the subject. The
>> Mail will contain what will be moved merged, I collect all references in
>> the mail.
>> If there is no objection within 3+ days I conduct the move. (+ because I
>> need to find time to move and test the change.)
>> Is this a process feasible?
>> All the Best
>> Peter
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] refactoring OpenOffice

Patricia Shanahan
My motivation for wanting to update data structures is bug fixing. I've
already had to track down and fix buffer overflows. A general move to
self-expanding buffers and bounds checking would fix bugs we do not yet
know about.

On 3/2/2019 7:16 AM, Jim Jagielski wrote:

> FWIW, I agree. We've already seen how simple, obvious changes have a nasty ripple effect. Having a major restructure "now" would, from what I can see, have a major impact on us being able to release 4.2.0 in anything close to "soon"...
>
> I also have issues w/ fixing/restructuring things that work... dmake is weird, but it does seem to work, and unless we can completely rework the entire build system, I'd prefer to see us work on closing bugs and making releases and port to gbuild those parts that must be updated.
>
> Of course, this is a volunteer project and no one can, or should, force someone to work on stuff they don't want to or prevent someone from scratching an itch. I'd just like the project to be working together with a more unified vision...
>
>> On Mar 1, 2019, at 10:31 PM, Patricia Shanahan <[hidden email]> wrote:
>>
>> The OpenOffice build system is both complicated and fragile. If you do move things around, you MUST test the ability to build and install for each supported OS.
>>
>> To me, this change seems high risk for low benefit. I would far rather see any available cycles put into replacing ad-hoc data structures with STL structures.
>>
>> On 3/1/2019 11:05 AM, Peter Kovacs wrote:
>>> Hello all,
>>> I am really annoyed by the Code. I see repentance and to me a code
>>> concept is totally lacking.
>>> What I would like to do is a general cleanup / refactoring pass.
>>> I would like to start with similar features and move them together in
>>> the same module, maybe even merge them.
>>> As a process I suggest I post a mail with [refactor] in the subject. The
>>> Mail will contain what will be moved merged, I collect all references in
>>> the mail.
>>> If there is no objection within 3+ days I conduct the move. (+ because I
>>> need to find time to move and test the change.)
>>> Is this a process feasible?
>>> All the Best
>>> Peter
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] refactoring OpenOffice

Peter Kovacs-3
In reply to this post by Jim Jagielski
Hello Jim,

I agree we should move together, that's why I started the conversation.
However I think we should not only focus on 4.2.0.  I think we should
not only work on STL transformation, and we should not only do the gmake
transformation. All three topics are quite concrete and important
efforts. And they are good steps. But I think we should also address the
Architecture.

The Software Architecture is something you will not see when you look at
one file or issue. The Architecture we have is responsible for the
fragile build system we have. It is also responsible that a lot of
Issues are hard to be fixed. But IMHO unless we start talking about it,
we will not get down to the root cause of it. And I say talking not
doing. This discussion is only to set up a process to think together on
architecture and create a plan.

I think this would also help coders, who are not that firm with our
code, but want to help on creating a fix. See we have per month round
about 1 person who shows up to do something. And we have maybe every
three of those is a coder. So far we could not bring anyone on board.
They leave because it is very hard to create a deliverable. The most
promising has been George with the MSVC update, but I am not hearing
from him.

So related to the STL Conversations. I would also only note the spots,
maybe goals and then find someone who will try it. Maybe this is a fail
tactics, but we need to grow. And my ressource is quite over stretched,
because I myself looking for pathes into OpenOffice.

I hope I made my point somehow.


On 02.03.19 16:16, Jim Jagielski wrote:

> FWIW, I agree. We've already seen how simple, obvious changes have a nasty ripple effect. Having a major restructure "now" would, from what I can see, have a major impact on us being able to release 4.2.0 in anything close to "soon"...
>
> I also have issues w/ fixing/restructuring things that work... dmake is weird, but it does seem to work, and unless we can completely rework the entire build system, I'd prefer to see us work on closing bugs and making releases and port to gbuild those parts that must be updated.
>
> Of course, this is a volunteer project and no one can, or should, force someone to work on stuff they don't want to or prevent someone from scratching an itch. I'd just like the project to be working together with a more unified vision...
>
>> On Mar 1, 2019, at 10:31 PM, Patricia Shanahan <[hidden email]> wrote:
>>
>> The OpenOffice build system is both complicated and fragile. If you do move things around, you MUST test the ability to build and install for each supported OS.
>>
>> To me, this change seems high risk for low benefit. I would far rather see any available cycles put into replacing ad-hoc data structures with STL structures.
>>
>> On 3/1/2019 11:05 AM, Peter Kovacs wrote:
>>> Hello all,
>>> I am really annoyed by the Code. I see repentance and to me a code
>>> concept is totally lacking.
>>> What I would like to do is a general cleanup / refactoring pass.
>>> I would like to start with similar features and move them together in
>>> the same module, maybe even merge them.
>>> As a process I suggest I post a mail with [refactor] in the subject. The
>>> Mail will contain what will be moved merged, I collect all references in
>>> the mail.
>>> If there is no objection within 3+ days I conduct the move. (+ because I
>>> need to find time to move and test the change.)
>>> Is this a process feasible?
>>> All the Best
>>> Peter
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]