On 5/1/17, 11:44 AM, "Bolke de Bruin" <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. HTH, -Alex
