create new tag
, view all tags

Minutes of Edinburgh Release Meeting, 03 Jul 2006

TOC and Agenda

Logistics, Participants, IRC log

1. Review Previous Action Items

  • Kenneth: Invite for Doc meeting No meeting held
  • Peter: followup on 4.0.3 release incl index.html update - DONE
  • 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

2. 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 than 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!!!

decision: Arthur to propose a compromise download topic which balance presentation with overview over available extra downloads

3. Next big release focus

  • Desired outcome: Gathering fresh input.

  • 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.

  • Main topic that was brought up was better editing for our users

  • Second topic was performance

Action Items

  • Kenneth to schedule a meeting in doc group.
  • ALL: Give Harald more feedback on Codev topic concerning VarXXX topics: OrganizeTWikiVariables
  • Crawford: draft release manager role in codev, with responsibilities and criteria for decisions - DONE TWikiReleaseManagerRole
  • Arthur: Create an improved download page with better balance between main download and Release complements. May choose to do a test download page with 10 imaginary hotfixes.

  • FIXME Next meeting


Back to: EdinburghRelease

Comments / Feedback

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2006-07-07 - PeterThoeny
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.