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" <hit...@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 <aha...@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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
