Tags:
create new tag
, view all tags

Minutes of Freetown Release Meeting, 2007-05-28

TOC and Agenda

Logistics, Participants, IRC log

0. develop.twiki.org

  • Action item: Get develop.twiki.org up again. Peter to call again.
  • Action item: Sven: When develop.twiki.org is up again all core team members need access to the server with full sudo rights. We cannot be dependent on only having Sven admin the server. There has been too many periods with no actions.

1. Action Item Review

  • All. Implement accepted feature proposals before 28 May 2007 - or defer them to Georgetown (5.0)
  • DONE Peter: Create a TWikiBetaTesting topic in Codev, with info for beta testers.
    • Need to do this before next release. Need to recruit beta testers.

2. Review Proposed Features

3. Coordinate TWiki Release 4.2

  • Desired outcome: Confirm code freeze date, tentative schedule for 4.2 release

The plan from previous release meeting:

  • Feature freeze (last day to checkin new features): Monday 28 May 2007.
  • Beta release: 17 Jun 2007
  • Earliest release date (can be delayed if too many bugs are open or tests fail): 30 Jun 2007

And all other proposals that are not yet agreed or not yet implemented are deferred to Georgetown or in other words, anything that's not implemented as of now, is automatically deferred to 5.0

4. Change "Proposed For" field

  • Desired outcome: Community decision on use of "Proposed For" field

CrawfordCurrie: Can we please change the way the releases are listed in the "Proposed For" field in the Codev forms? I want to be able to propose a change for the next patch release, for the next minor release, or the next major release. I don't care what the number is, and I don't care what it's called; I only care that it's the "next release" at that level. This approach also lets us carry items over more easily without the risk of losing them.

  • We forgot to discuss this one. I agree. But I would not look at if it is minor/major. Just two values. One for the next release. And one for the following. It will be an exception to the rule to role new features into patch releases that are so large that they require more than a simple bug item. -- KJL

The proposal was discussed and rejected. Only Kenneth supported it. We continue with the current explicit release name approach. Kenneth will update the proposal targets so they are correct.

5. Need to increase the code quality

Desired outcome: Developers thinking about how they behave in the community.

The number of bugs is extremely high at the moment and running MAIN is often a challenge because of many basic features are broken.

I can see that hardly any of the new contributors have contributed the past months and I think the main reason is to be found in how old developers behave - as developers - not as humans. You are all a bunch of crazy but nice guys.

We have a very well written DeveloperResponsibilities document. Here are some quotes from it - mainly by Crawford.

  • "It goes without saying that all changes should be tested before, and preferably after, check-in."
  • "If something breaks, fix it"
  • "Revert your changes that are inappropriate"
  • "Run the tests ... If they break as a result of your change, find out why and fix it. If the tests don't run on your platform, find out why and fix it."
  • "Revert other people's changes that are inappropriate"

I see mainly these problems.

  • People add more and more features instead of fixing those that have already been committed.
  • Features are not tested properly before they are checked in. Unit tests is not enough. You need to functionally test - with real realistic test topics.
  • Features are committed to SVN in small incomplete chunks. Subversion is often used as a scratch pad. Finish the code before you commit.
  • Features are committed to SVN without fixing unit tests first. Broken units tests become an excuse for other developers to not run them either because a unit test run is a complete mess of noise and errors.
  • People are not prepared to react when other community members notify them that new code breaks something else. You should either fix immediately or revert the change and commit it back later when fixed.

Above was presented and noone disagreed.

Action Items

  • Get develop.twiki.org up again. Peter to call again.
  • Sven: When develop.twiki.org is up again all core team members need access to the server with full sudo rights. We cannot be dependent on only having Sven admin the server. There has been too many periods with no actions.
  • Kenneth changes all proposals not yet implemented to Georgetown.
  • Peter: Need to do this before next release. Need to recruit beta testers

IRC Log

Back to: FreetownRelease

Comments / Feedback

I removed Sven and CDot from the participants. Putting an IRC client in read only mode is not participating. It is disapointing that people that have proposals on the agenda do not show up. If you want us to try a different time or day for the release meetings then let us know. These release meetings are the place where the important decisions are made.

-- KennethLavrsen - 29 May 2007

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2007-05-29 - KennethLavrsen
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.