View
215
Download
0
Category
Preview:
Citation preview
Developing for OpenOffice.org / How to contribute - Slide 1
OOoCon 2005 - Koper
Developing for OpenOffice.org
(aka How to Contribute)
Developing for OpenOffice.org / How to contribute - Slide 2
Agenda
Speaker IntroductionContributions to the OOo projectThe JCA and other stuffA new/different development processChild workspaces in practiceChallengesQ & A
Developing for OpenOffice.org / How to contribute - Slide 3
Who I am
Joined the StarWriter 2.0 Team in 1994Program Manager OpenOffice.org / StarOfficeProject Lead ToolsProject Lead PortingProject Lead External Member of Community Council“Ratte”: Release Mgr of SRC680 code line
Developing for OpenOffice.org / How to contribute - Slide 4
Contributions to OOo
Use the productDownload, install and use OOo
http://download.openoffice.orgGive feedback via Survey
http://www.openoffice.org/welcome/regitsratrion-site.html
Donate money or other resources
http://www.openoffice.org/contributing/donate.html
Join a projectReview work, give feedback via mail, IssueTrackerRequest for enhancements, input for specifications
ParticipateSubscribe to mailing listsAsk questions and give answers
Wiki on ooo.services.openoffice.org /go-ooo.org
Developing for OpenOffice.org / How to contribute - Slide 5
Contributions to OOo
Become a QA expertUse the the latest snapshots (biweekly snapshots)Review and file new issuesWork on test plans
Core DevelopmentAdd new functionalityPorting
DevelopUse the APIComponentsCompile and review the code
LocalizeNew localizations
Developing for OpenOffice.org / How to contribute - Slide 6
The JCA and other stuff
Code contributionsSign the JCA for changes or additions to the code basis or localization
External componentsCode: LGPL, BSD style
Get documented within external projectOther artifacts
Licenses compliance
Developing for OpenOffice.org / How to contribute - Slide 8
Software Development
PreparationWriting a SpecificationPlanning a change
VerificationQA with a testplanDoes the beast compileRegression/automated tests
ImplementationCoding Hacking
Developing for OpenOffice.org / How to contribute - Slide 9
OOo complexity
The PlatformsUnix (Linux, Solaris, MacOSX, FreeBSD and other)
Different baselinesWindows
LocalizationUI-FreezeLayout
The Code sizeThe beast need hours to build (interface changes)It's a moving target (several hundred code changes per day)Architectural dependencies (layered arch.)
Developing for OpenOffice.org / How to contribute - Slide 10
The traditional model
Continuous integration and buildDeveloper has to stay until their changes has been build and smoke tested (tinderbox builds)The build has to be fixed immediately
Make a Release stableUntil it is ready/bug free
Release early and oftenEarly and often releases ensures quick bug findings
Developing for OpenOffice.org / How to contribute - Slide 11
The problems with the traditional model
Continuous integration and buildToo many changes within a build cycle The problem of not having atomic commits
Make a Release stableCan be an unpredictable process
Release early and oftenA developer wants user to test codeA user wants already tested code and not extra burden writing bugs
Developing for OpenOffice.org / How to contribute - Slide 12
The OOo 2.0 numbers
>100 developers committed to the repository
Fixing > 4000 issuesReported by > 500 people
Committed > 100,000 times450 files per day
Developing for OpenOffice.org / How to contribute - Slide 13
The new process
Continuous commitsQA after integration Having known problems in the master buildFeatures which are not finished get into the tree
Scheduled commitsQA before integration into the code lineHave less problems on the master build A new feature only get integrated when it is readyPossibility to reschedule target milestone of a feature
Old New
Developing for OpenOffice.org / How to contribute - Slide 14
Child workspace
A child workspace is implemented as a CVS branch
Developing for OpenOffice.org / How to contribute - Slide 15
Cws resync
A cvs branch can be merged backed without conflicts only if now conflicted changes has been done in the meantime“Long” living cws will need a resync first before joined back
Developing for OpenOffice.org / How to contribute - Slide 16
Tools for cws
Create a new child workspace – cwscreateAdd a new module – cwsaddUpdate a child workspace – cwsresyncAnalyze a child workspace - cwsanalyzeRegister a new task – cwsaddtaskEnvironment Information System (EIS)
http://tools.openoffice.org/dev_docs/ooo-cws-tools-doc.sxwhttp://eis.services.openoffice.org
Developing for OpenOffice.org / How to contribute - Slide 18
Child workspace creation
Create a new child workspaceRegister in database in EISWhat's the purpose ?
Provide a description
What level of QA is needed
UI relevant
Help relevant
-> Specification needed ?!
Timeframe
What are the impactsRegarding the user experience ?
To other developers ?
Developing for OpenOffice.org / How to contribute - Slide 20
Cws lifetime
The quick thing (less than one day, some days)There's no impact, it just fix the damn thing
Trivial bug fixes
Build problems
The big thing (months or years)New functionality
Leads to new UI, translation is needed
Needs documented in Help, Documentation
Specification is needed
New architecture Other developer need to know about these changes
Developing for OpenOffice.org / How to contribute - Slide 25
A better solution
Continuous integration and buildSimulate atomic commits of file setsGroup issues to logical entities
stable ReleaseMinimize the time needed to make the product stableBe able to release a stable code base at any time
Release early and oftenRelease often already tested codeIt does not matter if a features gets in weeks earlier or later
Developing for OpenOffice.org / How to contribute - Slide 26
Challenges
Experimental code linesDevelopers requires to have experimental code tested broadlyMore than one build is required
Communicationhttp://www.go-ooo.org/ooo-build.htmlBe honest, speak about pro's and con'sTalk with each other, make sure that you get understood by your partner
Specification process Which Criteria make a specification necessaryIn which cases a test plan, documentation or just comment in the source code are sufficient
Developing for OpenOffice.org / How to contribute - Slide 27
Experimental code line
Work with #ifdef for experimental codeHigh maintenance costsGets horrible if you get staggered ifdef cascades
Cascading parent/child conceptscales
Dependent MasterResync after every new milestoneExit criteria must be clear
Open Question: Single or multiple cws integration ?
Developing for OpenOffice.org / How to contribute - Slide 29
Source Control System
Is CVS perfect for OpenOffice.org ?Which problems we do have with CVS ?CVS vs Subversion ?Are there other alternatives (distributed Source Control) ?
Developing for OpenOffice.org / How to contribute - Slide 30
Team Work
Common understanding of Users, Developers and QA how a feature is intended to workDocumentation of why decisions have been made about controversial issueshttp://specs.openoffice.org/collaterals/Specification_template.stwhttp://specs.openoffice.org/collaterals/OpenOffice_org_Specification_guide.sxw Different levels of specifications:
SpecificationTest planComments in Source Code
Developing for OpenOffice.org / How to contribute - Slide 31
ToDo's and the vision
Experimental / QA code lineInteraction with community
Tweaking the Specification ProcessRequests of Enhancements
Planning ReleasesGet quick cws round trips for “need to have” thingsSpeed up the patch process
Patch Gatekeeper wanted
Get automated tinderbox builds for cwsQA wanted to test before integration
Enhance smoketest and automated test and integrate them into the build system
Recommended