[DISCUSS] release and voting process

57 views
Skip to first unread message

Jason Plurad

unread,
Oct 13, 2017, 10:03:51 AM10/13/17
to JanusGraph developers
I want to bring this up since it isn't clearly listed out in the current release policy docs.
There has been one issue so far that has been identified during the vote on the 0.2.0 release.

1. What types of issues qualify for a -1 vote?
2. Should a doc error hold up the release or should it be fixed?
3. If the docs are fixed, do we rebuild the release artifacts, update the tags, etc?
4. Does the voting clock get reset?

Robert Dale

unread,
Oct 13, 2017, 10:40:36 AM10/13/17
to Jason Plurad, JanusGraph developers
1. I would say egregious and/or technical errors would be a -1.  That is, it would hinder an offline user from using JanusGraph.
2. If -1 and technical, it should hold up the release. Everything else should get fixed and can be published later online.
3. If -1 and technical, yes.
4. No, unless someone feels like the extra time is needed.

To apply this to the current release, the outstanding issue involves minor link errors. There is nothing that would prevent a user from comprehending documentation or using JanusGraph. If the user were viewing offline (the packaged documentation), then the links wouldn't work anyway.  The corrected documentation can be published online which is done separately from building the artifacts thus no need to rebuild artifacts.


Robert Dale

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/5885e613-e225-4479-a069-da5d9fc7b75e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jason Plurad

unread,
Oct 13, 2017, 10:58:27 AM10/13/17
to JanusGraph developers
Thanks, Robert. I agree with that approach also.
Still interested in hearing other opinions or affirmations.


On Friday, October 13, 2017 at 10:40:36 AM UTC-4, Robert Dale wrote:
1. I would say egregious and/or technical errors would be a -1.  That is, it would hinder an offline user from using JanusGraph.
2. If -1 and technical, it should hold up the release. Everything else should get fixed and can be published later online.
3. If -1 and technical, yes.
4. No, unless someone feels like the extra time is needed.

To apply this to the current release, the outstanding issue involves minor link errors. There is nothing that would prevent a user from comprehending documentation or using JanusGraph. If the user were viewing offline (the packaged documentation), then the links wouldn't work anyway.  The corrected documentation can be published online which is done separately from building the artifacts thus no need to rebuild artifacts.


Robert Dale

Alexander Patrikalakis

unread,
Oct 13, 2017, 1:43:23 PM10/13/17
to JanusGraph developers
I don't think we should delay the vote clock just because of last minute issues. The whole point behind a freeze is to scrutinize last minute fixes. Rather, I would be more worried about exceptional processes used to generate documentation. Best would be to fix the remaining documentation issues and use exactly the same release process while not resetting the clock.


On Friday, October 13, 2017 at 11:58:27 PM UTC+9, Jason Plurad wrote:
Thanks, Robert. I agree with that approach also.
Still interested in hearing other opinions or affirmations.

On Friday, October 13, 2017 at 10:40:36 AM UTC-4, Robert Dale wrote:
1. I would say egregious and/or technical errors would be a -1.  That is, it would hinder an offline user from using JanusGraph.
2. If -1 and technical, it should hold up the release. Everything else should get fixed and can be published later online.
3. If -1 and technical, yes.
4. No, unless someone feels like the extra time is needed.

To apply this to the current release, the outstanding issue involves minor link errors. There is nothing that would prevent a user from comprehending documentation or using JanusGraph. If the user were viewing offline (the packaged documentation), then the links wouldn't work anyway.  The corrected documentation can be published online which is done separately from building the artifacts thus no need to rebuild artifacts.


Robert Dale

On Fri, Oct 13, 2017 at 10:03 AM, Jason Plurad wrote:
I want to bring this up since it isn't clearly listed out in the current release policy docs.
There has been one issue so far that has been identified during the vote on the 0.2.0 release.

1. What types of issues qualify for a -1 vote?
2. Should a doc error hold up the release or should it be fixed?
3. If the docs are fixed, do we rebuild the release artifacts, update the tags, etc?
4. Does the voting clock get reset?

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.

sjudeng

unread,
Oct 13, 2017, 8:23:37 PM10/13/17
to JanusGraph developers
Is the intent to propose a new 0.2.0 release with the additional commits that were merged into master since the original release was prepared? If so I would expect notice and a request for a new vote on the vote thread. Those changes affect the release artifacts under review including janusgraph-0.2.0-hadoop2.zip (API doc change) and janusgraph-0.2.0-hadoop2-doc.zip. The vote expiration could stay the same ... I think 72 hours or more from the changes being published is plenty of time.

Misha Brukman

unread,
Oct 15, 2017, 2:40:35 AM10/15/17
to Robert Dale, Jason Plurad, JanusGraph developers
I'm with Robert on this, and I should also point out these links have been broken since the 0.1.0 release, and no one has yet complained (or discovered) them other than Robert.

Another way to think about it is as follows: imagine the 0.2.0 release happened, and we then realized some HTML links are broken. We can't "recall" the 0.2.0 release then, so the only thing we would be able to do is to release an 0.2.1 with updated docs, but I don't think that's a sufficient reason to call for a release, so we would either fix the docs in-place (*) or leave them broken until 0.3.0 release (**).

In this case, we are choosing between (*) or (**). I am not the release manager, so it's easy to request all binary artifacts to be rebuilt, but I just don't see the value of spending that time/effort — they will be effectively the same, and while not bit-for-bit identical, they will be indistinguishable from the user perspective.

In summary, I'm fine with either shipping the artifacts as-is with the minor doc fixes. Alternatively, if we are going for strictness, we can leave the artifacts as-is and push the docs with links known to be broken, consistent with 0.1.0 and 0.1.1 releases, and the updated docs will be pushed with the next 0.2.x or 0.3.0 release.

I'm fine with either of these options.

Jason Plurad

unread,
Oct 15, 2017, 1:39:34 PM10/15/17
to JanusGraph developers
My goal with this thread is to clarify and document the process for the release manager since it is currently lacking. Then the release manager executes the process that was already agreed upon by consensus.

Here's what I'm proposing:

* Document what qualifies for a -1 vote: egregious error that prevents JanusGraph from working, artifacts not signed properly
* Document procedure for revoking the pre-release: removing pre-release binaries, removing git tag
* Document procedure for handling doc fixes during vote: we pushed doc fixes during the vote, but did not respin the release artifacts. The docs published on docs.janusgraph.org will have the fixes. If any -1 votes come up before the deadline, the respun release would get the new doc fixes.



On Sunday, October 15, 2017 at 2:40:35 AM UTC-4, Misha Brukman wrote:
I'm with Robert on this, and I should also point out these links have been broken since the 0.1.0 release, and no one has yet complained (or discovered) them other than Robert.

Another way to think about it is as follows: imagine the 0.2.0 release happened, and we then realized some HTML links are broken. We can't "recall" the 0.2.0 release then, so the only thing we would be able to do is to release an 0.2.1 with updated docs, but I don't think that's a sufficient reason to call for a release, so we would either fix the docs in-place (*) or leave them broken until 0.3.0 release (**).

In this case, we are choosing between (*) or (**). I am not the release manager, so it's easy to request all binary artifacts to be rebuilt, but I just don't see the value of spending that time/effort — they will be effectively the same, and while not bit-for-bit identical, they will be indistinguishable from the user perspective.

In summary, I'm fine with either shipping the artifacts as-is with the minor doc fixes. Alternatively, if we are going for strictness, we can leave the artifacts as-is and push the docs with links known to be broken, consistent with 0.1.0 and 0.1.1 releases, and the updated docs will be pushed with the next 0.2.x or 0.3.0 release.

I'm fine with either of these options.
On Fri, Oct 13, 2017 at 10:40 AM, Robert Dale wrote:
1. I would say egregious and/or technical errors would be a -1.  That is, it would hinder an offline user from using JanusGraph.
2. If -1 and technical, it should hold up the release. Everything else should get fixed and can be published later online.
3. If -1 and technical, yes.
4. No, unless someone feels like the extra time is needed.

To apply this to the current release, the outstanding issue involves minor link errors. There is nothing that would prevent a user from comprehending documentation or using JanusGraph. If the user were viewing offline (the packaged documentation), then the links wouldn't work anyway.  The corrected documentation can be published online which is done separately from building the artifacts thus no need to rebuild artifacts.


Robert Dale

On Fri, Oct 13, 2017 at 10:03 AM, Jason Plurad wrote:
I want to bring this up since it isn't clearly listed out in the current release policy docs.
There has been one issue so far that has been identified during the vote on the 0.2.0 release.

1. What types of issues qualify for a -1 vote?
2. Should a doc error hold up the release or should it be fixed?
3. If the docs are fixed, do we rebuild the release artifacts, update the tags, etc?
4. Does the voting clock get reset?

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/5885e613-e225-4479-a069-da5d9fc7b75e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jerry He

unread,
Oct 18, 2017, 4:18:07 PM10/18/17
to JanusGraph developers
+1 on the proposal.

Some of the things that are not considered blockers for a release will not impose a -1 on a release.  Docs fix on docs.janusgraph.org can have some flexibility.

Thanks.

Robert Dale

To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages