Sands (and Everyone),
I've been putting some thought into this and while I agree we need a better
means to deal with review. I have some significant concerns with this
approach in that it doesn't solve the problem that we are now dealing with
several long lived branches that are not getting accepted for commit. It
does not solve the bottleneck caused by trying to process so many
contributions in such a small period.
I think we are going to experience a deadlock if we do not break the
contributions up into sets or waves. Existing open Pull Requests in the
queue are getting stale and difficult to maintain for some of us, likewise,
we cannot complete the next set of pull requests until at least some of the
current work in the queue is accepted into the master such that we can
integrate it into the next requests we have on deck.
For instance, within @Mire, we have the following to Pull Requests in on
base:
Advanced Embargo
https://github.com/DSpace/DSpace/pull/43
Discovery Enhancements
https://github.com/DSpace/DSpace/pull/45
And we have three projects on deck that need these changes to go through
before we can properly merge them and bring the final set of contributions
into pull requests for review
Item Level Versioning
Configurable Workflow
Statistics Enhancements
We cannot push these forward until the previous requests are accepted. If
we wait around until after friday to get formal voting to pass, the
contribution deadline will have passed. Likewise, we anticipate that a
significant amount of integration work will still be necessary with other
requests in the queue as well.
What we need is:
1.) Pushing the overall contribution freeze date into the future and
2.) A more concrete and rapid process of voting on any Pull request with
the conclusion being the acceptance of the pull request.
An example of where this is evident is that both the above pull requests
have been open for some time and available for review, the minor
considerations have been integrated into the latest changes, but if there
is supposed to be a procedure, no one is actually voting on them to get us
the three votes to accept the pull request.
Given the Pull Requests have been open for some time and they have been
talked about over several meetings, there is not a clear procedure for
accepting and closing them given theres been no major complaints. This is
happening on all the Requests. The vote required in the processes
described here (
https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures) does
not have a clear "process", especially now that we are using Pull Requests.
Should a vote thread be opened in email?, should folks vote in the
committer meeting in IRC? should they vote in the Pull Request comments
themselves, or should they vote in the JIRA task? Its not formalized.
It is critical that we review the list of existing pull requests and begin
work to accept those that have been there for some time. I propose this
process should be similar to the JIRA review process:
a.) Pull Requests that can be accepted immediately should be.
b.) Large Pull Requests needing a vote should be voted on in IRC in the
meeting and accepted, rejected or identified as still needing work.
c.) Pull requests still needing work should be identified as such by a [IN
PROCESS] prefix in their title
d.) New and Existing Pull Requests ready for acceptance review should be
marked as such with a [COMPLETE] prefix in their title
e.) Prior to accepting, the reviewer that will complete the accept should
remove the [COMPLETE] prefix and accept it.
f.) In each committer meeting we are responsible for reviewing a number of
pull requests starting with the earliest, with the intent to be decisive.
g.) If there is a problem or opposition with a committed contribution
during the test phase, it would need to be rolled back.
The objective of this approach is to to stagger the contribution and review
process so that those of us with longer lived Pull Requests already
prepared can have them accepted before the freeze date reducing the risk
and effort to maintain them and allow for further contributions to be
completed prior to the freeze.
Regards,
Mark
On Tue, Aug 14, 2012 at 9:13 AM, Sands Alden Fish <[email protected]> wrote:
> Hello from the DSpace 3.0 Release Team!
>
> We've been discussing a number of things that are unique to this release
> and we'd like to suggest some adjustments that will hopefully make the
> process smoother.
>
> Particularly unique to this release is the fact that this is the first
> time GitHub has been in place as our code management system. This has
> impacted the workflow of accepting contributions and how they make their
> way into the final release. Because of this, we believe the release
> process could be better aligned with the new workflow. Pursuant of that,
> we would like to announce the following changes:
>
> 1.) What we have been calling the "Feature Freeze" date will now be
> referred to as the "Code Submission Deadline". This helps to clarify
> exactly what is needed by this date. Due to the fact that we now receive
> Git Pull Requests <https://help.github.com/articles/using-pull-requests/>,
> the contributor can continue to refine and shape their submission, even
> after offering the code for contribution, often as part of a dialog with
> the committers. The Code Submission Deadline makes clear that Pull
> Requests for working code intended for a release are due by this date, not
> that the code need be reviewed, discussed, documented and fully merged with
> the codebase to be included in the release. Any new feature code submitted
> after this date will NOT be in 3.0 & will not even be reviewed for the
> current release (obviously the only exception is bug fixes).
>
> 2.) The name "Feature Freeze" will now refer to the date by which the
> Release Team and Committers will have reviewed via Pull Request, and
> accepted or rejected all contributions made for a certain release.
> Rejected code has to wait for the next version of DSpace (or is suggested
> to be released separate from the current release as a "third party add-on",
> if applicable).
>
> 3.) Regarding the current release, we would like to adjust the timeline
> to allow for a more thorough review of the numerous contributions being
> considered for 3.0. Below is an outline of the new schedule:
>
> - Aug 24 : Feature/Code Submission Deadline
> - Aug 31 : Feature Documentation Due Date
> - Sept 7 : Feature Freeze
> - Sept 14 : Release Candidate 1 is released
> - Sept 17-28 : Test-a-thon
> - Oct 12 : Release Candidate 2 is released
> - Oct 15-24 : Final Testing & Bug Fixing period
> - Oct 26 : 3.0 is released
>
> We hope these changes will make for an easier and more clear release
> process.
>
>
> - Sands Fish, for the DSpace 3.0 Release Team
>
>
> P.S. - Many thanks go to Tim Donohue & Valorie Hollister for their
> consultation and input into this decision.
>
>
>
> --
> sands fish
> Senior Software Engineer
> MIT Libraries
> Technology Research & Development
> [email protected]
> E25-131
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Dspace-commit mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-commit
>
>
--
[image: @mire Inc.]
*Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>)
*2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
*Esperantolaan 4, Heverlee 3001, Belgium*
http://www.atmire.com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
