...
Please squash a bug!
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 Tickets resolved this week:
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 Tickets created this week:
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
Minutes
- Previous version support – at present, there is effectively no policy. Now there are production deployments.
- Unknown User (acoburn): a "bug" is ambiguous in the absence of a spec.
- Andrew Woods: there are also unambiguous bugs even in the absence of a spec.
- Unknown User (acoburn): we should rapidly move toward publishing a spec
- David Chandek-Stark: If Fedora is "production ready", then what support does that imply?
- A. Soroka: What does "production ready" mean?
- David Chandek-Stark: Reality of Fedora turned out to be different from the assumptions of Fedora
- Andrew Woods: Expectations of behavior have not been formalized, but there is a 90-something % overlap in expectations of what Fedora does
- 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
- 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
- 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.
- David Chandek-Stark: I would expect the rest API would change; what is the management of that change over time?
- 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.
- 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.
- 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.
- Unknown User (acoburn): this should be a function of the developer commitments
- 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
- 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.
- A. Soroka: this should be part of the semantic versioning scheme
- 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.
- 4.6.0 Release is ready for code freeze (next week). 4.7.0 will be released soon thereafter.
- 4.6.0 will be a (informal) LTS; tooling will need to be put into place for migrating MODE 4 -> 5
- Unknown User (acoburn): why can't we do these concurrently?
- Andrew Woods: testing may suffer
- Elliot Metsger: why the rush to move to MODE 5? Does MODE provide tooling to move from 4 -> 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 - Nick Ruest: if we're putting out two release candidates, what are we committing ourselves to in terms of supporting two releases?
- Andrew Woods: this would be two supported versions
- Elliot Metsger: two simultaneous releases would be confusing; if there was more clarity about Modeshape 4 -> 5 and previous version support
- Unknown User (acoburn): if there are not two simultaneous releases, I could build my own MODE5-backed Fedora for our immediate institutional needs
- Andrew Woods: we can move forward now with a 4.6.0 release; a 4.7.0 will happen at some future time
- What is the support strategy for mode 4.6.0?
- A. Soroka: import/export tooling is the answer to that
- Andrew Woods: back-porting bugs would be applied on a case-by-case basis, as discussed earlier in the meeting
- 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.