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" <bdbr...@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" <bdbr...@gmail.com> wrote: > > > > > >> On 1 May 2017, at 22:39, Alex Harui <aha...@adobe.com> wrote: > >> > >> > >> > >> On 5/1/17, 11:44 AM, "Bolke de Bruin" <bdbr...@gmail.com <mailto: > > bdbr...@gmail.com>> wrote: > >> > >>> > >>>> On 1 May 2017, at 17:36, Alex Harui <aha...@adobe.com> wrote: > >>>> > >>>> > >>>> > >>>> On 5/1/17, 7:44 AM, "Hitesh Shah" <hit...@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-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
