EMT discussions/decisions

Managing packages in EMI & EPEL

Discussion tracked in action #21172

The following decision was taken during the PEB-F2F meeting, 25-26 July 2011, CERN (to be tranformed into an EMI-EPEL policy (??)):

  • the present EPEL-maintainer of the majority of EMI-developed/maintained components will request approval before implementing any changes that will require new versions of packages to be uploaded to EPEL, explaining why the changes are needed and what the changes are about
    • approval request will be done through a GGUS tkt, category "Change Request", that should be assigned to the corresponding PT SU, that is developing the affected component
    • PT must acknowledge receiving the request and must answer if it agrees or not with the changes and new components version.
    • only if a positive answer is received from the PT the EPEL maintainer can continue implementing the change and submitting the new packages to EPEL.
      • In parallel the PT will start implementing the suggested changes also to EMI components, tracking this activity by opening a corresponding RfC in the PT internal tracker. The priority is decided by the PT, but, unless proven differently, the recommended one is "Medium".
      • the GGUS tkt will be treated as any other GGUS tkt - put in "On hold", attaching the RfC, and "Solved" only when the new components are available in EMI repository.
    • in case of a negative answer the PT should justify it with valid reasons
      • rejection reason should be discussed and once an agreement is reached between the EPEL maintainer and PT, the GGUS tkt will be closed as "Unsolved". No changes will be implemented and submitted to EPEL.
    • packages prepared by the EPEL maintainer will be checked by the PT to verify that they don't damage the EMI release or the software being repackage. The technical details on how this will be implemented are still under discussion
  • During the EMI project lifetime no packages developed and maintained throughout the project will be made available directly to EPEL
    • all EMI products will have consistent releases, according to EMI policies;
    • only after products are released within EMI, for the packages that are considered EPEL-compliant, the respective PT can claim the ownership and further maintain those packages also in EPEL.

Managing JAVA APIs in Maven Central

How to use Java in EMI

ETICS Maven build optimization

As discussed at the 19.12.2011 - EMT meeting here is the wiki page describing how EMI maven builds on ETICS can be optimized:

All PTs that build their components with maven are adviced to check if the maven settings work well for their build and let us know if something doesn't work as expected.

"orphan" components for EMI 1

Information taken from emi-emt action #18995:

  • Status at 2011-06-06:
    • LSF released, fully supported by CERN
    • PBS/Torque+Maui released, supported on best effort by NIKHEF, looking for a solution to move it to full support
    • SGE not yet released, planned for release in mid-June, supported by LIP as external contributor
    • Condor not released, no current plans for a release, ongoing discussions with the Condor team in Wisconsin to see whether they can be involved
      • missing information-providers and yaim-configuration

Status of components assigned by PTB to the gLite job management PT but not under INFN responsability:

  • lcg-tags and lcg-ManageVOTags:
    • Responsible persons identified: Marteen Litmaath and Andrea Sciaba` (Cern)
  • lcg-info-dynamic-scheduler-generic:
    • Responsible person: Jeff Templon (NIKHEF) communicated that he will keep maintaing it. but we will have to help him with ETICS
  • lcg-info-dynamic-software:
    • Assigned to CERN by PTB, Responsible person: Laurence Field
  • LSF info provider:
    • Assigned to CERN by PTB. Not clear yet who will maintain it
  • Torque-utils (info provider, yaim module, metapackage):
    • Assigned to NIKHEF by PTB. Not clear yet who will maintain it
      • Concerning the component emi.lrms-utils.dynamic-scheduler-generic gLite JobManagement PT is working with Jeff Templon on the restructuring of the build commands for ETICS
  • SGE binding: SGE support in BLAH plus SGE-utils (info provider, yaim module, metapackage):
    • Assigned to CESGA by PTB. CESGA didn't hire yet the relevant person. For the time being best effort manpower provided by people working full time for EGI.
      • Update from Goncalo Borges concerning (S)GE support: all the work is done on a best effort basis until April where dedicated staff from CESGA will enter. Basically, we propose to deliver something which is EMI 1.0 compliant by June
  • glite-initscript-globus-gridftp:
    • Responsible person: Andrew Elwell
      • It's maintained (at a code level) as a 'Reasonable Efforts' basis -- there have been no changes since Jan 2008 to the script.
      • It's presently used by the (legacy lcg-ce), WMS and Cream CE, and there is a forked version maintained by DPM.

-- DoinaCristinaAiftimiei - 14-Apr-2011

Edit | Attach | Watch | Print version | History: r10 < r9 < r8 < r7 < r6 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r10 - 2012-06-22 - DoinaCristinaAiftimiei
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback