...
- Releases management
- Status
- Next steps
Moving forward reviewing PRs on VIVO and Vitro
- https://github.com/vivo-project/Vitro/pulls and https://github.com/vivo-project/VIVO/pulls
- Tiny and big PRs classification
- Assignment of reviewers
- VIVO 2.0 architecture
Notes
- Releases management
Dragan: apologize for missing committers call two weeks ago
Dragan: status of release; still no functional 1.12 release; share release responsibility
William: have someone else take responsibility for 1.12 release?
Bryan: almost half of year after announcing 1.12 release
William: release documentation appears live and do not have confidence
Bryan: not entirely confident in release process; suggest maybe Dragan take it on with collaboration with Ralph
Dragan: organize meeting with Ralph and go over release process
Georgy: figure out what is going wrong; was under impression it was resolved; first approach with discussion to determine and improve documentation for clear procedure
William: last known issue was to revert CI PR merge on Vitro that published the installer
Dragan: action item to work toward release
2. Moving forward reviewing PRs on VIVO and Vitro
Dragan: ralph committed to providing list of PR reviews and details; how to proceed? PRs to which branch
William: branch management in disarray
Ben: expresses concern of merge conflicts without release
Dragan: not all same branch restrictions on all repositories
William: apply some level of restrictions on all repositories
Bryan: conditional level of requiring reviews
Dragan: document or comment for PR classification
Bryan: can use labels for this?
William: second that; also that should look into new GitHub beta projects
Dragan: actions; get with Ralph for release and classify PRs
William: what does assignment of reviewers look like
Dragan: should we use more of a push approach
William: would accept some assigned reviews
Georgy: how to handle certain PRs that appear to be not required or relevant; should comment and/or close?
Dragan: comment and attempt to get more eyes on
Georgy: should discuss certain PRs
Dragan: what is first step, comment or discuss with committers
Bryan: two different cases; one only determined by code review and another is significant feature requiring discussion; multiple rounds to determine
William: we should go issue first approach; discuss bug and feature on issue and save time for PRs
Dragan: is similar to MongoDB
William: how to handle stale issues and PRs?
Benjamin: GitHub does represent actual issue creation dates
Georgy: need more information on issues created; should we use slack chat to discuss with issue creators?
Dragan: yes
Dragan: How we are going to deal with requests? How to deal with it?
Georgy: Organize discussion in Slack.
Dragan: If it is not became obvious in Slack then discuss it on Committers meetings.
Brian: We may consider minor policy changes. If we want some procedure if PRs author not respond, close outdated PRs.
Dragan: I agree with you. We should improve documentation and align with it as much as possible. In reality 2 weeks is not working. We have PRs that are more than 3 years ago.
Brian: There will still be delays, but if the other side is not responding for too long then we should close it after some period. That would be a clearer procedure.
Dragan: If we are very interested in that contribution but other side is not ready to finish it, what should we do?
Brian: I think there are plenty of bottlenecks on both sides. But some long running big things should be removed if they are not needed.
Georgy: We should also think about license aspect of contributions.
Dragan: I will check Lyrasis to know more about policies.
Brian: We can build up on Fedora policy rules.
Georgy: If we have an option to simplify policies as much as possible that would be great.
Dragan: Sure. But first we should solve current issues with releases and PRs.
Actions
- Dragan Ivanovic to help Ralph in resolving publishing releases issue. Also, to try to improve documentation.
- Dragan Ivanovic to assign PRs to reviewers (committers)
- Later, we can improve contribution policy, including closing PR with inactive PR creators (who didn't responded on comments). We should also consider introducing Contributor license agreements in the process - link
Previous actions
- Ralph O'Flinn To investigate reversing publishing VIVO installer artifact to Sonatype
Previous actions
- Ralph O'Flinn first pass through PRs and sending out an email to other committers
- All to read and provide feedback for VIVO 2.0 architecture https://docs.google.com/document/d/1z51mkqlAopQ2rLkitHiQVwRojijnPM9pB8tQelW-lSA/edit?usp=sharing