caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gabriel Scherer <gabriel.scherer@gmail.com>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] About contributions to the Standard Library
Date: Thu, 30 Jun 2016 11:52:11 -0400	[thread overview]
Message-ID: <CAPFanBHbrh+ASWJz0w4Eb7uXjui5r8BQGwdpMp0v9mzdOC-VCQ@mail.gmail.com> (raw)
In-Reply-To: <20160630110806.GB16808@frosties>

[-- Attachment #1: Type: text/plain, Size: 3990 bytes --]

On Thu, Jun 30, 2016 at 7:08 AM, Goswin von Brederlow <goswin-v-b@web.de>
wrote:

> But then you should ask for more workers, not for more work.
>

Very true, and we do!

We've always repeatedly claimed that reviewing proposed patches/changes
would be a big help. Some external contributors frequently do it and it is
very useful. (It is particularly useful when they're ready to go to the
level of a code review, but feedback on the design is already useful.)

For a concrete example, the email I sent to announce that we would accept
pull-requests on Github, in addition to patches on Mantis (
https://sympa.inria.fr/sympa/arc/caml-list/2014-01/msg00254.html ), starts
as follows:

I think we need more people ready to review patches proposed for
> inclusion in the OCaml compiler/distribution; lack of reviews is
> currently one of the bottleneck in the development process -- among
> others, such as the sheer difficulty to reach consensus on any change
> to the language itself. Doing patch reviews is helpful, extremely
> interesting, and an excellent way to get to know more about small
> parts of the compiler.
>

To repeat again: any help reviewing proposed patches, on *both* Mantis and
Github, is warmly welcome. It's an excellent way to get to know diverse
parts of the compiler distribution codebase, it's informative, low-risk,
interesting, very helpful. Do it!

That should, of course, not prevent us from un-blocking a situation with
the compiler stdlib, where people interested in also improving its state
(such as you) were prevented from contributing by lack of clear upstream
guidance on the range of accepted changes and the decision process. We want
more reviews *and* more good stuff, and we should have both.

On Thu, Jun 30, 2016 at 7:08 AM, Goswin von Brederlow <goswin-v-b@web.de>
wrote:

> On Mon, Jun 27, 2016 at 09:21:11AM -0400, Gabriel Scherer wrote:
> > Well there are more tickets on the bugtracker (and github PRs) than human
> > time to review and make decisions on all of them. I'm very sorry if some
> > contributions are left to bitrot. Anyone can help by reviewing and giving
> > informed opinions on suggestions, and it's most helpful if contributors
> are
> > ready to ping from time to time to ask for an opinion on their
> contribution.
> >
> > On Mon, Jun 27, 2016 at 7:19 AM, Gerd Stolpmann <info@gerd-stolpmann.de>
> > wrote:
> >
> > > Am Montag, den 27.06.2016, 11:09 +0200 schrieb Goswin von Brederlow:
> > > > Why should we contribute when contibutions are just left to bitrot?
> > > >
> > > > Like: http://caml.inria.fr/mantis/view.php?id=4909 which has had a
> > > > patch for 6 1/2 year that's just left rotting.
> > >
> > > I guess you hit one of the pain points of the current library design,
> > > namely the various integer types (and the issue of combinatorial
> > > increase of possible variants). In my most recent code (a data science
> > > lib) I solved that radically - no support for 32 bit architectures
> > > anymore. The truth is that with current OCaml you cannot support both
> 32
> > > bit and 64 bit equally well. Either you get a performance loss from
> > > boxed ints, or you get macros in central places of your code.
> > >
> > > Of course, that's no excuse for not responding at all.
> > >
> > > Gerd
>
> But then you should ask for more workers, not for more work.
>
> If you already can't keep up with the existing rate of contributions
> then more contributions will only mean more are left to bitrot. Worse,
> it means less contribution do get added because you spend more time
> just checking new contributions and deciding to not handle them right
> now.
>
> But anyway, consider this a ping for my patch. Hopefully it will be
> looked at again now.
>
> MfG
>         Goswin
>
> --
> 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
>

[-- Attachment #2: Type: text/html, Size: 5744 bytes --]

  reply	other threads:[~2016-06-30 15:52 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-21 11:56 Damien Doligez
2016-06-21 15:48 ` Gabriel Scherer
2016-06-21 15:54   ` [Caml-list] About "precise (formal) things that can be said about properties of certain interfaces" David MENTRE
2016-06-21 19:11     ` Gabriel Scherer
2016-06-21 20:06       ` Jesper Louis Andersen
2016-06-22 15:33   ` [Caml-list] About contributions to the Standard Library Junsong Li
2016-06-22 21:31   ` Alain Frisch
2016-07-07 10:26   ` Daniel Bünzli
2016-07-08 14:01     ` Alain Frisch
2016-07-08 14:37       ` Daniel Bünzli
2016-07-11  8:55         ` Goswin von Brederlow
2016-07-11  9:43           ` Daniel Bünzli
2016-07-11  9:48             ` Adrien Nader
2016-07-11 10:28               ` Daniel Bünzli
2016-07-11 18:34                 ` Adrien Nader
2016-07-11 20:36                   ` Daniel Bünzli
2016-07-11  9:49             ` Goswin von Brederlow
2016-07-12 18:32           ` Ian Zimmerman
2016-07-12 19:01             ` Gabriel Scherer
2016-07-12 21:26               ` Ian Zimmerman
2016-07-12 22:35                 ` Gabriel Scherer
2016-07-12 23:20                   ` Ian Zimmerman
2016-06-27  9:09 ` Goswin von Brederlow
2016-06-27 11:19   ` Gerd Stolpmann
2016-06-27 13:21     ` Gabriel Scherer
2016-06-30 11:08       ` Goswin von Brederlow
2016-06-30 15:52         ` Gabriel Scherer [this message]
2016-06-30 10:59     ` Goswin von Brederlow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPFanBHbrh+ASWJz0w4Eb7uXjui5r8BQGwdpMp0v9mzdOC-VCQ@mail.gmail.com \
    --to=gabriel.scherer@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=goswin-v-b@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).