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