llvm dev - Jan 2013 - [LLVMdev] Obsolete PTX is NOT completely removed in 3.2 release

Pawel,

First, all your help with the 3.2 release is greatly appreciated. I do not think
anyone is saying otherwise.

I apologize for the lack of documentation regarding this issue. I do ask that
you consult with previous release manager (myself or Bill) to determine what the
best course of action is. There is a lot of room to improve our release process,
but its a collaborative effort.

You are correct that we do not do "dot" releases. There has long been
debate on this and we just don't have the man power to accomplish such a
task. This is why we have a relatively short release process.

However, we do not change the tarballs after the release has been
"shipped". I remember once we did have a critical issue that caused us
to a quick "reship" of a tarball, but we labeled it 3.Xa" to
denote the new tarball.

So I ask that the changes be reverted and then hopefully we can just move
forward from this misunderstanding.

Thank you again for your hard work here,

Tanya


On Jan 13, 2013, at 11:10 AM, Pawel Wodnicki <root at 32bitmicro.com>
wrote:
> Anton,
> 
>> Pawel,
>> 
>> We all understand that you're pretty new to release process, etc.,
but
>> I think you should understand the implications of your actions.
>> 
>> You just created a lot of harm for really huge pile of users - the
>> ones who downloads the tarball via some automated build system and
>> rely on the known good checksum. This includes, but not limited to to
>> the users of FreeBSD, Gentoo, etc.
>> 
>> Even worse, you did this silently. Without any announcement, with any
>> e-mail to llvm-dev, etc. And all this at the same time when people do
>> wide announcement for e.g. 30 mins of restart of buildbot master ro 10
>> minute restart of web server.
>> 
>> What you did it definitely inacceptable for release manager of such
>> big project as LLVM. So, may I kindly ask you to revert the tarball
>> back within next 24 hours an write and entry to New section on the
>> website. If you want to include the changes name them 3.2.1 or 3.2a
>> and write an entry on the website. This is the only way how you can
>> fix all the weird stuff you done in a moment.
> 
> 
> All I can say is if you did not get involved in the release but you
> depend on it don't cry wolf now.
> 
> Before we get any more personal read carefully my reply to Brooks
> message.
> 
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058088.html
> 
> Paweł
> 
>> 
>> All: If anyone has the old taball + sig please let me know where I can
>> download them to replace the current ones if Pawel will fail to do so.
>> 
>> On Sat, Jan 12, 2013 at 12:59 AM, Pawel Wodnicki <root at
32bitmicro.com> wrote:
>>> On 1/11/2013 2:51 PM, Justin Holewinski wrote:
>>>> On Fri, Jan 11, 2013 at 3:47 PM, Pawel Wodnicki <root at
32bitmicro.com> 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?
>>>>> 
>>>> 
>>>> Many of these environments rely on checking against a
known-good checksum.
>>>> If a tarball is replaced at the source, that checksum changes. 
Once a
>>>> release is cut, that particular release should never change. 
If a change
>>>> is necessary, some sort of point release (3.2.1) is preferable,
so anyone
>>>> wanting 3.2 still gets the old binary with the old checksum.
>>> 
>>> Current process does not have any provision for any more releases
>>> beyond 3.2.
>>> 
>>> Frankly, anybody who depends on the release should have been
>>> involved in it during RC1,RC2 or RC3 at the latest.
>>> 
>>> Paweł
>>> 
>>>> 
>>>> 
>>>>> 
>>>>>> 
>>>>>> -- Brooks
>>>>>> 
>>>>> 
>>>>> Paweł
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> 
>> 
>> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Tanya,
> Pawel,
> 
> First, all your help with the 3.2 release is greatly appreciated. I do not
think anyone is saying otherwise.
 Nothing was said so nothing to worry about.
> 
> I apologize for the lack of documentation regarding this issue. I do ask
that you consult with previous release manager (myself or Bill) to determine
what the best course of action is. There is a lot of room to improve our release
process, but its a collaborative effort.
> 
 No need to apologize for anything, the were a lot of changes for the
3.2 release and not everything can be captured in process documentation.
Bill spent a lot time giving me pointers on the release which I really
appreciate. However, if I am managing the release then I take full
responsibility for the decisions. At the same time one can reasonably
expect that anybody who is depending on the release would at least
contact release manager before the release happens!

 Which brings us to the collaborative effort. I was working with this
assumption but it turned out to be not what really happened.
Frankly there was no collaborative effort!

 Not a single, I'll repeat again not a single project or OS that
supposedly critically depends on the clang+llvm distribution
has helped with the release, either testing or building
binaries or just letting me know they exist!

 I think this is the real problem.

> You are correct that we do not do "dot" releases. There has long
been debate on this and we just don't have the man power to accomplish such
a task. This is why we have a relatively short release process.
> 
> However, we do not change the tarballs after the release has been
"shipped". I remember once we did have a critical issue that caused us
to a quick "reship" of a tarball, but we labeled it 3.Xa" to
denote the new tarball.
> 
> So I ask that the changes be reverted and then hopefully we can just move
forward from this misunderstanding.
> 
 It was not a misunderstanding, I have made a decision to re-ship
based on the information I had at the time. What is interesting
is that the timing of my commit was such that it has got almost
immediately out before I had a chance to send the announcement.

 Anyway, both versions of the tarball are available from the the SVN.
I do not see a technical reason of not being able to pull one or the
other. At this point reverting the commit might cause even more "harm"
then good so perhaps we should consult this with wider LLVM community.

Considering that my role as LLVMRM has effectively ended on Dec 21st
I will be happy to "finalize" the release once we reach a consensus.

> Thank you again for your hard work here,
> 
> Tanya
> 
Paweł

Hi Pawel,

  Sorry for the trouble. At first I think maybe we can upload a new
release tarball not replacing it, sorry I didn't say it in the previous
mail. IMHO, if you have to do something new after the post-release, make
a "dot" release would be better. Perhaps you can write down this
experience to benifit other LLVMRM in the future. :-)

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj