On 20 January 2014 15:44, Tom Stellard <tom at stellard.net> wrote:> Thanks for the feedback. Here is a summary of the responses. > These items are still up for discussion, but if there are no > objections in the next few days, I will add these to the > release documentation: >Hi Tom, Thanks for the summary, I agree with mostly everything, but I have some specific comments inline... + Shared library name will remain libLLVM-Major.Minor.so, but>a libLLVM-Major.Minor.Patch.so symlink will be added.>You mean a library M.m.p will be created and a symlink M.m will point to it, right? + Supported platforms will be determined by test coverage.>I'm in two minds about it. While it makes no sense to re-build for all archs if the bug-fix is specific to only one, it'll confuse people if you need to use the same toolchain across different architectures, and we'll end up replying on the list: "oh, 3.5.1 is only for ARM and x86, while 3.5.2 is only for Mips...", etc. I think we should release all binaries, and maybe test less extensively on the architectures that have no bug-fixes, but still build the binaries, the libraries, and symlinks. The problem arises when no one will build and test for arch A and we simply cannot release something without even knowing it runs. We shouldn't stop the release because of that, and that would be an acceptable case where there simply is no patch-release for that arch. I would expect it not to happen for the architectures listed as "supported" in the documentation, and in time, it should be "frowned upon" for "supported" architectures NOT to do a patch release. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140120/6f912306/attachment.html>
On Mon, Jan 20, 2014 at 04:06:04PM +0000, Renato Golin wrote:> On 20 January 2014 15:44, Tom Stellard <tom at stellard.net> wrote: > > > Thanks for the feedback. Here is a summary of the responses. > > These items are still up for discussion, but if there are no > > objections in the next few days, I will add these to the > > release documentation: > > > > Hi Tom, > > Thanks for the summary, I agree with mostly everything, but I have some > specific comments inline... > > > + Shared library name will remain libLLVM-Major.Minor.so, but > > > a libLLVM-Major.Minor.Patch.so symlink will be added. > > > > You mean a library M.m.p will be created and a symlink M.m will point to > it, right? >Yes. libLLVM-M.m.so -> libLLVM-M.m.p.so> > + Supported platforms will be determined by test coverage. > > > > I'm in two minds about it. While it makes no sense to re-build for all > archs if the bug-fix is specific to only one, it'll confuse people if you > need to use the same toolchain across different architectures, and we'll > end up replying on the list: "oh, 3.5.1 is only for ARM and x86, while > 3.5.2 is only for Mips...", etc. I think we should release all binaries, > and maybe test less extensively on the architectures that have no > bug-fixes, but still build the binaries, the libraries, and symlinks. >How many people actually depend on the binaries posted on llvm.org? I agree that if we are providing binaries we should try to build binaries for the same architectures each release. However, it seems to me like a majority of LLVM's users are using a binary produced somewhere else, so I wonder if we even need to worry about which architectures we build for. I'm much more concerned about platform testing and validation than I am the binaries.> The problem arises when no one will build and test for arch A and we simply > cannot release something without even knowing it runs. We shouldn't stop > the release because of that, and that would be an acceptable case where > there simply is no patch-release for that arch. I would expect it not to > happen for the architectures listed as "supported" in the documentation, > and in time, it should be "frowned upon" for "supported" architectures NOT > to do a patch release. > >What you've described is the main problem I'm trying to avoid. Where we say we support ARM, for example, and then there is a critical fix for X86 somewhere in the core libraries, and we can't do a release because there are no ARM testers to build binaries. As far as I understand, there only two "supported" or "first-tier" platforms: X86 and ARM. I just want it to be clear what to do in case there are no testers for one of these platforms. Do we cancel the release, or do we take the position that if no one is willing to provide testing resources for a platform, then it is not really worthy of "supported" or "first-tier" status. -Tom> cheers, > --renato
On 20 January 2014 16:34, Tom Stellard <tom at stellard.net> wrote:> I'm much more concerned about platform testing and validation than I am > the binaries. >That's a good point. Distributions should trust our source branches because we tested on the release platforms, not because our binary releases are out. As far as I understand, there only two "supported" or "first-tier"> platforms: > X86 and ARM.Yes. That makes three architectures: x86, x86_64 and ARM32. ARM64, Mips, PPC and others still aren't "first-tier" so we don't need to worry about them right now. Do we cancel the release, or do we take the position> that if no one is willing to provide testing resources for a platform, > then it > is not really worthy of "supported" or "first-tier" status. >We can't cancel the status of first-tier because patch releases are not yet official. Heck, even skipping an official release wouldn't necessarily remove the status if we have buildbots, and extensive offline tests elsewhere. So we can't play that card. Since both x86 and ARM communities are large enough, I don't think we'll ever be without hands to at least build the release and run a test-suite. That should give us enough peace of mind to progress with the release. But as more platforms start joining the release process, we'll have to make sure they can cope with the process when demand comes. Furthermore, as it stands, we have at least two people willing to build and test for each platform. As a last resort, I could do all three releases, since I have the hardware available, so we can still test the patch release on all three major archs. Other people in this list can also do the same, so I think that we're covered. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140120/a0e75645/attachment.html>