Tags:
create new tag
, view all tags

Minutes of Edinburgh Release Meeting, 26 Jun 2006

Logistics, Participants, IRC log

Agenda

  • Review Previous Action Items
  • Next Release 4.0.4 or 4.1
  • Next big release focus
  • Visibility of hotfixes for our releases
  • Removal of WebPreferences (an admin-oriented item) from normal users' left bars

The actual TOC:

1. Review Previous Action Items

  • TWiki Doc Users Focus group:
    • Yes / Done Establish good old conference call. DONE - first meeting was on Fri 2006-06-16
    • Summary: We will create drafts of twiki.org home, Plugins home and Support home. We'll leave Codev as is for a while. The doc group has a playground web to avoid confusing our users with unfinished work. We will make is public ASAP. There is a strong wish for that.

  • TWiki 4.0.3
    • Yes / Done Kenneth Lavrsen makes a Release Candidate.
    • Yes / Done We kindly ask Sven to step in a do the real build of 4.0.3 this coming weekend.
    • Yes / Done Kenneth will update TWiki.org when release is ready.
    • Lessons learned:
      • For next release we need to automate making the -changes file.
      • And we need to make it as part of release candidates so we can test that also

2. Next Release 4.0.4 or 4.1

  • Desired outcome: Decide release level (patch or minor release); review feature candidates for 4.1; timeframe

Short summary for the discussion.

  • The past two release we have discussed if the next release should be called 4.0.X or 4.1. We have now released a 4.0.3. If we look at the bug fix list, the bugs are many but compared to 4.0.0 - 4.0.2 the bugs are more "narrow scoped" and "borderline cases" which the normal user would never notice. So 4.0.3 should be a relatively stable release. I (Kenneth) spent round 16 hours testing this weekend while Sven was preparing the build and I found only a minor configure cosmetic issue. I think 4.0.3 is going to be a good release.
  • DEVELOP has many new features pending. No revolutions. But enhancements that the community agreed should not go into a patch release. There are also many proposals for major changes in TWiki but none really starting being implemented.

The proposal I (Kenneth) want to put forward is.

  • Current TWiki4 branch officially changes scope from 4.0 branch to 4.1
  • We cannot guarantee that there will not be a major showstopper bug or security issue that requires a very quick 4.0.4. I propose if a major super-urgent issue happens we take the 4.0.3 tagged release and create a quick branch - implement only the hot fix and release the 4.0.4. But the plan is that next release is 4.1.
  • Features we agree should be in 4.1 which are already in DEVELOP are merged into 4.1 the next weeks so we can start power testing them. DEVELOP has not been tested by many so we should expect stability problems.
  • DEVELOP contunues to run with a 5.0 type scope.
  • A target release date for a 4.1 is earliest in September with a first beta in August. Summer vacations generally means people are outside and on vacations. It is not realistic to expect huge efforts in July. This is quite normal in open source projects.

Decision

  • It is agreed that TWiki4 branch is now the 4.1 scope branch

3. Next big release focus

  • Desired outcome: Gathering fresh input, or pick a date when to do this.

  • CDot proposed a major update and improvement of configure script which includes download and installation of extensions. Could also be extended to installing hotfixes.

  • Process: Many proposals on the Air. We need proposal developed on Codev. Crawford made WhatIsIn04x01.

  • Timeframe: Beta in ultimo August and release primo September.

4. Visibility of hotfixes for our releases

  • Desired outcome: Revisit current practice, brainstorm on improvement

  • Current practice is to create a new topic for patch patches and listing it in the known issues topic
  • Kenneth on IRC: Why do we hide patches for known issues so people can hardly find them? Does it really give a bad impression that they are visible on the download topic? Or is making hotfixes available a signal that we care about our customers? If you look at the download page I can see that recently the line "Read also the known issues topic." has been added just below the table of files so it is pretty visible now.
  • My suggestion is to add all relevant downloadable files to the release topic table - see current table in TWikiRelease04x00x03 "Release complements and fixes" so it becomes clear (without needing to look any further) what files are needed to run the most stable and secure TWiki. -- ArthurClemens - 26 Jun 2006

Follow up questions to think about

  • Is our known issues topic visible enough?
  • Is the minor patch for the CSS fix for 4.0.3 too visible?
  • On known issues - Are links to bug reports enough for admins to not only know about problems but also to fix them adequate? Can the average admin dig a patch out of a SVN repository?
  • Should we in general - when a bugfix is broad and important - be better at making small hotfix patches available for download? We do it with those emberassing bugs we find a few hours after a release. But once some weeks have passed even huge requirement type bugs are only fixed on SVN with no easy path for admins to install a hotfix.
  • And if we decide to make more hotfixes (maybe of the 5% top severe bugs fixed)? (We will not have time to make them for every fix we make. Only very severe issues that impacts many should we make them)
  • Should hotfixes be stored away in a known issues topic?
    • Should they be buried in the known issues topic?
    • Should they be listed very visible below the distribution downloads?
    • Should they be in a hotfix topic which is linked to right below the table with the distribution downloads?
    • Other ideas?

When I look at products such as Linux distributions, Windows XP, BIOSes for motherboards, major open source programs, etc, the hotfixes are rarely displayed with the same emphasis as the main product. But the products I (Kenneth) consider well supported have them available very visible and never hides that there are updates available.

When the number of hotfixes get large I prefer that they become accumulated in service packs. I do not think TWiki needs to go that way. Our patch releases are our service packs.

Kenneth proposes

  • Developers make more hotfixes then today. But keep the number low. A total of 10-15 should be what I would expect on a given release before the next release is out.
  • List of available hotfixes is displayed on the download topic - in a secondary presentation that does not take emphasis away from the main download and max one description line per hotfix with a link to a more detailed hotfix topic - which can be a new hotfix topic we make or section in the known issues topic.
  • There are no detailed rules and no obligation to create hotfixes - and no official approval or consensus process to upload one. If a developer thinks a particular bug is so severe and urgent that it cannot wait for next release - he can make the hotfix and add it. I am sure the balance between responsibility/customer-focus and lazyness/lack-of-time will keep the right balance in practical. As long as we have a simple infrastructure on the download topic or hotfix topic so it is easy and fast to do it. Hotfixes shoud be replacement files and may contain previous hotfixes when necessary. Unified diff type patch file hotfixes are for geeks only! Windows users do not know the patch program at all. Admins are not developers in general!!!

5 Removal of WebPreferences (an admin-oriented item) from normal users' left bars

No additional notes.

Decision All agreed to hide the link on _default, Main and Sandbox webs but not TWiki web.

Action Items

  • Kenneth: Invite for Doc meeting
  • Peter: followup on 4.0.3 release incl index.html update
  • Martin? Make link to WebPreferences conditional in all distro webs except TWiki web so only the TWiki Admins will see the link.
  • Harald: Investigate further the VarXXX topics and their linking. Including creating VarTopics for TWikiPreferences defined vars: OrganizeTWikiVariables
  • Crawford: Will draft a Codev topic on the process that the rest can comment on. - DONE WhatIsIn04x01

  • Next meeting is 03 Jul 2006 - 19:00 GMT, 21:00 CEST. There was not enough time for item 4 which will be discussed a week from now.
  • Meeting following that: Sven proposed time.

IRC Log

Back to: EdinburghRelease

Comments / Feedback

Edit | Attach | Watch | Print version | History: r9 < r8 < r7 < r6 < r5 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r9 - 2006-06-27 - CrawfordCurrie
 
  • 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.