[LLVMdev] RFC: Bug fix releases for 3.3 and beyond

[Tom Stellard]

On Wed, Apr 03, 2013 at 07:35:59PM -0400, Sean Silva wrote:
> On Wed, Apr 3, 2013 at 5:44 PM, Tom Stellard <tom at stellard.net> wrote:
> 
> > On Wed, Apr 03, 2013 at 05:12:42PM -0400, Sean Silva wrote:
> > > On Wed, Apr 3, 2013 at 4:09 PM, Tom Stellard <tom at stellard.net> wrote:
> > > >
> > > >
> > > > > How many customers out there are shipping their LLVM-based products
> > > > > without actually including the LLVM sources?  If they do include the
> > > > > sources, they may fix the bug locally, especially if they are
> > > > > capable of investigating what the problem is.
> > > > >
> > > >
> > > > Projects that wants to be distributed as part of a Linux or *BSD
> > > > distribution really can't ship their own custom version of LLVM
> > > > with their project.  They need to use the LLVM version that is provided
> > > > by distributions, so this rules out this kind of solution.
> > > >
> > > >
> > > Your initial proposal seems to be trying to cast a very wide net
> > (affecting
> > > possible every LLVM developer) in the hope of getting patches needed by
> > > downstream rolled into stable dot-releases. It may be more appropriate to
> > > let the needs of the external projects drive the stable branch than for
> > the
> > > LLVM developers to try to guess what might be good to have on a stable
> > > branch. i.e. it may be better for the needs of external projects to
> > "pull"
> > > just the patches they need into a stable branch than for LLVM developers
> > to
> > > globally try to "push" patches into a stable branch in the hopes that one
> > > of those patches will be needed by downstream.
> > >
> >
> > I agree with you here.  I think the changes that end up in the stable
> > branch should be ones that somebody cares about and is willing to put at
> > least some effort into getting it backported.  This may be developers or
> > it may be external projects that need a bug-fix, but if a developer
> > doesn't think backporting a fix is important than they shouldn't be
> > forced to do it.
> >
> 
> I think some developers (myself included) were a bit apprehensive of your
> initial proposal because it made it sound like the onus was on us, the LLVM
> developers, to try to identify all the patches that should be funnelled
> into stable dot-releases for downstream. This is a lot more reasonable.
> 
> So my understanding of the discussion so far is that really all we need is
> a way for downstream projects to request that certain bugfixes be rolled
> into a dot-release that is officially backed by LLVM and which distros are
> expected to package and upgrade to. Also necessary is the infrastructure to
> qualify such releases in order to make sure that nothing breaks.
> 
> 
> >
> > >
> > > On another level, it seems like what you are asking for is just an easier
> > > way for downstream projects that run into bugs to get those bugfixes
> > rolled
> > > into a packaged release in a timely fashion. Is this correct? If so, I'm
> > > sure it would be possible to set up a fairly simple protocol for getting
> > > just the code they need into an "official" release.
> > >
> >
> > I'm not quite sure if I follow you here.  How would this help with
> > bugs that are found after an "official" release.
> >
> 
> Sorry, that was poorly worded. By "official" I meant "a release that
> distros would be expected to package". I.e. not just a tarball put together
> by some developer, but something that is recognized as having backing by
> the LLVM project. So with this meaning a dot-release would count
> as "official".
> 
> 
> >
> >
> > > You also appear to have suggested pushing new C API changes and possibly
> > > new target features (!), and in light of this the above statement could
> > be
> > > extended to "get new C API and target features into a packaged release
> > in a
> > > timely fashion", which seems awfully close to simply being a way for code
> > > owners to push new code into "official dot-releases" in circumvention of
> > > our release schedule. While having such a side-channel may be
> > pragmatically
> > > useful I can't help but feel that it is a bit hackish and would be better
> > > addressed by improving the automation of our release process (and the
> > > infrastructure supporting it) to enable a faster release schedule.
> > >
> >
> > A faster release cycle would help for new features, and I think it
> > would be great to have a more automated release process, but I think
> > there would still be value in dot releases.  Mainly for giving users the
> > chance
> > to stabilize their projects with a stable version of LLVM and know that
> > if they found an LLVM bug, they would have the opportunity to fix it.
> >
> >
> I'm not aware of any issues where users don't feel they can contribute
> patches back to us, and that sounds like an orthogonal issue.
> 

Sorry, I wasn't very clear.  I was referring to contributing bug fixes to
a released version of LLVM that is being distributed by distros, which
isn't currently possible without a whole lot of effort (i.e. convincing
every distro to pick up your bug fix).  I don't think there is any issue
for users contributing to ToT.

-Tom