[neomutt-devel] Issue labels / Waffle Board

guyzmo z+mutt+notmuch at m0g.net
Mon Jan 30 02:46:23 CET 2017


On Sun, Jan 29, 2017 at 11:35:07PM +0100, Pietro Cerutti wrote:
> > On 29 Jan 2017, at 15:55, guyzmo <z+mutt+neomutt at m0g.net> wrote:
> > → status:progress → status:review → [approved] → status:ready → [merged] → status:closed
> 
> Two minor points.
> 

> 1) In my experience, issues are better left open until the code fixing
> them is released. Regressions are likely to be reported by more than
> one user, and having them in some kind of open state (e.g.,
> status:fixed) gives them more visibility and reduces the likeliness of
> duplicates. It also gives a general idea of what's going to go into
> the next release.

It's an excellent thing to care about.

An alternative way, which I've seen done on a bunch of other projects
I've participated in, is to handle that to avoid the "status:fixed"
column, is to have two branches, a devel branch and a master branch. 

Then keep the associated issues in st:ready up until it's merged in the
master branch, on which a commit means a new release has been issued.
(ultimately the CI could build and make the .tar.gz available each time
a commit happens on master).

> 2) As we are working today, with stuff being merged into the main
> branch as soon as it's ready, I don't see a reason for having a
> separate status between approval and merging.

I did not, and this is why I originally suggested the workflow

[pool] → [backlog] → [progress] → [ready] → [closed]

But with Rich asking us to make two reviews before getting him to merge
the code, it could be a good idea to have a column in between for
pending reviews.

[pool] → [st:backlog] → [st:progress] → [st:ready] → [st:review] → [closed]

> Based on this, I'd like to propose the following alternative workflow
> (labels abbreviated so transitions fit on a line)

> st:progress -> [work done] -> st:review
> st:review -> [approve] -> [merge] -> st:fixed
> st:fixed -> [release tag] -> st:closed

the issue with the above, is that once reviewed and approved, Rich
needs to be notified that the issue is good to be merged for him. Having
a Ready column is a good way for him to manage the approved patches and
merge them as he can.

So either way I'm ok with it, as my role will be limited to focus on
progress (doing patches) and review columns (approving other's work).
All I (we?) can do is suggest good ideas for we can help Rich take as
little time as possible doing the merges.

-- 
Z


More information about the neomutt-devel mailing list