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

Anton Korobeynikov anton at korobeynikov.info
Sun Jan 13 08:31:09 PST 2013


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

With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

More information about the llvm-dev mailing list