You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Hitesh Shah <hi...@apache.org> on 2017/05/01 14:44:28 UTC
Re: Airflow voting on release artifacts
Hi Justin,
Currently, the podling has been modifying the contents and hence this
discussion.
thanks
-- Hitesh
On Thu, Apr 27, 2017 at 8:48 PM, Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > 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.
>
> How are the artefacts modified after the vote?
>
> IMO As long as the hashes and signature are the same there is no issue. If
> any of the contents change, rather than just files names, then it would no
> longer be a valid release.
>
> If it is just a rename, a safer way to rename the file this would be to do
> so when you do the svn move from dev staging area to the release area.
>
> Thanks,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Airflow voting on release artifacts
Posted by Alex Harui <ah...@adobe.com>.
On 5/1/17, 2:00 PM, "Bolke de Bruin" <bd...@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
Re: Airflow voting on release artifacts
Posted by Niclas Hedhman <ni...@hedhman.org>.
I think the problem is lying with "users cannot tell the difference"...
Possibly that the term "release candidate" is not aligned/defined along the
same semantics.
"Users", as in outside the committers, are NOT to download any
source/binary artifacts up for a vote. Before the vote artifacts are not to
be publicly available, such as on dist.apache.org or Python's global/public
repositories (which I blatantly assumes exist and pip works against those),
nor are committers expected to put these artifacts on local repositories
(also assuming those are possible).
"Committers", on the other hand are EXPECTED to understand what a release
candidate is, how it is treated and how it is discarded after the vote
(whether it passes or not, should not matter).
HTH
NIclas
On Tue, May 2, 2017 at 6:01 AM, Bolke de Bruin <bd...@gmail.com> wrote:
> Yes you can, but how do we verify it actually happened? Maven will, afaik,
> happily upgrade “apache-beam-1.0.0rc2” to “apache-beam-1.0.0” although they
> contain the exact same artefact. Pip won’t do that.
>
> If we use a release candidate named “apache-airflow-1.8.1rc2” while the
> package requires us to contain “apache-airflow-1.8.1” users cannot tell the
> difference if they installed RC2 or if it was the actual release. Worse
> even, we cannot tell the difference anymore. Then we just need to wait for
> the confusion in the bug reports.
>
> B.
>
> > On 1 May 2017, at 23:42, Stian Soiland-Reyes <st...@apache.org> wrote:
> >
> > Sorry for my ignorance, but is there no easy way with pip to uninstall
> the
> > package or force-install a new RC?
> >
> > If a previous RC failed the vote, then it should be uninstalled by
> everyone
> > anyway. In fact if you test a RC by installing it globally, then you
> should
> > always uninstall it after testing as you don't know the result of the
> vote
> > yet and should revert to the latest official release (or your own build
> > from scm).
> >
> > This is no different from Java/Maven - if you happen to test an RC by
> "mvn
> > install" (instead of "mvn verify") then you need to clean it out
> > afterwards. There is no easy command for it in mvn, although you can
> > usually just rm -rf the corresponding folder in .m2/repository.
> >
> >
> >
> > On 1 May 2017 10:00 pm, "Bolke de Bruin" <bd...@gmail.com> wrote:
> >
> >
> >> On 1 May 2017, at 22:39, Alex Harui <ah...@adobe.com> wrote:
> >>
> >>
> >>
> >> On 5/1/17, 11:44 AM, "Bolke de Bruin" <bdbruin@gmail.com <mailto:
> > bdbruin@gmail.com>> wrote:
> >>
> >>>
> >>>> On 1 May 2017, at 17:36, Alex Harui <ah...@adobe.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 5/1/17, 7:44 AM, "Hitesh Shah" <hi...@apache.org> wrote:
> >>>>
> >>>>> Hi Justin,
> >>>>>
> >>>>> Currently, the podling has been modifying the contents and hence this
> >>>>> discussion.
> >>>>
> >>>> I agree with Justin and others that modification after the vote is
> not a
> >>>> good thing. So my assumption was that if you add your 2a step and
> >>>> modify
> >>>> the binary before the vote, it will be acceptable. IMO, all you need
> >>>> is a
> >>>> way to verify that the binary the voters test is essentially the same
> as
> >>>> the binary you want to actually release.
> >>>>
> >>>> -Alex
> >>>>
> >>>>
> >>>
> >>> Hi Alex,
> >>>
> >>> As mentioned earlier this is not possible in a clean way. Version
> >>> information is contained within the source package and it is required
> by
> >>> specification to be. Installation happens from this source package.
> There
> >>> are no “binaries”.
> >>>
> >>> We understand the need to vote on the artefacts, however the way it is
> >>> required to work put us between a rock and a hard place: either our
> users
> >>> can end up with an outdated pre-release while reporting they have the
> >>> release installed or we need to vote 2+2 times (PMC+IPMC).
> >>>
> >>> We are looking to optimize this process either technically or
> >>> procedurally, but until so far haven’t been able to distill anything
> that
> >>> really helps.
> >>
> >> Well, I'm quite confused now. Hitesh seems to say there are binaries.
> >> And I have proposed a couple of ideas where you create different
> artifacts
> >> for voters vs. customers that I think get around all of these issues.
> >> AFAIK, nobody on this list has objected to those proposals.
> >>
> >> Maybe there is something about Python I don't understand, but if I had
> to
> >> ship a set of Javascript files with an embedded version number in one of
> >> those files, I would use what I proposed. AFAICT, there is no
> obligation
> >> to make your customers (not your voters) consume the source package, it
> >> just has to be possible to generate what the customers use from the
> source
> >> package.
> >>
> >
> > 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.
> >
> > Bolke.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: Airflow voting on release artifacts
Posted by Stian Soiland-Reyes <st...@apache.org>.
I understand that concern. Why do you think your users install release
candidates under vote? It might be time to think about splitting out a
users@ list?
Perhaps you can expand the instructions in the VOTE email with the exact
commands to install and uninstall, or a special test script that enforces
use of virtualenv for instance. With a larger community the VOTE emails
need to be more guiding for expectation management.
On 1 May 2017 11:01 pm, "Bolke de Bruin" <bd...@gmail.com> wrote:
> Yes you can, but how do we verify it actually happened? Maven will, afaik,
> happily upgrade “apache-beam-1.0.0rc2” to “apache-beam-1.0.0” although they
> contain the exact same artefact. Pip won’t do that.
>
> If we use a release candidate named “apache-airflow-1.8.1rc2” while the
> package requires us to contain “apache-airflow-1.8.1” users cannot tell the
> difference if they installed RC2 or if it was the actual release. Worse
> even, we cannot tell the difference anymore. Then we just need to wait for
> the confusion in the bug reports.
>
> B.
>
> > On 1 May 2017, at 23:42, Stian Soiland-Reyes <st...@apache.org> wrote:
> >
> > Sorry for my ignorance, but is there no easy way with pip to uninstall
> the
> > package or force-install a new RC?
> >
> > If a previous RC failed the vote, then it should be uninstalled by
> everyone
> > anyway. In fact if you test a RC by installing it globally, then you
> should
> > always uninstall it after testing as you don't know the result of the
> vote
> > yet and should revert to the latest official release (or your own build
> > from scm).
> >
> > This is no different from Java/Maven - if you happen to test an RC by
> "mvn
> > install" (instead of "mvn verify") then you need to clean it out
> > afterwards. There is no easy command for it in mvn, although you can
> > usually just rm -rf the corresponding folder in .m2/repository.
> >
> >
> >
> > On 1 May 2017 10:00 pm, "Bolke de Bruin" <bd...@gmail.com> wrote:
> >
> >
> >> On 1 May 2017, at 22:39, Alex Harui <ah...@adobe.com> wrote:
> >>
> >>
> >>
> >> On 5/1/17, 11:44 AM, "Bolke de Bruin" <bdbruin@gmail.com <mailto:
> > bdbruin@gmail.com>> wrote:
> >>
> >>>
> >>>> On 1 May 2017, at 17:36, Alex Harui <ah...@adobe.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 5/1/17, 7:44 AM, "Hitesh Shah" <hi...@apache.org> wrote:
> >>>>
> >>>>> Hi Justin,
> >>>>>
> >>>>> Currently, the podling has been modifying the contents and hence this
> >>>>> discussion.
> >>>>
> >>>> I agree with Justin and others that modification after the vote is
> not a
> >>>> good thing. So my assumption was that if you add your 2a step and
> >>>> modify
> >>>> the binary before the vote, it will be acceptable. IMO, all you need
> >>>> is a
> >>>> way to verify that the binary the voters test is essentially the same
> as
> >>>> the binary you want to actually release.
> >>>>
> >>>> -Alex
> >>>>
> >>>>
> >>>
> >>> Hi Alex,
> >>>
> >>> As mentioned earlier this is not possible in a clean way. Version
> >>> information is contained within the source package and it is required
> by
> >>> specification to be. Installation happens from this source package.
> There
> >>> are no “binaries”.
> >>>
> >>> We understand the need to vote on the artefacts, however the way it is
> >>> required to work put us between a rock and a hard place: either our
> users
> >>> can end up with an outdated pre-release while reporting they have the
> >>> release installed or we need to vote 2+2 times (PMC+IPMC).
> >>>
> >>> We are looking to optimize this process either technically or
> >>> procedurally, but until so far haven’t been able to distill anything
> that
> >>> really helps.
> >>
> >> Well, I'm quite confused now. Hitesh seems to say there are binaries.
> >> And I have proposed a couple of ideas where you create different
> artifacts
> >> for voters vs. customers that I think get around all of these issues.
> >> AFAIK, nobody on this list has objected to those proposals.
> >>
> >> Maybe there is something about Python I don't understand, but if I had
> to
> >> ship a set of Javascript files with an embedded version number in one of
> >> those files, I would use what I proposed. AFAICT, there is no
> obligation
> >> to make your customers (not your voters) consume the source package, it
> >> just has to be possible to generate what the customers use from the
> source
> >> package.
> >>
> >
> > 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.
> >
> > Bolke.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Airflow voting on release artifacts
Posted by Bolke de Bruin <bd...@gmail.com>.
Yes you can, but how do we verify it actually happened? Maven will, afaik, happily upgrade “apache-beam-1.0.0rc2” to “apache-beam-1.0.0” although they contain the exact same artefact. Pip won’t do that.
If we use a release candidate named “apache-airflow-1.8.1rc2” while the package requires us to contain “apache-airflow-1.8.1” users cannot tell the difference if they installed RC2 or if it was the actual release. Worse even, we cannot tell the difference anymore. Then we just need to wait for the confusion in the bug reports.
B.
> On 1 May 2017, at 23:42, Stian Soiland-Reyes <st...@apache.org> wrote:
>
> Sorry for my ignorance, but is there no easy way with pip to uninstall the
> package or force-install a new RC?
>
> If a previous RC failed the vote, then it should be uninstalled by everyone
> anyway. In fact if you test a RC by installing it globally, then you should
> always uninstall it after testing as you don't know the result of the vote
> yet and should revert to the latest official release (or your own build
> from scm).
>
> This is no different from Java/Maven - if you happen to test an RC by "mvn
> install" (instead of "mvn verify") then you need to clean it out
> afterwards. There is no easy command for it in mvn, although you can
> usually just rm -rf the corresponding folder in .m2/repository.
>
>
>
> On 1 May 2017 10:00 pm, "Bolke de Bruin" <bd...@gmail.com> wrote:
>
>
>> On 1 May 2017, at 22:39, Alex Harui <ah...@adobe.com> wrote:
>>
>>
>>
>> On 5/1/17, 11:44 AM, "Bolke de Bruin" <bdbruin@gmail.com <mailto:
> bdbruin@gmail.com>> wrote:
>>
>>>
>>>> On 1 May 2017, at 17:36, Alex Harui <ah...@adobe.com> wrote:
>>>>
>>>>
>>>>
>>>> On 5/1/17, 7:44 AM, "Hitesh Shah" <hi...@apache.org> wrote:
>>>>
>>>>> Hi Justin,
>>>>>
>>>>> Currently, the podling has been modifying the contents and hence this
>>>>> discussion.
>>>>
>>>> I agree with Justin and others that modification after the vote is not a
>>>> good thing. So my assumption was that if you add your 2a step and
>>>> modify
>>>> the binary before the vote, it will be acceptable. IMO, all you need
>>>> is a
>>>> way to verify that the binary the voters test is essentially the same as
>>>> the binary you want to actually release.
>>>>
>>>> -Alex
>>>>
>>>>
>>>
>>> Hi Alex,
>>>
>>> As mentioned earlier this is not possible in a clean way. Version
>>> information is contained within the source package and it is required by
>>> specification to be. Installation happens from this source package. There
>>> are no “binaries”.
>>>
>>> We understand the need to vote on the artefacts, however the way it is
>>> required to work put us between a rock and a hard place: either our users
>>> can end up with an outdated pre-release while reporting they have the
>>> release installed or we need to vote 2+2 times (PMC+IPMC).
>>>
>>> We are looking to optimize this process either technically or
>>> procedurally, but until so far haven’t been able to distill anything that
>>> really helps.
>>
>> Well, I'm quite confused now. Hitesh seems to say there are binaries.
>> And I have proposed a couple of ideas where you create different artifacts
>> for voters vs. customers that I think get around all of these issues.
>> AFAIK, nobody on this list has objected to those proposals.
>>
>> Maybe there is something about Python I don't understand, but if I had to
>> ship a set of Javascript files with an embedded version number in one of
>> those files, I would use what I proposed. AFAICT, there is no obligation
>> to make your customers (not your voters) consume the source package, it
>> just has to be possible to generate what the customers use from the source
>> package.
>>
>
> 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.
>
> Bolke.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Airflow voting on release artifacts
Posted by Stian Soiland-Reyes <st...@apache.org>.
Sorry for my ignorance, but is there no easy way with pip to uninstall the
package or force-install a new RC?
If a previous RC failed the vote, then it should be uninstalled by everyone
anyway. In fact if you test a RC by installing it globally, then you should
always uninstall it after testing as you don't know the result of the vote
yet and should revert to the latest official release (or your own build
from scm).
This is no different from Java/Maven - if you happen to test an RC by "mvn
install" (instead of "mvn verify") then you need to clean it out
afterwards. There is no easy command for it in mvn, although you can
usually just rm -rf the corresponding folder in .m2/repository.
On 1 May 2017 10:00 pm, "Bolke de Bruin" <bd...@gmail.com> wrote:
> On 1 May 2017, at 22:39, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 5/1/17, 11:44 AM, "Bolke de Bruin" <bdbruin@gmail.com <mailto:
bdbruin@gmail.com>> wrote:
>
>>
>>> On 1 May 2017, at 17:36, Alex Harui <ah...@adobe.com> wrote:
>>>
>>>
>>>
>>> On 5/1/17, 7:44 AM, "Hitesh Shah" <hi...@apache.org> wrote:
>>>
>>>> Hi Justin,
>>>>
>>>> Currently, the podling has been modifying the contents and hence this
>>>> discussion.
>>>
>>> I agree with Justin and others that modification after the vote is not a
>>> good thing. So my assumption was that if you add your 2a step and
>>> modify
>>> the binary before the vote, it will be acceptable. IMO, all you need
>>> is a
>>> way to verify that the binary the voters test is essentially the same as
>>> the binary you want to actually release.
>>>
>>> -Alex
>>>
>>>
>>
>> Hi Alex,
>>
>> As mentioned earlier this is not possible in a clean way. Version
>> information is contained within the source package and it is required by
>> specification to be. Installation happens from this source package. There
>> are no “binaries”.
>>
>> We understand the need to vote on the artefacts, however the way it is
>> required to work put us between a rock and a hard place: either our users
>> can end up with an outdated pre-release while reporting they have the
>> release installed or we need to vote 2+2 times (PMC+IPMC).
>>
>> We are looking to optimize this process either technically or
>> procedurally, but until so far haven’t been able to distill anything that
>> really helps.
>
> Well, I'm quite confused now. Hitesh seems to say there are binaries.
> And I have proposed a couple of ideas where you create different artifacts
> for voters vs. customers that I think get around all of these issues.
> AFAIK, nobody on this list has objected to those proposals.
>
> Maybe there is something about Python I don't understand, but if I had to
> ship a set of Javascript files with an embedded version number in one of
> those files, I would use what I proposed. AFAICT, there is no obligation
> to make your customers (not your voters) consume the source package, it
> just has to be possible to generate what the customers use from the source
> package.
>
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.
Bolke.
Re: Airflow voting on release artifacts
Posted by Bolke de Bruin <bd...@gmail.com>.
> On 1 May 2017, at 22:39, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 5/1/17, 11:44 AM, "Bolke de Bruin" <bdbruin@gmail.com <ma...@gmail.com>> wrote:
>
>>
>>> On 1 May 2017, at 17:36, Alex Harui <ah...@adobe.com> wrote:
>>>
>>>
>>>
>>> On 5/1/17, 7:44 AM, "Hitesh Shah" <hi...@apache.org> wrote:
>>>
>>>> Hi Justin,
>>>>
>>>> Currently, the podling has been modifying the contents and hence this
>>>> discussion.
>>>
>>> I agree with Justin and others that modification after the vote is not a
>>> good thing. So my assumption was that if you add your 2a step and
>>> modify
>>> the binary before the vote, it will be acceptable. IMO, all you need
>>> is a
>>> way to verify that the binary the voters test is essentially the same as
>>> the binary you want to actually release.
>>>
>>> -Alex
>>>
>>>
>>
>> Hi Alex,
>>
>> As mentioned earlier this is not possible in a clean way. Version
>> information is contained within the source package and it is required by
>> specification to be. Installation happens from this source package. There
>> are no “binaries”.
>>
>> We understand the need to vote on the artefacts, however the way it is
>> required to work put us between a rock and a hard place: either our users
>> can end up with an outdated pre-release while reporting they have the
>> release installed or we need to vote 2+2 times (PMC+IPMC).
>>
>> We are looking to optimize this process either technically or
>> procedurally, but until so far haven’t been able to distill anything that
>> really helps.
>
> Well, I'm quite confused now. Hitesh seems to say there are binaries.
> And I have proposed a couple of ideas where you create different artifacts
> for voters vs. customers that I think get around all of these issues.
> AFAIK, nobody on this list has objected to those proposals.
>
> Maybe there is something about Python I don't understand, but if I had to
> ship a set of Javascript files with an embedded version number in one of
> those files, I would use what I proposed. AFAICT, there is no obligation
> to make your customers (not your voters) consume the source package, it
> just has to be possible to generate what the customers use from the source
> package.
>
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.
Bolke.
Re: Airflow voting on release artifacts
Posted by Alex Harui <ah...@adobe.com>.
On 5/1/17, 11:44 AM, "Bolke de Bruin" <bd...@gmail.com> wrote:
>
>> On 1 May 2017, at 17:36, Alex Harui <ah...@adobe.com> wrote:
>>
>>
>>
>> On 5/1/17, 7:44 AM, "Hitesh Shah" <hi...@apache.org> wrote:
>>
>>> Hi Justin,
>>>
>>> Currently, the podling has been modifying the contents and hence this
>>> discussion.
>>
>> I agree with Justin and others that modification after the vote is not a
>> good thing. So my assumption was that if you add your 2a step and
>>modify
>> the binary before the vote, it will be acceptable. IMO, all you need
>>is a
>> way to verify that the binary the voters test is essentially the same as
>> the binary you want to actually release.
>>
>> -Alex
>>
>>
>
>Hi Alex,
>
>As mentioned earlier this is not possible in a clean way. Version
>information is contained within the source package and it is required by
>specification to be. Installation happens from this source package. There
>are no “binaries”.
>
>We understand the need to vote on the artefacts, however the way it is
>required to work put us between a rock and a hard place: either our users
>can end up with an outdated pre-release while reporting they have the
>release installed or we need to vote 2+2 times (PMC+IPMC).
>
>We are looking to optimize this process either technically or
>procedurally, but until so far haven’t been able to distill anything that
>really helps.
Well, I'm quite confused now. Hitesh seems to say there are binaries.
And I have proposed a couple of ideas where you create different artifacts
for voters vs. customers that I think get around all of these issues.
AFAIK, nobody on this list has objected to those proposals.
Maybe there is something about Python I don't understand, but if I had to
ship a set of Javascript files with an embedded version number in one of
those files, I would use what I proposed. AFAICT, there is no obligation
to make your customers (not your voters) consume the source package, it
just has to be possible to generate what the customers use from the source
package.
HTH,
-Alex
Re: Airflow voting on release artifacts
Posted by Bolke de Bruin <bd...@gmail.com>.
> On 1 May 2017, at 17:36, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 5/1/17, 7:44 AM, "Hitesh Shah" <hi...@apache.org> wrote:
>
>> Hi Justin,
>>
>> Currently, the podling has been modifying the contents and hence this
>> discussion.
>
> I agree with Justin and others that modification after the vote is not a
> good thing. So my assumption was that if you add your 2a step and modify
> the binary before the vote, it will be acceptable. IMO, all you need is a
> way to verify that the binary the voters test is essentially the same as
> the binary you want to actually release.
>
> -Alex
>
>
Hi Alex,
As mentioned earlier this is not possible in a clean way. Version information is contained within the source package and it is required by specification to be. Installation happens from this source package. There are no “binaries”.
We understand the need to vote on the artefacts, however the way it is required to work put us between a rock and a hard place: either our users can end up with an outdated pre-release while reporting they have the release installed or we need to vote 2+2 times (PMC+IPMC).
We are looking to optimize this process either technically or procedurally, but until so far haven’t been able to distill anything that really helps.
Cheers
Bolke
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Airflow voting on release artifacts
Posted by Alex Harui <ah...@adobe.com>.
On 5/1/17, 7:44 AM, "Hitesh Shah" <hi...@apache.org> wrote:
>Hi Justin,
>
>Currently, the podling has been modifying the contents and hence this
>discussion.
I agree with Justin and others that modification after the vote is not a
good thing. So my assumption was that if you add your 2a step and modify
the binary before the vote, it will be acceptable. IMO, all you need is a
way to verify that the binary the voters test is essentially the same as
the binary you want to actually release.
-Alex