8/8/2019 dev_model

1/7

GNU MyServer hacking guide

1 Introduction

This document is an introduction to how develop GNU MyServer and interactwith other team members. It is not and it doesnt want to be a complete guideto be a programmer but only an introduction to the development model usedby this project. The figure 1 shows the GNU MyServer development process.In short, at every loop some objectives are planned and a new release will beout when they will be completed. Before the final release is completed, someminors releases are done on specified dates, no matter if planned objectivesare already completed or not.

This development model is not test-driven because write tests and developcode are parallel processes. If somebody finds test-driven a better choice

then he or she is free to adopt it, it is a personal choice, in any case code iscommitted to the central repository after it is compilable and it is validatedby all tests. The central repository at any time must contain a snapshot ofthe current development status and it must be compilable and usable.

Differently the bugs fixing process is test driven, when a bug is detectedit should be reproduced by a test. After the code is modified to validate alltests, including the new bug test. Objectives are replanned after a bug isfixed because there can be need to release immediately.

Before the release, code can be changed until it reaches a good readablestatus (refactoring).

2 How start hacking

The first step to take before be a MyServer hacker is to fetch latest sourcecode version from the subversion version(section 6) and be able to compile it,

1

8/8/2019 dev_model

2/7

only after you are able to compile and execute MyServer you can think about

modify its source code. To be updated about the MyServer developmentthe best idea is to join the mailing lists (section 5), it is not required topartecipate actively there, reading what other members are discussing is agood way to be introduced to the project; hopefully after some time you willbe very active there too.

3 Tracking systems

3.1 Tasks list

Planned tasks are defined by the tasks manager here: https://savannah.gnu.org/task/?group=myserver .

There are two categories of task: task and wish. The former specify aplanned task that must be completed. Once all planned task are completedthen a new release will be done.

Task that are in the wish category are not considered for the release.Any task should be a basic task, in a way that a developer without a

previous knowledge of the software can start working immediately on it.In the past the TODO list files used to be a wish list with tasks like

Implement the FTP protocol, such big tasks must be avoided and replacedby smaller and more detailed ones, that can be done in few hours. Have these

macro-tasks means that the feature is not well designed or not designedat all and it is a good idea to plan a design for it before start workingon its implementation and discuss it on the mailing list with other teammembers. Lately it will be possible to define small tasks and proceed withits implementation.

On a bug fix it may be possible to release before other tasks are completed,thus all planned tasks that are not completed yet will be moved to the nextrelease.

3.2 Bug tracking

Any bug should be notified using this bugs tracking system: https://savannah.gnu.org/bugs/?group=myserver . When it is possible, a test forthe bug must be provided, it will be useful for regression tests as the samebug can appear again in future.

2

8/8/2019 dev_model

3/7

4 Source code guidelines

4.1 License header

Any source file must start with the GPL license header. All the source codeis copyrighted to the Free Software Foundation Inc. You can take the headerdirectly from existing source files.

4.2 Code format

This simple code snippet shows how format the code and how indent it.Dont use the tab character to indent it, instead use 2 blank spaces.

// i n c l u d e / f o o . hc l a s s Foo{p u b l i c :

Foo() {}i n t max( i n t a , i n t b ){

i f( a > b )r e t u r n a ;

r e t u r n b ;}i n t longMethod () ;

p r i v a t e :i n t bar ;

} ;. . . ./ / s r c / f o o . cp pi n t Foo : : longMetho d ( ){. . .

r e t u r n bar ;}

3

8/8/2019 dev_model

4/7

4.3 Writing code suggestions

These are some simple rules to keep in mind writing code:

Short methods, avoid long methods.

Add comments only when there is really need, code should be cleanitself, have many comments will make it more difficult to maintainbecause any change in the code must be duplicated in the comment.

Add a doxygen compatible comment to every method, this is the onlykind of comment that should be always present, more informationabout doxygen can be found here: http://www.stack.nl/dimitri/

doxygen/. Try to avoid mock objects during testing, base classes can be imple-

mented to dont do anything, if you dont know what a mock object isthen take a look here http://en.wikipedia.org/wiki/Mock object.

Possibility to use unit testing as code snippets for APIs, tests codeshould be as much clean and readable as possible.

Make the code breathe, add blank lines to separe different sections andmake it clearer.

In general any code smell should be considered too, you can find some ofthem here: http://c2.com/cgi/wiki?CodeSmell .

4

8/8/2019 dev_model

5/7

Write tests

Develop

classes

Tests

validation

Commit code

Check

objectives

Release

Refactoring

Achieved

Plan objectives for

next version

Not Achieved

Bug

Reproduce it with

a test

Fix the code

Replan

objectives

Figure 1: Development process

5

8/8/2019 dev_model

6/7

5 Mailing lists

The communication with other project members is fundamental and whena message interests everybody then it should be sent on the dev mailinglist, you can find a list of the mailing lists here: http://savannah.gnu.org/mail/?group=myserver .

Actually there are two mailing lists:

bug-myserver@gnu.org Differently from what the name can suggest, itis not used only for bugs but for any development related discussion.

myserver-commit@gnu.org It is a read-only mailing list, any committo the repository is notified here. It is not only a way to annouceyou that something happened but it has a very important role in thedevelopment process. Review patches by humans is done at this point,after the commit happened, more eyes can notice better if something iswrong. If you notice that something is not as it should be, then reply tothe bug-myserver@gnu.org adding the developer who made the commitin CC, explaining what you consider wrong.

6 Subversion repository

6.1 BranchesIf there is need to change many things in the source code, like for examplewhen we implemented an event driven scheduler, that changed several classesin different sections of the code, then it is a good choice to create a branchfrom trunk. After the job is completed in a way the branched version isworking well and it is validated by tests then it can be merged back to thetrunk tree. For branches it is not valid the rule that it should work at anytime or validated by tests as they are experimental versions. In general thedeveloper who created the branch is responsible for the politic to follow.

6.2 Access the repositoryYou can find information about how access the source code repository here:http://savannah.gnu.org/svn/?group=myserver .

6

8/8/2019 dev_model

7/7

6.3 Commits

A commit to the repository shouldnt contain two or more different modi-fications to the source code. Every commit must be logical different thanother ones, any different modification must stay in a different commit. Use ashort but descriptive commit message, the ChangeLog file is not maintainedmanually as it is possible to retrieve it using the commits history. The svn2clutility can generate a GNU compatible ChangeLog file.

7