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
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. -- Sean Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130403/b69878dd/attachment.html>
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