On Tue, Jun 6, 2017 at 12:41 AM, Flavio Junqueira <f...@apache.org> wrote:
> > > On 05 Jun 2017, at 18:30, Sijie Guo <guosi...@gmail.com> wrote: > > > > On Mon, Jun 5, 2017 at 2:53 AM, Flavio Junqueira <f...@apache.org> wrote: > > > >> Ok, so why don't we make clear what we are voting for? > > > > If this vote is approved, then the outcome is that the community is going > >> to work on a plan to move to github issues, and that plan will be voted? > > > > > > I believed that I made the clarification on what to vote in this thread. > > > > This is probably where we are not converging. I don't know what passing > this vote entails other than a wish to move to github issues in the case it > passes. I'd much rather vote on a proposal that includes the precise steps > so that we can assess whether that's a good move or not. But wait, you say > something interesting next... > > > Implementing the new github workflow would be a separated bookkeeper > > proposal and that implementation will follow bookkeeper proposal process > to > > vote, which is a lazy majority vote from committers. > > > > Anyone are welcome to work on implementing the workflow. > > > > I see, we aren't really voting on a change or committing to anything, you > just want to assess preferences. > > > > >> Or is it going to be considered a code change and require just a +1 > from a > >> committer? The reason I'm insisting is that I like the idea of moving to > >> github issues, but I'm not sure what we are voting for precisely. > >> > >> As for the approval process, it is not clear from the list of actions > >> which one is the one to take as not a single one is a good match. When > this > >> is the case, the binding votes should be the PMC ones, and given that > this > >> is a pretty significant change, I'd be more comfortable with lazy > >> consensus. Also, note that the shared resources of the project are > >> responsibility of the PMC. While we can do it in the open to gather > >> feedback from the community, and in fact, I'd say that this makes a lot > of > >> sense to do it, it is the PMC responsibility. > >> > > > > Thanks for pointing it out. Yes, the binding votes for this will be > active > > PMC members. > > > > Although I have a different personal opinion on the responsibility on > > shared resources. My feel is the shared resources are more developer > > resources, which committers/developers should own more responsibilities. > We > > can discuss it separately. > > It is not really my preference, this is in the bylaws of the project. It > is a responsibility of the PMC to maintain shared resources. I think that > the issue tracking application is a shared resource. > > > > > > >> My recommendation is that we clarify what we are voting for and call a > >> second vote. I'd happy to help out if it comes to that. > >> > > > > Let me know if the clarification is good to you or not. > > Possibly, if this vote is about declaring intention rather than > committing, then I'm totally good with that. > Flavio, if you are good with that, I would like to close this vote, so that we can move forward to make it happen. If you have a proposal on the workflow, feel free to raise it up as a BP. - Sijie > > -Flavio > > > > > > >> > >> Thanks, > >> -Flavio > >> > >> > >>> On 03 Jun 2017, at 19:29, Sijie Guo <guosi...@gmail.com> wrote: > >>> > >>> On Sat, Jun 3, 2017 at 7:39 AM, Flavio Junqueira <f...@apache.org> > wrote: > >>> > >>>> Thanks for pushing this through, Sijie. I have a couple of concerns > >> about > >>>> this proposal: > >>>> > >>>> 1- There is a proposal, but I'm not seeing a workflow defined for > github > >>>> issues. Should we define one and make that part of the vote? > >>>> > >>> > >>> Defining a workflow requires efforts and putting attentions into the > >>> community. The vote carries the proposal from last sync up to achieve a > >>> consensus in the community - "shall we try out github issues". If the > >>> community agrees on this, we can call for volunteers to drive the > >>> discussion on defining a workflow and help with logistics (e.g. works > >> with > >>> INFRA team) to make it happen. > >>> > >>> If the community isn't interested in moving forward, it doesn't make > any > >>> sense to put the efforts on it. > >>> > >>> > >>>> 2- I'm not sure what the binding votes are and what the approval > process > >>>> is. Are we following the project bylaws here? > >>>> > >>> > >>> http://bookkeeper.apache.org/bylaws.html > >>> > >>> This is related to development/release workflow, is counted as "Release > >>> Plan". It follows the "Lazy majority" approval process, any votes from > >>> committers are binding votes. > >>> > >>> The voting period is 3 days. > >>> > >>> - Sijie > >>> > >>> > >>>> > >>>> Thanks, > >>>> -Flavio > >>>> > >>>>> On 01 Jun 2017, at 21:59, Sijie Guo <guosi...@gmail.com> wrote: > >>>>> > >>>>> Per the community meeting > >>>>> <https://cwiki.apache.org/confluence/display/BOOKKEEPER/ > >>>> 2017-06-01+Meeting+notes> > >>>>> this morning, JV proposed to start use Github issues for issue > tracking > >>>> for > >>>>> a few months and see how does it work out. I am starting this email > >>>> thread > >>>>> to vote for this. > >>>>> > >>>>> The vote will be: > >>>>> > >>>>> - Start using Github issues/pull requests for issue tracking for 3 > >>>> months. > >>>>> - During this 3 months, we will continue using both JIRA and Github > >>>> issues. > >>>>> - After 3 months, if the community decides whether we should continue > >>>> using > >>>>> Github issues or moving from JIRA to Github issues. (The final > decision > >>>>> will be a separate vote in 3 months) > >>>>> > >>>>> Please vote +1 if in favor of trying out Github issues and -1 if not. > >>>>> > >>>>> See below thread and community meeting notes > >>>>> <https://cwiki.apache.org/confluence/display/BOOKKEEPER/ > >>>> 2017-06-01+Meeting+notes> > >>>>> for reference: > >>>>> > >>>>> http://mail-archives.apache.org/mod_mbox/bookkeeper-dev/ > 201705.mbox/% > >>>> 3CCAO2yDyYKmUiSfGfkGCKtfP8mmQtcJubGoMO-KsWsjM9_3pOd0Q%40mail > .gmail.com > >> %3E > >>>>> > >>>>> - Sijie > >>>> > >>>> > >> > >> > >
