Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:

Attendees 

Agenda

  1. Revisit "Previous Versions Support" policy, as well as policy for emergency patch releases
  2. Fedora 4.6.0 / 4.7.0 release plan proposal
    1. 4.6.0 Code freeze, Thurs July 21
      1. ModeShape4
      2. Guarantee some flavor of LTS
    2. 4.7.0 to be release immediately following 4.6.0 release
      1. ModeShape5
    3. Begin Mode4 to Mode5 migration pilots immediately
      1. Package, document, and verify tooling from:  Unable to locate Jira server for this macro. It may be due to Application Link configuration.
  3. Import/export of Bags
  4. Ready for Performance/Scale summary page/message
  5. Supporting gzip compression of responses via Jersey filters.
  6. ...

  7. Status of "in-flight" tickets

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Ticket Summaries

  1. Please squash a bug!

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  2. Tickets resolved this week:

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  3. Tickets created this week:

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Minutes

  1. Previous version support – at present, there is effectively no policy. Now there are production deployments.
    1. Unknown User (acoburn): a "bug" is ambiguous in the absence of a spec.
    2. Andrew Woods: there are also unambiguous bugs even in the absence of a spec.
    3. Unknown User (acoburn): we should rapidly move toward publishing a spec
    4. David Chandek-Stark: If Fedora is "production ready", then what support does that imply?
    5. A. Soroka: What does "production ready" mean?
    6. David Chandek-Stark: Reality of Fedora turned out to be different from the assumptions of Fedora
    7. Andrew Woods: Expectations of behavior have not been formalized, but there is a 90-something % overlap in expectations of what Fedora does
    8. A. Soroka: there is a difference b/t creating a policy (what Andrew Woods is suggesting) and fixing a bug (what David Chandek-Stark wants), and bugs can be fixed w/o a policy. Holding David Chandek-Stark's need to the standard of this policy may result in much unhappiness; instead, in the absence of a policy, if the bug gets fixed, this may be sufficient
    9. David Chandek-Stark: in the absence of a spec, I assume as a user that if the REST API says "X", Fedora will do "X". If that's not true, that would concern me
    10. A. Soroka: yes, the API can change, and until a spec is formalized, there is no standard for deciding when that API should or should not change; there have been cases when the documentation was wrong and there have been cases when the code was wrong and it could be a misunderstanding of the documentation.
    11. David Chandek-Stark: I would expect the rest API would change; what is the management of that change over time?
    12. A. Soroka: That is correct, change management is unclear; it is currently acted on in a case-by-case basis; the Spec should have a change management process built in.
    13. Andrew Woods: IF we had the spec and TCK, how would we approach a support policy? acknowledging that we have limited developer resources. What would be the appropriate policy.
    14. A. Soroka if there is agreement of the spec, this would go to the implementation team. The spec change management should be different than the ref impl. 
    15. Unknown User (acoburn): this should be a function of the developer commitments
    16. A. Soroka: Andrew Woods is asking for guarantees, and if developer time is from single individuals and institutions, supporting maintenance branches relates to real time commitments
    17. Andrew Woods: for example, in the change from MODE 4 -> 5, there is still a hurdle migrating from one backend to the other, this supports a higher need to support bug fixes in the earlier version.
    18. A. Soroka: this should be part of the semantic versioning scheme
    19. Andrew Woods: Example where the underlying backend is undergoing a major change, but the Fedora API isn't changing; all the versions now are tied to 4.x.x, which doesn't work well with semantic versioning.
  2. 4.6.0 Release is ready for code freeze (next week). 4.7.0 will be released soon thereafter.
    1. 4.6.0 will be a (informal) LTS; tooling will need to be put into place for migrating MODE 4 -> 5
    2. Unknown User (acoburn): why can't we do these concurrently?
    3. Andrew Woods: testing may suffer
    4. Elliot Metsger: why the rush to move to MODE 5? Does MODE provide tooling to move from 4 -> 5?
    5. Andrew Woods: MODE does provide support for migration ( /fcr:backup and /fcr:restore); Esmé Cowles has tested backup and restore, though with some glitches; We don't want to tie people to particular back ends, but this is useful for migrations
    6. Nick Ruest: if we're putting out two release candidates, what are we committing ourselves to in terms of supporting two releases?
    7. Andrew Woods: this would be two supported versions
    8. Elliot Metsger: two simultaneous releases would be confusing; if there was more clarity about Modeshape 4 -> 5 and previous version support
    9. Unknown User (acoburn): if there are not two simultaneous releases, I could build my own MODE5-backed Fedora for our immediate institutional needs
    10. Andrew Woods: we can move forward now with a 4.6.0 release; a 4.7.0 will happen at some future time
    11. What is the support strategy for mode 4.6.0? 
    12. A. Soroka: import/export tooling is the answer to that
    13. Andrew Woods: back-porting bugs would be applied on a case-by-case basis, as discussed earlier in the meeting
    14. A. Soroka: not sure about the degree to which we can guarantee back-porting bugs; there may be situations where we do back-port, but we should be clear that we may not back-port bugs to earlier released versions. This gives us a powerful incentive to bring the Spec process to a resolution.

 

 

  • No labels

3 Comments

  1. David Chandek-Stark

    Fwiw, 1i and 1k were my comments.

    1. A. Soroka

      Meeting minutes are open, David Chandek-Stark: if you see something wrong, jump right in and fix it! (smile)

      1. David Chandek-Stark

        I would have, but on mobile, so seems I can't edit.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.