Request For Comments

Summary of ideas from issues #62 and #164

Different means of infrastructure for discussion (forum, wiki, mailinglist) have been suggested. Until now, discussion is done within issue comments.

People agree that "some sort of planned releases" should be implemented.

Some mentioned that - in addition to the "smoke tests" that are currently conducted - more formal test methods like unit tests, integration tests and planned system tests should be implemented and executed regularly, at least before a version goes to th emarket.

Different ideas for release schedules have been mentioned, two to four weeks seems to be common-sense, but people like to focus more on features than on specific dates.

Different version numbering schemes have been suggested. Latest market release is called "15.08.2011" externally and "20100815" internally.

It was suggested to use tags to mark those versions that go to the market.

If you don't mind, pleas take your time and give a brief comment on the followin request for comments. Please add your comments inline on this page. If there is a need for more discussion on a specifit topic, we can do that on a separate wiki page.

RFC: discussion - forum vs. wiki vs. mailinglist

BFKC I think that the wiki is enough. For me, benefits from a 'real' forum cannot compensate the overhead for swithing between different tools or websites. Suggestion: use the wiki for discussion.

rsudev As I use tabbed browsing heavily I do not feel overhead by using another website. But a forum makes it much easier to discuss, as all entries are automatically tagged with an author and a date and easily distinguishable without any work on my side when commenting.

RFC: release planning, time schedule

BFKC I think we should try to stick to a time schedule of two to for weeks between market releases because users shall recognize c:geo as an actively developed application.

rsudev I agree that this as a viable target. Especially if we split up branches between 'released, receiving bugfixes' and 'new features' it should be relatively easy to push out bugfix releases frequently.

RFC: testing

BFKC I think we should do more intensive (and if you want to call it such: more formal) testing before market releases. Refactoring work will imply large changes to the code and we shoul not publish unstable versions to the market. For the same reason, I would strongly suggest to set up separate branches for releases and feature / refactoring work. We should allow the "release versions" some time to be tested and bug-fixed while refactoring and implementation of new features should continue on separate brances.

rsudev Agreed. We should have a set of operations that define the core functionality and that we want to test before giving a version to market. The non-interactive parts (e.g. cache-download) should be automatable.

mintbridge What about setting up a hudson/jenkins ci server that can monitor the build and test status of the branches, that can be triggered on commit?

RFC: version numbering

BFKC I would have preferred "simple" version numbers like "2.1" for market releases, because people would have had a chance to realize that a change from 1.1 to 1.1.2 would probably contain just a small bugfix while for 3.0 he would expect new features. With the new scheme, it is more or less impossible to estimate the "size" of the change by just looking at the version numbers.

rsudev I'd prefer a 'traditional' versioning scheme as well. If we tag the source that goes to market this is also easily connectable to our development. I am not sure how much 'interpretation' should go into these numbers, as 'small bugfix' and 'new feature' can be perceived very differently.