On Wed, 2 Jan 2008, Mark Mitchell wrote:
> I think that's an appropriate patch, for now. I've had some offline
> discussions about other changes we might want to make, but let's capture
> the current state.
Exactly. That was my thinking. :-) If we want to make any updates to
our processes, I'
Gerald Pfeifer wrote:
> On Tue, 23 Oct 2007, Mark Mitchell wrote:
>> [...]
>
> I realized that the documentation we currently have up at
> http://gcc.gnu.org/bugs/management.html
> was partly incorrect (only listing P1 to P2) and certainly
> quite incomplete, so I tried to cast my understanding
On Tue, 23 Oct 2007, Mark Mitchell wrote:
> [...]
I realized that the documentation we currently have up at
http://gcc.gnu.org/bugs/management.html
was partly incorrect (only listing P1 to P2) and certainly
quite incomplete, so I tried to cast my understanding and
what I found in this thread int
Jason Merrill wrote:
> Mark Mitchell wrote:
>> When I mark a PR as "P1", that means "This is a regression, and I think
>> it's embarrassing for us, as a community, to have this bug in a
>> release." Unfortunately, every release goes out with P1 bugs open, so
>> we can't really call them "release b
On Tue, Oct 23, 2007 at 02:20:24PM -0400, Jason Merrill wrote:
> Mark Mitchell wrote:
> >When I mark a PR as "P1", that means "This is a regression, and I think
> >it's embarrassing for us, as a community, to have this bug in a
> >release." Unfortunately, every release goes out with P1 bugs open,
Mark Mitchell wrote:
When I mark a PR as "P1", that means "This is a regression, and I think
it's embarrassing for us, as a community, to have this bug in a
release." Unfortunately, every release goes out with P1 bugs open, so
we can't really call them "release blockers". My judgment isn't alwa
Ian Lance Taylor wrote:
> Jason Merrill <[EMAIL PROTECTED]> writes:
>
>> I think that the release process for recent releases has given undue
>> priority to bugs marked as regressions. I agree that it's important
>> for things that worked in the previous release to keep working in the
>> new rele
Jason Merrill <[EMAIL PROTECTED]> writes:
| But in any case, nobody has code that relies on getting an error from
| a previous version of the compiler that would be broken by moving to
| 4.3. Only regressions on valid code seem serious enough to me to
| warrant blocking a release.
I strongly agre
On Tue, 2007-10-23 at 03:05 -0400, David Fang wrote:
> > I still think that is too strong a position. A good fraction
> > of compiler time is spent bugging out user code.. one could
> > even say the job of a compiler is not generating machine code,
> > but telling programmers they're idiots :)
>
I still think that is too strong a position. A good fraction
of compiler time is spent bugging out user code.. one could
even say the job of a compiler is not generating machine code,
but telling programmers they're idiots :)
Every compiler version I've tried has been telling me this for years.
I think this is a very important point. If it didn't block a previous
release, it shouldn't block the current release. It doesn't mean it
shouldn't get looked at, but it also shouldn't be a blocker. I think
the high priority regressions should be ones that are new to 4.3 because
they have c
Jason Merrill <[EMAIL PROTECTED]> writes:
> I think that the release process for recent releases has given undue
> priority to bugs marked as regressions. I agree that it's important
> for things that worked in the previous release to keep working in the
> new release. But the regression tag is
On Tue, 2007-10-23 at 00:00 -0400, Jason Merrill wrote:
> skaller wrote:
> > But Jason, the compiler worked properly in rejecting invalid syntax.
> > Now you're suggesting it fails to do so. This suggests a real regression
> > and a real bug: the new feature should have an enabling flag
> > that
On 10/22/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> I think this is a very important point. If it didn't block a previous
> release, it shouldn't block the current release.
Yes it is but does a regression that is just found to be a regression
is considered a blocking one, it should block the
On 10/22/07, Jason Merrill <[EMAIL PROTECTED]> wrote:
> David Miller wrote:
>
> > But wouldn't you agree that it's not all that great to ship a new
> > feature in GCC that users have already found ways to ICE?
>
> Oh, absolutely, it's just not a regression.
Except it is still ICEing. There was a
skaller wrote:
But Jason, the compiler worked properly in rejecting invalid syntax.
Now you're suggesting it fails to do so. This suggests a real regression
and a real bug: the new feature should have an enabling flag
that couldn't have been set before it was implemented, and without
that flag s
David Miller wrote:
But wouldn't you agree that it's not all that great to ship a new
feature in GCC that users have already found ways to ICE?
Oh, absolutely, it's just not a regression.
Jason
Jason Merrill wrote:
Similarly, bugs marked as 4.1/4.2/4.3 regression don't seem like a
high priority to me. If a bug wasn't a blocker for 4.2, it shouldn't
be a blocker for 4.3. It makes sense to give such a bug a higher
priority than it would normally (say, one point higher), but it seems
On Mon, 2007-10-22 at 15:42 -0400, Jason Merrill wrote:
> I think that the release process for recent releases has given undue
> priority to bugs marked as regressions. I agree that it's important for
> things that worked in the previous release to keep working in the new
> release. But the r
From: Jason Merrill <[EMAIL PROTECTED]>
Date: Mon, 22 Oct 2007 15:42:50 -0400
> For instance, Bug 32252 is an ice-on-valid bug in a new C++ feature,
> variadic templates. But since 4.2 gave a syntax error instead of an
> ICE, this gets marked as a regression.
I agree that the regression marker i
I think that the release process for recent releases has given undue
priority to bugs marked as regressions. I agree that it's important for
things that worked in the previous release to keep working in the new
release. But the regression tag is used for much more trivial things.
For instanc
21 matches
Mail list logo
