[LLVMdev] [cfe-dev] LLVM 3.4 Branch Freeze

[Hal Finkel]

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