----- Original Message -----> From: "Tom Stellard" <tom at stellard.net> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: cfe-dev at cs.uiuc.edu, llvmdev at cs.uiuc.edu, "Óscar Fuentes" <ofv at wanadoo.es> > Sent: Wednesday, December 18, 2013 10:55:43 AM > Subject: Re: [cfe-dev] [LLVMdev] LLVM 3.4 Branch Freeze > > On Fri, Dec 13, 2013 at 04:49:11PM -0600, Hal Finkel wrote: > > ----- Original Message ----- > > > From: "Tom Stellard" <tom at stellard.net> > > > To: "Óscar Fuentes" <ofv at wanadoo.es> > > > Cc: cfe-dev at cs.uiuc.edu, llvmdev at cs.uiuc.edu > > > Sent: Friday, December 13, 2013 10:24:59 AM > > > Subject: Re: [cfe-dev] [LLVMdev] LLVM 3.4 Branch Freeze > > > > > > On Fri, Dec 13, 2013 at 02:45:51PM +0100, Óscar Fuentes wrote: > > > > Hal Finkel <hfinkel at anl.gov> writes: > > > > > > > > [snip] > > > > > > > > > Many of my colleagues say that, with gcc, they wait for > > > > > the x.y.1 release before upgrading because the .0 is too > > > > > buggy. > > > > > But if > > > > > we're not doing point releases, then I think we need tighter > > > > > standards > > > > > for release. Doing otherwise is not fair to our users. > > > > > > > > What happened to the LLVM/Clang maintenance release project? > > > > > > > > > > We weren't able to make a 3.3.1 release, because we did not have > > > enough > > > testers. > > > > > > In order to have a successful maintenance release, we need to > > > either: > > > > > > a) Get commitments from everyone who wants a maintenance release > > > that > > > they will help test the release. > > > > > > or > > > > > > b) Have less strict testing requirements for maintenance releases > > > with > > > the assumption that there is a lot of ongoing testing between > > > .0 > > > and .1 > > > so there are less likely to be bugs left when it is time to > > > release .1, > > > and anyone who cares about a maintenance release has had > > > enough > > > time to file > > > bugs. > > > > > > I really think maintenance releases are really important for Open > > > Source > > > projects, because these projects get much more testing after a > > > release than > > > before it. > > > > > > I would volunteer to maintain a stable branch again after the 3.4 > > > release, > > > > I would certainly also help. > > > > > but I think we need to solve our release validation issues > > > first. > > > > To be honest, I don't think this will be a problem in practice. The > > amount of incremental change is small and there is already ongoing > > testing of all changes that go into the release (which should all > > be bug fixes). You may not get as much testing as for the primary > > release, but I suspect that many of those same people who test the > > base releases will also try the maintenance releases. Personally, > > yes, I'd contribute to testing the maintenance releases. > > > > Maybe we can re-visit this after the holidays are over. I am still > interested in doing bugfix releases for LLVM.Sounds good; let's do that.> > Besides the issue with testers the other thing we need to determine > is > whether or not we want to maintain a stable ABI for the bugfix > releases. > With 3.3, the plan was to have a stable ABI, but this caused me to > reject several fixes. I would recommend relaxing this requirement > if there is are bugfix releases for 3.4, but I'd like to hear what > other > people think about this.What kinds of changes were made? (can you provide a couple of examples)? -Hal> > -Tom > > > -Hal > > > > > > > > -Tom > > > > _______________________________________________ > > > > LLVM Developers mailing list > > > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > _______________________________________________ > > > cfe-dev mailing list > > > cfe-dev at cs.uiuc.edu > > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > > > > > > -- > > Hal Finkel > > Assistant Computational Scientist > > Leadership Computing Facility > > Argonne National Laboratory >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
On Wed, Dec 18, 2013 at 10:57:58AM -0600, Hal Finkel wrote:> ----- Original Message ----- > > From: "Tom Stellard" <tom at stellard.net> > > To: "Hal Finkel" <hfinkel at anl.gov> > > Cc: cfe-dev at cs.uiuc.edu, llvmdev at cs.uiuc.edu, "Óscar Fuentes" <ofv at wanadoo.es> > > Sent: Wednesday, December 18, 2013 10:55:43 AM > > Subject: Re: [cfe-dev] [LLVMdev] LLVM 3.4 Branch Freeze > > > > On Fri, Dec 13, 2013 at 04:49:11PM -0600, Hal Finkel wrote: > > > ----- Original Message ----- > > > > From: "Tom Stellard" <tom at stellard.net> > > > > To: "Óscar Fuentes" <ofv at wanadoo.es> > > > > Cc: cfe-dev at cs.uiuc.edu, llvmdev at cs.uiuc.edu > > > > Sent: Friday, December 13, 2013 10:24:59 AM > > > > Subject: Re: [cfe-dev] [LLVMdev] LLVM 3.4 Branch Freeze > > > > > > > > On Fri, Dec 13, 2013 at 02:45:51PM +0100, Óscar Fuentes wrote: > > > > > Hal Finkel <hfinkel at anl.gov> writes: > > > > > > > > > > [snip] > > > > > > > > > > > Many of my colleagues say that, with gcc, they wait for > > > > > > the x.y.1 release before upgrading because the .0 is too > > > > > > buggy. > > > > > > But if > > > > > > we're not doing point releases, then I think we need tighter > > > > > > standards > > > > > > for release. Doing otherwise is not fair to our users. > > > > > > > > > > What happened to the LLVM/Clang maintenance release project? > > > > > > > > > > > > > We weren't able to make a 3.3.1 release, because we did not have > > > > enough > > > > testers. > > > > > > > > In order to have a successful maintenance release, we need to > > > > either: > > > > > > > > a) Get commitments from everyone who wants a maintenance release > > > > that > > > > they will help test the release. > > > > > > > > or > > > > > > > > b) Have less strict testing requirements for maintenance releases > > > > with > > > > the assumption that there is a lot of ongoing testing between > > > > .0 > > > > and .1 > > > > so there are less likely to be bugs left when it is time to > > > > release .1, > > > > and anyone who cares about a maintenance release has had > > > > enough > > > > time to file > > > > bugs. > > > > > > > > I really think maintenance releases are really important for Open > > > > Source > > > > projects, because these projects get much more testing after a > > > > release than > > > > before it. > > > > > > > > I would volunteer to maintain a stable branch again after the 3.4 > > > > release, > > > > > > I would certainly also help. > > > > > > > but I think we need to solve our release validation issues > > > > first. > > > > > > To be honest, I don't think this will be a problem in practice. The > > > amount of incremental change is small and there is already ongoing > > > testing of all changes that go into the release (which should all > > > be bug fixes). You may not get as much testing as for the primary > > > release, but I suspect that many of those same people who test the > > > base releases will also try the maintenance releases. Personally, > > > yes, I'd contribute to testing the maintenance releases. > > > > > > > Maybe we can re-visit this after the holidays are over. I am still > > interested in doing bugfix releases for LLVM. > > Sounds good; let's do that. > > > > > Besides the issue with testers the other thing we need to determine > > is > > whether or not we want to maintain a stable ABI for the bugfix > > releases. > > With 3.3, the plan was to have a stable ABI, but this caused me to > > reject several fixes. I would recommend relaxing this requirement > > if there is are bugfix releases for 3.4, but I'd like to hear what > > other > > people think about this. > > What kinds of changes were made? (can you provide a couple of examples)? >Here are a few examples: http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/157018 -Tom
----- Original Message -----> From: "Tom Stellard" <tom at stellard.net> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: cfe-dev at cs.uiuc.edu, llvmdev at cs.uiuc.edu, "Óscar Fuentes" <ofv at wanadoo.es> > Sent: Wednesday, December 18, 2013 11:07:23 AM > Subject: Re: [cfe-dev] [LLVMdev] LLVM 3.4 Branch Freeze > > On Wed, Dec 18, 2013 at 10:57:58AM -0600, Hal Finkel wrote: > > ----- Original Message ----- > > > From: "Tom Stellard" <tom at stellard.net> > > > To: "Hal Finkel" <hfinkel at anl.gov> > > > Cc: cfe-dev at cs.uiuc.edu, llvmdev at cs.uiuc.edu, "Óscar Fuentes" > > > <ofv at wanadoo.es> > > > Sent: Wednesday, December 18, 2013 10:55:43 AM > > > Subject: Re: [cfe-dev] [LLVMdev] LLVM 3.4 Branch Freeze > > > > > > On Fri, Dec 13, 2013 at 04:49:11PM -0600, Hal Finkel wrote: > > > > ----- Original Message ----- > > > > > From: "Tom Stellard" <tom at stellard.net> > > > > > To: "Óscar Fuentes" <ofv at wanadoo.es> > > > > > Cc: cfe-dev at cs.uiuc.edu, llvmdev at cs.uiuc.edu > > > > > Sent: Friday, December 13, 2013 10:24:59 AM > > > > > Subject: Re: [cfe-dev] [LLVMdev] LLVM 3.4 Branch Freeze > > > > > > > > > > On Fri, Dec 13, 2013 at 02:45:51PM +0100, Óscar Fuentes > > > > > wrote: > > > > > > Hal Finkel <hfinkel at anl.gov> writes: > > > > > > > > > > > > [snip] > > > > > > > > > > > > > Many of my colleagues say that, with gcc, they wait for > > > > > > > the x.y.1 release before upgrading because the .0 is too > > > > > > > buggy. > > > > > > > But if > > > > > > > we're not doing point releases, then I think we need > > > > > > > tighter > > > > > > > standards > > > > > > > for release. Doing otherwise is not fair to our users. > > > > > > > > > > > > What happened to the LLVM/Clang maintenance release > > > > > > project? > > > > > > > > > > > > > > > > We weren't able to make a 3.3.1 release, because we did not > > > > > have > > > > > enough > > > > > testers. > > > > > > > > > > In order to have a successful maintenance release, we need to > > > > > either: > > > > > > > > > > a) Get commitments from everyone who wants a maintenance > > > > > release > > > > > that > > > > > they will help test the release. > > > > > > > > > > or > > > > > > > > > > b) Have less strict testing requirements for maintenance > > > > > releases > > > > > with > > > > > the assumption that there is a lot of ongoing testing > > > > > between > > > > > .0 > > > > > and .1 > > > > > so there are less likely to be bugs left when it is time > > > > > to > > > > > release .1, > > > > > and anyone who cares about a maintenance release has had > > > > > enough > > > > > time to file > > > > > bugs. > > > > > > > > > > I really think maintenance releases are really important for > > > > > Open > > > > > Source > > > > > projects, because these projects get much more testing after > > > > > a > > > > > release than > > > > > before it. > > > > > > > > > > I would volunteer to maintain a stable branch again after the > > > > > 3.4 > > > > > release, > > > > > > > > I would certainly also help. > > > > > > > > > but I think we need to solve our release validation issues > > > > > first. > > > > > > > > To be honest, I don't think this will be a problem in practice. > > > > The > > > > amount of incremental change is small and there is already > > > > ongoing > > > > testing of all changes that go into the release (which should > > > > all > > > > be bug fixes). You may not get as much testing as for the > > > > primary > > > > release, but I suspect that many of those same people who test > > > > the > > > > base releases will also try the maintenance releases. > > > > Personally, > > > > yes, I'd contribute to testing the maintenance releases. > > > > > > > > > > Maybe we can re-visit this after the holidays are over. I am > > > still > > > interested in doing bugfix releases for LLVM. > > > > Sounds good; let's do that. > > > > > > > > Besides the issue with testers the other thing we need to > > > determine > > > is > > > whether or not we want to maintain a stable ABI for the bugfix > > > releases. > > > With 3.3, the plan was to have a stable ABI, but this caused me > > > to > > > reject several fixes. I would recommend relaxing this > > > requirement > > > if there is are bugfix releases for 3.4, but I'd like to hear > > > what > > > other > > > people think about this. > > > > What kinds of changes were made? (can you provide a couple of > > examples)? > > > > Here are a few examples: > http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/157018I think that we should keep source compatibility, not necessarily binary compatibility, in maintenance releases. Binary compatibility, when possible, is nice, but should not stand in the way of the bug fixes themselves. Some of the packagers should comment on this topic :) -Hal> > -Tom > >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory