You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bookkeeper.apache.org by Jia Zhai <zh...@gmail.com> on 2017/06/10 19:19:51 UTC
BP-9 - Github issues for Issue Tracking
Hi all,
I've put up a proposal
<https://cwiki.apache.org/confluence/display/BOOKKEEPER/BP-9+-+Github+issues+for+Issue+Tracking>
on how to use Github issues, try to start with very simple steps. Any
thoughts?
Best Regards.
-Jia
Re: BP-9 - Github issues for Issue Tracking
Posted by Sijie Guo <gu...@gmail.com>.
Thanks Jia. More comments added on Enrico's.
There are unknowns related INFRA permissions. It might be making sense for
you to reach out first and update what permissions work in the BP. So other
people knows the INFRA situation.
On Jun 11, 2017 4:38 AM, "Enrico Olivelli" <eo...@gmail.com> wrote:
Thank you Jia for starting the discussion.
I think the labes/milestones can work as you described, but maybe we can
consider to use composite labels like component/server or type/improvement.
Good idea the fact to only mark blocker issues, it is a good starting
point, simple but effective
Good idea to not create too simple issues which will be duplicates of their
corresponding PR
The only thing I would like to drop is the idea of using github merge
facility, motivations:
1) the merge script is powerful and we can adapt it to our needs as well.
It is useful to record the reviewers explicitly in git log
2) it is better to use directly ASF infrastructure, I am thinking to
security, a github account is more volatile than our ids on apache infra
OK for updating the merge script, I have already created an issue on GitHub
for that improvement, see:
https://github.com/apache/bookkeeper/issues/184
I think the ASF is moving to full github, not just mirror. That is I heard
at Apache Con. If the INFRA team has full github support, it would be
making sense to use what INFRA supports. So it might be worth checking out
the permissions at INFRA.
We should also explicitly decide how to finish 4.5.0 release, as most of
the issues are on JIRA
I think 4.5.0 will follow the current release process and we can manually
add the github issues to the notes.
Maybe we could draft in the BP how in the future we will migrate currently
open issues on JIRA
We are not officially moving. This is a try out period. I don't think we
should talk about migration.
Last point is to imagine how we will prepare "release notes", in JIRA it is
simple to automatically create a report page, on the GitHub I have no
experience
I would suggest moving the release part on a separate BP. The reason is :
it is a try out period, we might first just focus on issues and pull
requests. For 4.5.0, we can manually manage the issues on github to add to
release notes. Starting simpler is always easier.
It is better to defer this as it is a tryout period. The release procedure
discussion only makes sense to me when we officially move.
-- Enrico
Il sab 10 giu 2017, 21:19 Jia Zhai <zh...@gmail.com> ha scritto:
> Hi all,
>
> I've put up a proposal
> <https://cwiki.apache.org/confluence/display/BOOKKEEPER/
> BP-9+-+Github+issues+for+Issue+Tracking>
> on how to use Github issues, try to start with very simple steps. Any
> thoughts?
>
> Best Regards.
> -Jia
>
Re: BP-9 - Github issues for Issue Tracking
Posted by Enrico Olivelli <eo...@gmail.com>.
Thank you Jia for starting the discussion.
I think the labes/milestones can work as you described, but maybe we can
consider to use composite labels like component/server or type/improvement.
Good idea the fact to only mark blocker issues, it is a good starting
point, simple but effective
Good idea to not create too simple issues which will be duplicates of their
corresponding PR
The only thing I would like to drop is the idea of using github merge
facility, motivations:
1) the merge script is powerful and we can adapt it to our needs as well.
It is useful to record the reviewers explicitly in git log
2) it is better to use directly ASF infrastructure, I am thinking to
security, a github account is more volatile than our ids on apache infra
OK for updating the merge script, I have already created an issue on GitHub
for that improvement, see:
https://github.com/apache/bookkeeper/issues/184
We should also explicitly decide how to finish 4.5.0 release, as most of
the issues are on JIRA
Maybe we could draft in the BP how in the future we will migrate currently
open issues on JIRA
Last point is to imagine how we will prepare "release notes", in JIRA it is
simple to automatically create a report page, on the GitHub I have no
experience
-- Enrico
Il sab 10 giu 2017, 21:19 Jia Zhai <zh...@gmail.com> ha scritto:
> Hi all,
>
> I've put up a proposal
> <https://cwiki.apache.org/confluence/display/BOOKKEEPER/
> BP-9+-+Github+issues+for+Issue+Tracking>
> on how to use Github issues, try to start with very simple steps. Any
> thoughts?
>
> Best Regards.
> -Jia
>
Re: BP-9 - Github issues for Issue Tracking
Posted by Jia Zhai <zh...@gmail.com>.
FYI. created bookkeeper [issue](
https://github.com/apache/bookkeeper/issues/191) and [PR](
https://github.com/apache/bookkeeper/pull/192)，
We could try them out to see what permissions we have now under Apache’s
mirror github.
On Mon, Jun 12, 2017 at 2:50 PM, Jia Zhai <zh...@gmail.com> wrote:
> Thanks Sijie and Flavio, will add above workflow part into the BP.
>
> On Mon, Jun 12, 2017 at 2:26 PM, Sijie Guo <gu...@gmail.com> wrote:
>
>> On Mon, Jun 12, 2017 at 12:27 PM, Jia Zhai <zh...@gmail.com> wrote:
>>
>> > Hi Enrico, Sijie And Flavio,
>> >
>> > Thanks a lot for the great comments on this. the BP have changed
>> following
>> > the comments.
>> >
>> > ```
>> > I think the labels/milestones can work as you described, but maybe we
>> can
>> > consider to use composite labels like component/server or
>> type/improvement.
>> > ```
>> > < == seems "server" could be included in label "bookie", and
>> "improvement"
>> > could be included in label "task"
>> >
>> > ```
>> > In jira, we submit a patch when a contributor wants it merged and a
>> > committer cancels the patch when there are necessary changes. Do we
>> want to
>> > implement a similar workflow using labels?
>> > ```
>> > < == We could control it in github pull request by feature "review
>> changes"
>> > tab, right? As currently it is a try period, How about make the lablels
>> > simple as currently?
>> >
>>
>> - If a change is in-progress but you want an early feedback, you can send
>> out a pull request with "WIP - Issue xxxx".
>> - If a change is done and you want to review, you can send out a pull
>> request with "Issue xxxx".
>> - If people reviewed a pull request and the change needs to be improved,
>> people should "request changes" through the github review button. the
>> merge
>> script should only merge changes approved by committers and no pending
>> 'request changes'.
>>
>>
>>
>> >
>> >
>> > ```
>> > It might be worth adding a point to the proposal about sub-tasks as
>> this is
>> > probably how we will be working with umbrella issues: use (- [ ]) for
>> > each subtask and create a corresponding issue to map to the sub-task.
>> > ```
>> > < == have changed the issue_template to include suggestion for subtasks.
>> >
>> > ```
>> > we could just say that we always create
>> > an issue for a pull request and the only discussions on the pull
>> requests
>> > are the ones about the code changes
>> > ```
>> > < == have changed this in the BP, to always create an issue for change.
>> >
>> >
>> > Regarding the permissions, have opened INFRA issue
>> > <https://issues.apache.org/jira/browse/INFRA-14337> to confirm.
>> >
>> > Regarding the release part, we will start a new BP to discuss it, such
>> as
>> > the release procedures, how to prepare the release notes, etc.
>> >
>> >
>> > Thanks a lot.
>> > -Jia
>> >
>>
>
>
Re: BP-9 - Github issues for Issue Tracking
Posted by Jia Zhai <zh...@gmail.com>.
Thanks Sijie and Flavio, will add above workflow part into the BP.
On Mon, Jun 12, 2017 at 2:26 PM, Sijie Guo <gu...@gmail.com> wrote:
> On Mon, Jun 12, 2017 at 12:27 PM, Jia Zhai <zh...@gmail.com> wrote:
>
> > Hi Enrico, Sijie And Flavio,
> >
> > Thanks a lot for the great comments on this. the BP have changed
> following
> > the comments.
> >
> > ```
> > I think the labels/milestones can work as you described, but maybe we can
> > consider to use composite labels like component/server or
> type/improvement.
> > ```
> > < == seems "server" could be included in label "bookie", and
> "improvement"
> > could be included in label "task"
> >
> > ```
> > In jira, we submit a patch when a contributor wants it merged and a
> > committer cancels the patch when there are necessary changes. Do we want
> to
> > implement a similar workflow using labels?
> > ```
> > < == We could control it in github pull request by feature "review
> changes"
> > tab, right? As currently it is a try period, How about make the lablels
> > simple as currently?
> >
>
> - If a change is in-progress but you want an early feedback, you can send
> out a pull request with "WIP - Issue xxxx".
> - If a change is done and you want to review, you can send out a pull
> request with "Issue xxxx".
> - If people reviewed a pull request and the change needs to be improved,
> people should "request changes" through the github review button. the merge
> script should only merge changes approved by committers and no pending
> 'request changes'.
>
>
>
> >
> >
> > ```
> > It might be worth adding a point to the proposal about sub-tasks as this
> is
> > probably how we will be working with umbrella issues: use (- [ ]) for
> > each subtask and create a corresponding issue to map to the sub-task.
> > ```
> > < == have changed the issue_template to include suggestion for subtasks.
> >
> > ```
> > we could just say that we always create
> > an issue for a pull request and the only discussions on the pull requests
> > are the ones about the code changes
> > ```
> > < == have changed this in the BP, to always create an issue for change.
> >
> >
> > Regarding the permissions, have opened INFRA issue
> > <https://issues.apache.org/jira/browse/INFRA-14337> to confirm.
> >
> > Regarding the release part, we will start a new BP to discuss it, such as
> > the release procedures, how to prepare the release notes, etc.
> >
> >
> > Thanks a lot.
> > -Jia
> >
>
Re: BP-9 - Github issues for Issue Tracking
Posted by Sijie Guo <gu...@gmail.com>.
On Mon, Jun 12, 2017 at 12:27 PM, Jia Zhai <zh...@gmail.com> wrote:
> Hi Enrico, Sijie And Flavio,
>
> Thanks a lot for the great comments on this. the BP have changed following
> the comments.
>
> ```
> I think the labels/milestones can work as you described, but maybe we can
> consider to use composite labels like component/server or type/improvement.
> ```
> < == seems "server" could be included in label "bookie", and "improvement"
> could be included in label "task"
>
> ```
> In jira, we submit a patch when a contributor wants it merged and a
> committer cancels the patch when there are necessary changes. Do we want to
> implement a similar workflow using labels?
> ```
> < == We could control it in github pull request by feature "review changes"
> tab, right? As currently it is a try period, How about make the lablels
> simple as currently?
>
- If a change is in-progress but you want an early feedback, you can send
out a pull request with "WIP - Issue xxxx".
- If a change is done and you want to review, you can send out a pull
request with "Issue xxxx".
- If people reviewed a pull request and the change needs to be improved,
people should "request changes" through the github review button. the merge
script should only merge changes approved by committers and no pending
'request changes'.
>
>
> ```
> It might be worth adding a point to the proposal about sub-tasks as this is
> probably how we will be working with umbrella issues: use (- [ ]) for
> each subtask and create a corresponding issue to map to the sub-task.
> ```
> < == have changed the issue_template to include suggestion for subtasks.
>
> ```
> we could just say that we always create
> an issue for a pull request and the only discussions on the pull requests
> are the ones about the code changes
> ```
> < == have changed this in the BP, to always create an issue for change.
>
>
> Regarding the permissions, have opened INFRA issue
> <https://issues.apache.org/jira/browse/INFRA-14337> to confirm.
>
> Regarding the release part, we will start a new BP to discuss it, such as
> the release procedures, how to prepare the release notes, etc.
>
>
> Thanks a lot.
> -Jia
>
Re: BP-9 - Github issues for Issue Tracking
Posted by Jia Zhai <zh...@gmail.com>.
Hi Enrico, Sijie And Flavio,
Thanks a lot for the great comments on this. the BP have changed following
the comments.
```
I think the labels/milestones can work as you described, but maybe we can
consider to use composite labels like component/server or type/improvement.
```
< == seems "server" could be included in label "bookie", and "improvement"
could be included in label "task"
```
In jira, we submit a patch when a contributor wants it merged and a
committer cancels the patch when there are necessary changes. Do we want to
implement a similar workflow using labels?
```
< == We could control it in github pull request by feature "review changes"
tab, right? As currently it is a try period, How about make the lablels
simple as currently?
```
It might be worth adding a point to the proposal about sub-tasks as this is
probably how we will be working with umbrella issues: use (- [ ]) for
each subtask and create a corresponding issue to map to the sub-task.
```
< == have changed the issue_template to include suggestion for subtasks.
```
we could just say that we always create
an issue for a pull request and the only discussions on the pull requests
are the ones about the code changes
```
< == have changed this in the BP, to always create an issue for change.
Regarding the permissions, have opened INFRA issue
<https://issues.apache.org/jira/browse/INFRA-14337> to confirm.
Regarding the release part, we will start a new BP to discuss it, such as
the release procedures, how to prepare the release notes, etc.
Thanks a lot.
-Jia
Re: BP-9 - Github issues for Issue Tracking
Posted by Flavio P JUNQUEIRA <fp...@apache.org>.
Thanks for putting this together, Jia.
> If a change is trivial, or you have the code ready, you
> can open a PR directly; otherwise create an issue for
> discussion before starting writing code.
This is one of those things that sound like a good idea initially, but then
judging whether we need an issue or not may not be entirely obvious. Or
perhaps, we think the issue won't require discussion and the discussion
ends up happening. I know there is redundancy between issue and pull
request in github and a discussion on the pull request is also valid, but
to keep the rules simple and clear, we could just say that we always create
an issue for a pull request and the only discussions on the pull requests
are the ones about the code changes. Also, if we have an issue for each
pull request, then we can make the commit message look like: "BK-1024: My
cute little issue" plus a short change log description if we want.
> sub-tasks
It might be worth adding a point to the proposal about sub-tasks as this is
probably how we will be working with umbrella issues: use (- [ ]) for
each subtask and create a corresponding issue to map to the sub-task.
> workflow
In jira, we submit a patch when a contributor wants it merged and a
committer cancels the patch when there are necessary changes. Do we want to
implement a similar workflow using labels?
-Flavio
On Sun, Jun 11, 2017 at 12:49 AM, Jia Zhai <zh...@gmail.com> wrote:
> Hi all,
>
> I've put up a proposal
> <https://cwiki.apache.org/confluence/display/BOOKKEEPER/
> BP-9+-+Github+issues+for+Issue+Tracking>
> on how to use Github issues, try to start with very simple steps. Any
> thoughts?
>
> Best Regards.
> -Jia
>