From ezyang at mit.edu Mon Jul 11 04:37:14 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 11 Jul 2016 00:37:14 -0400 Subject: I reorged labels on Cabal's GitHub Message-ID: <1468211667-sup-5569@sabre> If you hate it I can change it back but give it a try for now. If the "component" prefix in "component: solver" is too long we could go for something like "C-solver" but I think that is less transparent. I also added some new labels, "paging: ezyang (...)". In the parenthetical should be a quick summary of the types of things you are interested in getting paged for. I tried to guess some but I am not perfect, please feel free to change your description / add a label for yourself (I didn't get everyone) / tell me how you want yours changed. Edward From mikhail.glushenkov at gmail.com Mon Jul 11 05:09:27 2016 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Mon, 11 Jul 2016 07:09:27 +0200 Subject: I reorged labels on Cabal's GitHub In-Reply-To: <1468211667-sup-5569@sabre> References: <1468211667-sup-5569@sabre> Message-ID: Hi, On 11 July 2016 at 06:37, Edward Z. Yang wrote: > If you hate it I can change it back but give it a try for now. > If the "component" prefix in "component: solver" is too long we could go for > something like "C-solver" but I think that is less transparent. Thanks, looks much better than the previous version. Re: the "specification" tag, I think it's supposed to mark proposed changes to the .cabal file format and GHC/Cabal interaction (i.e. the Cabal spec). From oleg.grenrus at iki.fi Tue Jul 12 11:03:43 2016 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 12 Jul 2016 14:03:43 +0300 Subject: I reorged labels on Cabal's GitHub In-Reply-To: References: <1468211667-sup-5569@sabre> Message-ID: 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)? - 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 - how priority labels interact with milestones? - 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`) - Oleg > On 11 Jul 2016, at 08:09, Mikhail Glushenkov > wrote: > > Hi, > > On 11 July 2016 at 06:37, Edward Z. Yang > wrote: >> If you hate it I can change it back but give it a try for now. >> If the "component" prefix in "component: solver" is too long we could go for >> something like "C-solver" but I think that is less transparent. > > Thanks, looks much better than the previous version. > > Re: the "specification" tag, I think it's supposed to mark proposed > changes to the .cabal file format and GHC/Cabal interaction (i.e. the > Cabal spec). > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mikhail.glushenkov at gmail.com Tue Jul 12 13:59:13 2016 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Tue, 12 Jul 2016 15:59:13 +0200 Subject: I reorged labels on Cabal's GitHub In-Reply-To: References: <1468211667-sup-5569@sabre> Message-ID: Hi, On 12 July 2016 at 13:03, Oleg Grenrus wrote: > 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)? "Assignee" usually means that the implementation is in progress and the assigned persons are working on it (though we haven't always used it for this purpose). > - how priority labels interact with milestones? In the obvious way, I guess: tickets targeted at a specific milestone are ordered by priority. > Should we add “pr welcome” or “awaiting pr” +1 from me. From ezyang at mit.edu Tue Jul 12 15:42:21 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 12 Jul 2016 08:42:21 -0700 Subject: I reorged labels on Cabal's GitHub In-Reply-To: References: <1468211667-sup-5569@sabre> Message-ID: <1468337813-sup-6598@sabre> 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 - I can put more metadata in the tag name than assignable (to help people decide who to page) But it's an experiment. If it's not useful we can delete the tags. > - 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 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! discuss/enhancement/question are useful and I support tags for them. Presently we have "priority: enhancement" but we can rename that as needed. > - 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. Edward From oleg.grenrus at iki.fi Tue Jul 12 19:45:05 2016 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 12 Jul 2016 22:45:05 +0300 Subject: I reorged labels on Cabal's GitHub In-Reply-To: <1468337813-sup-6598@sabre> References: <1468211667-sup-5569@sabre> <1468337813-sup-6598@sabre> Message-ID: <1D991361-A039-4627-A422-60BC5FAB751C@iki.fi> > On 12 Jul 2016, at 18:42, Edward Z. Yang 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 > - 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...). > > But it's an experiment. If it's not useful we can delete the tags. > >> - 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 > > 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. > > 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. > >> - 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). 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?) 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 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? - Oleg -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ezyang at mit.edu Tue Jul 12 20:48:11 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 12 Jul 2016 13:48:11 -0700 Subject: I reorged labels on Cabal's GitHub In-Reply-To: <1D991361-A039-4627-A422-60BC5FAB751C@iki.fi> References: <1468211667-sup-5569@sabre> <1468337813-sup-6598@sabre> <1D991361-A039-4627-A422-60BC5FAB751C@iki.fi> Message-ID: <1468355633-sup-6915@sabre> Excerpts from Oleg Grenrus's message of 2016-07-12 12:45:05 -0700: > > > On 12 Jul 2016, at 18:42, Edward Z. Yang 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 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 > > > > 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 > > 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 From oleg.grenrus at iki.fi Tue Jul 12 21:03:01 2016 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 13 Jul 2016 00:03:01 +0300 Subject: I reorged labels on Cabal's GitHub In-Reply-To: <1468355633-sup-6915@sabre> References: <1468211667-sup-5569@sabre> <1468337813-sup-6598@sabre> <1D991361-A039-4627-A422-60BC5FAB751C@iki.fi> <1468355633-sup-6915@sabre> Message-ID: <142DE7CC-E5F6-43B6-9C68-5C0CE57DD161@iki.fi> 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 ) (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 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 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 > > 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 >>> >>> 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 >> >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cheecheeo at gmail.com Tue Jul 12 21:18:03 2016 From: cheecheeo at gmail.com (John Alfred Nathanael Chee) Date: Tue, 12 Jul 2016 14:18:03 -0700 Subject: I reorged labels on Cabal's GitHub In-Reply-To: <1468355633-sup-6915@sabre> References: <1468211667-sup-5569@sabre> <1468337813-sup-6598@sabre> <1D991361-A039-4627-A422-60BC5FAB751C@iki.fi> <1468355633-sup-6915@sabre> Message-ID: On Tue, Jul 12, 2016 at 1:48 PM, Edward Z. Yang wrote: > > > - 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 If you don't already know about it, this bot: https://github.com/facebook/mention-bot is worth investigating in addition to the work you've mentioned. -- Love in Jesus Christ, John Alfred Nathanael Chee http://www.biblegateway.com/ http://web.cecs.pdx.edu/~chee/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Tue Jul 12 21:41:45 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 12 Jul 2016 14:41:45 -0700 Subject: I reorged labels on Cabal's GitHub In-Reply-To: References: <1468211667-sup-5569@sabre> <1468337813-sup-6598@sabre> <1D991361-A039-4627-A422-60BC5FAB751C@iki.fi> <1468355633-sup-6915@sabre> Message-ID: <1468359694-sup-3302@sabre> Thanks for the note. I went ahead and enabled it. Let's see if it's useful! Excerpts from John Alfred Nathanael Chee's message of 2016-07-12 14:18:03 -0700: > On Tue, Jul 12, 2016 at 1:48 PM, Edward Z. Yang wrote: > > > > > - 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 > > > If you don't already know about it, this bot: > https://github.com/facebook/mention-bot is worth investigating in addition > to the work you've mentioned. > From ezyang at mit.edu Tue Jul 12 21:58:25 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 12 Jul 2016 14:58:25 -0700 Subject: I reorged labels on Cabal's GitHub In-Reply-To: <142DE7CC-E5F6-43B6-9C68-5C0CE57DD161@iki.fi> References: <1468211667-sup-5569@sabre> <1468337813-sup-6598@sabre> <1D991361-A039-4627-A422-60BC5FAB751C@iki.fi> <1468355633-sup-6915@sabre> <142DE7CC-E5F6-43B6-9C68-5C0CE57DD161@iki.fi> Message-ID: <1468360613-sup-5714@sabre> 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 ) > (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 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 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 > > > > 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 > >>> > >>> 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 > >> > >> 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 > > From mikhail.glushenkov at gmail.com Tue Jul 12 22:49:07 2016 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Wed, 13 Jul 2016 00:49:07 +0200 Subject: I reorged labels on Cabal's GitHub In-Reply-To: <1468360613-sup-5714@sabre> References: <1468211667-sup-5569@sabre> <1468337813-sup-6598@sabre> <1D991361-A039-4627-A422-60BC5FAB751C@iki.fi> <1468355633-sup-6915@sabre> <142DE7CC-E5F6-43B6-9C68-5C0CE57DD161@iki.fi> <1468360613-sup-5714@sabre> Message-ID: Hi, On 12 July 2016 at 23:58, Edward Z. Yang wrote: > 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? LGTM. One other thing is that the "documentation" label should perhaps be merged with "component:user-guide". From ezyang at mit.edu Wed Jul 13 23:32:39 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 13 Jul 2016 16:32:39 -0700 Subject: Opening up Cabal development Message-ID: <1468451489-sup-3240@sabre> Hey all, Paolo Giarrusso suggested that the Cabal project might look into giving more people commit bits, ala http://felixge.de/2013/03/11/the-pull-request-hack.html I think we do need to give more commit bits. There's a sliding scale of how extreme we can go: 1. We can adopt this wholesale: you PR, your GitHub profile checks out, we give you bits. 2. If we accept your PR, we give you bits. 3. If we accept your PR for a new feature, we give you bits. For (2), I trawled the commit history for 2016 and here's what I think is all the commits from people without bits. I apologize if I missed anyone (I just went through the commit list by hand.) @thumphries https://github.com/haskell/cabal/commit/ce2ffb24902816ab02f6c6b50921fb3a9a8b92aa @sjakobi https://github.com/haskell/cabal/commit/bb9501bc23914a50684f288bc88cf04747d69c32 @accraze https://github.com/haskell/cabal/commit/11650b26ecf0ba95c3a7e747c0968735e906c3b0 @headprogrammingczar https://github.com/haskell/cabal/commit/e9883dced04e6a16e25752cc8513ce26325b4b4b https://github.com/haskell/cabal/commit/0252a0aed79e881d4f6210d9296216aef3c301d0 @randen https://github.com/haskell/cabal/commits/master?author=randen @aisamanra https://github.com/haskell/cabal/commit/6e2fca4314a01f07d520bc7b7669e70f70a231ce @kolmodin https://github.com/haskell/cabal/commit/0122e821825b875447f3844b349fba582fff39cf @mightybyte https://github.com/haskell/cabal/commit/ea01974be888d25ef918e7808aa6cf6b8aac1275 @gbaz https://github.com/haskell/cabal/commit/c69dfb8209dc7bfd9abf2a7e494704db652073c9 @garetxe https://github.com/haskell/cabal/commit/c72aa8dbb5a11fb4137bda62c9b7a99fb48b7649 @komadori https://github.com/haskell/cabal/commit/1da9b3533e6a0fae8692fa0f4f532ea63d43ccc8 @mgsloan https://github.com/haskell/cabal/commit/c10a4ca8c50290efc0b0ea65b34116ae165ccc9b @lukexi https://github.com/haskell/cabal/commit/5efc6341643e7fd98b33aea5a6ab96873d597787 @mpkh https://github.com/haskell/cabal/commit/fcaf5d02947c5fd853ff69e2326e08f0082530c1 @pra85 https://github.com/haskell/cabal/commit/a69b0ea23b0f00be30933a1dbb63fbc4f1306c17 @tvestelind https://github.com/haskell/cabal/commit/fe7b597542d57c74814620ed7a553e252b570ac7 @corngood https://github.com/haskell/cabal/commit/4214572306205ad2c20943ef2b3aacbc912c45d3 @gelisam https://github.com/haskell/cabal/commit/6b3457de66772d958fd5fe96066b08e93d0fb0c7 Why don't we give them all commit access! (If we want to do (1) also look at the current PR queue.) If people want, we could also formalize some more rules about the state of master, e.g., - The Travis build must always be green. We should prioritize adding more tests for things we care about. Look into regular Hackage tests. - PR all your changes (so that you can check that Travis is green), try to get approval for big changes but BE BOLD. Cheers, Edward From mikhail.glushenkov at gmail.com Wed Jul 13 23:45:58 2016 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Thu, 14 Jul 2016 01:45:58 +0200 Subject: Opening up Cabal development In-Reply-To: <1468451489-sup-3240@sabre> References: <1468451489-sup-3240@sabre> Message-ID: Hi, On 14 July 2016 at 01:32, Edward Z. Yang wrote: > Why don't we give them all commit access! (If we want to do (1) also > look at the current PR queue.) Fine with me. I tried something like this on a smaller scale previously, giving write access to a number of people with a history of quality contributions. > If people want, we could also formalize some more rules about the state > of master, e.g., > > - The Travis build must always be green. We should prioritize > adding more tests for things we care about. Look into regular > Hackage tests. > - PR all your changes (so that you can check that Travis is green), > try to get approval for big changes but BE BOLD. +1 on having a welcome page for new developers on the wiki. From gershomb at gmail.com Thu Jul 14 01:01:50 2016 From: gershomb at gmail.com (Gershom B) Date: Wed, 13 Jul 2016 18:01:50 -0700 Subject: Opening up Cabal development In-Reply-To: <1468451489-sup-3240@sabre> References: <1468451489-sup-3240@sabre> Message-ID: On July 13, 2016 at 7:32:47 PM, Edward Z. Yang (ezyang at mit.edu) wrote: The general notion sounds good to me. I’m semi-indifferent between (1) and (2) though conservatively lean towards the latter. > - The Travis build must always be green. We should prioritize > adding more tests for things we care about. Look into regular > Hackage tests. > - PR all your changes (so that you can check that Travis is green), > try to get approval for big changes but BE BOLD. I’d add - I don’t break backwards compat for APIs without notice and discussion, and don’t break backwards compat for any element of cabal files without lots of discussion. (and I don’t know what tests would be necessary to help notice this, but they’d probably be useful!) —gershom From ezyang at mit.edu Thu Jul 14 01:13:31 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 13 Jul 2016 18:13:31 -0700 Subject: Opening up Cabal development In-Reply-To: References: <1468451489-sup-3240@sabre> Message-ID: <1468458470-sup-4095@sabre> Excerpts from Gershom B's message of 2016-07-13 18:01:50 -0700: > On July 13, 2016 at 7:32:47 PM, Edward Z. Yang (ezyang at mit.edu) wrote: > > The general notion sounds good to me. I’m semi-indifferent between (1) > and (2) though conservatively lean towards the latter. > > > - The Travis build must always be green. We should prioritize > > adding more tests for things we care about. Look into regular > > Hackage tests. > > - PR all your changes (so that you can check that Travis is green), > > try to get approval for big changes but BE BOLD. > > I’d add > > - I don’t break backwards compat for APIs without notice and > discussion, and don’t break backwards compat for any element of cabal > files without lots of discussion. > > (and I don’t know what tests would be necessary to help notice this, > but they’d probably be useful!) Simple, we need Hackage-level CI. Here are few possible things to test: 1. Can we parse all of Hackage? 2. Can we build all of Stackage? https://groups.google.com/forum/#!msg/haskell-stack/oi-VJrAIJbE/FjAPVZTUAQAJ Attempting to build all of Hackage is dicey business because it is a combinatorial explosion, and you do not know what is supposed to build. But Stackage is supposed to build. Test that 3. Can we build all Setup.hs scripts on Hackage? This lets us know which APIs in Cabal matter, and which ones we can change. We'll need to establish base truth for this. It is a travesty that this infrastructure does not exist; it may even be possible to do (1) and (3) on Travis, as they should not take too long to do. Edward From mikhail.glushenkov at gmail.com Thu Jul 14 01:19:54 2016 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Thu, 14 Jul 2016 03:19:54 +0200 Subject: Opening up Cabal development In-Reply-To: <1468458470-sup-4095@sabre> References: <1468451489-sup-3240@sabre> <1468458470-sup-4095@sabre> Message-ID: On 14 July 2016 at 03:13, Edward Z. Yang wrote: > 1. Can we parse all of Hackage? > > [...] > > 3. Can we build all Setup.hs scripts on Hackage? This lets us know > which APIs in Cabal matter, and which ones we can change. > We'll need to establish base truth for this. If someone wants to look into this, the following links should be helpful: https://github.com/commercialhaskell/all-cabal-files https://github.com/23Skidoo/all-custom-setups From hvriedel at gmail.com Thu Jul 14 06:40:06 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 14 Jul 2016 08:40:06 +0200 Subject: Opening up Cabal development In-Reply-To: <1468458470-sup-4095@sabre> (Edward Z. Yang's message of "Wed, 13 Jul 2016 18:13:31 -0700") References: <1468451489-sup-3240@sabre> <1468458470-sup-4095@sabre> Message-ID: <87wpko67uh.fsf@gmail.com> On 2016-07-14 at 03:13:31 +0200, Edward Z. Yang wrote: [...] >> - I don’t break backwards compat for APIs without notice and >> discussion, and don’t break backwards compat for any element of cabal >> files without lots of discussion. [...] > 3. Can we build all Setup.hs scripts on Hackage? This lets us know > which APIs in Cabal matter, and which ones we can change. > We'll need to establish base truth for this. While we shouldn't break the API without a good reason, we added custom-setup/setup-depends for the very reason to finally be able to break Setup.hs. Now we can specify `Setup.hs`'s dependencies with version constraints accurately, just like we already do with other library dependencies via build-depends. Moreover, cabal-install has a generous implicit upper bound on the Cabal lib version: -- The idea here is that at some point we will make significant -- breaking changes to the Cabal API that Setup.hs scripts use. -- So for old custom Setup scripts that do not specify explicit -- constraints, we constrain them to use a compatible Cabal version. -- The exact version where we'll make this API break has not yet been -- decided, so for the meantime we guess at 2.x. cabalCompatMaxVer = Version [2] [] So criteria 3 should be seen in the light of custom-setup/setup-depends. Otoh, maybe we should collect and batch up all ideas (including refactoring/aesthetic changes) to break the Cabal API for a big Cabal 2.0 rupture... :-) > It is a travesty that this infrastructure does not exist; it may even > be possible to do (1) and (3) on Travis, as they should not take too > long to do. So far, the criteria mentioned address mostly regressions. What about changes extending the .cabal syntax? There's frequently proposals to extend the features of .cabal files. I happen to propose extensions myself from time to time (motivated by the issues I see as Hackage Trustee). Since changes to .cabal are effectively changes to the CABAL specification future generations will have to cope with, I'd propose that changes affecting or introducing new .cabal syntax/semantics should go through a proposal process. I.e. write up a specification/proposal outlining motivation (i.e. what problem does this solve), specify what the changes are exactly (syntax & semantics), what the consequences are, and so on. Then we inevitably need some criteria to decide whether a proposal is accepted and approved for implementation. This could be formally in the hands of the core library committee together with the Hackage trustees (since we do have quite some experience with .cabal files and care a lot about the Hackage ecosystem). -- hvr -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From ezyang at mit.edu Thu Jul 14 06:54:19 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 13 Jul 2016 23:54:19 -0700 Subject: Opening up Cabal development In-Reply-To: <87wpko67uh.fsf@gmail.com> References: <1468451489-sup-3240@sabre> <1468458470-sup-4095@sabre> <87wpko67uh.fsf@gmail.com> Message-ID: <1468478802-sup-3343@sabre> Excerpts from Herbert Valerio Riedel's message of 2016-07-13 23:40:06 -0700: > I.e. write up a specification/proposal outlining motivation (i.e. what > problem does this solve), specify what the changes are exactly (syntax & > semantics), what the consequences are, and so on. > > Then we inevitably need some criteria to decide whether a proposal is > accepted and approved for implementation. This could be formally in the > hands of the core library committee together with the Hackage trustees > (since we do have quite some experience with .cabal files and care a lot > about the Hackage ecosystem). Why can't we release experimental changes to the Cabal specification? Neither setup-depends nor convenience libraries went through any formal proposal mechanism. If a feature is good people will start using it and we will have to continue supporting it. If a feature is bad/not useful we can yank it from the next release; anyone using an experimental feature like this isn't trying to maximize their Cabal compatibility anyway. And any change to the format with cabal-install can't parse is not going to be supportable via custom-setup anyway. So how about this script, which is how web standards work: Cabal changes need to be informally proposed and discussed. But the advancer can also write a PR and get it merged in as an experimental extension, to be trialed for the next major release series. Eventually it gets standardized. Edward From oleg.grenrus at iki.fi Thu Jul 14 09:08:54 2016 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Thu, 14 Jul 2016 12:08:54 +0300 Subject: Opening up Cabal development In-Reply-To: <1468478802-sup-3343@sabre> References: <1468451489-sup-3240@sabre> <1468458470-sup-4095@sabre> <87wpko67uh.fsf@gmail.com> <1468478802-sup-3343@sabre> Message-ID: <5B0D65D1-6BDA-4CB3-AEC2-438E34BD00F1@iki.fi> > On 14 Jul 2016, at 09:54, Edward Z. Yang wrote: > > Excerpts from Herbert Valerio Riedel's message of 2016-07-13 23:40:06 -0700: >> I.e. write up a specification/proposal outlining motivation (i.e. what >> problem does this solve), specify what the changes are exactly (syntax & >> semantics), what the consequences are, and so on. >> >> Then we inevitably need some criteria to decide whether a proposal is >> accepted and approved for implementation. This could be formally in the >> hands of the core library committee together with the Hackage trustees >> (since we do have quite some experience with .cabal files and care a lot >> about the Hackage ecosystem). > > Why can't we release experimental changes to the Cabal specification? > Neither setup-depends nor convenience libraries went through any formal > proposal mechanism. If a feature is good people will start using it > and we will have to continue supporting it. If a feature is bad/not > useful we can yank it from the next release; anyone using an > experimental feature like this isn't trying to maximize their > Cabal compatibility anyway. And any change to the format with > cabal-install can't parse is not going to be supportable via > custom-setup anyway. You gave a reason yourself: - Can we parse all of Hackage? With my industrial hat on, I don’t like the idea that I might need older Cabal, to be able to install some package. OTOH new-build could install older Cabal. So we’d need to maintain older Cabals, to be build able with newer GHCs, that’s not fun, but not impossible. I agree, that we could have discussed setup-depends more, hopefully no-one disagrees about them (and dcoutts took very conservative approach there). Also taking them out of Cabal, doesn’t mean that package becomes unbuildable, there will be just more luck involved. About convenience libraries I agree even more. We should discussed them more. There are questions I’d might to ask, but I guess it too late Or maybe not too late, but for another thread: what is convenience library name clashes with the library on package, say I define convenience library fancylib-lens, which is on Hackage, but maybe also after I made my package? I guess, some shadowing happens? Is there a warning? But we have quite formal feeling proposals about `provides`, and `or-dependencies / multi-way-flag / depends`, and formal process would help to get them thru (or say no, with an explanation) > > So how about this script, which is how web standards work: > > Cabal changes need to be informally proposed and discussed. > But the advancer can also write a PR and get it merged in > as an experimental extension, to be trialed for the next > major release series. Eventually it gets standardized. > > Edward About the original topic, I’d require “ a history of quality contributions”, so something between (2) or (3). I don’t like many rules, also making fair but non-abusable ones is difficult, but as we have this conversation, the outcome should be well defined (also how we change the rules). As with (2) does every accepted PR counts, like single character typo fix in the documentation? And I don’t know how to define “quality contribution” :( (Maybe I’m just to scared about dramas happened elsewhere) Related to this, a thought I had for some time: I’d like to split Cabal and cabal-install repositories. Pros: - `cabal-install` can be much more liberal in giving out commit bits, as you cannot make too much damage here. - we already have `hackage-security` as a dependency between them. - the CI setup could be simplified, resulting into - their tests could do more things: `Cabal` parses all `Hackage`, changes to `cabal-install` doesn’t need to do it, and vice-versa, fixing ui of cabal-install doesn’t need to do package tests of Cabal. - their other processes could be different too. Cons: Simultaneous development is almost impossible. And this is almost a show-stopper. - `cabal-install` would need to lag one release behind `Cabal` (development agains released `Cabal`). This could work as `Setup.hs` should work to install packages requiring newer Cabal (isn’t it how it works nowadays?). There will be a problem when newer `Cabal` won’t accept build-plan created by solver in older `cabal-install` (proposals mentioned above), but I hope it won’t be a huge issue. - To make this work we’d need to release more Cabal major versions, so there aren’t many breaking and intrusive changes accumulating. But that’s good thing, isn’t it? Or it could be a quality win to separate them. After all `cabal-install` is not the only consumer of `Cabal`. `stack` uses it very limitedly atm though (i.e. to extract dependencies and maybe verify install plan?) I don’t know what `ghc-pkg` does. IMHO we should develop Cabal-the-library with highest standards (starting with having detailed CHANGELOG) for library development. Now we might have been too focused on developing Cabal for cabal-install. Cabal should provide quality plumbing support for “everyone”. (if we could start with a clean desk, i’d make Setup.hs and cabal-install commands different, that’s one confusing part). The separation into different repositories would make things a bit clearer: Cabal-the-library and cabal-install are different things. (For example: cabal-install doesn’t parse *.cabal files). - Oleg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ezyang at mit.edu Thu Jul 14 16:08:25 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 14 Jul 2016 09:08:25 -0700 Subject: Opening up Cabal development In-Reply-To: <5B0D65D1-6BDA-4CB3-AEC2-438E34BD00F1@iki.fi> References: <1468451489-sup-3240@sabre> <1468458470-sup-4095@sabre> <87wpko67uh.fsf@gmail.com> <1468478802-sup-3343@sabre> <5B0D65D1-6BDA-4CB3-AEC2-438E34BD00F1@iki.fi> Message-ID: <1468511744-sup-3411@sabre> Excerpts from Oleg Grenrus's message of 2016-07-14 02:08:54 -0700: > About convenience libraries I agree even more. We should discussed them more. > There are questions I’d might to ask, but I guess it too late It's not too late. They are not in any real release. They can be removed. > Or maybe not too late, but for another thread: > what is convenience library name clashes with the library on package, > say I define convenience library fancylib-lens, which is on Hackage, but maybe also after I made my package? > I guess, some shadowing happens? Is there a warning? Convenience library shadows the one on Hackage. There's no warning but it would be easy to add one; however, I don't think there should be a warning--these names are just lexically scoped. > But we have quite formal feeling proposals about `provides`, > and `or-dependencies / multi-way-flag / depends`, and > formal process would help to get them thru (or say no, with an explanation) Yes. Especially when there are competing solutions and there is not an obvious "best one". > About the original topic, I’d require “ a history of quality contributions”, so something between (2) or (3). > I don’t like many rules, also making fair but non-abusable ones is difficult, but as we have this conversation, > the outcome should be well defined (also how we change the rules). > As with (2) does every accepted PR counts, like single character typo fix in the documentation? > And I don’t know how to define “quality contribution” :( In the blog post linked, the suggestion was to apply discretion by looking at the GitHub profile / erstwhile contribution history. But yes, I DO think we should accept single character typo fixes! That's how you get new contributors who help spruce up the documentation. We should trust but verify. > (Maybe I’m just to scared about dramas happened elsewhere) Too late; there's already drama ;) > Related to this, a thought I had for some time: > I’d like to split Cabal and cabal-install repositories. > > Pros: > - `cabal-install` can be much more liberal in giving out commit bits, as you cannot make too much damage here. > - we already have `hackage-security` as a dependency between them. > - the CI setup could be simplified, resulting into > - their tests could do more things: `Cabal` parses all `Hackage`, changes to `cabal-install` doesn’t need to do it, > and vice-versa, fixing ui of cabal-install doesn’t need to do package tests of Cabal. > - their other processes could be different too. > > Cons: Simultaneous development is almost impossible. And this is almost a show-stopper. > - `cabal-install` would need to lag one release behind `Cabal` (development agains released `Cabal`). > This could work as `Setup.hs` should work to install packages requiring newer Cabal (isn’t it how it works nowadays?). > There will be a problem when newer `Cabal` won’t accept build-plan created by solver > in older `cabal-install` (proposals mentioned above), but I hope it won’t be a huge issue. > - To make this work we’d need to release more Cabal major versions, > so there aren’t many breaking and intrusive changes accumulating. But that’s good thing, isn’t it? > > Or it could be a quality win to separate them. After all `cabal-install` is not the only consumer of `Cabal`. > `stack` uses it very limitedly atm though (i.e. to extract dependencies and maybe verify install plan?) > I don’t know what `ghc-pkg` does. > > IMHO we should develop Cabal-the-library with highest standards (starting with having detailed CHANGELOG) for library development. > Now we might have been too focused on developing Cabal for cabal-install. Cabal should provide quality plumbing support for “everyone”. > (if we could start with a clean desk, i’d make Setup.hs and cabal-install commands different, that’s one confusing part). > > The separation into different repositories would make things a bit clearer: > Cabal-the-library and cabal-install are different things. (For example: cabal-install doesn’t parse *.cabal files). Currently cabal-install is tightly coupled to Cabal. I'm all for looser coupling (e.g., https://github.com/haskell/cabal/issues/3549). Separate repositories force this, but in general looser coupling will lead to some short term pain. Edward From ezyang at mit.edu Sat Jul 16 21:57:16 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Sat, 16 Jul 2016 14:57:16 -0700 Subject: Opening up Cabal development In-Reply-To: <1468451489-sup-3240@sabre> References: <1468451489-sup-3240@sabre> Message-ID: <1468706205-sup-9752@sabre> I pulled the trigger. If you are mad, talk to me. https://github.com/haskell/cabal/issues/3567 Edward Excerpts from Edward Z. Yang's message of 2016-07-13 16:32:39 -0700: > Hey all, > > Paolo Giarrusso suggested that the Cabal project might look into > giving more people commit bits, ala http://felixge.de/2013/03/11/the-pull-request-hack.html > > I think we do need to give more commit bits. There's a sliding scale of > how extreme we can go: > > 1. We can adopt this wholesale: you PR, your GitHub profile checks > out, we give you bits. > 2. If we accept your PR, we give you bits. > 3. If we accept your PR for a new feature, we give you bits. > > For (2), I trawled the commit history for 2016 and here's what I think > is all the commits from people without bits. I apologize if I missed > anyone (I just went through the commit list by hand.) > > @thumphries https://github.com/haskell/cabal/commit/ce2ffb24902816ab02f6c6b50921fb3a9a8b92aa > @sjakobi https://github.com/haskell/cabal/commit/bb9501bc23914a50684f288bc88cf04747d69c32 > @accraze https://github.com/haskell/cabal/commit/11650b26ecf0ba95c3a7e747c0968735e906c3b0 > @headprogrammingczar https://github.com/haskell/cabal/commit/e9883dced04e6a16e25752cc8513ce26325b4b4b > https://github.com/haskell/cabal/commit/0252a0aed79e881d4f6210d9296216aef3c301d0 > @randen https://github.com/haskell/cabal/commits/master?author=randen > @aisamanra https://github.com/haskell/cabal/commit/6e2fca4314a01f07d520bc7b7669e70f70a231ce > @kolmodin https://github.com/haskell/cabal/commit/0122e821825b875447f3844b349fba582fff39cf > @mightybyte https://github.com/haskell/cabal/commit/ea01974be888d25ef918e7808aa6cf6b8aac1275 > @gbaz https://github.com/haskell/cabal/commit/c69dfb8209dc7bfd9abf2a7e494704db652073c9 > @garetxe https://github.com/haskell/cabal/commit/c72aa8dbb5a11fb4137bda62c9b7a99fb48b7649 > @komadori https://github.com/haskell/cabal/commit/1da9b3533e6a0fae8692fa0f4f532ea63d43ccc8 > @mgsloan https://github.com/haskell/cabal/commit/c10a4ca8c50290efc0b0ea65b34116ae165ccc9b > @lukexi https://github.com/haskell/cabal/commit/5efc6341643e7fd98b33aea5a6ab96873d597787 > @mpkh https://github.com/haskell/cabal/commit/fcaf5d02947c5fd853ff69e2326e08f0082530c1 > @pra85 https://github.com/haskell/cabal/commit/a69b0ea23b0f00be30933a1dbb63fbc4f1306c17 > @tvestelind https://github.com/haskell/cabal/commit/fe7b597542d57c74814620ed7a553e252b570ac7 > @corngood https://github.com/haskell/cabal/commit/4214572306205ad2c20943ef2b3aacbc912c45d3 > @gelisam https://github.com/haskell/cabal/commit/6b3457de66772d958fd5fe96066b08e93d0fb0c7 > > Why don't we give them all commit access! (If we want to do (1) also > look at the current PR queue.) > > If people want, we could also formalize some more rules about the state > of master, e.g., > > - The Travis build must always be green. We should prioritize > adding more tests for things we care about. Look into regular > Hackage tests. > - PR all your changes (so that you can check that Travis is green), > try to get approval for big changes but BE BOLD. > > Cheers, > Edward From p.giarrusso at gmail.com Sun Jul 17 11:27:14 2016 From: p.giarrusso at gmail.com (Paolo G. Giarrusso) Date: Sun, 17 Jul 2016 11:27:14 +0000 (UTC) Subject: Opening up Cabal development References: <1468451489-sup-3240@sabre> <1468458470-sup-4095@sabre> <87wpko67uh.fsf@gmail.com> <1468478802-sup-3343@sabre> Message-ID: Edward Z. Yang mit.edu> writes: > Excerpts from Herbert Valerio Riedel's message of 2016-07-13 23:40:06 -0700: > > I.e. write up a specification/proposal outlining motivation (i.e. what > > problem does this solve), specify what the changes are exactly (syntax & > > semantics), what the consequences are, and so on. > > > > Then we inevitably need some criteria to decide whether a proposal is > > accepted and approved for implementation. This could be formally in the > > hands of the core library committee together with the Hackage trustees > > (since we do have quite some experience with .cabal files and care a lot > > about the Hackage ecosystem). > > Why can't we release experimental changes to the Cabal specification? > Neither setup-depends nor convenience libraries went through any formal > proposal mechanism. If a feature is good people will start using it > and we will have to continue supporting it. If a feature is bad/not > useful we can yank it from the next release; anyone using an > experimental feature like this isn't trying to maximize their > Cabal compatibility anyway. Important nitpick: to do that, experimental features should be marked as experimental and this policy should be made explicit. That'd be kinder to the one user who starts using it without realizing. I guess that goes without saying (probably in ways I don't realize), but hey :-D From ezyang at mit.edu Sun Jul 17 17:57:07 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Sun, 17 Jul 2016 10:57:07 -0700 Subject: Opening up Cabal development In-Reply-To: References: <1468451489-sup-3240@sabre> <1468458470-sup-4095@sabre> <87wpko67uh.fsf@gmail.com> <1468478802-sup-3343@sabre> Message-ID: <1468778193-sup-1386@sabre> Yep, of course. (I sometimes get the feeling that a less good way people do this is by just not documenting the feature :o) Excerpts from Paolo G. Giarrusso's message of 2016-07-17 04:27:14 -0700: > Edward Z. Yang mit.edu> writes: > > > Excerpts from Herbert Valerio Riedel's message of 2016-07-13 23:40:06 -0700: > > > I.e. write up a specification/proposal outlining motivation (i.e. what > > > problem does this solve), specify what the changes are exactly (syntax & > > > semantics), what the consequences are, and so on. > > > > > > Then we inevitably need some criteria to decide whether a proposal is > > > accepted and approved for implementation. This could be formally in the > > > hands of the core library committee together with the Hackage trustees > > > (since we do have quite some experience with .cabal files and care a lot > > > about the Hackage ecosystem). > > > > Why can't we release experimental changes to the Cabal specification? > > Neither setup-depends nor convenience libraries went through any formal > > proposal mechanism. If a feature is good people will start using it > > and we will have to continue supporting it. If a feature is bad/not > > useful we can yank it from the next release; anyone using an > > experimental feature like this isn't trying to maximize their > > Cabal compatibility anyway. > > Important nitpick: to do that, experimental features should be > marked as experimental and this policy should be made explicit. > That'd be kinder to the one user who starts using it without > realizing. > > I guess that goes without saying (probably in ways I don't > realize), but hey :-D >