Just as a short term measure whilst discussions continue what about we
vote on 43 and 45 at today's meeting ? Hopefully get them approved and
merged.
Cheers.
On 15/08/12 09:04, Mark Diggory wrote:
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]
<mailto:[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] <mailto:[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]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/dspace-commit
--
@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 <http://www.atmire.com/>
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
------------------------------------------------------------------------------
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
