incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
Subject Re: Airflow voting on release artifacts
Date Mon, 01 May 2017 22:12:42 GMT
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" <bdbruin@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 <stain@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" <bdbruin@gmail.com> wrote:
> >
> >
> >> On 1 May 2017, at 22:39, Alex Harui <aharui@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 <aharui@adobe.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 5/1/17, 7:44 AM, "Hitesh Shah" <hitesh@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message