Re: Proposal process status

[Carter Schonwald]

On Wednesday, July 20, 2016, Ben Gamari  wrote:

> Yuras Shumovich > writes:
>
> > Looks like reddit is a wrong place, so I'm replicating my comment here:
> >
> Thanks for your comments Yuras!
>
> >>   * Do you feel the proposed process is an improvement over the
> >> status quo?
> >
> > Yes, definitely. The existing process is too vague, so formalizing it
> > is a win in any case.
> >
> Good to hear.
>
> >>   * What would you like to see changed in the proposed process, if
> >> anything?
> >
> > The proposed process overlaps with the Language Committee powers. In
> > theory the Committee works on language standard, but de facto Haskell
> > is GHC/Haskell and GHC/Haskell is Haskell. Adding new extension to GHC
> > adds new extension to Haskell. So I'd like the process to enforce
> > separation between experimental extensions (not recommended in
> > production code) and language improvements. I'd like the process to
> > specify how the GHC Committee is going to communicate and share powers
> > with the Language Committee.
> >
> To clarify I think Language Committee here refers to the Haskell Prime
> committee, right?
>
> I think these two bodies really do serve different purposes.
> Historically the Haskell Prime committee has been quite conservative in
> the sorts of changes that they standardized; as far as I know almost all
> of them come from a compiler. I would imagine that the GHC Committee
> would be a gate-keeper for proposals entering GHC and only some time
> later, when the semantics and utility of the extension are
> well-understood, would the Haskell Prime committee consider introducing
> it to the Report. As far as I understand it, this is historically how
> things have worked in the past, and I don't think this new process would
> change that.
>
> Of course, let me know if I'm off-base here.


As one of the 20 members of the Haskell (Prime) 2020 committee id like to
interject on this front: the preliminary discussions the committee has had
thus far had a clear agreement that we shall aim to be a bit more
progressive about what shall be included in the standard. The main bar will
be the extent to which features or capabilities can be articulated without
over specifying implementation details and can tractably have compatible
but different compilers for the standard.

  I think some of the other prime committee members can articulate this a
bit better than I, so don't hold me to this precise phrasing ;)




>
> Cheers,
>
> - Ben
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Ben Gamari]

Jack Hill  writes:

> Hi all,
>
> I'm a bit of an outsider here as I'm not involved in GHC development (but 
> I am interested in how it goes). I've struggled with my own desire to 
> avoid using proprietary software like GitHub, and the desire to work with 
> those who favor it, so I am interested in how these competing desires can 
> be addressed.
>
> Would the barrier to entry to a non-GitHub system be reduced by using 
> GitHub for user authentication/accounts (like http://exercism.io/ ), or is 
> knowing how to use other software too much of a barrier (I guess that 
> would depend on the software…)?
>
To some extent. The size of the barrier posed by an alternate
system isn't a discrete quantity and is highly dependent upon one's
frame of reference. Many people won't wander from GitHub at all; other
won't even register for a GitHub account. People vary widely in their
preferences, which is what makes this problem so difficult.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 20/07/16 23:41, Jack Hill wrote:
> Would the barrier to entry to a non-GitHub system be reduced by
> using GitHub for user authentication/accounts
For what it's worth, GitLab supports this[0]. You can also use
Twitter, or whatever.

[0]  
- -- 
Alexander
alexan...@plaimi.net
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXj/B7AAoJENQqWdRUGk8BJZcQAJQc/v7UWFdFEVVHlE9Mp/PR
ddlT5ngNJEagxzv5vZpEAk3oVTq2jyMaHP/KM+RGwR8l025jdP/groZ73g2X1qTn
EMLg+orKO5SGMeHK0jdypBQCMEhwNI3kDvh/Nu3ZOdM2yBWHbHHkW/3CD6T4n+zo
UpSDfmlkpOXfOtssqngjlnYJ0/roldrJGY1RCGmtrljFmvWTlmBBTTA/HqxB1mQy
doA9uJnwI8Cr7MTpoV7W8yOzv8IkfiOgO7Q3kUv8rrRtij7uN4wqM0+/eyFEmapO
BGMWM5RixmffjIyKILFUr0WkgYk8WtgXfqA8+kcYYeKQB+er7Jppbzw+IeSdyJ0g
UyM7140uBtLAqHUCpvXx8Yp36qRmEtf5Bqscz9+4oQoAWLeYAvHWaIcifj1fqtUd
HQuMdES0Pm1PcXPBu1WNd31QUeb0UsM7N1STvgAv/Iwi2SH/OFk4JyPgjSrtPDc+
KoD5LunsWBotipZr1reia7pW0mjhwPf8e6rI7FOhZjNFyNesoQWxIDFTp3IBxSYZ
oyz7bdGRP1H1MsxwBeVpPN5IzWA4EkCiWKcCb6lGFvg9lqSFfFY36HGwoHehkvo/
cSV9agY4V4ZSl0wIp3sy5eCPcUmaBR/JHCiDrhpVl+x8kRaYVbjvoS09Kty0J3nj
upaF1qaI20+1Jdv0pyab
=n/aA
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Jack Hill]

On Wed, 20 Jul 2016, Adam Foltzer wrote:


 1. Higher than necessary barrier-to-entry.
For the purposes of this proposal, whether we would prefer a competing 
alternative is secondary to the fact that a Github account has become a very low
common denominator for people wishing to participate in the development of open 
source projects. If we decide to proceed with a non-Github platform, we
need to make a compelling case that the alternate choice does not raise the 
barrier to entry, or else we need to decide that we have different priorities
for this effort.


Hi all,

I'm a bit of an outsider here as I'm not involved in GHC development (but 
I am interested in how it goes). I've struggled with my own desire to 
avoid using proprietary software like GitHub, and the desire to work with 
those who favor it, so I am interested in how these competing desires can 
be addressed.


Would the barrier to entry to a non-GitHub system be reduced by using 
GitHub for user authentication/accounts (like http://exercism.io/ ), or is 
knowing how to use other software too much of a barrier (I guess that 
would depend on the software…)?


Thanks,
Jack___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Adam Foltzer]

I really appreciate you putting so much work into this. It is very
important, and I believe could do much to increase awareness of and
participation in these processes.

I've left most of my thoughts as line comments on the proposal document,
but since discussion of platform choice is taking place here, I'll quote
the Motivations section:

   1. Higher than necessary barrier-to-entry.

For the purposes of this proposal, whether we would prefer a competing
alternative is secondary to the fact that a Github account has become a
very low common denominator for people wishing to participate in the
development of open source projects. If we decide to proceed with a
non-Github platform, we need to make a compelling case that the alternate
choice does not raise the barrier to entry, or else we need to decide that
we have different priorities for this effort.

Thanks,
Adam

On Wed, Jul 20, 2016 at 12:56 PM, Ben Gamari  wrote:

> Alexander Berntsen  writes:
>
> > On 20/07/16 19:04, Ben Gamari wrote:
> >> I know, it's rather frustrating. I also have fairly strong feelings
> >>  about open-source purity, but in this case I just don't see any
> >> way to improve the current situation under this constraint.
> >
> > I don't think that starting to rely on proprietary software *is* an
> > improvement, but the opposite.
> >
> This is a bit of a judgement call. I know this is a long-contested
> issue, but personally for me it puts me at ease if,
>
>  * the proprietary code is running on someone else's machine
>
>  * I can use the application with open tools (a web browser of your
>choice, git, and an email client)
>
>  * I can get my data out if needed
>
>
> >> It does look like Gitlab is an impressive option but really then
> >> we are back to the problem of fragmented development tools. Using
> >> Trac, Phabricator, Gitlab, and mailing lists all in one project
> >> seems a bit silly.
> >
> > I don't understand why using GitLab is more silly than using GitHub,
> > when considering fragmentation.
>
> When put this way my argument does indeed sound a bit silly. :-)
>
> Perhaps it's not. I think the difference is that we would
> be consolidating on a platform which much of the Haskell community
> already uses in their non-GHC development.
>
> Cheers,
>
> - Ben
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Ben Gamari]

Alexander Berntsen  writes:

> On 20/07/16 19:04, Ben Gamari wrote:
>> I know, it's rather frustrating. I also have fairly strong feelings
>>  about open-source purity, but in this case I just don't see any
>> way to improve the current situation under this constraint.
>
> I don't think that starting to rely on proprietary software *is* an
> improvement, but the opposite.
>
This is a bit of a judgement call. I know this is a long-contested
issue, but personally for me it puts me at ease if,

 * the proprietary code is running on someone else's machine

 * I can use the application with open tools (a web browser of your
   choice, git, and an email client)

 * I can get my data out if needed


>> It does look like Gitlab is an impressive option but really then
>> we are back to the problem of fragmented development tools. Using
>> Trac, Phabricator, Gitlab, and mailing lists all in one project
>> seems a bit silly.
>
> I don't understand why using GitLab is more silly than using GitHub,
> when considering fragmentation.

When put this way my argument does indeed sound a bit silly. :-)

Perhaps it's not. I think the difference is that we would
be consolidating on a platform which much of the Haskell community
already uses in their non-GHC development.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Niklas Larsson]

> 20 juli 2016 kl. 19:38 skrev amin...@gmail.com:
> 
> 
> 
>> El 20 jul 2016, a las 12:45, Ben Gamari  escribió:
>> 
>> Iavor Diatchki  writes:
>> 
>>> Hello Ben,
>>> 
>>> I posted this when you originally asked for feed-back, but perhaps it
>>> got buried among the rest of the e-mails.
>> Indeed it seems that way. Sorry about that!
>> 
>>> I think the proposal sounds fairly reasonable, but it is hard to say how
>>> well it will work in practice until we try it, and we should be ready to
>>> change it if needs be.
>> Right. I fully expect that we will have to iterate on it.
>> 
>>> Some clarifying questions on the intended process:
>>> 1.  After submitting the initial merge request, is the person making the
>>> proposal to wait for any kind of acknowledgment, or just move on to step 2?
>> The discussion phase can happen asynchronously from any action by the
>> Committee. Of course, the Committee should engauge in discussion early,
>> but I don't think any sort of acknowledgement is needed. An open pull
>> request should be taken to mean "let's discuss this idea."
>> 
>>> 2. Is the discussion going to happen on one of the mailing lists, if so
>>> which?   Is it the job of the proposing person to involve/notify the
>>> committee about the discussion?  If so, how are they to find out who is on
>>> the committee?
>> 
>> The proposed process places the discussion in a pull request. The idea
>> here is to use well-understood and widely-used code review tools to
>> faciliate the conversation.
> 
> This part runs strongly against the grain of what I'd prefer: email is 
> lightweight, decentralized, standard, and has many clients. We can read 
> discussion of Haskell proposals any way we like. Github on the other hand 
> only allows us to read issues by going to Github, and using whatever 
> interface Github has given us (which personally I find very annoying, esp. on 
> mobile). In addition, reading proposals offline becomes very difficult. Many 
> of us read discussion when commuting, where, e.g. in NYC, there isn't cell 
> service.
> 
> For reviewing code that implements a proposal, I'm a lot more flexible 
> (although again I'm not a fan of Github)
> 
> For the people who like having history tracked with git: gitit is a 
> possibility, and is written in Haskell.
> 
> Tom
> 

It's possible both follow and contribute to issues in a github repo via email. 
I do it all the time for Idris.

// Niklas

> 
> 
>> The Committee members will be notified of the open pull request by the
>> usual event notification mechanism (e.g. in GitHub one can subscribe to
>> a repository).
>> 
>>> 3. How does one actually perform step 3, another pull request or simply
>>> an e-mail to someone?
>> The opening of the pull request would mark the beginning of the
>> discussion period. When the author feels that the discussion has come to
>> something of a conclusion, they will request that the GHC Committee
>> consider the proposal for acceptable by leaving a comment on the pull
>> request.
>> 
>>> Typo: two separate bullets in the proposal are labelled as 4.
>> I believe this should be fixed now. Thanks!
>> 
>> Cheers,
>> 
>> - Ben
>> 
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[amindfv]

> El 20 jul 2016, a las 12:45, Ben Gamari  escribió:
> 
> Iavor Diatchki  writes:
> 
>> Hello Ben,
>> 
>> I posted this when you originally asked for feed-back, but perhaps it
>> got buried among the rest of the e-mails.
> Indeed it seems that way. Sorry about that!
> 
>> I think the proposal sounds fairly reasonable, but it is hard to say how
>> well it will work in practice until we try it, and we should be ready to
>> change it if needs be.
> Right. I fully expect that we will have to iterate on it.
> 
>> Some clarifying questions on the intended process:
>>  1.  After submitting the initial merge request, is the person making the
>> proposal to wait for any kind of acknowledgment, or just move on to step 2?
> The discussion phase can happen asynchronously from any action by the
> Committee. Of course, the Committee should engauge in discussion early,
> but I don't think any sort of acknowledgement is needed. An open pull
> request should be taken to mean "let's discuss this idea."
> 
>>  2. Is the discussion going to happen on one of the mailing lists, if so
>> which?   Is it the job of the proposing person to involve/notify the
>> committee about the discussion?  If so, how are they to find out who is on
>> the committee?
> 
> The proposed process places the discussion in a pull request. The idea
> here is to use well-understood and widely-used code review tools to
> faciliate the conversation.

This part runs strongly against the grain of what I'd prefer: email is 
lightweight, decentralized, standard, and has many clients. We can read 
discussion of Haskell proposals any way we like. Github on the other hand only 
allows us to read issues by going to Github, and using whatever interface 
Github has given us (which personally I find very annoying, esp. on mobile). In 
addition, reading proposals offline becomes very difficult. Many of us read 
discussion when commuting, where, e.g. in NYC, there isn't cell service.

For reviewing code that implements a proposal, I'm a lot more flexible 
(although again I'm not a fan of Github)

For the people who like having history tracked with git: gitit is a 
possibility, and is written in Haskell.

Tom



> The Committee members will be notified of the open pull request by the
> usual event notification mechanism (e.g. in GitHub one can subscribe to
> a repository).
> 
>>  3. How does one actually perform step 3, another pull request or simply
>> an e-mail to someone?
> The opening of the pull request would mark the beginning of the
> discussion period. When the author feels that the discussion has come to
> something of a conclusion, they will request that the GHC Committee
> consider the proposal for acceptable by leaving a comment on the pull
> request.
> 
>> Typo: two separate bullets in the proposal are labelled as 4.
> I believe this should be fixed now. Thanks!
> 
> Cheers,
> 
> - Ben
> 
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 20/07/16 19:04, Ben Gamari wrote:
> I know, it's rather frustrating. I also have fairly strong feelings
>  about open-source purity, but in this case I just don't see any
> way to improve the current situation under this constraint.
I don't think that starting to rely on proprietary software *is* an
improvement, but the opposite.

> It does look like Gitlab is an impressive option but really then
> we are back to the problem of fragmented development tools. Using
> Trac, Phabricator, Gitlab, and mailing lists all in one project
> seems a bit silly.
I don't understand why using GitLab is more silly than using GitHub,
when considering fragmentation.
- -- 
Alexander
alexan...@plaimi.net
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXj6/uAAoJENQqWdRUGk8Bk4UP/RsWT2YjFTxFR0mPxx0gQgFd
jq9lp8DlJsZJ33I7OF4kuFLxjbMoybRDRbr9rDSWXVhor25mxogXa+5VU6/PXj5I
IKsh495k8BZDDajlUuPPvC0jymHtJI2urVWls9Da/uVOu/xeuutK+fvuosLsuPAh
0AaoncvDV9LaGDYxOEGIQa5ucEiDwE5k+PbPyxH9lCWXH8ULKGG+tPIh+0/wCCbx
pxoQhire9LLWUXtkMQ654mgurQ76BD97b4Hab42ommtwNwFnxS4Oqw/Q7n2dzmdc
WSiHu6S8twcWgqiJNr+OVcNuXcRHmFHYnS0VvI9tTYvvE5cZAenjJrXE1ncyoZkh
yTPulCx18GxNafzEsGxw7LYSmMIb2/QKWEkRDh7kkP+fOFvXPTl7QhUjz5RGJ90s
RgbDD9M17fRJ96yGwogFSzSVZP1KTiYCOMnqk8KjDQgwXOqQFCDKUS1dawpeARCi
M6zJsVkuVjJCsb/lKzlq71w1yJuOMS6gO92SajqRFfJ+j8q+GTP6/DnY+vUDvoxq
klNAhqQGJKLgvy47fS6MN9hv8K4yj4NmDY8vSruOOJ1RBlruNiUoEXFKSfRZVwpk
FjEZYar7/rdOIVsI5W7Tt4Qip3LGnpqzdHH3lehxWaDtWgwrV0hnMToVapOsm0Rs
n2OTI95HXi21nm7jYV+X
=I8EH
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 20/07/16 19:00, Richard Eisenberg wrote:
> While I indeed sympathize with your desire to avoid proprietary, 
> closed software, I'd like to point out that avoiding GitHub
> because it's closed has a real cost
I don't value those points over my freedom. But those who don't value
their freedom might value them, so thanks for listing them.

> Also, what proprietary programs are needed to fully utilize GitHub?
> I just use git and ssh, both pieces of free software.
For proposals, we'll be doing lots of discussions and review. Those
parts of GitHub rely heavily on proprietary client-side JavaScript.
- -- 
Alexander
alexan...@plaimi.net
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXj69RAAoJENQqWdRUGk8Bnv8P+wc2CV4CEifkebXniGte7oOm
yJ3fB/wOhm5sgGVOOAVNiv3VfvQb8t3qsouFkYyaVJXfLMGhK1PehC3Y38mI28HU
NA1FK9CVyBU3YHQmyyqegJGyjj+DEVrN/rmydgU3xCPCRflB/gvMdv0PMUhlIj8v
2tTjXguElLxAncnsU4YIVWcmvN+Wssikv8H/FWksJTsuZdFXkC1VzLbGJHGc0plt
s8v6OWWFxXqv3ujFy1e4yTv+VoBeKEbEVPhsxGvU7q4IkrVGLUOEnR0LPV3+H+Um
1XWez8VIBMIobnDE/0ZR++6AXc08iOhTR1Cgd+6YW0SGDP54HqG/Oj1Hop7kdAy6
7j62Csr8DAjUOfJyWng+vmIOd66g/Cu3OxQlmtiznjnStDQKmPpLTe3srYWC2w0T
iIR8sKqmFb4QnohDH6bG4JPCtwVIM2RXg8xzcfbHMihqa1DZqS8DCrtx80Ga5UHP
Ln0/j6ig5erQFJU7XM5CvnUDIMu0wQp8bP4VbTqRM4dvFVoBxOk8D9vZFh2LlSNM
/sYkD0oRHeFFoXRiL5XuTLufntA/BR+n/fFGoHL2ZtLEWk+Phe70PvLT/vqXJtZk
AtwlNXCr1uD/4rhCxdNAoVuV8o+8F+Iq0l4kFGqtH8hZdRN9+HpISWO3HgaeyIVD
tJbo1M5Eo3+Ky7o25uiQ
=cPxT
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Ben Gamari]

Alexander Berntsen  writes:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 20/07/16 11:36, Ben Gamari wrote:
>> * What would you like to see changed in the proposed process, if 
>> anything?
> No GitHub. In order to fully utilise GitHub, one needs to run
> proprietary programs. Additionally, GitHub is proprietary software
> server-side.
>
I know, it's rather frustrating. I also have fairly strong feelings
about open-source purity, but in this case I just don't see any way to
improve the current situation under this constraint.

I agree that Phabricator is the logical choice for self-hosting in our
situation, but sadly it just doesn't have the features at the moment to
make the process convenient and accessible (which is the motivation for
the change in the first place).


> While I don't feel too strongly about which of the proposed
> alternatives are chosen, since they are both free software, augmenting
> Phabricator would probably be the best choice, since this avoids
> adding another piece of infrastructure to use and administer.

The Phabricator developers already do a fair amount for us without
charging for their time. We can ask them to add the features that we
need but this will take time, if it happens at all, unless we put money
on the table. Unless someone is willing to put money down I'm not sure
Phabricator will be an option in the foreseeable future.

It does look like Gitlab is an impressive option but really then we are
back to the problem of fragmented development tools. Using Trac,
Phabricator, Gitlab, and mailing lists all in one project seems a bit
silly.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Richard Eisenberg]

> On Jul 20, 2016, at 12:47 PM, Alexander Berntsen  wrote:
> 
> On 20/07/16 11:36, Ben Gamari wrote:
>> * What would you like to see changed in the proposed process, if 
>> anything?
> No GitHub. In order to fully utilise GitHub, one needs to run
> proprietary programs. Additionally, GitHub is proprietary software
> server-side.

While I indeed sympathize with your desire to avoid proprietary, closed 
software, I'd like to point out that avoiding GitHub because it's closed has a 
real cost:
 * It requires more work (a very limited resource) to maintain our own instance 
of whatever alternate solution we come up with.
 * GitHub is very current in our community. Moving away from GitHub may 
increase barriers to contributions.

Of course, our use of GitHub would appear to increase barriers to those who 
avoid closed software. This fact means that we need to balance the desires of 
some potential contributors (who prefer to avoid closed software) with other 
potential contributors (who prefer to use GitHub).

To be clear, I'm not trying to shoot down Alexander's point -- just trying to 
point out that there are shades of gray here.

Also, what proprietary programs are needed to fully utilize GitHub? I just use 
git and ssh, both pieces of free software.

Richard
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 20/07/16 11:36, Ben Gamari wrote:
> * What would you like to see changed in the proposed process, if 
> anything?
No GitHub. In order to fully utilise GitHub, one needs to run
proprietary programs. Additionally, GitHub is proprietary software
server-side.

While I don't feel too strongly about which of the proposed
alternatives are chosen, since they are both free software, augmenting
Phabricator would probably be the best choice, since this avoids
adding another piece of infrastructure to use and administer.
- -- 
Alexander
alexan...@plaimi.net
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXj6s4AAoJENQqWdRUGk8BI9oP/RCV14jmpHpbJ1Cr42Nr+yam
cXrjSmKGfHNDGbBRqfORBTaAGkRbXvVJAWYiaUXddl1FUmB40JWg+sDQ/a2PVp28
10QB361+FzqSir+7wkJd27GH3mki1Hmsm/wKHISDal2P40QWSRVKZh8xr1vvWzje
MVL42AvBV/P9nF40bEI+axO11A7/PnkHCzQqspK/DdtwRWLZ5ny3XYI1owH/zy9m
Roo2+Zw0jIxKL18l6edLoPEiunsj7B9iHwf+TglODgyBbIdqAndxuQuJinOYEz+q
FooDD3Qv+qhrRAUnTXXQ+pXO7hYqXTLqeEQKekhaj8zgo2OqzY96RM7Q2OQ0xuaR
mYDe99Bg9SC5fqYZX4yVSr8anw+dGqT2FDeqWg3OBg0wDH+QZ7mhlqXbdXENaFcx
0TtIEYTf7QGZioE3B21DcfQSoXoWOPvEWE7qityPLBIln/FcA/B0obtBVNooErdA
c2WM7BdNnE6+nBuxMC39FhX1Tr61Ao3BtGKJJyeANcLxefrGu+6T1udM7IsKfPAC
obZllRLNrTTR9xyD/8ebVpI8wstxcjmaGCFN8kA74byMwoX/fMN/Ol7N47Ee3BWE
l4OqPSxAACZrwkRLoovX/PhulOxX5E/go4aio9fDZT8i5HKxocb66GmixBxALejA
Vjegvti1Nfj6cAAWmNT1
=apBk
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Ben Gamari]

Iavor Diatchki  writes:

> Hello Ben,
>
> I posted this when you originally asked for feed-back, but perhaps it
> got buried among the rest of the e-mails.
>
Indeed it seems that way. Sorry about that!

> I think the proposal sounds fairly reasonable, but it is hard to say how
> well it will work in practice until we try it, and we should be ready to
> change it if needs be.
>
Right. I fully expect that we will have to iterate on it.

> Some clarifying questions on the intended process:
>1.  After submitting the initial merge request, is the person making the
> proposal to wait for any kind of acknowledgment, or just move on to step 2?
>
The discussion phase can happen asynchronously from any action by the
Committee. Of course, the Committee should engauge in discussion early,
but I don't think any sort of acknowledgement is needed. An open pull
request should be taken to mean "let's discuss this idea."

>2. Is the discussion going to happen on one of the mailing lists, if so
> which?   Is it the job of the proposing person to involve/notify the
> committee about the discussion?  If so, how are they to find out who is on
> the committee?

The proposed process places the discussion in a pull request. The idea
here is to use well-understood and widely-used code review tools to
faciliate the conversation.

The Committee members will be notified of the open pull request by the
usual event notification mechanism (e.g. in GitHub one can subscribe to
a repository).

>3. How does one actually perform step 3, another pull request or simply
> an e-mail to someone?
>
The opening of the pull request would mark the beginning of the
discussion period. When the author feels that the discussion has come to
something of a conclusion, they will request that the GHC Committee
consider the proposal for acceptable by leaving a comment on the pull
request.

> Typo: two separate bullets in the proposal are labelled as 4.
>
I believe this should be fixed now. Thanks!

Cheers,

- Ben



signature.asc
Description: PGP signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Ben Gamari]

Yuras Shumovich  writes:

> Looks like reddit is a wrong place, so I'm replicating my comment here:
>
Thanks for your comments Yuras!

>>   * Do you feel the proposed process is an improvement over the
>> status quo?
>
> Yes, definitely. The existing process is too vague, so formalizing it
> is a win in any case.
>
Good to hear.

>>   * What would you like to see changed in the proposed process, if
>> anything?
>
> The proposed process overlaps with the Language Committee powers. In
> theory the Committee works on language standard, but de facto Haskell
> is GHC/Haskell and GHC/Haskell is Haskell. Adding new extension to GHC
> adds new extension to Haskell. So I'd like the process to enforce
> separation between experimental extensions (not recommended in
> production code) and language improvements. I'd like the process to
> specify how the GHC Committee is going to communicate and share powers
> with the Language Committee.
>
To clarify I think Language Committee here refers to the Haskell Prime
committee, right?

I think these two bodies really do serve different purposes.
Historically the Haskell Prime committee has been quite conservative in
the sorts of changes that they standardized; as far as I know almost all
of them come from a compiler. I would imagine that the GHC Committee
would be a gate-keeper for proposals entering GHC and only some time
later, when the semantics and utility of the extension are
well-understood, would the Haskell Prime committee consider introducing
it to the Report. As far as I understand it, this is historically how
things have worked in the past, and I don't think this new process would
change that.

Of course, let me know if I'm off-base here.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Iavor Diatchki]

Hello Ben,

I posted this when you originally asked for feed-back, but perhaps it
got buried among the rest of the e-mails.

I think the proposal sounds fairly reasonable, but it is hard to say how
well it will work in practice until we try it, and we should be ready to
change it if needs be.

Some clarifying questions on the intended process:
   1.  After submitting the initial merge request, is the person making the
proposal to wait for any kind of acknowledgment, or just move on to step 2?
   2. Is the discussion going to happen on one of the mailing lists, if so
which?   Is it the job of the proposing person to involve/notify the
committee about the discussion?  If so, how are they to find out who is on
the committee?
   3. How does one actually perform step 3, another pull request or simply
an e-mail to someone?

Typo: two separate bullets in the proposal are labelled as 4.

Cheers,
-Iavor

On Wed, Jul 20, 2016 at 2:36 AM, Ben Gamari  wrote:

>
> Hello everyone,
>
> As you hopefully know, a few weeks ago we proposed a new process [1] for
> collecting, discussing, and deciding upon changes to GHC and its Haskell
> superset. While we have been happy to see a small contingent of
> contributors join the discussion, the number is significantly smaller
> than the set who took part in the earlier Reddit discussions.
>
> In light of this, we are left a bit uncertain of how to proceed. So,
> we would like to ask you to let us know your feelings regarding the
> proposed process:
>
>   * Do you feel the proposed process is an improvement over the status
> quo?
>
>   * Why? (this needn't be long, just a sentence hitting the major points)
>
>   * What would you like to see changed in the proposed process, if
> anything?
>
> That's all. Again, feel free to reply either on the GitHub pull request
> [1] or this thread if you would prefer. Your response needn't be long;
> we just want to get a sense of how much of the community feels that 1)
> this effort is worth undertaking, and 2) that the proposal before us is
> in fact an improvement over the current state of affairs.
>
> Thanks for your help!
>
> Cheers,
>
> - Ben
>
>
> [1] https://github.com/ghc-proposals/ghc-proposals/pull/1
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Yuras Shumovich]

Looks like reddit is a wrong place, so I'm replicating my comment here:

On Wed, 2016-07-20 at 11:36 +0200, Ben Gamari wrote:
> Hello everyone,
> 
> As you hopefully know, a few weeks ago we proposed a new process [1]
> for
> collecting, discussing, and deciding upon changes to GHC and its
> Haskell
> superset. While we have been happy to see a small contingent of
> contributors join the discussion, the number is significantly smaller
> than the set who took part in the earlier Reddit discussions.
> 
> In light of this, we are left a bit uncertain of how to proceed. So,
> we would like to ask you to let us know your feelings regarding the
> proposed process:
> 
>   * Do you feel the proposed process is an improvement over the
> status
> quo?

Yes, definitely. The existing process is too vague, so formalizing it
is a win in any case.


> 
>   * Why? (this needn't be long, just a sentence hitting the major
> points)
> 
>   * What would you like to see changed in the proposed process, if
> anything?


The proposed process overlaps with the Language Committee powers. In
theory the Committee works on language standard, but de facto Haskell
is GHC/Haskell and GHC/Haskell is Haskell. Adding new extension to GHC
adds new extension to Haskell. So I'd like the process to enforce
separation between experimental extensions (not recommended in
production code) and language improvements. I'd like the process to
specify how the GHC Committee is going to communicate and share powers
with the Language Committee.

Thanks,
Yuras.

> 
> That's all. Again, feel free to reply either on the GitHub pull
> request
> [1] or this thread if you would prefer. Your response needn't be
> long;
> we just want to get a sense of how much of the community feels that
> 1)
> this effort is worth undertaking, and 2) that the proposal before us
> is
> in fact an improvement over the current state of affairs.
> 
> Thanks for your help!
> 
> Cheers,
> 
> - Ben
> 
> 
> [1] https://github.com/ghc-proposals/ghc-proposals/pull/1
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-user
> s
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Thomas Miedema]

>
>   * What would you like to see changed in the proposed process, if
> anything?
>

*Simon Peyton Jones as Benevolent Dictator For Life (BDFL)*

If the BDFL had made a simple YES/NO decision on ShortImports [1] and
ArgumentDo [2], we wouldn't be here talking about process proposals,
Anthony wouldn't be mad, everything would be fine. We don't need another
Haskell committee.

* Keep using Trac for proposals, but use the description field of a ticket
for the specification, instead of separate wiki page.

* Add better filtering possibilities to Trac (say someone wants to only
subscribe to tickets where syntax extensions are discussed). Adding better
filtering possibilities will also benefit bug fixers (say someone wants to
only subscribe to bugs on Windows or with keyword=PatternSynonyms).

* Don't let hotly debated feature requests go without a resolution.

[0] https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
[1] https://ghc.haskell.org/trac/ghc/ticket/10478
[2] https://ghc.haskell.org/trac/ghc/ticket/10843
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Proposal process status

[Ben Gamari]

Hello everyone,

As you hopefully know, a few weeks ago we proposed a new process [1] for
collecting, discussing, and deciding upon changes to GHC and its Haskell
superset. While we have been happy to see a small contingent of
contributors join the discussion, the number is significantly smaller
than the set who took part in the earlier Reddit discussions.

In light of this, we are left a bit uncertain of how to proceed. So,
we would like to ask you to let us know your feelings regarding the
proposed process:

  * Do you feel the proposed process is an improvement over the status
quo?

  * Why? (this needn't be long, just a sentence hitting the major points)

  * What would you like to see changed in the proposed process, if
anything?

That's all. Again, feel free to reply either on the GitHub pull request
[1] or this thread if you would prefer. Your response needn't be long;
we just want to get a sense of how much of the community feels that 1)
this effort is worth undertaking, and 2) that the proposal before us is
in fact an improvement over the current state of affairs.

Thanks for your help!

Cheers,

- Ben


[1] https://github.com/ghc-proposals/ghc-proposals/pull/1


signature.asc
Description: PGP signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users