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 Mon, 01 May 2017 22:49:22 GMT


On 5/1/17, 2:00 PM, "Bolke de Bruin" <bdbruin@gmail.com> wrote:
>
>In Python we are used to install through so called source distributions
>“sdist”. Package managers (e.g. pip) use the filename to determine
>whether to download a new package and if they do they examine the
>contents of the package to find out it they need to install the package.
>They do this by examining the version contained inside the package. Thus
>while a different filename will trigger a new download, it might not
>install updated parts of the package. This is different from your example
>as no installer is examining both the name of the tar ball and the
>contents of your javascript files for a version identifier.
>
>But maybe you have a point. We could just do a "git clone”, update the
>version (not push it to git until final release), tar it. We then ask
>people to vote on it. Then we could provide the convenience package (that
>everyone will use) next to it. Or if we consider the “sdist” a binary
>release officially we vote on that one as well after the first vote. Two
>downsides to this are: if only option 1) nobody would user the tar, as
>the sdist is essentially the same and works with the package managers.
>Might be a bit excessive? 2) that would be a 2+2 vote again.
>
>Option 1 could work, it isn’t ideal, but will satisfy the procedure.

Many projects produce two packages: the actual sources, and something most
customers want to use.  The main reason ASF projects focus on the source
is because we are an "Open Source" foundation, but also because you can
verify that a source package isn't infected by a virus more easily than
reviewing other kinds of files.  AIUI, there are customers who are
concerned enough about the safety of a release that they only work with
source packages and compile everything from source.  So, whatever you call
your "source" package that is officially voted on must meet this criteria.

The customer package can be collection of files, but it must meet certain
requirements like having a LICENSE and NOTICE and detached signature that
the voters verify.

Many release examiners want to verify the source package against a Git
hash or SVN tag. That isn't a "must do", but a good thing if you can do
it.  So, I'm not sure delaying pushing the tag is a good idea.  What we do
in our project is pick whatever hash is the point in history for the
release and tag is as RC1, then when the vote passes, tag whatever hash
finally passes with the release tag.

So, if an sdist is entirely source, IMO, you can just make two sdist
packages (one for customers and one with "RC1" appended to the version
number) and offer both to the voters.  If the voters can easily validate
that the RC1 version they test is essentially the same as the other
package, then I think you are good to go.

HTH,
-Alex

Mime
View raw message