[LLVMdev] Obsolete PTX is NOT completely removed in 3.2 release

[Pawel Wodnicki]

On 1/14/2013 2:28 PM, Brooks Davis wrote:
> On Mon, Jan 14, 2013 at 01:41:06PM -0600, Pawel Wodnicki wrote:
>> On 1/14/2013 12:40 PM, Brooks Davis wrote:
>>> On Sun, Jan 13, 2013 at 01:00:55PM -0600, Pawel Wodnicki
>>> wrote:
>>>> Brooks,
>>>> 
>>>>> On Fri, Jan 11, 2013 at 02:47:01PM -0600, Pawel Wodnicki
>>>>> wrote:
>>>>>> On 1/11/2013 2:40 PM, Brooks Davis wrote:
>>>>>>> On Fri, Jan 11, 2013 at 09:33:17PM +0100, Benjamin
>>>>>>> Kramer wrote:
>>>>>>>> 
>>>>>>>> On 11.01.2013, at 21:31, Justin Holewinski 
>>>>>>>> <justin.holewinski at gmail.com> wrote:
>>>>>>>> 
>>>>>>>>> On Fri, Jan 11, 2013 at 3:26 PM, Benjamin Kramer 
>>>>>>>>> <benny.kra at gmail.com> wrote:
>>>>>>>>> 
>>>>>>>>> On 11.01.2013, at 07:36, ????????? (Wei-Ren Chen) 
>>>>>>>>> <chenwj at iis.sinica.edu.tw> wrote:
>>>>>>>>> 
>>>>>>>>>> Hi Pawel,
>>>>>>>>>> 
>>>>>>>>>> PTX already be replaced with NVPTX. However, PTX 
>>>>>>>>>> subdirectory still sit in lib/Target in 3.2
>>>>>>>>>> release. Do you think update the release tarball
>>>>>>>>>> is a good idea? Also could you remove it from the
>>>>>>>>>> trunk?
>>>>>>>>> 
>>>>>>>>> Please do not, under no circumstances, change the
>>>>>>>>> 3.2 release tarballs at this point. They are
>>>>>>>>> mirrored around the world now with cryptographic
>>>>>>>>> hashes and signatures. Changing them will break
>>>>>>>>> things for many people, especially for an extremely
>>>>>>>>> minor thing like an empty directory.
>>>>>>>>> 
>>>>>>>>> I'm not sure if Pawel's tarball change should be
>>>>>>>>> reverted now as it already caused uproar, so
>>>>>>>>> changing it back might only make matters worse.
>>>>>>>>> 
>>>>>>>>> The tarballs were changed?
>>>>>>>> 
>>>>>>>> r172208
>>>>>>> 
>>>>>>> I finally updated the FreeBSD ports yesterday and today
>>>>>>> a user complained about distfile changes.  IMO, this
>>>>>>> revision should be reverted or all the other BSDs will
>>>>>>> have to chase checksums as well.
>>>>>>> 
>>>>>>> If you really want to remove the directory, ship a
>>>>>>> 3.2.1 tarball rather than screwing all the downstream
>>>>>>> consumers who's infrastructure exists to detect
>>>>>>> trojan'd tarballs.
>>>>>> 
>>>>>> Tarball is signed, it is not trjoan. Your infrastructure
>>>>>> should be able to deal with it?
>>>>> 
>>>>> The FreeBSD ports collection maintains a set of sha256
>>>>> hashes for each distfile.  The system can deal with them
>>>>> changing, but it's an inconvenience to port maintainers and
>>>>> users.  Even if we did have infrastructure to verify the
>>>>> signatures we'd still have to check the contents and would
>>>>> not just trust the signature since there's always a risk of
>>>>> keys being compromised.
>>>>> 
>>>>> -- Brooks
>>>>> 
>>>> 
>>>> At first your reaction has puzzled me, but despite a few
>>>> fire breathing dragons getting loose and after carefully
>>>> re-reading these posts over the weekend I think I understand
>>>> the underlying issue.
>>>> 
>>>> Simply put we both take this release seriously.
>>>> 
>>>> The problem is the release process is not entirely defined.
>>>> Which is reflected in question from David Blaikie (the other
>>>> post I am quoting here).
>>>> 
>>>>> Which release process document are you referring to that
>>>>> indicates that?
>>>>> 
>>>> 
>>>> Simple answer is the one on the llvm.org website. But the
>>>> real answer is, it all depends on how you read it. 
>>>> Apparently, we read it differently which is not that 
>>>> surprising as even our well defined compilers have a bit of a
>>>> problem with undefined behavior.
>>>> 
>>>> So what can we expect from a release process document? My
>>>> hope is that we have reached a sort of sequence point and the
>>>> ambiguity of the release process can be resolved despite all
>>>> the side effects.
>>>> 
>>>> 
>>>> David also stated this:
>>>> 
>>>>> Generally, so far as I know, this kind of post-release
>>>>> change is unprecedented.
>>>> 
>>>> I agree with this conclusion but even more unprecedented is
>>>> to a expect timely and problem free release with zero and 
>>>> I'll repeat again zero involvement from the wider community
>>>> that depends on the clang+llvm! This is how the 3.2 release
>>>> has happened, just compare the list of 3.2 to 3.1 binaries
>>>> and BTW not a single 3.2 binary has been produced with the
>>>> help of a respective project, distribution or who ever.
>>>> 
>>>> I hear the cries of your wounded infrastructures and I
>>>> understand that in the days of forged root certificates my
>>>> signature on the tarballs may not guarantee much of a 
>>>> security.
>>>> 
>>>> But why didn't you get involved in the 3.2 release?
>>>> 
>>>> We could have resolved all this in the 2 months since the 3.2
>>>> release got rolling. Everybody knew about the changes for the
>>>> 3.2 release, simple e-mail to the new LLVMRM would go a long
>>>> way to resolve any security or other release related issues
>>>> not to mention a bit of a courtesy.
>>> 
>>> I don't understand how my lack of involvement with this release
>>> has anything to do with your decision to fix what appears to me
>>> to be a non-problem in the release tarball well after the
>>> release and in the process do something (replacing release
>>> tarballs) that is quite simply NOT DONE to by projects who wish
>>> to treat their downstreams with respect.  This is something
>>> many projects end up learning due to the painful way so it's
>>> not something you should feel bad about as long as the project
>>> learns the right lesson(s).
>> 
>> Yessir! - lesson learned. Right one? Depends on a point of view.
>> 
>> Seems that downstream might also learn a thing or two about 
>> participating in the release, and it does not have that painful.
> 
> On the FreeBSD ports side, I certainly could have done better, but 
> was unable to keep LLVM interactions high enough on my priority
> list. Unfortunately, the release cycle seems to be well
> synchronized with the schedule of meetings that require me to focus
> almost exclusively on hacking demos.  The version in the base
> system saw considerable testing as it was integrated into FreeBSD
> at a couple points.
> 

What I meant is that it is good to know who gets the final product
and also to get some feedback on the release before it goes out.
Staring at the web page with some links as the final product
at least for me does not seem to carry the same weight.


> Thanks for all your work on the 3.2 release.  When all is said and
> done I'm quite happy with it.

Glad to hear this!

> 
> -- Brooks
> 

Paweł