Re: [dev] Specification Process Possibilities ... what about a wiki?
David Fraser schrieb: Hi Christian Thanks for your offer! I think a wiki version of the Template would be a substantial aid to many people, and from the rest of the response on the mailing list I'm not alone in thinking that. Could you let us know if you start working on this - I presume wiki.services.openoffice.org is the place - as then others could perhaps participate :-) Yes, wiki.services.openoffice.org would be the place. What would like to see is a solution which works for those who want to write in the wiki and for those who want to use the template. So, the OOo Wiki should learn to handle mime types such as ODF, ODT, PDF, ODS, OTT, etc... Transforming the template to the wiki would be the first step. But we need to address two other pain point to. Search and editing. Currently it is very hard to get an overview of what is documented and what's not. The other pain point the wiki editing itself. A Rich Text Editor (http://meta.wikimedia.org/wiki/FCKeditor) would really lower the barrier to create Wiki content. Especially, if you create complex tables the mixing code and content works not very well. Regards, Christian Regards David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
Thorsten Behrens wrote: Mathias Bauer [EMAIL PROTECTED] writes: Not exclusively. Also developers will benefit from a spec if they have to refactor/change/extend the code later on. Believe me, I can't count the occasions any more where I would have been glad to have a specification for a feature that needed a larger rework. Without a spec we very often are standing in the dark and hope to be lucky not to damage too much things just because we just don't know about their existence. Hi Mathias, yes, you might catch a few bugs using this approach. But I think one of the key messages of agile software engineering is that in the end, the code determines behaviour, not documentation. Put differently, code and documentation will quickly diverge, simply because there can't be technical, automated means to check that they are in sync. This answer is typically for the whole thread. We (including myself) mix too many things into each other. IMHO it is undoubtfull correct that a spec has the value I described, even if it is not completely in sync with every detail of the code. And it is also undoubtfull that specs tend to get out of sync with the code if you don't fight against this tendency. And it has happened for a lot of specs already (to a different degree). But both facts don't mean that either specs are useless at all or OTOH specs are the greatest thing on earth and so everybody (even the development noob) must provide one for even trivial features before he gets his entry to the holy of holies. I start to subscribe to your idea of lowering the burden for new developers - not by dropping our requirements for some kind of documentation but by making the process more agile and light weight and also putting some work on the shoulders of the project members or even project leads. But not because I think that we are doing something wrong now (from a technical or project management POV) but because I think that if specs are an important barrier to contribution we must do something to lower or remove this barrier. If this created some problems or a little more work for others we would have to names these problems and additional duties and decide what is more important for us: avoiding them or lowering the barriers to contribution. In my understanding community building and fostering community based development is one of our most important goals and so this deserves some compromises elsewhere. I still want paid or even long term non-paid developers (not only Sun developers!) to stick to our rules. I'm also for more agility and usage of common sense in the application of them, but not as a creeping undermining. This is something we must agree upon beforehand (and we comprises not only development but also QA, Documentation etc.). Until then we should stick to the current way of doing things. I think it's time for a summary. Ciao, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Possible exploit potential in openoffice
James Courtier-Dutton wrote: Stephan Bergmann wrote: Caolan McNamara wrote: [...] Also, we really should also add... .section.note.GNU-stack,,@progbits That should probably be: #ifdef __ELF__ .section .note.GNU-stack,,%progbits #endif as explained on the url I put in my initial email: http://www.gentoo.org/proj/en/hardened/gnu-stack.xml Yes, see http://www.openoffice.org/nonav/issues/showattachment.cgi/40053/noexecstack.patch at http://www.openoffice.org/issues/show_bug.cgi?id=70845 (which uses @progbits instead of %progbits?!). -Stephan [...] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
Mathias Bauer [EMAIL PROTECTED] writes: Thorsten Behrens wrote: Mathias Bauer [EMAIL PROTECTED] writes: Not exclusively. Also developers will benefit from a spec if they have to refactor/change/extend the code later on. Believe me, I can't count the occasions any more where I would have been glad to have a specification for a feature that needed a larger rework. Without a spec we very often are standing in the dark and hope to be lucky not to damage too much things just because we just don't know about their existence. yes, you might catch a few bugs using this approach. But I think one of the key messages of agile software engineering is that in the end, the code determines behaviour, not documentation. Put differently, code and documentation will quickly diverge, simply because there can't be technical, automated means to check that they are in sync. This answer is typically for the whole thread. We (including myself) mix too many things into each other. IMHO it is undoubtfull correct that a spec has the value I described, even if it is not completely in sync with every detail of the code. Moin Mathias, right - you are stressing the fact that specs are useful (which I conceded further down in the same posting), I'm saying that they don't solve the root cause of the problem you were describing. We seem to agree. I start to subscribe to your idea of lowering the burden for new developers - not by dropping our requirements for some kind of documentation but by making the process more agile and light weight and also putting some work on the shoulders of the project members or even project leads. Cool! I guess this is all that's needed here. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
Hi Thorsten, However, far more important than a string review, IMHO, would be to drop German as a developer provided second source localization. Let's get rid of that. Aww, of course. I thought we already did that. :-/ +1 here. That's an obsolete requirement for an international project such as OOo. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] The QuickStarter Spec.
Hi Michael,
I think there's some kind of agreement (or general direction, at least)
in this thread that
- *some* documentation of a feature is needed for various audiences
- the form of the documentation should not matter
- there needs to be a lightwight possibility to provide this
documentation
I'll take this as granted in everything I say below.
Thankfully the code works :-) But the very concept of rampant
duplication of state all over the place is at root broken IMHO. Having
unnecessary screenshots,
Unnecessary? Hmm. But useful. From a given complexity onwards, I'd
*always* ask you to provide a screenshot. Not necessarily for a
(quickstarter) menu, but certainly for a complex tab dialog.
duplicating bi-lingual strings etc. adds
[AFAICS] nothing at all to an existing impl, but a huge amount of pain
in terms of re-synchronising things.
...
Well; clearly the argument that at least with a spec. QA can know what
the impl. should do is shown to be almost totally bogus :-)
That's a too simple conclusion, and I don't know where you take it from.
The fact that the spec you examined is obsolete, mixes a lot of
different things, as has not been kept in sync with all changes actually
done to the product doesn't justify it.
If the implementor provices a spec/documentation of the feature which is
up-to-date at the moment the CWS goes to QA, then the fact that later on
the spec quality decreases (slower or faster) doesn't mean the idea is
totally bogus.
Well, the main problem with the spec. process - beside the specs being
way too verbose ('Complete'), is the latency problem. It's all very well
soliciting input from all sundry, but if they ~never respond life
becomes very painful indeed;
I think we all in the thread got this point, which wasn't difficult
since you mentioned it often enough ;)
Perhaps we need some pool of people to approach, or something like this ...
An asynchronous work-flow, whereby an Engineer can implement a
feature / fix, knock up a quick wiki page describing it, commit it to a
CWS, assign it to QA, mail the dev@ui.openoffice.org list about it, and
get on with his next task would be ideal. Of course, U.E. could poke at
the wiki/issue (if they were interested had time), otherwise it would
just proceed, QA likewise could ask questions / extend the wiki page
describing the change (if at all necessary), otherwise they could focus
on the real grist of the implementation.
Sounds good to me. However, then it should also be granted that QA/UE
have the right to question/veto certain decisions, designs, etc. If we
introduce such a possibility (and I'm all in for it), then it must be
two way: The Engineer can *not* give up responsibility for the feature
as such by just firing the CWS into the ready for QA state.
Of course, this right needs to be used carefully by QA/UE (which
probably has not always been the case in the past).
Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Database http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dev] An attempt of a summary: specification process possibilities
Hi together, as I have the feeling that many discussions in our most beloved thread started to go around in circles I want to break out and focus the discussion by providing a personal summary of it. Please read this summary as a whole before you comment on single items, I really tried to cover all points of view, but not in each and every sentence. IMHO the discussion was about quality of the producet and it touched two major aspects: - source control - specs and mixed them in a way that many of us talked in cross-purposes. Unfortunately we mixed the spec discussion with the question wether we should throw code in fast or not - and I for myself was jointly responsible for that as I mixed those aspects in one of my first mails. I think that these two topics are only losely coupled and to concentrate on the spec discussion we should leave the integrate early and fast part out for now. We also touched the matter of early communication and it wasn't disproved that early communication is the best way to avoid delayed integration. Also nobody denied that early exchange of ideas is a good thing though that isn't necessary in case of trivial or uncontroversial changes. OTOH it is only fair that contributors trying to get in touch with others can expect a reaction in a reasonable time frame. My personal take on that is that we should track this in the same way as we track response times for patches though I don't want to go too much into details here. But even then we must deal with the situation that something might get stuck and we must avoid that contributions vanish in a black hole. All communication should happen with the spirit thanks for your work, let me help you get it included and not I'm so busy I can't be bothered to reply to your mail/issue. OTOH contributors should accept that they might receive some requests for improvements of their contribution - the more the longer they are on board. To enable contributors to communicate with others they might need for the integration of their contribution we should have a contact list that makes it easier to find the right people to talk with. Alltogether resolving the communication problems seems to be the most important step towards any possible closer interaction (e.g. specs or iTeams). Now back to specs. Specs doesn't necessarily mean exactly what we have now. It can be something more lightweight, but it must be agreed upon by all stakeholders how this should look like. To enable this the stakeholders must publish their goals they connect to specs. Some of the already mentioned goals are: - helping QA to create and execute test plans - helping documentation to describe the feature - helping developers to implement what the requirement is about (something that usually does not apply to community development as in this case most often the requirement comes from the one who does the implementation) - helping developers to change existing features in a controlled way - to be continued Let's think about specs as a kind of documentation that currently has a defined shape but not necessarily must keep this in the future. Whatever shape it will have it must be accessible, understandable and usable for all stakeholders (so it can't be use the source :-)). Though nobody of the spec supporters ever made claimed that you can't reach quality without specs as we have them today it was used as a weapon against them. Instead of continuing this endless discussion I would like to propose that we should agree upon this: Specs (not necessarily in their current shape) are a means for achieving quality, but not the only one. It's open for discussion wether the effort/result relation of specs in one or the other shape is fine or not. If we see specs as I described them above I think that even those who argue against our current way of doing specs didn't deny that having some kind of spec is a good thing. If we want to change something we must find a replacement for the current process, we must not undermine or ignore it. Whatever we do with specs in the future we should address a lot of problems that have been mentioned: - content can be out of sync with the code - missing content - broken or unaccessible links - maintainability of screenshots (embedded/linked?) - maintainability of localized strings - uncontroversial and trivial changes should go in fast and easy - non-responsiveness of people shouldn't block contributions: ensure that the spec. process is filled with shortish timeouts to handle people that don't respond - make every possible step asynchronous so there are as few round-trips as humanly possible - separate the aspects of design requirements (team) and documentation (spec) and make it less formal - focus the saving in (very scarce) developer / QA resource on other things: a good unit test framework eg. (*) - re-direct some spec. process time in favour of peer code review - it will yield a higher quality, and ultimately better trained, more
Re: [dev] Re: [framework-dev] [Fwd: [installation-dev] Updating to OOo 2.1 language packs]
Hi, Unfortunately I overlooked Olivers request to follow up in dev@installation.openoffice.org and so I unintentionally opened this side discussion. Sorry for that. Please let's continue in [EMAIL PROTECTED] Mathias Bauer wrote: Oliver Braun wrote: with the move to the new numbering schema also the default installation directory changes from OpenOffice.org 2.0 to OpenOffice.org 2.1 resp. from openoffice.org2.0 to openoffice.org2.1. Perhaps we should stop using directory names containing version numbers? Firefox e.g. always installs into the same directory (on Windows it's program files\Mozilla Firefox). What's the point in keeping the version numbers in the directory names? Would be interesting to ask the Firefox developers if they experienced any user problems or complaints. Besides that: Assuming that users might have language packs installed in their OOs 2.0.x, the result when updating will be platform dependant: * on Windows, the installer will detect the existing 2.0.4 and propose OpenOffice.org 2.0 as destination directory instead = language packs still there, but potentially incompatible (might even lead to crashes). * on Unix, the default directory openoffice.org2.1 will be used, resulting in a naked OOo 2.1 with the language packs still present in openoffice.org2.0. Shouldn't we issue a warning on Windows and install to OpenOffice.org 2.1 by default as on Unix ? Users willing to take the risk might still choose the OpenOffice.org 2.0 manually. This would be acceptable as a stop gap solution. In alignment with my idea from above and also as a clearer approach: can we find a way to disable/deinstall language packs? Ciao, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] The QuickStarter Spec.
Hi, Mathias Bauer wrote: Michael Meeks wrote: Thankfully the code works :-) But the very concept of rampant duplication of state all over the place is at root broken IMHO. Having unnecessary screenshots, duplicating bi-lingual strings etc. adds [AFAICS] nothing at all to an existing impl, but a huge amount of pain in terms of re-synchronising things. I don't want to argue against this, just a question: how should the QA find out wether the strings they find in the product are the right ones that others wanted to have there? I don't get how this works. just one example: On Solaris, I see the string Load StarOffice During System Start-Up as a command in the Quickstarter menu. Without a spec doc, how can I tell this is intended or just a copypaste error from the Windows version? I can only guess. Our Solaris system starts up about once every 10 years... Uwe -- [EMAIL PROTECTED] - Technical Writer StarOffice - Sun Microsystems, Inc. - Hamburg, Germany http://www.sun.com/staroffice http://documentation.openoffice.org/ http://documentation.openoffice.org/online_help/index.html http://blogs.sun.com/oootnt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to store sensitive information
Robert Vojta wrote: On 10/31/06, Mathias Bauer [EMAIL PROTECTED] wrote: We have a password container that can collect passwords at runtime and keeps them. Currently we don't store passwords persistently (only in memory), though the implementation would be there. It uses a configuration backend and the passwords can be sealed with a master password. Sounds like good news to me ... Can you tell me in which module is this implementation? Is this implementation enabled by default and not used or it's just there and nobody is using it? Are those passwords (sealed with a master password) encrypted? Yes, the master password is used to encrypt the other passwords. It is not enabled but currently it can't be enabled just by setting a configuration switch. To force the password container to store passwords one line of code must be changed in uui/source/iahndl.cxx. In this case we should perhaps make it configurable wether passwords are stored or not in the future. Until now we didn't want to use storing passwords in OOo so we didn't add the code to make it configurable. I don't remember why (would be fine to have a spec so that we could find out the reason for this decision ;-)). The whole implementation is encapsulated into a UNO service and if somebody wanted we could show him the ropes and discuss possible ways to integrate with other backends. Hmm, I think that the Mozilla approach is better. Lot of backends on all available platforms - never ending job. If persistently stored passwords can be encrypted, configuration backend fits all needs for this feature. In what way is the Mozilla approach different to our current one? We collect passwords, remember them and (optionally) save them into a configuration file. The only difference IIRC is that we don't save passwords without a master password. I just mentioned the backend because I thought that you wanted to use something external to OOo. I don't know what the keyring manager is but I think that the passwordcontainer code could possibly be changed to use it instead of storing them into its own configuration files. But if that is OK for you forget that I mentioned possible integrations with other backends. BTW: the password container is used for http or ftp access, not for document passwords. It would be possible to extend it for this case though. Ciao, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to store sensitive information
On 11/1/06, Mathias Bauer [EMAIL PROTECTED] wrote: To force the password container to store passwords one line of code must be changed in uui/source/iahndl.cxx. In this case we should perhaps make it configurable wether passwords are stored or not in the future. Thanks for this hint ... In what way is the Mozilla approach different to our current one? As you wrote, there's no difference. I meant that it's better to use Mozilla's approach, which is same as OO.o approach (didn't know this), than to use different backends for different platforms ... -- Robert Vojta - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] The QuickStarter Spec.
On Wed, 2006-11-01 at 13:01 +0100, Uwe Fischer wrote: Hi, Mathias Bauer wrote: Michael Meeks wrote: Thankfully the code works :-) But the very concept of rampant duplication of state all over the place is at root broken IMHO. Having unnecessary screenshots, duplicating bi-lingual strings etc. adds [AFAICS] nothing at all to an existing impl, but a huge amount of pain in terms of re-synchronising things. I don't want to argue against this, just a question: how should the QA find out wether the strings they find in the product are the right ones that others wanted to have there? I don't get how this works. just one example: On Solaris, I see the string Load StarOffice During System Start-Up as a command in the Quickstarter menu. Without a spec doc, how can I tell this is intended or just a copypaste error from the Windows version? I can only guess. Our Solaris system starts up about once every 10 years... Uwe he,he. I think that you should read system as session. As in when you login, logout and login again. This would mean that system is the wrong word but its use is likely harmless as *NIX users will not likely care and windows users are already familiar with the nomenclature. -- G. Roderick Singleton [EMAIL PROTECTED] OpenOffice.org smime.p7s Description: S/MIME cryptographic signature
Re: [dev] The QuickStarter Spec.
on 2006-11-01 klockan 07:50 -0500 skrev G. Roderick Singleton: I think that you should read system as session. [...] This would mean that system is the wrong word but its use is likely harmless as *NIX users will not likely care and windows users are already familiar with the nomenclature. Nah, I don't think so. It's just plain misleading and wrong to talk about system when you mean session. This should be changed. I bothered to open an issue for it some time ago, 70789. --tml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
On Tue, 2006-10-31 at 17:42 +0100, Christian Lohmaier wrote: I disagree. Esp. when the UI is changed significantly the UI-mockups are necessary. Both for finding flaws in the proposed design as well as for documentation. I'm well up for the UI team doing mock-ups and communicating those to the developer, makes perfect sense. Of course, what comes out in the product may not be like the mockups, hopefully it's even better - so why enshrine the mockup process in a formal document ? I'm sure nobody expects you to do a pixel-accurate mockup, but again the user-interaction part should be clearly visualized. Sure - and of course UI is important. Snip some good quick-starter related questions - sure - all of these things can be easily added to an unstructured wiki page / FAQ, that can be built up as people ask the questions. In this scenario, a spec cannot be used to verify the implementation, because the implementation is done first. Well, you can still see whether what you coded actually is what you thought it would do (i.e. what you coded is what you wrote down in the spec). But we didn't write down a spec. We conceived of the idea, then implemented it, now we have it. The original conception of course was prolly inaccurate, no-one gets things right 1st time, we most likely have a solution that is now far better than that, similarly we are now probably aware of the various limitations of the current approach, and various next steps / future development to do. It is true that you miss the find errors in the planning phase (but again I don't think you start coding without having planned the changed first, so no gain/no loss) The problem is that there is a very large difference between conceiving an idea and writing it down as prose (with pictures); you can conceive of things almost instantly, writing a general document for an uncertain audience is very time consuming. Anyhow, Good stuff, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... - unit testing
Hi Christian, On Tue, 2006-10-31 at 17:54 +0100, Christian Lohmaier wrote: An unfair cite. ;-) lets look at the context contention: On Mon, 2006-10-30 at 23:57 +0100, Mathias Bauer wrote: You mix up some things here. Nobody said that we need a spec for each and every tiny ergonomic fix. ^^^ On Tue, Oct 31, 2006 at 02:27:23PM +, Michael Meeks wrote: I refer you to the Sun rubric ** emphasis added. ... I Want to Change Something in OpenOffice.org - Do I Have to Write a Software Specification? **In general the answer is YES**. This applies to: Features, Enhancements, **Defects** That page appears to say nothing to exclude tiny ergonomic fixes (for defects) from the spec. process, -) Indeed they are clearly in the Behavioral changes of the UI. I think the current thrust of the process is clear here. An unfair cite. it is Defects **requiring the following type of changes**: list of criteria You don't cite include the relevant criteria either :-) Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
Hi David, All, It would be great if we could continue the wiki discussion on [EMAIL PROTECTED] I think this is the right place for stuff like that. BTW. The spec template macro problems are now fixed. Regards, Christian David Fraser schrieb: Hi Christian Thanks for your offer! I think a wiki version of the Template would be a substantial aid to many people, and from the rest of the response on the mailing list I'm not alone in thinking that. Could you let us know if you start working on this - I presume wiki.services.openoffice.org is the place - as then others could perhaps participate :-) Regards David Christian Jansen wrote: Hi David, from a feature documentation perspective it makes no difference to use the template, a wiki, a HTML page, or what ever comes into your mind. I think it is more important that the UI feature and its functionality is described in well mannor. I personally think a wiki is absolutely fine to do that, but both (template or wiki) should follow the same guidelines. The template was intended to give novice spec writers some help to write a spec. We decided to use the Writer format because it allows us to do some automation which makes it convenient to use. Especially creating complex tables in a wiki is no fun. However, I can offer to create a wiki-version of the new template. Regards, Christian David Fraser schrieb: Kazunari Hirano wrote: Hi, Frank Schönheit wrote: However, what I really *really* like about this process is the exchange of ideas and arguments. I respect the process. I encourage community developers and CJK developers to access the spec project wiki [1] and the spec template [2]. For issue 12719 I attempted to have a faster and more accessible specification process This involved developing the spec collaboratively in the wiki Unfortunately the spec team did not like this idea and have gone for an OOo template for designing specifications with This is perhaps better than the previous system, but I think there are still significant cases where using a wiki is a much faster route for people (particularly outside contributors) to use to collaboratively produce a specification. Unfortunately I did not have time to pursue this idea; fortunately the Sun team that took over the issue did look through our wiki-based spec and hopefully included some things - the issue is now fixed which is nice :-) But I would like to propose that this approach to spec generation be given more thought. Reasons: 1) Wikis are designed for this 2) It is easier for a person not heavily involved in OOo to go to a wiki page, make a few changes, edit it, and submit, then it is to get a document out of version control etc, open it in OOo, change it and submit 3) The spec process is apparently working well for those inside Sun, less well for those outside. If there were an easier route for those less involved in development to produce specs it could be run concurrently as an alternate mechanism (possibly with a final step of converting to the required template format, that could be automated) 4) This would perhaps be particularly helpful for outside contributers who are not coders 5) Less likely to break due to problems in the OOo template macros :-) This was done by having a wiki template that could then be filled out to produce the spec. Thoughts? David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Improving source documentation: CWS codecomments01
Hi *, in the wake of the spec discussion thread, people mentioned that they'd like to write down hard-won understanding of the code how things work somewhere. IMO the best place for nitty-gritty details and (self)justification why things are as they are is the code itself - most easy (and thus most likely) to keep stuff in sync there. I've therefore created CWS codecomments01, so everyone feeling the urge to improve code comments is welcome to commit there/dump me your patches (the former much preferred, of course ;-)). If at all possible, please provide your class/method commentary in autodoc/doxygen compatible format: http://tools.openoffice.org/autodoc/HowToWriteDocumentation-Cpp.html Other places where (possibly more high-level) code explanation might get: http://wiki.services.openoffice.org/wiki/Source_code_directories (link your module descriptions from there) http://wiki.services.openoffice.org/wiki/User:Ericb#Sort_of_documentation_about_VCL_around_Native_Mac_OS_X_port (might benefit from separation etc. but much appreciated) Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
Michael Meeks wrote: But we didn't write down a spec. We conceived of the idea, then implemented it, now we have it. The original conception of course was prolly inaccurate, no-one gets things right 1st time, we most likely have a solution that is now far better than that, similarly we are now probably aware of the various limitations of the current approach, and various next steps / future development to do. The problem is that there is a very large difference between conceiving an idea and writing it down as prose (with pictures); you can conceive of things almost instantly, writing a general document for an uncertain audience is very time consuming. Conceiving an idea can be very easy. But too often - and I don't have any particular event nor person in mind, seriously - an easy idea turns out to be less consistent, less good, once the idea-owners is forced to write it down, to make it clear... The original 'instance' of the quickstarter ánd the new one, would have been better if specs were written. Regards, -- Cor Nouws Arnhem - Netherlands nl.OpenOffice.org - marketing contact - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
Mathias Bauer wrote: Kohei Yoshida wrote: 2) The target audience is not very clear. Thanks to this thread, though, now I'm beginning to see who the specification documents are intended for (mostly for QA, right?). Not exclusively. Also developers will benefit from a spec if they have to refactor/change/extend the code later on. Believe me, I can't count the occasions any more where I would have been glad to have a specification for a feature that needed a larger rework. Without a spec we very often are standing in the dark and hope to be lucky not to damage too much things just because we just don't know about their existence. If you contribute features to a project you should see that you add something useful to the project but also a legacy for the code owner who has to maintain your code in the future. Code alone isn't documentation enough, even for developers. Just a thought worth another 2ct, IMHO. And mine - experienced on a different level of development - but oh so much the same -- Cor Nouws Arnhem - Netherlands nl.OpenOffice.org - marketing contact - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
many people wrote: As mentioned by others: it is a good thing if writing (some sort of) specification can be made easier. OTOH, I've dóne it once, and it took me about three hours. Including studying the template and the related documentation at the Wiki - both very good IMHO. Next time, it will take me much less effort, since the process is known. So, what are we all talking about? Time needed for (some sort of) specs includes: - thinking; - making a clear description of what is really intended; - preparing screen prints (if involved); - finding people to help with for example QA; and/or - maybe some extra discussion with others; - writing all down. This all does take some time, yes. However, part of that energy is (sooner or later) needed anyway for documentation and QA. Part of the energy is needed anyway, to make a sound feature. And writing it down (or another form of communication) is needed as well... And about the last point:I do prefer by far to write my stuff in Writer, rather than on a Wiki page. Writing in Writer is easier. Of course I'm not sure if I'm the only one of this opinion ;-) Furthermore, it easy to hold different versions of the .ODT. Mind: I'm not against making the process easier and or better. However: I've seen (and joined) a very lengthy and intense discussion on [EMAIL PROTECTED] about all good things that using the Wiki would bring. About more community involvement especially. The Wiki came, but very little extra time, if any at all, has been spent by all people, using that tool. Much time was spent in discussion about and creating it. So I'm a bit careful, conservative... The Wiki is not a magic formula that will solve it all ;-) Are we not fooling ourselves with this discussion? But, being aware of these limitations, íf a Wiki is really better: go for it. With respect, -- Cor Nouws Arnhem - Netherlands nl.OpenOffice.org - marketing contact - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
On 11/1/06, Cor Nouws [EMAIL PROTECTED] wrote: Michael Meeks wrote: But we didn't write down a spec. We conceived of the idea, then implemented it, now we have it. The original conception of course was prolly inaccurate, no-one gets things right 1st time, we most likely have a solution that is now far better than that, similarly we are now probably aware of the various limitations of the current approach, and various next steps / future development to do. The problem is that there is a very large difference between conceiving an idea and writing it down as prose (with pictures); you can conceive of things almost instantly, writing a general document for an uncertain audience is very time consuming. Conceiving an idea can be very easy. But too often - and I don't have any particular event nor person in mind, seriously - an easy idea turns out to be less consistent, less good, once the idea-owners is forced to write it down, to make it clear... While I agree with the gist of your statement, I must say this is not universally applicable to all forms of creative activities, of which coding is one. Often a conceived idea of a certain code design can be easily formulated in terms of programming code, but the same idea may not be easily expressed in words. Even if an attempt is made to express it in words, it just incurs a great deal of pain, and more often than not, it ends up not accurately depicting the original idea, or ends up with lengthy piece of sentences and paragraphs that accurately depicts the idea, but becomes far larger in size than the original piece of code it tries to depict. In the latter case, it is much easier to test the idea with code rather than with words. Moreover, as a programmer gains more experience thinking and writing code, the tendency to conceive of ideas instantly without the help of words becomes stronger. So, to a seasoned programmer, dumping an idea in terms of code is equivalent of non-programmer dumping an idea in words, not to mention doing so is much more pleasant and fun activity than trying to describe an algorithm or code design in words alone... Just for what it's worth... Kohei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
Hi Kohei, Kohei Yoshida wrote: While I agree with the gist of your statement, I must say this is not universally applicable to all forms of creative activities, of which coding is one. Often a conceived idea of a certain code design can be easily formulated in terms of programming code, but the same idea may not be easily expressed in words. Even if an attempt is made to express it in words, it just incurs a great deal of pain, and more often than not, it ends up not accurately depicting the original idea, or ends up with lengthy piece of sentences and paragraphs that accurately depicts the idea, but becomes far larger in size than the original piece of code it tries to depict. In the latter case, it is much easier to test the idea with code rather than with words. Moreover, as a programmer gains more experience thinking and writing code, the tendency to conceive of ideas instantly without the help of words becomes stronger. So, to a seasoned programmer, dumping an idea in terms of code is equivalent of non-programmer dumping an idea in words, not to mention doing so is much more pleasant and fun activity than trying to describe an algorithm or code design in words alone... Just for what it's worth... I think it is party right what you write. Because I've some more experience is writing words than code, I don't have that 'problem' and maybe under estimate it. OTOH, there is an idea, and a programmer has to be able to tell /explain what he/she wants to achieve, one way or another. Isn't it? Maybe the problem is, that the description shouldn't include details and all steps, but just the main-lines. For example: this feature offers a dialog/menu, that the user can find there, which gets data from there, and in which the user can do this, and has as result that such, and so, and the data is stored in that place/way. Just my thoughts ... Cor -- Cor Nouws Arnhem - Netherlands nl.OpenOffice.org - marketing contact - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
Hi Thorsten, Thorsten Behrens wrote: However: I've seen (and joined) a very lengthy and intense discussion on [EMAIL PROTECTED] about all good things that using the Wiki would bring. About more community involvement especially. The Wiki came, but very little extra time, if any at all, has been spent by all people, using that tool. I tend to disagree. More than 600 content pages, and ~18,000 page edits speak for themselves, I hope: (http://wiki.services.openoffice.org/wiki/Special:Statistics) It's obvious that the experience on the marketing project is not representative ... so hopefully the statistics for the MP will improve as well. (pls note: no offense meant to anyone involved) At least the barriers for entry are far lower than on the CVS-based OOo main site. So I'm a bit careful, conservative... The Wiki is not a magic formula that will solve it all ;-) Are we not fooling ourselves with this discussion? Sure - the wiki is no silver bullet. But the wish to provide wiki-based specs came from code contributors themselves - all else being equal, why shouldn't we do it? Yes of course. Any (slight) improvement could turn out to be worth. Regards, Cor -- Cor Nouws Arnhem - Netherlands nl.OpenOffice.org - marketing contact - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
Hi Michael, *, On Wed, Nov 01, 2006 at 02:20:28PM +, Michael Meeks wrote: On Tue, 2006-10-31 at 17:42 +0100, Christian Lohmaier wrote: I disagree. Esp. when the UI is changed significantly the UI-mockups are necessary. Both for finding flaws in the proposed design as well as for documentation. I'm well up for the UI team doing mock-ups and communicating those to the developer, makes perfect sense. Of course, what comes out in the product may not be like the mockups, hopefully it's even better - so why enshrine the mockup process in a formal document ? I don't expect the spec to be final from the very beginning. I don't want you or anybody else to do a mockup that fits every need in the very first attempt. But when you have agreed on an UI (and you need to have that agreement, since you need to code that stuff), that should be put into the spec. In the formal document. Again to give documentation a chance to prepare help-texts that actually match the product as well for outsiders (people not part of the implementation team) to have a look. I'm sure nobody expects you to do a pixel-accurate mockup, but again the user-interaction part should be clearly visualized. Sure - and of course UI is important. Snip some good quick-starter related questions - sure - all of these things can be easily added to an unstructured wiki page / FAQ, that can be built up as people ask the questions. ^^ Oh, good that you write this. It seems you have a completely different view of wiki based specs than I have. Writing the spec after the bugs are found and reported is /not/ an option. Using the wiki to collaboratively write and edit the spec is OK, no matter whether it is before implementation (preferable), during implementation (well,...) or after integration into a CWS (not the best choice obviously). But surely the specification needs to be final or stable or whatever you want to call it before the code gets into the master. So adjusting the spec as your likings after throwing random junks of code into the tree is not what I have in mind when talking about wiki-based specifications. (Don't confuse this with updating the spec when the feature gets redesigned or changed afterwards, this is of course fine - but this should not be an excuse for not creating a spec in the beginning) In this scenario, a spec cannot be used to verify the implementation, because the implementation is done first. Well, you can still see whether what you coded actually is what you thought it would do (i.e. what you coded is what you wrote down in the spec). But we didn't write down a spec. We conceived of the idea, then implemented it, now we have it. The original conception of course was prolly inaccurate, no-one gets things right 1st time, we most likely have a solution that is now far better than that, similarly we are now probably aware of the various limitations of the current approach, and various next steps / future development to do. I don't understand how this is contradicting my point. Again what you need to write down is not how many lines of codes you used or how you named your variables and stuff. And if you need to change your whole feature multiple times, then you ought to thing before. (and again this doesn't relate on how to actually code it, but on what the feature is supposed to do) It is true that you miss the find errors in the planning phase (but again I don't think you start coding without having planned the changed first, so no gain/no loss) The problem is that there is a very large difference between conceiving an idea and writing it down as prose (with pictures); you can conceive of things almost instantly, writing a general document for an uncertain audience is very time consuming. Hunting for the missing information is as well. And for more people. ciao Christian -- NP: Metallica - Better Than You - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
Hi Cor, On 11/1/06, Cor Nouws [EMAIL PROTECTED] wrote: Hi Kohei, I think it is party right what you write. Because I've some more experience is writing words than code, I don't have that 'problem' and maybe under estimate it. I have no doubt that expressing and formulating ideas into words is probably fun and rewarding activity for you, just as it is fun and rewarding for me to formulate my ideas into code. This is probably why you're in marketing and I'm not. ;-) OTOH, there is an idea, and a programmer has to be able to tell /explain what he/she wants to achieve, one way or another. Isn't it? Yes. Actually it was never my intention to counter this point. Maybe the problem is, that the description shouldn't include details and all steps, but just the main-lines. For example: this feature offers a dialog/menu, that the user can find there, which gets data from there, and in which the user can do this, and has as result that such, and so, and the data is stored in that place/way. :-) Yes, I fully agree. This is what I would call a feature description, and I'd be glad to provide one if asked, whether it is for marketing or for documentation. What I think we are discussing (to death) on this thread is the method of communication between developers and QAs, and whether or not the specification is the right medium for that purpose and/or whether the specification process is executed optimally to satisfy all parties (developers vs QA / Sun vs non-Sun / paid vs volunteer / etc.) Just my thoughts ... Your thoughts are much appreciated. :-) Kohei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Bounty for performance improvements
Utomo wrote: I am waiting and open for suggestions. Is there somebody can help me to determine how is the performance improvements measured ? Utomo I have a few comments: Performance should be quantified and explained by the submitter. In other words, the submitter should indicate how to test and demonstrate a speed improvement. Memory and runtime both sounds like improvements to me. Broader impact should carry more weight. For example, a 100% improvement in sort speed is probably not as important as a 10% improvement in screen redraw time because the screen is almost always updated. By the same token, a 10% improvement in screen redraw may also beat a 20% improvement in macro run-time. I would probably use imprecise statements as those, and then after some prioritizing, leave the final decision to public voting if it is not obvious as to the final winner, or simply decide up front, that public voting will be done. -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt My Book: http://www.hentzenwerke.com/catalog/oome.htm Info: http://www.pitonyak.org/oo.php See Also: http://documentation.openoffice.org/HOW_TO/index.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
Hi Mathias, On 10/31/06, Mathias Bauer [EMAIL PROTECTED] wrote: Kohei Yoshida wrote: 2) The target audience is not very clear. Thanks to this thread, though, now I'm beginning to see who the specification documents are intended for (mostly for QA, right?). Not exclusively. Also developers will benefit from a spec if they have to refactor/change/extend the code later on. Believe me, I can't count the occasions any more where I would have been glad to have a specification for a feature that needed a larger rework. Without a spec we very often are standing in the dark and hope to be lucky not to damage too much things just because we just don't know about their existence. If you contribute features to a project you should see that you add something useful to the project but also a legacy for the code owner who has to maintain your code in the future. Code alone isn't documentation enough, even for developers. I fully agree that, there are clearly cases where a correctly written specification can save your day, as you pointed out above. But there are also cases where, because of an incorrectly written specification/documentation/inline comments, you could end up wasting time in the end. I'll give you an example. One day I was working on adding a new feature to an existing application (this is not OO.o BTW). So, I started tracing the existing code, which was pretty well documented with lots of header comments, to try to figure out where best to add a hook for that new functionality. I found the right point of insertion and added the hook, but somehow the code didn't work as expected. So, naturally I started tracing the whole call stack to figure out what I was doing wrong. I literally traced all the way down to the main() function. Still no luck finding the root cause of the problem. Since each method had a pretty good header comment, I read those comments fully and trusted that they were all correct (the original code author was long gone and unavailable). It turned out that, the root cause of the problem was not because of what I was doing wrong, but because one of those function's comments specified the wrong return value (e.g. return 0 on success, and 0 on failure type of comment). Once I realized that, and made necessary changes in my code as well as in that incorrect header comment, things started to work. It took me a whole day to realize this. So, while I agree that, when you *know* with certainty that the documentation/specification is correct, it will help save your day. But you cannot always make that assumption. Sometimes, the documentation may be incorrect, but the code still speaks for itself. Anyway, I'm not trying to agree or disagree. I just wanted to offer a counter example. :-) Kohei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] Bounty for performance improvements
Thanks for the suggestions. My original idea was. To make Ooo faster opening the Microsoft Office files. (but without adding memory usage by OOo) Especially for user with old computer, such as PIII with around 128 memory (which now mostly suffer from the huge memory usage by Ooo, and they feel very long time opening the Microsoft office files). I hear many PIII user complain about this, and this make them stop using Ooo. And I think it need to be improved, so it can make them happy and use Ooo. (I will provide some test file when the bounty start.) Example: Original Ooo without patch open the file in 60 second Ooo with patch open the file in 30 second In My opinion this is a 50% Improvements. But sometimes it is not easy to measure how long opening a files is. ( I think judges will help decide it) What do you think ? Best Regards, Utomo -Original Message- From: Andrew Douglas Pitonyak [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 10:35 AM To: dev@openoffice.org Subject: Re: [dev] Bounty for performance improvements Utomo wrote: I am waiting and open for suggestions. Is there somebody can help me to determine how is the performance improvements measured ? Utomo I have a few comments: Performance should be quantified and explained by the submitter. In other words, the submitter should indicate how to test and demonstrate a speed improvement. Memory and runtime both sounds like improvements to me. Broader impact should carry more weight. For example, a 100% improvement in sort speed is probably not as important as a 10% improvement in screen redraw time because the screen is almost always updated. By the same token, a 10% improvement in screen redraw may also beat a 20% improvement in macro run-time. I would probably use imprecise statements as those, and then after some prioritizing, leave the final decision to public voting if it is not obvious as to the final winner, or simply decide up front, that public voting will be done. -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt My Book: http://www.hentzenwerke.com/catalog/oome.htm Info: http://www.pitonyak.org/oo.php See Also: http://documentation.openoffice.org/HOW_TO/index.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] Bounty for performance improvements
-Original Message- From: Utomo [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 7:07 AM To: dev@openoffice.org Subject: RE: [dev] Bounty for performance improvements Thanks for the suggestions. My original idea was. To make Ooo faster opening the Microsoft Office files. (but without adding memory usage by OOo) Especially for user with old computer, such as PIII with around 128 memory (which now mostly suffer from the huge memory usage by Ooo, and they feel very long time opening the Microsoft office files). I I will express my point of view once again - P!!! system can be inexpensively (for about $40) upgraded with RAM, so RAM usage is not very critical. But upgrading CPU in such system will be real challenge (because you can't reuse old CPU and because compatibility is very questionable), so OO optimization should concentrate on lowering CPU usage (reducing RAM usage is nice too, but less important). I would go as far as stating that if there is a choice between lowering CPU usage at cost of increasnig RAM usage CPU usage should be favored. WBR, K. Palagin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] uno:
hi,everybody! I found a amazing problem, when I using replaceByIndex of XIndexAccess in so_active.cxx, whatever parameter ,the IllegalArgumentException always through, even if I use the return value of GetByIndex. the replaceByIndex definition is : void replaceByIndex( [in] longIndex, [in] any Element ) raises( ::com::sun::star::lang::IllegalArgumentException, ::com::sun::star::lang::IndexOutOfBoundsException, ::com::sun::star::lang::WrappedTargetException ); and the getByIndex definition is : any getByIndex( [in] longIndex ) raises( ::com::sun::star::lang::IndexOutOfBoundsException, ::com::sun::star::lang::WrappedTargetException ); my test code is : CComVariant dummyResult; hr = ExecuteFunc( m_ItemContainer, LgetByIndex, CComVariant(index), 1, dummyResult ); CComVariant arg[2]; arg[1] = CComVariant(index); arg[0] = dummyResult; hr = ExecuteFunc(m_ItemContainer, LreplaceByIndex, arg, 2, dummyResult); if(!SUCCEEDED( hr )) return S_OK; by debug, I doubt this is a bug of uno-com bridge, can anybody help me! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
