Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 99220200B8E for ; Mon, 26 Sep 2016 17:59:33 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 9794D160ACA; Mon, 26 Sep 2016 15:59:33 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id DA176160AC8 for ; Mon, 26 Sep 2016 17:59:32 +0200 (CEST) Received: (qmail 18596 invoked by uid 500); 26 Sep 2016 15:59:31 -0000 Mailing-List: contact general-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@incubator.apache.org Delivered-To: mailing list general@incubator.apache.org Received: (qmail 18585 invoked by uid 99); 26 Sep 2016 15:59:31 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Sep 2016 15:59:31 +0000 Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 324421A0329 for ; Mon, 26 Sep 2016 15:59:31 +0000 (UTC) Received: by mail-lf0-f41.google.com with SMTP id y6so147648831lff.1 for ; Mon, 26 Sep 2016 08:59:31 -0700 (PDT) X-Gm-Message-State: AA6/9Rll8p5QtJfEVZjQm4fe6xYjcJEl7ZjUD8/AMAfogelGY4apnMzVDSp7X4poiIrhVQkTY7Kpc0VCokgFxg== X-Received: by 10.194.126.196 with SMTP id na4mr7831076wjb.134.1474905569222; Mon, 26 Sep 2016 08:59:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.223.196 with HTTP; Mon, 26 Sep 2016 08:59:08 -0700 (PDT) X-Originating-IP: [130.88.195.113] In-Reply-To: References: <1960476297.769312.1474896868498@mail.yahoo.com> <1320641991.899576.1474903369034@mail.yahoo.com> From: Stian Soiland-Reyes Date: Mon, 26 Sep 2016 16:59:08 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [VOTE] Apache BatchEE 0.4-incubating To: general@incubator.apache.org Cc: Mark Struberg Content-Type: text/plain; charset=UTF-8 archived-at: Mon, 26 Sep 2016 15:59:33 -0000 I think it's sufficient if you push to dist for the 0.4 release under vote here. If you want to add the older versions to archive.apache.org then you can add them to dist and then remove them again after 24h. On 26 September 2016 at 16:52, Romain Manni-Bucau wrote: > Think you lost me a bit :s > > so here where we started the fork from: > http://apache-incubator-general.996316.n3.nabble.com/Re-DISCUSS-jbatch-impl-Apache-td36529.html > > About dist: should i push it there now or is that a todo for next release? > > > Romain Manni-Bucau > @rmannibucau | Blog > | Old Wordpress Blog > | Github | > LinkedIn | Tomitriber > | JavaEE Factory > > > 2016-09-26 17:48 GMT+02:00 Stian Soiland-Reyes : > >> I didn't want to start a git tag best practices war :) >> >> I think we agree that as long as a commit ID is in the email, and/or >> the hash of the source distribution, then we know what we're voting on >> and their location is not so important. If you want to skip those, >> then my opinion is that the release candidate must be on a >> *.apache.org server - ideally with some kind of log. >> >> >> I am flagging it mainly as I got a bit concerned when adding up >> several issues around Batchee releases - it should be easy to fix with >> a few svn commands on https://dist.apache.org/repos/dist/. >> >> The older Batchee releases are already voted over - although without >> checksums in the email - but this is the incubator so I guess they can >> just be dug out from >> https://repository.apache.org/content/repositories/releases/ >> org/apache/batchee/batchee/ >> (ode Archaeologists go check those git tags!) >> >> >> >> >> On 26 September 2016 at 16:22, Mark Struberg wrote: >> > Stian, this is established practice in the ASF since the very early days >> of playing with GIT. >> > It is used e.g. in the following TLPs: >> > TomEE >> > DeltaSpike >> > Johnzon >> > CouchDB >> > Maven >> > and many, many more! >> > >> > >> > It also got discussed on members, infra and even board lists. >> > >> > The nice thing about GIT is that it absolutely doesn't matter where I >> push the commit to as long as the sha1 of the commit later pushed to the >> ASF repo is the same. >> > >> > >> > Regarding 'pushing something different'. I trust an ASF member that he >> doesn't do that. Plus we have the sha as explained before. >> > Regarding 'not getting pushed at all': This would get catched pretty >> quickly as we would miss the version update ;) >> > >> > >> > Also bear in mind that ASF projects do NOT vote on the tags nor branches >> - we solely vote on the release source distributable! >> > >> > >> > >> >> branches are there to be created and removed again >> > Branches in GIT _cannot_ get removed from any downstream repo! >> > >> > That's the whole point. And if you do RCs, then you actually would have >> to later do a NEW vote again with the 'RC' removed from the version. But >> who guarantees that the source tarball is the same now? What if someone >> changed the source in the meantime? You see, it also has flaws. >> > >> >> Perhaps "git tag --sign" so you get a PGP-signed tag commit >> > >> >> would be a good idea? >> > >> > Agree, would be a good idea! >> > It happens that I wrote the Maven GIT integration somewhen in the >> 2000s... ;) >> > >> > We don't have the tagging feature yet. Could you please file a ticket >> against Maven SCM? >> > >> > >> > txs and LieGrue, >> > strub >> > >> > >> > >> > >> >> On Monday, 26 September 2016, 16:34, Stian Soiland-Reyes < >> stain@apache.org> wrote: >> >> > On 26 September 2016 at 14:34, Mark Struberg >> >> >> wrote: >> >>> We *never* push commits for in-progress votes to hte ASF repos when >> we use >> >> GIT! >> >>> The reason is that we cannot get rid of those afterwards! Of course >> we can >> >> delete the branch/tag/commit from the ASF repo, but we cannot delete >> them from >> >> all the hundreds downstream repos which almost immediately pull those >> changes... >> >>> >> >>> You can think of pushing this to a private (but PMC owned!) github >> repo as >> >> kind of parallel to the Maven 'staging' process. >> >> >> >> Of course it is up to each project what particular release/tag >> >> practice they want to follow. Many projects do this classically even >> >> with git, e.g. using branches or tags like 0.4-RC1 - see for instance: >> >> >> >> https://lists.apache.org/list.html?dev@jena.apache.org:lte=10M:VOTE >> >> >> >> Some communities like Apache Commons even keep around all RC tags; >> >> then archived emails around failed RCs still have valid links - e.g. >> >> https://github.com/apache/commons-lang/releases >> >> >> >> I wouldn't personally see a problem with a RC branch showing up in >> >> forked repositories - branches are there to be created and removed >> >> again - if downstream want to keep them for archival purposes that's >> >> their choice - just like they can keep the commit emails. >> >> >> >> >> >> But if that's not your project's cup of tea, then I guess just a >> >> commit IDs and hashes in the email should work, no matter where the >> >> commit 'is' - in git the commit is hashed and it's not forgotten >> >> after >> >> the vote is passed. >> >> >> >> Perhaps "git tag --sign" so you get a PGP-signed tag commit would be a >> >> good idea? >> >> >> >> >> >> Without the commit ID or hashes in the email - then particularly for >> >> mutable release candidates tags hosted in third-party repositories, we >> >> don't have a record over exactly what was voted on and the commiter >> >> could easily by mistake push the 'wrong' RC commits or dists without >> >> anyone being able to notice or check later. In fact, this very vote >> >> shows two different commit IDs which this time luckily had the same >> >> content. >> >> >> >> Many projects posts RCs on https://dist.apache.org/repos/dist/dev/ - >> >> which is SVN-based - here the revision number and log is sufficient - >> >> we assume the ASF-hosted SVN repository to be 'trusted'. A closed >> >> Nexus repository is similarly tracked and immutable. >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> Stian Soiland-Reyes >> >> http://orcid.org/0000-0001-9842-9718 >> >> >> >> >> >> -- >> Stian Soiland-Reyes >> http://orcid.org/0000-0001-9842-9718 >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org >> For additional commands, e-mail: general-help@incubator.apache.org >> >> -- Stian Soiland-Reyes http://orcid.org/0000-0001-9842-9718 --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.org