llvm dev - Apr 2013 - [LLVMdev] RFC: Bug fix releases for 3.3 and beyond

On Wed, Apr 03, 2013 at 02:51:05PM -0500, Krzysztof Parzyszek
wrote:
> On 4/3/2013 2:36 PM, Tom Stellard wrote:
> >
> >I don't think the length of the release cycle really matters too
much.
> 
> It does.  Someone has to do the work---the effort goes to either to
> the ongoing development or to the maintenance releases.  A short
> release cycle generally means less "free time" in the main
> development.  Also, if the maintenance release goes out of service
> when a main release is made, then the users may still be forced to
> switch---the shorter the release cycle, the more likely this is to
> happen.
>
I understand this. The point I was trying to make was that regardless
of the length of the development cycle, it is still necessary to have
dot releases.
> 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.

Also, I think it is in the LLVM project's best interest to encourage
users to contribute bug fixes back to the project.  If projects are
required to maintain their own bug fix versions of LLVM, then they have
little incentive to contribute the fixes back.

-Tom

On 4/3/2013 3:09 PM, Tom Stellard wrote:
>
> 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.
In case of FreeBSD, the fix would more likely go into the OS source 
tree, not a dot branch of LLVM.  For projects like that there is still 
the issue of having their managers/coordinators incorporate a new dot 
release of LLVM into the project.  They will need good reasons to 
proceed with it.

> Also, I think it is in the LLVM project's best interest to encourage
> users to contribute bug fixes back to the project.  If projects are
> required to maintain their own bug fix versions of LLVM, then they have
> little incentive to contribute the fixes back.
If the problem no longer happens with ToT, then yes, they may have no 
reason to contribute a fix, but if it still happens, the fix will likely 
be needed.


I don't have any personal interest in not having dot releases.  My point 
is basically that there are a lot of complications with having this sort 
of effort going.  In practice, this can be very expensive, and if there 
are ways to manage bug fixes without resorting to dot releases, then 
those would be the preferred solutions.  Local workarounds are usually 
the best, and they can be reverted once a new LLVM release is 
incorporated into the project.

If you do this, you will need to manage expectations on both 
sides---LLVM developers/testers and the customers.  Sooner or later you 
will ask the developers to do something which was not in their original 
plan---how are you going to justify your requests?  I'm not sure how 
much resources the corporations paying for LLVM development will be 
willing to devote to this.  If you want, go ahead, just make sure you 
know ahead of time how to deal with all the issues that can come up.

-Krzysztof


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

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.


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.

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.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130403/ab71deed/attachment.html>

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

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

-Tom