On Mon, Jan 13, 2014 at 5:27 AM, Gabriel Scherer <gabriel.scherer@gmail.com> 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çois 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 écrit :
>>>>
>>>> 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 and
>>>> burden of reviewers and especially commiters.
>>>>
>>>> The goal is not to replace patches on mantis and you shouldn't believe
>>>> 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 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 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çois
>
>
> --
> 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