From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id ABBBB7EC6E for ; Mon, 13 Jan 2014 17:43:03 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.216.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.216.47 as permitted sender) identity=mailfrom; client-ip=209.85.216.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qa0-f47.google.com) identity=helo; client-ip=209.85.216.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-qa0-f47.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYEACkX1FLRVdgvlWdsb2JhbABag0NWp1KJSIhVgQwIFg4BAQEBBw0JCRIqgiUBAQEEQAEbEgsBAwwGBQsNDSEhAQERAQUBChIGExKHXQEDEQ2dcIxcgwmRKwoZJwMKZIQVEQEFDIxogSgJCgYCAUsEB4Q3BIlDjGiBbIEwiyqDThgphHcegSw X-IPAS-Result: AmYEACkX1FLRVdgvlWdsb2JhbABag0NWp1KJSIhVgQwIFg4BAQEBBw0JCRIqgiUBAQEEQAEbEgsBAwwGBQsNDSEhAQERAQUBChIGExKHXQEDEQ2dcIxcgwmRKwoZJwMKZIQVEQEFDIxogSgJCgYCAUsEB4Q3BIlDjGiBbIEwiyqDThgphHcegSw X-IronPort-AV: E=Sophos;i="4.95,653,1384297200"; d="scan'208";a="44635020" Received: from mail-qa0-f47.google.com ([209.85.216.47]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 13 Jan 2014 17:43:01 +0100 Received: by mail-qa0-f47.google.com with SMTP id j5so2353802qaq.6 for ; Mon, 13 Jan 2014 08:43:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4uFyO0xlHSjkWtLkQYcBmL/vqYjKAAAXvDia783OSPY=; b=0UQkrAc7pX3z/FZYT+j5slEMmgfiwnzwqJDP/4xLnPiKBq7lTAQUjKKTxIBW3m4yaP aAOpVp4va5B/FRr2NUQa7RM8e7UPHv2m7R/gJFovzyD+j06VvoP8d6Q5K9I5Efggi/NJ a5yXuT8hW8/0kEwdizdIb1sp9LHJS+AOAarcFjMZBftpveGW1G/AOeeA6I0z/Mfxeexh w3FW/WbXd+NUcMXGUOoAdAtAkQTqVmdVfYIMTHdA+QCw6WpoPmI+9m4WO8UGF6hC6y1O KMoOEZ5dT5XUCf3v6BY6wZjRHizKIgESoYJgQvS4HXu6jA8FPSNF64weuW0ckjdZ6krS NUMQ== X-Received: by 10.229.14.1 with SMTP id e1mr28582743qca.15.1389631380637; Mon, 13 Jan 2014 08:43:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.95.8 with HTTP; Mon, 13 Jan 2014 08:42:40 -0800 (PST) In-Reply-To: References: <20140111152357.GB28133@notk.org> <20140111154146.GA976@lenat> <20140113090444.GA8904@notk.org> <52D3B71B.40802@cea.fr> From: Yotam Barnoy Date: Mon, 13 Jan 2014 11:42:40 -0500 Message-ID: To: Gabriel Scherer Cc: =?ISO-8859-1?Q?Fran=E7ois_Bobot?= , caml users Content-Type: multipart/alternative; boundary=001a113386e8cfde6d04efdcc4ed Subject: Re: [Caml-list] Doing compiler patch review with a dedicated mailing-list --001a113386e8cfde6d04efdcc4ed Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jan 13, 2014 at 5:27 AM, Gabriel Scherer wrote: > (about Github, a Wise One > remarked that "yesterday the same people were commanding that we host > OCaml on Sourceforge; look where it is now!"). > I'm just going to focus on this comment: I don't see anything wrong with this. Companies find good developers by using recruiters and headhunters. Open source projects do so by, among other things, going to the most popular places for developers to hang out. Back when sourceforge was popular, it was a great place for people looking to get involved in open source projects (like myself). The proper view on this in my opinion is, how many great devs were *not* introduced to ocaml and did *not* join ocaml development because ocaml wasn't where the people were? Is it worth the little bit of hassle to get long-time devs to switch their methodologies for the benefit of getting more developers into the project/language? In my humble opinion, the answer is absolutely yes. Regardless, sourceforge's other advantages in its best days were minimal for an organization that can host its own repository and issue tracker. Github has a much bigger advantage in that it comes with a whole ecosystem of tools that make development that much easier. Github is also a much bigger player at a time when open source software is a much bigger player in the world: for example, employees are looking to add open source projects to their resumes, and they're looking mostly on github (Btw I realize that ocaml has a mirror on github, but consider that a read-only mirror is not a lively, encouraging environment with which to interact). My main problem with Mantis is that one misses out on the ability to see patches automatically applied to code, and to comment on specific parts of patches. These things are huge productivity boosts and make it much easier for many people to participate and comment on patches. Also, being able to fork and then just post a pull request means that I don't have to mess with managing patch files at all. There's a good reason the world is moving in this direction. I understand the trepidation to have all this extra value trapped within github, but I have a strong hunch that if github starts losing to another, better competitor, bigger projects will move out first, and tools will be developed using the github api to extract and duplicate the metadata. In fact, a quick search turned up several of these kinds of things already, just because they're easy to build, e.g. https://github.com/joeyh/github-backup It's also useful to see how other languages do things. Mono, Scala and Clojure are all on github. Of the three, Mono and Clojure don't use the 'issues' feature of github, but all three use pull requests (and the rich features they enable). Clojure uses Jira (which looks extremely powerful and is free to open source projects) to manage its issues and planning. Mono uses bugzilla for managing issues, but also allows/uses pull requests. Regarding the mailing list, my experience from another open source project suggests that mailing lists are better for discussion of bigger features, or for pointing out specific patches for review, rather than spreading out the discussion in multiple places, but I could definitely be wrong about this. -Yotam On Mon, Jan 13, 2014 at 10:51 AM, Fran=E7ois Bobot > wrote: > > On 13/01/2014 10:04, Adrien Nader wrote: > >> > >> On Sat, Jan 11, 2014, Simon Cruanes wrote: > >>> > >>> Le Sat, 11 Jan 2014, Adrien Nader a =E9crit : > >>>> > >>>> Hi, > >>>> > >>>> (and sorry for the mail sent a few minutes ago :) ) > >>>> > >>>> I'd like to know what people think about having a mailing-list for > >>>> reviews and tests of patches to the compiler and tools around it. > >>>> > >>>> The idea is to do something similar to the kernel mailing-list. I > mostly > >>>> like mantis and it is possible to attach files but it becomes fairly > >>>> unreadable after a while. The audience is also mostly limited to > people > >>>> who are subscribed to the bug report. I hope this reduces the work a= nd > >>>> burden of reviewers and especially commiters. > >>>> > >>>> The goal is not to replace patches on mantis and you shouldn't belie= ve > >>>> this has been blessed by the core development team (nor mentionned to > >>>> them actually). Instead, I hope this helps do quicker (and smaller?) > >>>> iteration of patches. > >>>> > > > > I don't know how you generate and _manage_ patches with svn. Indeed the > > linux kernel developers never used svn with their mailing-list review > > workflow and developed git for simplifying this workflow. > > > > It seems counterproductive to have more than one place for discussing o= ne > > thing so I think the developers must make a choice: > > - keeping patch review in mantis > > - going to a mailing-list review workflow and moving from svn > > - going to a merge-request workflow on github, specific gitlab instance, > > bitbuckets, ... > > > > The last two points have the benefit to allow to easily comment inside > the > > patches. > > > > The third point (at least on github) subsume the second point since you > can > > answer to github issues or merge-requests by email. You can also ask to > be > > notified for every issues or merge-requests of a project. > > > > Best, > > > > -- > > Fran=E7ois > > > > > > -- > > Caml-list mailing list. Subscription management and archives: > > https://sympa.inria.fr/sympa/arc/caml-list > > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > > Bug reports: http://caml.inria.fr/bin/caml-bugs > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > --001a113386e8cfde6d04efdcc4ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 13, 2014 at 5:27 AM, Gabriel Scherer <gabriel.scherer@gma= il.com> wrote:
(about Github, a Wise One=
remarked that "yesterday the same people were commanding that we host<= br> OCaml on Sourceforge; look where it is now!").
<= br>
I'm just going to focus on this comment: I don't see = anything wrong with this. Companies find good developers by using recruiter= s and headhunters. Open source projects do so by, among other things, going= to the most popular places for developers to hang out. Back when sourcefor= ge was popular, it was a great place for people looking to get involved in = open source projects (like myself). The proper view on this in my opinion i= s, how many great devs were *not* introduced to ocaml and did *not* join oc= aml development because ocaml wasn't where the people were? Is it worth= the little bit of hassle to get long-time devs to switch their methodologi= es for the benefit of getting more developers into the project/language? In= my humble opinion, the answer is absolutely yes.

Regardless, sourceforge's other advantages in its best d= ays were minimal for an organization that can host its own repository and i= ssue tracker. Github has a much bigger advantage in that it comes with a wh= ole ecosystem of tools that make development that much easier. Github is al= so a much bigger player at a time when open source software is a much bigge= r player in the world: for example, employees are looking to add open sourc= e projects to their resumes, and they're looking mostly on github (Btw = I realize that ocaml has a mirror on github, but consider that a read-only = mirror is not a lively, encouraging environment with which to interact).

My main problem with Mantis is that one misses out on the ability= to see patches automatically applied to code, and to comment on specific p= arts of patches. These things are huge productivity boosts and make it much= easier for many people to participate and comment on patches. Also, being = able to fork and then just post a pull request means that I don't have = to mess with managing patch files at all. There's a good reason the wor= ld is moving in this direction.

I understand the trepidation to have all this extra value trapped withi= n github, but I have a strong hunch that if github starts losing to another= , better competitor, bigger projects will move out first, and tools will be= developed using the github api to extract and duplicate the metadata. In f= act, a quick search turned up several of these kinds of things already, jus= t because they're easy to build, e.g. https://github.com/joeyh/github-backup

It's also useful to see how other languages do thin= gs. Mono, Scala and Clojure are all on github. Of the three, Mono and Cloju= re don't use the 'issues' feature of github, but all three use = pull requests (and the rich features they enable). Clojure uses Jira (which= looks extremely powerful and is free to open source projects) to manage it= s issues and planning.=A0 Mono uses bugzilla for managing issues, but also = allows/uses pull requests.

Regarding the mailing list, my experience from another = open source=20 project suggests that mailing lists are better for discussion of bigger=20 features, or for pointing out specific patches for review, rather than=20 spreading out the discussion in multiple places, but I could definitely be = wrong=20 about this.

-Yotam


On Mon, Jan 13, 2014 at 10:51 AM, Fran=E7ois Bobot <francois.bobot@cea.fr> wrote:
> On 13/01/2014 10:04, Adrien Nader wrote:
>>
>> On Sat, Jan 11, 2014, Simon Cruanes wrote:
>>>
>>> Le Sat, 11 Jan 2014, Adrien Nader a =E9crit :
>>>>
>>>> Hi,
>>>>
>>>> (and sorry for the mail sent a few minutes ago :) )
>>>>
>>>> I'd like to know what people think about having a mail= ing-list for
>>>> reviews and tests of patches to the compiler and tools aro= und it.
>>>>
>>>> The idea is to do something similar to the kernel mailing-= list. I mostly
>>>> like mantis and it is possible to attach files but it beco= mes fairly
>>>> unreadable after a while. The audience is also mostly limi= ted to people
>>>> who are subscribed to the bug report. I hope this reduces = the work and
>>>> burden of reviewers and especially commiters.
>>>>
>>>> The goal is not to replace patches on mantis and you shoul= dn't believe
>>>> this has been blessed by the core development team (nor me= ntionned to
>>>> them actually). Instead, I hope this helps do quicker (and= smaller?)
>>>> iteration of patches.
>>>>
>
> I don't know how you generate and _manage_ patches with svn. Indee= d the
> linux kernel developers never used svn with their mailing-list review<= br> > workflow and developed git for simplifying this workflow.
>
> It seems counterproductive to have more than one place for discussing = one
> thing so I think the developers must make a choice:
> - keeping patch review in mantis
> - going to a mailing-list review workflow and moving from svn
> - going to a merge-request workflow on github, specific gitlab instanc= e,
> bitbuckets, ...
>
> The last two points have the benefit to allow to easily comment inside= the
> patches.
>
> The third point (at least on github) subsume the second point since yo= u can
> answer to github issues or merge-requests by email. You can also ask t= o be
> notified for every issues or merge-requests of a project.
>
> Best,
>
> --
> Fran=E7ois
>
>
> --
> Caml-list mailing list. =A0Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

--
Caml-list mailing list. =A0Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
--001a113386e8cfde6d04efdcc4ed--