On 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?

I have a fix for issue 7995. I need to make a new pull request, tried to do too much in the last one. I'll hopefully have one ready today.

--
/Jacob Carlborg

On Tuesday, May 29, 2012 06:38:59 Jacob Carlborg wrote:
> > >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

I don't know how many people it really is, but there are a number of Linux people who consider it to be a major blocker. And the really insidious part is that there's going to be quite a few more who _would_ consider it to be a major blocker if they realized it was happenining. Instead, they just end up with buggy code.

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

On May 29, 2012, at 08:49 AM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> I don't know how many people it really is, but there are a number of Linux people who consider it to be a major blocker. And the really insidious part is that there's going to be quite a few more who _would_ consider it to be a major blocker if they realized it was happenining. Instead, they just end up with buggy code.

Yeah, I found out the hard way.

--
/Jacob Carlborg

On May 29, 2012, at 03:12 AM, Brad Roberts <braddr@puremagic.com> wrote:

> 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?

I agree. We really don't have an official road map or release schedule so I don't see any problem with waiting with the release until the regressions are fixed.

On 5/29/2012 12:02 AM, Jacob Carlborg wrote:
>
>
> On May 29, 2012, at 03:12 AM, Brad Roberts <braddr@puremagic.com> wrote:
>
>> 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?
>
> I agree. We really don't have an official road map or release schedule so I don't see any problem with waiting with the release until the regressions are fixed.
>

The issue would be with people who are blocked waiting for things that are already fixed in 2.060.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 5/28/2012 11:38 PM, Jacob Carlborg wrote:
>
>
> 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.

I think the changelog, which shows 80 bugs fixed in dmd alone, shows that this is better.

>
>> >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
>

Some people on the n.g. stated that this was a critical blocker for them because they could not make a credible interface to C libraries that relied on passing/returning structs.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 5/28/2012 11:49 PM, Jonathan M Davis wrote:
> I don't know how many people it really is, but there are a number of Linux people who consider it to be a major blocker. And the really insidious part is that there's going to be quite a few more who _would_ consider it to be a major blocker if they realized it was happenining. Instead, they just end up with buggy code.

True - the symptoms are a crash or worse, memory corruption.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

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

> The issue would be with people who are blocked waiting for things that are already fixed in 2.060.

But there will be people waiting for the the regressions to get fixed as well. Who will get priority? I think the regression should have higher priority.

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

> I think the changelog, which shows 80 bugs fixed in dmd alone, shows that this is better.

But if regression are introduced at the same time, in every release, and not fixed in the next one, it's not good.

> > * 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
> >
>
> Some people on the n.g. stated that this was a critical blocker for them because they could not make a credible interface to C libraries that relied on passing/returning structs.

But there's an easy workaround, compile for 32bit code. That what I said, I don't think it's _that_ many people that _actually_ depends on the code being 64bit.

Now that #6189 was fixed I recompiled my vector rasterizer
and I'm getting an ICE. Haven't reduced it yet but I guess
it's a regression.

Internal error: backend/cod1.c 1664
code *fixresult(elem *e,regm_t retregs,regm_t *pretregs)
{
  // ...
  assert(e && retregs);                 /* need something to work with  */
}
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals