Since I'll be out next week, I think that would be a good time to do a beta. So, let's aim towards getting a beta release ready by Saturday.

-Walter
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

There's an analogy that we like to use at work, and in my experience it holds pretty well for code quality and bleeds pretty well into the entire development process:

  http://en.wikipedia.org/wiki/Broken_windows_theory

We do an ok job when it comes to the tests (though certainly not perfect).  We've been getting a lot better at addressing regressions, though there's still 4 open right now (1 phobos, 2 druntime, 1 dmd).  Can we please make the remaining open regressions a release blocker?

Also, I'd really love to see the pull lists knocked down considerably before the next beta, particularly the phobos set (considering the larger set of people with access to it).  The d-p-l and tools sets should be even easier to keep at 0, but even those have some accumulated requests, the oldest of which is over a year now.

Several of the open requests (across all the repos) are open because there's some controversy about them.  I'll pick the 'dur' ones as a good, but hardly only, example.  Either those should be pulled or closed.  Leaving in limbo helps no one.  For this sort of request, a choice needs to be made and move on.  A key part of the problem with this set is that we don't have a process for deciding what to do with them.  Anyone care to put forth a proposal?

Another example is the const(Object)ref code change.  There's little value in the pull request being open for a year. Closing the pull request does NOT do anything irrevocable as the branch remains available (assuming the author doesn't delete it).  Keeping it open doesn't help with anything other than maybe loosing track of it, but that's better done through bugzilla, imho.  Closing it wouldn't be a rejection, but a long term deferral.

What's stopping us from handling all pull requests w/in a week?  Or even better a day or two?

My 2 cents,
Brad

On 5/28/2012 1:41 AM, Walter Bright wrote:
> Since I'll be out next week, I think that would be a good time to do a beta. So, let's aim towards getting a beta release ready by Saturday.
> 
> -Walter
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Hi,

> What's stopping us from handling all pull requests w/in a week?  Or even better a day or two?

I see two main causes:

1) Too few people in the community actually care enough to review pull requests. 2) Too few people have the necessary rights to actually merge pull requests.

I'm not sure how to rectify the former. The latter has an obvious solution.

See also the discussion on: https://github.com/D-Programming-Language/druntime/pull/204

Regards,
Alex

On Mon, May 28, 2012 at 10:07 PM, Brad Roberts <braddr@puremagic.com> wrote:
> There's an analogy that we like to use at work, and in my experience it holds pretty well for code quality and bleeds pretty well into the entire development process:
>
>  http://en.wikipedia.org/wiki/Broken_windows_theory
>
> We do an ok job when it comes to the tests (though certainly not perfect).  We've been getting a lot better at addressing regressions, though there's still 4 open right now (1 phobos, 2 druntime, 1 dmd).  Can we please make the remaining open regressions a release blocker?
>
> Also, I'd really love to see the pull lists knocked down considerably before the next beta, particularly the phobos set (considering the larger set of people with access to it).  The d-p-l and tools sets should be even easier to keep at 0, but even those have some accumulated requests, the oldest of which is over a year now.
>
> Several of the open requests (across all the repos) are open because there's some controversy about them.  I'll pick the
> 'dur' ones as a good, but hardly only, example.  Either those should be pulled or closed.  Leaving in limbo helps no
> one.  For this sort of request, a choice needs to be made and move on.  A key part of the problem with this set is that
> we don't have a process for deciding what to do with them.  Anyone care to put forth a proposal?
>
> Another example is the const(Object)ref code change.  There's little value in the pull request being open for a year. Closing the pull request does NOT do anything irrevocable as the branch remains available (assuming the author doesn't delete it).  Keeping it open doesn't help with anything other than maybe loosing track of it, but that's better done through bugzilla, imho.  Closing it wouldn't be a rejection, but a long term deferral.
>
> What's stopping us from handling all pull requests w/in a week?  Or even better a day or two?
>
> My 2 cents,
> Brad
>
> On 5/28/2012 1:41 AM, Walter Bright wrote:
>> Since I'll be out next week, I think that would be a good time to do a beta. So, let's aim towards getting a beta release ready by Saturday.
>>
>> -Walter
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
> _______________________________________________
> phobos mailing list
> phobos@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 29.05.2012 0:07, Brad Roberts wrote:
> There's an analogy that we like to use at work, and in my experience it holds pretty well for code quality and bleeds
> pretty well into the entire development process:
>
>    http://en.wikipedia.org/wiki/Broken_windows_theory
>
> We do an ok job when it comes to the tests (though certainly not perfect).  We've been getting a lot better at
> addressing regressions, though there's still 4 open right now (1 phobos, 2 druntime, 1 dmd).  Can we please make the
> remaining open regressions a release blocker?
>
> Also, I'd really love to see the pull lists knocked down considerably before the next beta, particularly the phobos set
> (considering the larger set of people with access to it).  The d-p-l and tools sets should be even easier to keep at 0,
> but even those have some accumulated requests, the oldest of which is over a year now.
>
> Several of the open requests (across all the repos) are open because there's some controversy about them.  I'll pick the
> 'dur' ones as a good, but hardly only, example.  Either those should be pulled or closed.  Leaving in limbo helps no
> one.  For this sort of request, a choice needs to be made and move on.  A key part of the problem with this set is that
> we don't have a process for deciding what to do with them.  Anyone care to put forth a proposal?
Would be awesome to have a simple official way of handling pull request.
Throwing in something to start a discussion.

    The D Pull Process (TDPP).
1. Pulls that are open longer then 1-2 weeks must be reviewed by at least one core dev.  (exceptions are large pulls, e.g.  1KLOC+ pulls)
2. The review MUST end with one of following verdicts (it should be obvious, like separate message, no free form only exact terms*) :
    a) "Good to go", followed by merge.
    b) "Needs work", review prolonged by another 1-2 weeks to let author address issues, then processed simillarly.
    c) "Not good enough" or "Rewrite" means that idea is OK, but implementation is no good and won't be accepted.  Pull is either closed  or in select cases it can be kept so that contributor can rewrite it with push --force.
    d) "Rejected", followed by explanation a-la:
        d.1 unfit, doesn't cover the problem set it objectively should
        d.2 disruptive, breaks (too much of) existing code
        d.3 pointless, adds no or too little value (observe that d.1 is "misses the boat", here it's too small a benefit )
        d.4 ineffective,  (though that may be rewrite)  if contributor refuses to rewrite ;)
        d.5 insecure/unsafe, breaking language or OS guarantees (proof links may help revert this decision)
        ...
    e) "Postponed", followed by close. Meaning that it delayed for arbitrary long amount of time (not 1 month, but like "try again later") Read it like  "till we have x64 dmd on win32" ;)

3. Longest period of review (given few prolongs) is 3** months. Then it's ether closed or merged, any possible limbo is handled via "e" - postponed (e.g. no response form authors etc.).

*Names are placeholders and debatable.
**values too, obviously

Another point - it looks like core developers are hesitant to pull in various stuff that touch parts of Phobos they know nothing about.  Would be great if we had coverage of factor ~2 at least. That is every module in Phobos is known at least to 2 developers (known in general).

-- 
Dmitry Olshansky

_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

Le 2012-05-28 à 16:07, Brad Roberts a écrit :

> Another example is the const(Object)ref code change.  There's little value in the pull request being open for a year.

Indeed... especially since I haven't updated it for many months and it has fallen behind. A pull request which is no longer being maintained and is no longer mergeable should be closed. It can always be reopened later if needed.

In this particular case, Walter couldn't handle it while it was maintained, and now too much time has passed without maintenance, so it is effectively lost... until some one digs it and do the required maintenance work. Personally, I have no intention of putting more time into it at this point.

So to avoid putting the burden on someone else I just closed pull #3. RIP const(Object)ref.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 5/28/2012 1:07 PM, Brad Roberts wrote:
> There's an analogy that we like to use at work, and in my experience it holds pretty well for code quality and bleeds
> pretty well into the entire development process:
>
>    http://en.wikipedia.org/wiki/Broken_windows_theory
>
> We do an ok job when it comes to the tests (though certainly not perfect).  We've been getting a lot better at
> addressing regressions, though there's still 4 open right now (1 phobos, 2 druntime, 1 dmd).  Can we please make the
> remaining open regressions a release blocker?

My idea is more along the lines of at least having it not be *worse* than the previous release. That would be one regression at this point, which has an outstanding pull request.




>What's stopping us from handling all pull requests w/in a week?  Or even better a day or two?


Currently I'm working on the 64 bit struct ABI, which is marked as a critical blocker (a sentiment I agree with).
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 5/28/2012 5:34 PM, Walter Bright wrote:
> On 5/28/2012 1:07 PM, Brad Roberts wrote:
>> There's an analogy that we like to use at work, and in my experience it holds pretty well for code quality and bleeds pretty well into the entire development process:
>>
>>    http://en.wikipedia.org/wiki/Broken_windows_theory
>>
>> We do an ok job when it comes to the tests (though certainly not perfect).  We've been getting a lot better at addressing regressions, though there's still 4 open right now (1 phobos, 2 druntime, 1 dmd).  Can we please make the remaining open regressions a release blocker?
> 
> My idea is more along the lines of at least having it not be *worse* than the previous release. That would be one regression at this point, which has an outstanding pull request.

Fully agree, but we are within reach of 0 open regressions, so let's close that gap now and keep it there.  The longer we wait the easier it is to wait just a little more.  If that's not practical for this release (and I'm not accepting that premise), can we commit NOW that the next release will be at 0 open regression bugs as a release criteria?

>> What's stopping us from handling all pull requests w/in a week?  Or even better a day or two?
> 
> Currently I'm working on the 64 bit struct ABI, which is marked as a critical blocker (a sentiment I agree with).

For the scope of this thread, let's set dmd aside and focus on the rest.  The rate of DMD pull requests and their being
committed is already higher than all the other components combined (863 closed for dmd vs 821 for the rest).  That
there's 97 open dmd pulls is a problem, but considering the bottleneck known as you, it's still doing remarkably good by
comparison.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 5/28/12 7:34 PM, Walter Bright wrote:
> My idea is more along the lines of at least having it not be *worse*
> than the previous release. That would be one regression at this point,
> which has an outstanding pull request.

The thing is we can't really measure that, as new regressions and blockers etc. may arise after the release. What we can measure and minimize is the number of already-known issues.

Andrei
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 5/28/2012 6:32 PM, Andrei Alexandrescu wrote:
> On 5/28/12 7:34 PM, Walter Bright wrote:
>> My idea is more along the lines of at least having it not be *worse*
>> than the previous release. That would be one regression at this point,
>> which has an outstanding pull request.
>
> The thing is we can't really measure that, as new regressions and blockers etc. may arise after the release. What we can measure and minimize is the number of already-known issues.
>

I know. But we did have a large number of regressions pop up after the last release, and much effort was put into fixing those.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On May 29, 2012, at 02:34 AM, Walter Bright <walter@digitalmars.com> wrote:

> On 5/28/2012 1:07 PM, Brad Roberts wrote:
> > There's an analogy that we like to use at work, and in my experience it holds pretty well for code quality and bleeds pretty well into the entire development process:
> >
> > http://en.wikipedia.org/wiki/Broken_windows_theory
> >
> > We do an ok job when it comes to the tests (though certainly not perfect). We've been getting a lot better at addressing regressions, though there's still 4 open right now (1 phobos, 2 druntime, 1 dmd). Can we please make the remaining open regressions a release blocker?
>
> My idea is more along the lines of at least having it not be *worse* than the previous release. That would be one regression at this point, which has an outstanding pull request.

I don't think that's good enough. If a regression is introduced in a release we need to do better than the previous release. Otherwise the number of regression may not have been reduced.

> >What's stopping us from handling all pull requests w/in a week? Or even better a day or two?
>
>
> Currently I'm working on the 64 bit struct ABI, which is marked as a critical blocker (a sentiment I agree with).

Sure it's great that you're working on this issue but I don't think there's that many that actally are depending on being able to generate 64bit code.

* Windows - can't generate 64bit code - not an issue.
* Mac OS X - one can seamlessly compile both 32 and 64bit code. All system libraries ship at least in 32 and 64bit x86 code - not an issue.
* Linux - Can usually not compile for other architectures. Needs to install 32bit compatible libraries - in most of the cases a minor inconvenience.
* FreeBSD - Don't know, but I'm assuming it's similar to how it's on Linux

--
/Jacob Carlborg