On 11/1/07, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> On Mon, 29 Oct 2007, Jason Merrill wrote:
> > I think I prefer Richard's suggestion of not branching until we're ready to
> > make the .0 release. The effect should be the same except that people don't
> > have to deal with checking patches i
On Thu, 1 Nov 2007, Richard Guenther wrote:
> Well, there are installable gcc 4.3 builds for openSUSE available,
> and I know of at least Debian packages in experimental. I wouldn't
> be surprised if Fedora also has gcc 4.3 packages ready.
FreeBSD also has packages (and of course the source ports
Jack Lloyd wrote:
On Thu, Nov 01, 2007 at 09:50:00AM -0700, Andrew Pinski wrote:
Create a beta that is released now and then release one once (or
twice) a month until we release 4.3. This is seperate from a release
candidate and the snapshot. The beta is get attention from some folks
that w
On 11/1/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 01, 2007 at 01:55:04PM -0400, Jack Lloyd wrote:
> > I would like this. It's common for snapshots to fail to build (at
> > least on my machines), which is definitely a discouragement from
> > trying them too often, and by the tim
On 11/1/07, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
> > Once we hit the target of 100 open PRs,( or whenever we would have
> > originally cut a stage 3 release branch), we firm up stage 3 so that
> > *really* only bugfixes go in. Then we work toward a release
> > candidate, etc etc.?
>
> I gu
On Thu, Nov 01, 2007 at 01:55:04PM -0400, Jack Lloyd wrote:
> I would like this. It's common for snapshots to fail to build (at
> least on my machines), which is definitely a discouragement from
> trying them too often, and by the time the RCs hit it's way too late
> to do much about any problems b
On Thu, Nov 01, 2007 at 09:50:00AM -0700, Andrew Pinski wrote:
> Create a beta that is released now and then release one once (or
> twice) a month until we release 4.3. This is seperate from a release
> candidate and the snapshot. The beta is get attention from some folks
> that would not have us
Andrew Pinski wrote:
On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
Now that GCC is in stage 4.3, I think we'd all be in agreement that it
would be nice to keep this stage short and get a release out.
Let me suggest something which is going sound a little crazy.
Create a beta
On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
>
> Now that GCC is in stage 4.3, I think we'd all be in agreement that it
> would be nice to keep this stage short and get a release out.
Let me suggest something which is going sound a little crazy.
Create a beta that is released now and th
> >> I think I prefer Richard's suggestion of not branching until we're
> >> ready to make the .0 release. The effect should be the same
> >> except that people don't have to deal with checking patches in on
> >> the branch vs. the trunk until after 4.3.0 goes out.
> >>
> >
> > I like this a
Gerald Pfeifer wrote:
On Mon, 29 Oct 2007, Jason Merrill wrote:
I think I prefer Richard's suggestion of not branching until we're ready to
make the .0 release. The effect should be the same except that people don't
have to deal with checking patches in on the branch vs. the trunk until afte
On Mon, 29 Oct 2007, Jason Merrill wrote:
> I think I prefer Richard's suggestion of not branching until we're ready to
> make the .0 release. The effect should be the same except that people don't
> have to deal with checking patches in on the branch vs. the trunk until after
> 4.3.0 goes out.
I
Richard Guenther writes:
> On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > > Note that we are building what-becomes-openSUSE 11.0 with current trunk
> > > in parallel to 4.2 at the moment, switching to 4.3 is in the next weeks
> > > (unless I get pushed back again ;)).
> > >
> > >
> > It
Jason Merrill wrote:
> No. Previously we've branched at <100 regressions, but waited for the
> numbers to get better than that before making the release. I'm
> suggesting that the release criteria stay about the same as before, just
> that we delay the branch until the release is ready rather th
Benjamin Kosnik wrote:
Jason, any thoughts on how to translate "ready to make a .0 release"
into "made a .0 release," in terms of a firm schedule, with dates? I'm
assuming that the < 100 bugzilla count is an adequate milestone for the
release branch to be cut.
Or do you think < 100 implies branc
Richard Guenther wrote:
> Sure. I'd expect the usual release candidate or two separated by
> one or two weeks. I'd also expect the mainline to be frozen after rc1.
> I guess branching can happen at the point there is either rc2 or
> the 4.3.0 release.
I'm following this discussion closely, of c
I've a fast idea.
To release now it as gcc-4.3.0 if the building of distribution's base
doesn't crashes.
To start the branch for gcc-4.4-ss.
Many linux's people start to test gcc-4.3.0 from their distributions
and to report their bugs.
Tomorrow, we will have a rocked gcc-4.3.15 quickly possible
On 10/29/07, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
>
> > I think I prefer Richard's suggestion of not branching until we're
> > ready to make the .0 release. The effect should be the same except
> > that people don't have to deal with checking patches in on the branch
> > vs. the trunk until
> I think I prefer Richard's suggestion of not branching until we're
> ready to make the .0 release. The effect should be the same except
> that people don't have to deal with checking patches in on the branch
> vs. the trunk until after 4.3.0 goes out.
This would certainly make things easier. A
> -Original Message-
> From: Andrew MacLeod [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 29, 2007 12:48 PM
> To: Richard Guenther
> Cc: Jason Merrill; Benjamin Kosnik; gcc@gcc.gnu.org;
> [EMAIL PROTECTED]
> Subject: Re: GCC 4.3 release schedule
> I don&#
On 10/29/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
> >> Sure, I think it boils down to the same thing from a conceptual point of
> >> view, but perhaps the nitty gritty details are easier if you keep it as
> >> mainline so we dont have to check everything into 2 branch
Richard Guenther wrote:
Sure, I think it boils down to the same thing from a conceptual point of
view, but perhaps the nitty gritty details are easier if you keep it as
mainline so we dont have to check everything into 2 branches. Bottom
line is you freeze development until its time to release.
On 10/29/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> Jason Merrill wrote:
> > Andrew MacLeod wrote:
> >> But yes, Id still be in favour of trying this or anything else which
> >> might help. Cut a release branch, and simply refuse to open stage 1
> >> until we release.
> >
> > I think I prefer
Jason Merrill wrote:
Andrew MacLeod wrote:
But yes, Id still be in favour of trying this or anything else which
might help. Cut a release branch, and simply refuse to open stage 1
until we release.
I think I prefer Richard's suggestion of not branching until we're
ready to make the .0 releas
Andrew MacLeod wrote:
But yes, Id still be in favour of trying this or anything else which
might help. Cut a release branch, and simply refuse to open stage 1
until we release.
I think I prefer Richard's suggestion of not branching until we're ready
to make the .0 release. The effect should
On 10/29/07, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
>
> > The only problem, is that anyone doing stage 1 work is already doing
> > so in a branch, and history (at least as I remember it :-) is that
> > if little johnny doesn't have a pressing need for the current
> > release, he will simply ke
> The only problem, is that anyone doing stage 1 work is already doing
> so in a branch, and history (at least as I remember it :-) is that
> if little johnny doesn't have a pressing need for the current
> release, he will simply keep plugging along on his branch until stage
> 1 happens, whether
Benjamin Kosnik wrote:
I'd rather take the make the dot-zero release approach while branching
and count on interested people fixing bugs on the branch after the
dot-zero release. This way if nobody is interested on a particular
release series then we can declare the dot-zero release final -
o
> I'd rather take the make the dot-zero release approach while branching
> and count on interested people fixing bugs on the branch after the
> dot-zero release. This way if nobody is interested on a particular
> release series then we can declare the dot-zero release final -
> otherwise we'd do
Dennis Clarke wrote:
Is "correctness" a feature ?
Yes, but not one that gets merged in during stage 1 :)
I would like to see a nice clean GCC 4.2.x before GCC 4.3.zero even gets
thought of. Why would one simply branch towards the next release when
the previous one still needs some work
* Joe Buck <[EMAIL PROTECTED]> [2007-10-26 14:53]:
> Can you estimate how many packages use or ?
Not easily because I backed out those changes.
--
Martin Michlmayr
http://www.cyrius.com/
On Fri, Oct 26, 2007 at 10:28:35PM +0200, Martin Michlmayr wrote:
> * Joe Buck <[EMAIL PROTECTED]> [2007-10-26 11:44]:
> > You might want to hold off on investing the work in fixing those 550
> > packages, because I think it's premature to consider the header
> > "cleanup" final.
> >
> > Can you e
> I added more entries to gcc-4.2/buildstat.html.
>
> Bootstrap and test results for 4.2.2:
>
> i686-pc-linux-gnu (Slackware 12.0, kernel 2.6.22, glibc 2.5)
>
> Test results for 4.2.2:
>
> hppa2.0w-hp-hpux11.11
> hppa64-hp-hpux11.11
> hppa-unknown-linux-gnu
> i386-unknown-freebsd5.5
> i
Mark Mitchell wrote:
Andrew MacLeod wrote:
we can at least make projected dates known so we have something firmer
than "at some point in the future" :-)
As RM, I try to take into account what I know about when distributors
will be applying effort, but I must absolutely avoid in any wa
On Fri, 2007-10-26 at 19:54 +0200, Eric Botcazou wrote:
> > When I look at the Build status page I see no one has posted a result
> > there for GCC 4.2.2 :
> >
> > Please see : http://gcc.gnu.org/gcc-4.2/buildstat.html
>
> Here are a couple of posts by Kaveh:
> http://gcc.gnu.org/ml/gcc-testre
* Joe Buck <[EMAIL PROTECTED]> [2007-10-26 11:44]:
> You might want to hold off on investing the work in fixing those 550
> packages, because I think it's premature to consider the header
> "cleanup" final.
>
> Can you estimate how many of the broken packages use
> or ?
Sorry I wasn't being clea
On Fri, Oct 26, 2007 at 08:20:02PM +0200, Martin Michlmayr wrote:
> * Richard Guenther <[EMAIL PROTECTED]> [2007-10-26 17:51]:
> > Yes. I think Ubuntu is on track for 4.3 as well, most likely Debian, too.
>
> I've been testing 4.3 on a number of architectures Debian supports and
> filings bugs.
>> Why isn't the main page for build reports updated ?
>
> Will do.
>
>> It *looks* like no one ( me too ) is getting clean builds.
>
> The GCC 4.2.x compiler is in pretty good shape on SPARC/Solaris, modulo the
> libgomp problems on Solaris 10 with the Sun tools. You need to use the GNU
> tools
* Richard Guenther <[EMAIL PROTECTED]> [2007-10-26 17:51]:
> Yes. I think Ubuntu is on track for 4.3 as well, most likely Debian, too.
I've been testing 4.3 on a number of architectures Debian supports and
filings bugs. There are still many that haven't been resolved yet.
Of course, gcc 4.3 also
> Why isn't the main page for build reports updated ?
Will do.
> It *looks* like no one ( me too ) is getting clean builds.
The GCC 4.2.x compiler is in pretty good shape on SPARC/Solaris, modulo the
libgomp problems on Solaris 10 with the Sun tools. You need to use the GNU
tools if you care
>> When I look at the Build status page I see no one has posted a result
>> there for GCC 4.2.2 :
>>
>> Please see : http://gcc.gnu.org/gcc-4.2/buildstat.html
>
> Here are a couple of posts by Kaveh:
> http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00388.html
> http://gcc.gnu.org/ml/gcc-te
> When I look at the Build status page I see no one has posted a result
> there for GCC 4.2.2 :
>
> Please see : http://gcc.gnu.org/gcc-4.2/buildstat.html
Here are a couple of posts by Kaveh:
http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00388.html
http://gcc.gnu.org/ml/gcc-testresults/20
> Mark Mitchell wrote:
>> As I said in
>> my status report, our practice has been to cut the release branch when
>> we reach 100 regressions, and release 2-4 months after that point,
>> depending on quality on the branch. To be honest, I'd rather wait
>> longer to make the branch -- but there ten
> On 10/26/07, Dennis Clarke <[EMAIL PROTECTED]> wrote:
>>On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
>> >> Richard Guenther wrote:
>> >> > On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
>> >> >>
>>
>> >
>> > ... when we think it's ready. It doesn't help anyone to declare victor
Mark Mitchell wrote:
As I said in
my status report, our practice has been to cut the release branch when
we reach 100 regressions, and release 2-4 months after that point,
depending on quality on the branch. To be honest, I'd rather wait
longer to make the branch -- but there tends to be intense
On 10/26/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>
> I've found schedules for GCC to be very hard to predict. As I said in
> my status report, our practice has been to cut the release branch when
> we reach 100 regressions, and release 2-4 months after that point,
> depending on quality on th
On 10/26/07, Dennis Clarke <[EMAIL PROTECTED]> wrote:
>
> > On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> >> Richard Guenther wrote:
> >> > On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> >> >>
>
> >
> > ... when we think it's ready. It doesn't help anyone to declare victory
>
Andrew MacLeod wrote:
> we can at least make projected dates known so we have something firmer
> than "at some point in the future" :-)
The canonical rule of project management is: "Features, Schedule, Cost:
Pick At Most 2." :-) In other words, you can decide what features you
want and when you
> On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
>> Richard Guenther wrote:
>> > On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
>> >>
>
> ... when we think it's ready. It doesn't help anyone to declare victory
> and release 4.3.0 when it still miscompiles the kernel (not that I k
On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
> > On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> >>
> >> Nov 14th - we'd like to start building F9 with a 4.3 compiler. Ideally
> >> we'd have a branch cut no later than that and starting to stabilize
> >>
Richard Guenther wrote:
On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
Now that GCC is in stage 4.3, I think we'd all be in agreement that it
would be nice to keep this stage short and get a release out.
We are interested in using 4.3 as the system compiler in Fedora 9, and
as such,
On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
>
> Now that GCC is in stage 4.3, I think we'd all be in agreement that it
> would be nice to keep this stage short and get a release out.
>
> We are interested in using 4.3 as the system compiler in Fedora 9, and
> as such, we'd like to nail d
Now that GCC is in stage 4.3, I think we'd all be in agreement that it
would be nice to keep this stage short and get a release out.
We are interested in using 4.3 as the system compiler in Fedora 9, and
as such, we'd like to nail down some time lines and requirements with
release management
53 matches
Mail list logo
