On Fri, Nov 18, 2011 at 2:56 AM, eric b <eric.bach...@free.fr> wrote: > Disclaimer: this list is not easy to read, and if the topic was already > discussed. In this case, thanks in advance to provide me the right link :-) > > Hi, > > I perfectly know the importance of the IP clearance, but in parallel, we'll > need to work on the code, say "partialy" (e.g. vcl + sd + slideshow only). > In OOo we used child work spaces in that purpose, but I'm not sure we > defined something similar yet with Apache OpenOffice.org. > > Obviously, some parts of the IP clearance could be achieved this way too. > > > Thus, my questions are : > > - what is the current strategy ? > - how does it work with svn ? And if there is something existing, is the > "methodology" available on the wiki ? > > > To contribute to the debate, I'd suggest several mnimalistic rules : >
This would work. The one downside is it encourages code to sit on a developer's machine until ready to integrate. So if a harddrive crashes or a laptop is stolen or whatever, the work is entirely lost. Reviews are also harder because we need to pass around large patch files. It also makes it impossible for more than one person to work on a larger new features. Maybe for simple cases this is fine. But for larger ones we could use SVN branches? I think branches in SVN are lightweight. So we could have a naming scheme, maybe using our Apache ID. So I could have a branch called "robweir_feature-name" and work on that until I am ready to integrate. -Rob > Methodology : > > 1. when starting working on a feature, an improvement or whatever, create an > issue, as "reference" : ( https://issues.apache.org/ooo/ ) > 2. inform the ooo-dev list with a subject like : [topic] working at > something > 3. if possible, try to describe the work in progress, on a wiki page. Sort > of a draft, containing the story, and/or whatever helpfull for the > developers. > 4. (crazy idea) : do an "IRC ClassRoom" around the topic ? (questions, > ideas, where / what in the code and so on, brainstorming, and keep the log) > > > Some examples from OOo4Kids wiki (to show the principle with the wiki): > > - How cursors work in OpenOffice.org: > http://wiki.ooo4kids.org/index.php/AddNewCursors > - Password protected preferences : > http://wiki.ooo4kids.org/index.php/PasswordProtectedPreferences > - Math sources description : > http://wiki.ooo4kids.org/index.php/ImproveMathEquationEditor/SourcesDescription > > As you can see, the point is not to write stupid administrative specs, but > to accompany the feature implementation, and invite to ask questions (and > answr them if possible). Plus share the knowledge, of course. > > > To improve the commit system : > > 5. before to commit, the commiter must build and verify the change will not > introduce a build breaker. Else, inform and ask for a review on the ooo-dev > list, in case of doubts. > > > > Thanks in advance, > Eric Bachard > > -- > qɔᴉɹə > Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page > L'association EducOOo : http://www.educoo.org > Blog : http://eric.bachard.org/news > > > > > >
