Re: Opening up Cabal development

2016-07-17 Thread Edward Z. Yang
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-

Re: Opening up Cabal development

2016-07-17 Thread Paolo G . Giarrusso
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 consequen

Re: Opening up Cabal development

2016-07-16 Thread Edward Z. Yang
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 > ht

Re: Opening up Cabal development

2016-07-14 Thread Edward Z. Yang
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 n

Re: Opening up Cabal development

2016-07-14 Thread Oleg Grenrus
> 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),

Re: Opening up Cabal development

2016-07-13 Thread Edward Z. Yang
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 inevitabl

Re: Opening up Cabal development

2016-07-13 Thread Herbert Valerio Riedel
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?

Re: Opening up Cabal development

2016-07-13 Thread Mikhail Glushenkov
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 so

Re: Opening up Cabal development

2016-07-13 Thread Edward Z. Yang
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 (ezy...@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 mus

Re: Opening up Cabal development

2016-07-13 Thread Gershom B
On July 13, 2016 at 7:32:47 PM, Edward Z. Yang (ezy...@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 ca

Re: Opening up Cabal development

2016-07-13 Thread Mikhail Glushenkov
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 qualit