Versions Compared

Old Version 6

changes.mady.by.user Former user

Saved on

compared with

New Version Current

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

5pm GMT / 1pm EDT
Phone number: 1 (812)856-7060
Internet: 156.56.240.9
Room code: 348#
Password: 72524#

...

  1. Review deprecation recommendations
  2. Community criteria updates
    1. Discussion of Incubation vs. Product Development
  3. Relationship of PC wrt other teams

Attendees

  • Nate Angell
  • Eli Cochran
  • Stephen Marquard
  • Noah Botimer
  • David Goodrum
  • Clay Fenlason
  • Michael Feldstein
  • John Lewis
  • John Norman (from 17:30)

This Meeting's etherpad (Meeting notes have been added below. The EtherPad service will be going away on May 14th)

2.7 Deprecations

Last meeting's etherpad: http://etherpad.com/8Mwo4toTGt

Meeting Notes

(Reminder) GOALS:

  • Shepherd new Sakai 2 tools/capabilities through the process
  • Facilitate Sakai 2 -> Sakai 3 transition planning
  • Develop criteria and process for moving from incubation to product development (This was left ambiguous as the product development process was defined), with a particular focus on S3.
  • Facilitate development of objective criteria for S3
  • Review of PC activity and recommendations going forward. Test whether expectations are being met.

AGENDA:
 
1) Review deprecation recommendations:
    http://confluence.sakaiproject.org//x/EhsQB
    
    - the PC's role wrt release management
    - different expectation about what the PC is and should be doing
    - whether PC is assuming responsibility for things that used to be RM and QA
        a) healthy for community if we spelled out groups and teams and respective remits - some published page
        b) lack of overlap btw RM and PC meetings; should have a liaison so that expectations don't diverge without realizing it. Perhaps PC members could rotate to join RM meetings so we all learn more
    - a lot of overlap btw RM and QA, which makes some things easier, but doesn't include PC
    - difference between maintenance team and kernel team? Some MT issues may really be kernel team issues. And these issues don't really need to come to PC.
    - clearer survey of impact of JCR work; may have jumped too quickly to stipulation rather than assessing impact
    - PC's role might help by showing how impact should be demonstrated, and what a good process would be - talking about what the right process should be to arrive at "environmental impact" report
    - it's not always clear to people how they might be affected
    - critria for deprecation would include question of impact beyond immediate case (eg, static covers deprecation's effect on web services that might not know about their dependency)
    - next step: some agreement on deprecation policy
    - next step: identify areas that are problematic and sketch out a different sort of process
    - kernel utils and static covers: PC should be consulted, but not decide
    - PC's role: to help steer them to community-based consensus
    - avoid situation where PC needs to approve a long list of code changes
    - normal situation: RM, QA, MT agree, no obvious problem
    - abnormal situation: no consensus view - PC as court of appeal
    1) what evidence do you have that the community agrees with proposal?
    2) is the decision consistent w/ past practices? or why not?
    - preference should be that PM is asking those questions, and only goes to PC if it's not working and a decision is required.
2) Community criteria updates

Next Steps