incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Airflow voting on release artifacts
Date Thu, 27 Apr 2017 23:38:49 GMT
I'm not on the IPMC, so I don't have an official vote, but for me, it
would be ok if you include step 2a and the voters have a way to validate
that the 1.8.1rc1 binary they tested is "the same"=="identical except for
version numbers" as the 1.8.1 binaries you want to distribute to customers.

Also, I believe the source package build script must be able to reproduce
the 1.8.1 binary you want to distribute to customers.

So if you can do that I would hope the IPMC would approve.

-Alex

On 4/27/17, 3:57 PM, "Hitesh Shah" <hitesh@apache.org> wrote:

>Hi folks,
>
>Given that the source bits are the official release, would it be okay if
>the community as a whole decided on say the following approach:
>
>1) Bundle source with version set to 1.8.1
>2) Bundle binary convenience artifacts built using version set to 1.8.1rc1
>3) Publish source and binary bits to dist.a.o/dev for vote
>4) If vote passes, publish the source tarball that was voted upon and
>"modified" binary convenience artifacts built with version set to 1.8.1
>
>The implication here is that the release manager is being trusted by the
>PMC to release the modified convenience artifacts from the voted-upon
>source without a new vote.
>
>If it helps, there are a couple of variations of the above which could be
>applied to reduce the no. of total votes:
>
>2a) Create 2 binary sets for the vote - one with version 1.8.1rc1 and
>other
>with version 1.8.1 ( with only 1.8.1 being published on a successful vote)
>
>OR
>
>4a) After PPMC vote passes, use the original source and modified binaries
>for the IPMC vote and therefore the IPMC vote is on the final bits being
>published.
>
>Any comments?
>
>thanks
>-- Hitesh
>
>
>On Tue, Apr 25, 2017 at 9:02 PM, Alex Harui <aharui@adobe.com> wrote:
>
>>
>>
>> >
>> >3. There is no “separate” build script. Pip will just install a binary
>> >(“wheel”) or uses the source package (as shown above). Both are used
>> >interchangeable by users. We only distribute source packages at the
>> >moment.
>> >
>> >@Alex: I have to think a little bit more about what you wrote, but it
>>is
>> >currently confusing the hell out of me :). Furthermore, I am not sure
>>if
>> >it applies considering the above #3.
>>
>> It could still apply.  You would just have to add a build script that
>> renames the package and metadata.
>>
>> Let's say I wanted to release a single file that reported the version
>> number.  Forgive me that I don't know Python so I just grabbed what I
>> think it would look like from the internet.
>>
>> ---MyRelease.py---
>> print("I am version 1.2.3.")
>>
>> Let's assume this is what your "customers" want to use.
>>
>> I am proposing that the Apache Source Package also contain the following
>> file:
>>
>> ---BuildScript.sh---
>> # creates Customer Package in out folder.
>> mkdir out
>> sed s/1.2.3/1.2.3$1/ < MyRelease.py > out/MyRelease$1.py
>>
>> Voters would run:
>>
>>    BuildScript.sh RC1
>>
>> That would result in:
>>
>> ---out/MyReleaseRC1.py---
>> print("I am version 1.2.3RC1.")
>>
>> And this version would be tested by the voters.  The source package
>>being
>> voted on contains the original MyRelease.py and BuildScript.sh.  The
>> release manager would also run:
>>
>>
>>     BuildScript.sh
>>
>> That would result in:
>>
>> ---out/MyRelease.py---
>> print("I am version 1.2.3.")
>>
>> In our project, the RM posts the source package in the RC folder and
>> creates a folder called "binaries" for the compiled source.  You could
>> call the folder something else, but let's keep the names for now.  The
>>RM
>> would copy a zip of MyRelease.py and BuildScript.sh (and LICENSE,
>>NOTICE,
>> README) into the RC folder and out/MyRelease.py to the "binaries"
>>folder.
>> Along with signatures and checksum files.
>>
>>
>> Voters would download the zip, expand it, run "BuildScript.sh RC1" and
>> test with their out/MyReleaseRC1.py.  They would examine the zip to make
>> sure it is compliant with Apache release policy.  This is what all other
>> voters on all other projects generally do.  But they would perform one
>> different step, which is, instead of testing the MyRelease.py in the
>> "binaries" folder, they would simply diff their MyReleaseRC1.py against
>> the MyRelease.py in the "binaries" folder.  If the only diffs are the
>> version, they should feel satisfied that the resulting "customer"
>>packages
>> is ok for release.
>>
>> Of course, I could be wrong...
>>
>> HTH,
>> -Alex
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Mime
View raw message