Tags:
create new tag
, view all tags

Minutes of Freetown Release Meeting, 2007-02-26

TOC and Agenda

Logistics, Participants, IRC log

1. TWiki Release 4.1.2 Coordination

  • Desired outcome: Decide release time frame; reprioritize items marked as urgent

  • Current release blockers, from Bugs:AllOutStandingItems
    • DONE Bugs:Item3567 - TablePlugin: css attributes priority of site/web preferences too agressive
      • Agreed the item is not a release blocker. It will require more time to fix it than we have for 4.1.2.
    • DONE Bugs:Item3652 - attachments to topic with umlauts in it are lost
      • Not a release blocker but since Michael had a great interest in seeing it fixed hard work and a lot of testing was done and it was fixed for 4.1.2.
        • This fix is fairly broken for some non-ISO-8859-1 character sets such as KOI8-R, but then the attachment URL code has been broken since 4.0... See comments below and on Bugs:Item3652 -- RD
    • DONE Bugs:Item3685 - Hidden mandatory form fields are no longer hidden in 4.1.1
      • Kenneth questioned if the bug was really a bug. Arthur explained that we did indeed have a bug and that TWikiForms says: "Multiple attributes can be entered, separated by spaces". The release meeting agreed that the bug should be fixed and the code work according to spec.
      • Kenneth looked at the code and it would take considerable effort to fix the new and not complete enhancement to the attribute field. Kenneth decided to roll back the original working code and ask the implementer (Thomas) to re-implement.
      • I shall attend to this issue (which results from an undocumented use of the attribute feature). I don't think it is appropriate for somebody to roll back changes for things that have not been determined a defect (certainly a non-documented use of a feature cannot be a defect)? -- TW
        • You obviously wrote the above without having read the attached transscript and without having read all of the follow-ups on Bugs:Item3685. Your code broke a documented feature and I as a release manager have every right to roll back buggy changes in order to maintain the code base on SVN stable. When you re-implement please track it on a new bug item as Bugs:Item3685 is now closed and in the release note of the released 4.1.2. And since it is an enhancement we'd keep this in MAIN only for a target release of 4.2. Do not get discouraged from having a feature rolled back. It happens to all of us and it is the conditions for an open source development owned by a community. We all have the responsibility to keep the code base stable and backwards compatible and bug free. And we all make bugs and mistakes. -- Kenneth
      • Well, I did read all the writeups, but I think the diagnosis is incorrect. I cannot see how the user actually entered the form as the examples are not reachable. But here is what really is going on: Long time ago, a defect was introduced which eliminated all spaces from attributes in the form definition. That was never noticed, as the only elements in the form were the H and M etc. characters. But it is clearly wrong. As a consequence, if a user entered multiple attributes, they would be condensed into a single string without spaces. That apparently is now in the topic as represented on disk. The challenge is: "what is the documented feature"? The documentation speaks about how to write the form, not what is stored on disk. But I understand the practical implications, and will write around this issue so that both the old representation and the fixed on work.
      • However, I reject the conclusion that the roll back is the correct way of handling this, as this brakes an accepted feature from 4.1. I will fix and the fix should be the correct handling. -- TW
        • The roll back decision was for 4.1.2 which was about to be released and had to be released very fast. In the bug item I wrote that I expected a re-implementation of the feature and you are very welcome to do that. Thanks for the analysis. Since we only had H and M as attributes it should not be too hard to write a work-around for this special case and get your new feature working with a better seperation between the attributes in the meta. KJL
        • Have already implemented the change and the special casing for H and M attributes being stored on disk in a non-standard way. As 4.1.2 is out, will generate additional test cases covering the various versions of attributes. The fix was three lines in Form.pm -- TW
    • DONE Bugs:Item3654 - Remove lib/LocalSite.cfg.txt
      • Not a release blocker.
        • Kenneth fixed it by implementing an altertive installation procedure using the existing TWiki.spec for non-configure installation. TWiki.spec is obviously always up to date so this is a better method and we avoid the mistake between LocalSite.cfg.txt and LocalLib.cfg.txt
    • Bugs:Item2960 - using utf8 breaks headline anchors
      • Not a release blocker. And it will take a significant effort to fix it and test it. It is a major or minor target release type of bug. Should be linked to other issues we have with TOC feature.
        • See comments below, simpler fix may be possible -- RD
    • DONE Bugs:Item3582 - Page loads unreasonable slow under IE with Twisty enabled
      • Agreed to remove the attachment twisty feature from 4.1.2 since Arthur does not have time to fix it in near future. May re-appear again in a later release.
    • Bugs:Item1742 - Support simultaneous edits in WysiwygPlugin
      • Targetted for a major release.

  • Additionally the following waiting for feedback items were discussed.
    • DONE Bugs:Item3443 - SEARCH performance under mod_perl is awful
      • Kenneth had rejected this from 4.1.1 because the feature was not stable yet. But now it seems to be and the minimal needed doc is there. And the feature has been tested at two of Crawfords clients. Agreed that feature is stable enough for 4.1.2 and that Crawford merges in. - Done!
    • DONE Bugs:Item2953 - Meta data ignored by TWiki::Func::checkAccessPermission
      • No brainer. Confirmed that existing plugins are compatible with the extra parameter. Agreed to merge it in. Kenneth did this right after.

Timing for 4.1.2

For a not yet disclosed reason the 4.1.2 have to be release ASAP. 4.1.2 was released Saturday the 04 Mar 2007. Upgrading ASAP is highly recommended.

2. Review Proposed Features

  • Desired outcome: Decide on feature items that are ready for the release meeting

  • Release process is: TWikiRelease04x01Process
  • Tracking topic is: TWikiFeature04x02
  • Kenneth is looking to add at least two more people - preferable non-developers to share the role as customers advocate
  • Need to update the TWiki application so the process becomes less manual
  • Sam Hasler announced that he no longer have time to contribute to the TWiki project. The TWiki community thanks Sam for all the good work smile This means that someone else will have to work on the feature tracking TWiki app.

  • Proposed feature items: Lack of preparation and time made the meeting look at the most urgent of the proposals.

  • AddTWikiAdminUser - Kenneth suggested a principle decision of the feature itself - not the implementation.
    • The release meeting agreed that the feature would be a great enhancement and that it is worth for Sven to continue working on the implementation
    • Implementation problem to watch out for were brought up
      • If we have a fixed name for the initial admin user - then it becomes difficult to authenticate this person when you use LDAP authentication and do not have any influence on a corporate LDAP server. Ie. you are not allowed to add users to this LDAP server. You only have one account for each employee. In this case it will be better to define the login name of the admin user in configure
      • If you define the admin user name in configure then configure will have to write the name of this user in the {SuperAdminGroup} topic and keep this group topic editable only to the {SuperAdminGroup} to maintain the idea of the proposal.
      • For more details see the attached transscript 14:39
    • Suggestion: Rename existing TWikiAdminGroup user to TWikiSuperAdmin for generic admin account. PTh
      • TWikiAdminGroup is not a user. It is a group. And it is important for compatibility that this group name stays unchanged. What we need and what the proposal is about is to create the first admin user in configure and this user and his password should be the same for configure and for Twiki. This is because the first step of registering a user, and making him an admin by manually adding him to TWikiAdminGroup is one of the most common difficulties newbie admins have, and they are often confused that the password they give in configure has nothing to do with the admin user in TWiki itself. Sven's proposal was to let the user created in configure be the first admin in TWiki with same password. The implementation of how to do this is what people are working on now but all have agreed on the basic problem and the idea of the solution. But please keep the TWikiAdminGroup as the default {SuperAdminGroup} for compatibility and upgradability KJL
  • ControlOverVariableExpansion
    • All agreed that this would be a great feature with much more potential then just the original proposal.
    • A key comment: "the scope of the initial implementation can be as narrow as you like, as long as the design is open and generic"

Action Items

  • DONE Kenneth: For Bugs:Item3568, auto create the /tmp/twiki directory if it does not exist.
  • DONE Kenneth: For Bugs:Item3564, test and fix TWiki to support Perl 5.6.1
  • Peter: Create a TWikiBetaTesting topic in Codev, with info for beta testers.

IRC Log

Back to: FreetownRelease

Comments / Feedback

Kenneth adds the minutes the day after the meeting!

-- KennethLavrsen - 26 Feb 2007

I added the log; meeting minutes are pending.

-- PeterThoeny - 02 Mar 2007

My apology for the late minutes. I had to put priority on the release work for 4.1.2.

-- KennethLavrsen - 04 Mar 2007

The fix for Bugs:Item3652 is fairly broken for non-ISO-8859-1 character sets, but then the attachment URL code has been broken since 4.0... See comments on Bugs:Item3652.

The place to fix this is in the TWiki.pm code, which has a nice SMELL comment on urlEncode that highlights the issue (although the comment is wrong - all that's needed is to URL encode in current site character set, e.g. KOI8-R.)

Also, Bugs:Item2960 may have a simpler fix than I first thought - just create a langAlphabetic boolean config option, and if this is set to true you can exclude any non-alphanumeric characters (more or less) from the anchor, including I18N characters I think. For Chinese etc, this would be configured off, and more characters are possible. However, I haven't really gone into this so I could be over-simplifying.

-- RichardDonkin - 04 Mar 2007

Topic attachments
I Attachment History Action Size Date Who Comment
Texttxt FreetownMinutes2007x02x26.txt r1 manage 40.0 K 2007-03-02 - 04:22 PeterThoeny Freetown Meeting Minutes 2007-02-26
Edit | Attach | Watch | Print version | History: r16 < r15 < r14 < r13 < r12 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r16 - 2007-03-05 - ThomasWeigert
 
  • 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.