Patricia, I do not want to discourage scratching an itch that is important to you.
I do need to express my concern for the limited capacity that we have for development work, and I have done that. Everyone is a volunteer, and at the end of the day we will have whatever we have. Enough said. I admire your work and enjoy very much our dance through the profile.c threading issues, and also the Windows build setup, if the opportunity returns. - Dennis Side comments: Starting with the least that can possibly work is an important principle for software maintenance, where the greatest fear is a hopeless regression or, worse for open-source especially, an incomplete effort for which the prize is not attained. It does not mean that major architecture and feature matters cannot also be addressed. But the users won't wait forever to have their bad experiences cured and timely interim solutions (and workarounds) are important. In my youth, I took the reverse approach a few times. It did not go well. I am very incremental and iterative in approaches now, even with what can grow into large efforts. Working with a monster existing code base which may have some significant bit rot is another story. Heroism won't carry the day. I am striving to not be too discouraged about that. > -----Original Message----- > From: Patricia Shanahan [mailto:p...@acm.org] > Sent: Friday, March 4, 2016 10:25 > To: dev@openoffice.apache.org > Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning > curve) > > On 3/4/2016 9:39 AM, Dennis E. Hamilton wrote: > > Patricia, > > > > Based on Damjan's finding that profile files are read by the > > application and that some are created during setup, with others > > copied in from the setup, it is settled that the code is used in > > current distributions and is also available to extensions. > > > > I recommend that we catch our breath over the weekend, take a fresh > > look at what we know, and then make that smallest repair that will > > work. > ... > > > > I would defer any extensive threading analysis and work on more > > pressing maintenance issues first, especially since the UDK is > > snarled up in this. It's worthwhile but other priorities deserve our > > attention. > > From my point of view there are benefits to me continuing to work on > threading analysis. > > Threading leverages my existing expertise in multiprocessor/multithread > issues, and therefore might be a good general area for me to work on. > > I find it very, very difficult to study a large system in the abstract. > I need a question I can get my teeth into to inspire reading, grep, etc. > Learning my way around AOO is key to me becoming productive on it. "Why > is the 'unx' code bristling with pthread_mutex calls but the 'w32' > version does not seem to have anything similar?" is just the right sort > of question to hold my attention. Maybe the 'w32' version needs > synchronization it lacks. Maybe it has a simpler way of controlling > access to the profile that could be copied for 'unx'. I want to know, > and finding out will lead to me learning how AOO works. > > I am wary of the "smallest repair" strategy. It tends to avoid ever > throwing anything out, leading to clutter, and ultimately > unmaintainability. > > Patricia > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
