YAIM tips for YAIM maintainer on duty

Status of yaim core

  • See the YAIM status page for an up to date overview of the released versions.
  • If you need to include any important fixes that can't wait for a normal release, then check which is the yaim version currently in production and create a branch in CVS from the corresponding tag.
  • For a list of changes check the Changelog in CVS.

What to do if a new yaim core is needed because there's an important fix that you need to release inmmediately

  • Open a bug in Savannah.
  • Checkout the branch you would create from the last tag in production and apply fixes in CVS. Make sure the fixes are committed also to HEAD and take this into account for releases coming from PPS or being certified, they would also need to be modified to include the quick fix!
  • Use Eclipse or any other tool to compare your tag with the latest one in production. Make sure your changes are the only difference with the mentioned tag.
  • Build a new rpm in ETICS.
  • Open a patch in Savannah and link the corresponding bug.
  • Document the fixes properly in the "Release Notes" (New feature, new site-info.def variable, what services are affected and need reconfiguration, etc).
  • Update the YAIM guide if necessary (if there's a new site-info.def variable for instance).
  • Don't forget to make sure the new fixes are also commited in HEAD (to have a coherent version in HEAD)

What to do if an important bug is found while certifying a yaim core patch

  • Agree with the certifier whether you can reuse the same patch or if it has to be rejected and a new one has to be created.
  • In case, you reuse the same patch, put the patch into With provider and assign it to yourself.
  • Put a comment explaining the reason why a new rpm is needed.
  • Repeat all the steps explained in the previous section. Use HEAD to commit the changes.
  • Once the rpm is ready in ETICS, put the patch back to Ready for Integration.

What to do if a bug is opened for any YAIM module:

  • If announcing the issue is something that can save some time to other users experiencing the bug, and there's a workaround, open a Known issue in the relevant section of the YAIM guide. All the Known issues found so far are described there.

General for all YAIM modules

  • Try to keep the Changelog file updated for all the modules. This helps documenting the release notes when a new patch is created.

Things to check when a yaim patch has been certified

  • Check if there are new site-info.def variables in the new release: describe their meaning and whether they are mandatory, optional or have a default value.
  • Check if there are new functions/features: describe whether services need reconfiguration and provide the corresponding yaim command in case partial configuration is needed.
    • Check they are described in the release notes.
  • Bug and patch dependency
    • If a bug/patch is not fixed, consider whether it's critical and otherwise document the problem as a 'Known issue'.
  • Check possible comments written by the tester about the whole certification process
    • Document any possible problem as 'Known issue' in the patch and in the YAIM 4 guide - Known issues section.

-- MariaALANDESPRADILLO - 11 Mar 2008

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r7 - 2009-09-03 - MariaALANDESPRADILLO
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EGEE All webs login

This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright & by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Ask a support question or Send feedback