For the PR, we can put in a checklist:
[ ] If you made a BC-breaking change, did you add an entry to the
changelog?
[ ] If you added a new user-level feature, did you add an entry
to the changelog? Did you write docs for it?
[ ] If you added a new, public API function, did you add a
@since annotation to it?
[ ] Did you Haddock all of your new functions?
[ ] Did you add a test? (If not why was it hard to write the test?
Maybe open a bug for it.)
Any did I forget?
Excerpts from Oleg Grenrus's message of 2016-07-12 14:03:01 -0700:
> Great, it looks awesome.
>
> Issue template is great idea as well. (for ones who aren’t familiar:
> https://github.com/blog/2111-issue-and-pull-request-templates
> <https://github.com/blog/2111-issue-and-pull-request-templates>)
> (I’m +1 for having GitHub stuff under .github/ directory)
>
> The issue template could ask for
> - Cabal/cabal-install/ghc versions
> - ask to run cabal-install with -v2 flag and add that to the issue?
>
> with quick glance it doesn’t apply to many issues, but when it does, it would
> be helpful.
>
>
> - Oleg
>
> > On 12 Jul 2016, at 23:48, Edward Z. Yang <ezy...@mit.edu> wrote:
> >
> > Excerpts from Oleg Grenrus's message of 2016-07-12 12:45:05 -0700:
> >>
> >>> On 12 Jul 2016, at 18:42, Edward Z. Yang <ezy...@mit.edu> wrote:
> >>>
> >>> Excerpts from Oleg Grenrus's message of 2016-07-12 04:03:43 -0700:
> >>>> Looks good indeed!
> >>>>
> >>>> I have few questions:
> >>>> - what is purpose of `paging:*` labels, to help people see issues they
> >>>> are interested in? How it’s different from assignees (which can be
> >>>> multiple)?
> >>>
> >>> Beyond what Mikhail stated:
> >>>
> >>> - Multiple people can be paged, only one assigned
> >> Yes you can.
> >> https://github.com/blog/2178-multiple-assignees-on-issues-and-pull-requests
> >>
> >> <https://github.com/blog/2178-multiple-assignees-on-issues-and-pull-requests>
> >
> > Haha! Learned something today.
> >
> >>> - I can put more metadata in the tag name than assignable
> >>> (to help people decide who to page)
> >> Ah, page as in ping. That meaning I always find weird (and don’t remember).
> >>
> >>> summon (someone) over a public address system, so as to pass on a message
> >>
> >> IMHO multiple assignment would work better as it actually sends
> >> notification (if one choose to receive such).
> >>
> >> Yet, you’re right, deciding whom to page/assign is often non-obvious. Not
> >> sure if few-word description if any helpful. (e.g. whom to contact on
> >> hackage-security problems, I’m actually unsure whether it’s edsko or
> >> dcoutts, or on something else...).
> >
> > OK, I am convinced we should drop it.
> >
> > Let's do this:
> >
> > - To page someone, just write CC @blah in the message
> > - We should add an issue template that requests you
> > CC someone and explains who you might want to CC
> >
> >>>> - why “bug” has “ezyang planning to delete this tag”. I’d prefer to have
> >>>> “type: bug” and other “type:*” labels as: “type: discuss”, “type:
> >>>> enhancement”, “type: question”, and maybe more as e.g. stack has
> >>>> https://github.com/commercialhaskell/stack/labels
> >>>> <https://github.com/commercialhaskell/stack/labels>
> >>>
> >>> OK, the tag served it's purpose! I planned to delete it because there
> >>> are lots of bugs in the issues tracker and no one has been methodically
> >>> tagging them bug or not, so it seemed that the tag was just not that
> >>> helpful. Just look at Stack's issues list:
> >>> https://github.com/commercialhaskell/stack/issues
> >>> who is tagging things as bugs!
> >>
> >> If we go for type:* tags, I’ll help with triaging all issues with type:*
> >> tag.
> >
> > OK, fine. I've reorged accordingly.
> >
> >>>
> >>> discuss/enhancement/question are useful and I support tags for them.
> >>> Presently we have "priority: enhancement" but we can rename that as
> >>> needed.
> >>
> >> I’d like priorities to have a total-order. high > low is obvious, but what
> >> about enhancement and user-question? I’d change latter two into type:*,
> >> and maybe later introduce third priority level if we feel we need one.
> >
> > Added.
> >
> >>>> - how priority labels interact with milestones?
> >>>
> >>> Agreed with Mikhail; priority within milestone.
> >>>
> >>>> - Should we add “pr welcome” or “awaiting pr” for issues which are
> >>>> discussed, but nobody have interest or time implementing right away
> >>>> (will help new contributors especially when combined with `meta: easy`)
> >>>
> >>> Sure! I wonder, however; for tickets that are tagged this way, I feel
> >>> the onus is on us to write a clear spec at the top of the bug for what
> >>> is desired (even better: link to a commit with a test!) Will help
> >>> contributors a lot.
> >>
> >> Yes, we should help as much as possible. I’d tag only “clear” issues, and
> >> add a comment that I can help with it, if there are some questions (or/and
> >> assign it to myself).
> >>
> >> Also I forgot to ask about "attention: please-merge”. What’s it purpose,
> >> to tag PRs that author thinks are amerceable? IMHO the comment is enough,
> >> and also would work for external-contributors, who **cannot** tag
> >> issues/prs. (This is the reason why I got push-rights in the first place,
> >> I’m still quite uncomfortable pushing changes myself).
> >
> > Dropped it.
> >
> >> And what’s the idea behind “attention: regression”? How it’s different
> >> from a `type: bug` (its special case of a bug, but does it matter that
> >> much. Regressions could be critical or not, so priority tag, with type:bug
> >> would be enough?)
> >
> > Regression is in here because we used to have a regression tag. I'll
> > reclassify them.
> >
> >> E.g.
> >> is:open label:"priority: high" label:"bug (ezyang is planning to delete
> >> this tag)" milestone:"Cabal 1.26"
> >> filter
> >> https://github.com/haskell/cabal/issues?utf8=%E2%9C%93&q=is%3Aopen%20label%3A%22priority%3A%20high%22%20label%3A%22bug%20(ezyang%20is%20planning%20to%20delete%20this%20tag)%22%20milestone%3A%22Cabal%201.26%22%20
> >>
> >> <https://github.com/haskell/cabal/issues?utf8=%E2%9C%93&q=is:open%20label:%22priority:%20high%22%20label:%22bug%20(ezyang%20is%20planning%20to%20delete%20this%20tag)%22%20milestone:%22Cabal%201.26%22%20>
> >>
> >> shows not that many.
> >>
> >> OTOH there are 210 open issues (is:open is:issue no:milestone) without any
> >> milestone. Should we put them all into _|_ - milestone, and then promote
> >> to version milestones, when the discussion advanced enough we know when we
> >> want to release them (the soonest, or the latest?). As Cabal-1.26 165 open
> >> issues indicates, it’s more like “the soonest”, at least at this point.
> >>
> >> cabal-install-1.24.0.1 has 12 open issues, should we create
> >> cabal-install-1.24.1 -milestone and move them there?
> >
> > I think we should try to arrange a phone call behind all the Cabal
> > stakeholders and have a triage session to remilestone these bugs.
> >
> > Edward
> >
_______________________________________________
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
