Re: [VOTE] Apache Geode (incubating) 1.0.0-incubating.M3 release

[Konstantin Boudnik]

+1 (binding)

- archive enames: ok
- keys  : ok
- signatures and hashes : ok
- binary archive's content and DISCLAIMER, LICENSE and NOTICE   : ok
- source archive's content and DISCLAIMER, LICENSE and NOTICE   : ok
- build from source : ok

Thanks,
  Cos

On Tue, Aug 09, 2016 at 06:24PM, William Markito wrote:
> Hello Incubator IPMC,
> 
> This is a call for a vote on the Apache Geode (incubating) release
> 1.0.0-incubating.M3.
> 
> This release candidate, 1.0.0-incubating.M2.RC7, has successfully passed a
> vote for a release on the Apache Geode developer mailing list.
> 
> Vote thread:
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201608.mbox/%
> 3CCAK7stcwXW9a4yV4ehxDf6gJMzoNTBaeaXvXZVDSAQhGvjtiY9Q%40mail.gmail.com%3E
> 
> Results:
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201608.mbox/%
> 3CCAK7stcwtOvE1ctfDY8EAUEN3varUgNG5DWUzg9YoiL5GwncPiQ%40mail.gmail.com%3E
> 
> It fixes the following issues:
>https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12318420=12335358
> 
> 
> Note that we are voting upon the source (tag):
>rel/v1.0.0-incubating.M3.RC7
> https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=tag;h=refs/tags/rel/v1.0.0-incubating.M3.RC7
> 
> Commit ID: 83f97ceef52febf92ef7737726548aa0865c1a59
> https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=commit;h=83f97ceef52febf92ef7737726548aa0865c1a59
> 
> Source and binary
> files:https://dist.apache.org/repos/dist/dev/incubator/geode/1.0.0-incubating.M3.RC7
> 
> For this release the documentation on how to install and use Apache Geode
> are hosted on pivotal.io:
>http://geode.docs.pivotal.io
> 
> 
> Maven staging 
> repo:https://repository.apache.org/content/repositories/orgapachegeode-1011
> 
> Geode's KEYS file containing PGP keys we use to sign the release:
>https://github.com/apache/incubator-geode/blob/release/
> 1.0.0-incubating.M3/KEYS
> 
> Release Key: pub  4096R/7AAED8BB 2016-07-13
> Fingerprint: 8E06 B711 DB13 3AE7 0CC1  ABDE 6A14 F0BC 7AAE D8BB
> 
> Please vote on releasing this package as Apache Geode 1.0.0-incubating.M3:
> 
> This vote will be open for 72 hours or until necessary number of
> votes.
> 
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
> 
> Thanks!
> 
> -- 
> ~/William on behalf of the Apache Geode (incubating) team

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Ease of release process and exit criteria

[Mark Struberg]

Actually we have 3 different 'staging' mechanisms at play when using Apache 
Maven with GIT:

1.) the Maven staging at repository.apache.org
2.) the temp GIT repo
3.) the dist/dev.


The third is actually not used by all projects. The feature was not that 
prominently advertised and for maven projects you have the release binary 
candidates in the maven staging repo anyway.
Actually 3 is most times populated by curling from 1 ;)



But it's of course a great place to put release candidates if you are not using 
Maven (like AOO)!


LieGrue,
strub


> On Friday, 19 August 2016, 17:41, Dennis E. Hamilton 
>  wrote:
> > 
> 
>>  -Original Message-
>>  From: Mark Struberg [mailto:strub...@yahoo.de.INVALID]
>>  Sent: Friday, August 19, 2016 03:19
>>  To: general@incubator.apache.org
>>  Subject: Re: Ease of release process and exit criteria
>> 
>>  Good links.
>> 
>>  I’d like to add some information for projects who use GIT with maven:
> [ ... ]
>>  Note that in most projects we do _not_ push the release candidate
>>  directly to the ASF repo but e.g. to the release managers private github
>>  account.
>>  Reason is that we cannot easily get rid of it from the cannonical ASF
>>  repo if the VOTE fails.
>>  (ASF repos get mirrored downstream in seconds, and while we could
>>  technically remove it from our own repo we have no control over all the
>>  clones).
> [orcmid] 
> 
> The ASF SVN supports a staging process by which projects have a place to put 
> dev-only builds that are for testing and consideration as release candidates. 
>  
> How that would tie into GIT-only projects and Maven as used is a different 
> matter and distinguishing between non-released developer artifacts, release 
> candidates, and releases seems to be much trickier.  
> 
> Using AOO as an example, the place where artifacts for dev-only use and 
> handling 
> as release candidates are at 
> 
> .  Release candidates 
> on which deliberation fails to achieve release approval can be deleted from 
> there.
> 
> When a release candidate is identified and approved as a release, it is 
> copied 
> or moved to 
> 
>  along with the 
> signatures and hashes that were with the candidate in the dev area.  (Using 
> SVN, 
> this is a cheap copy.)
> 
> That is the staging point for a general, public distribution.  
> Within something like 24-48 hours, the content of that release area is 
> automatically mirrored to
> 
> 
> 
> And THAT is the official public availability point (with whatever mirroring 
> and 
> other downstream distribution there happens to be).  That is where the 
> indelible 
> KEYS, hashes, signatures, etc. are to be accessed and the material is 
> preserved 
> in perpetuity. 
> 
> Deletions at dist.apache.org do not have any effect on the archive.apache.org 
> artifacts, so one can clean-up by removing those.  This is SVN so the 
> artifacts 
> are not completely gone, but they are not available for mistaken download by 
> direct access to those locations.
> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Ease of release process and exit criteria

[Alex Harui]

On 8/20/16, 11:16 PM, "Christopher"  wrote:

>By "source package must be able to build itself", are you suggesting that
>simple projects must create scripts inside the source itself to execute a
>simple tar/zip command (for example), instead of just documenting those
>lines? That seems a bit frivolous to me.

If by "simple projects" you mean those that simply package a tar/zip of a
repo, then I'm sure they could be an exception/degenerate-case/whatever.

But for any packaging that isn't simply a tar/zip of a repo, it might
force the scripting such that there isn't as much RM magic that can get
lost if key folks leave.

Just a thought,
-Alex

>
>On Sun, Aug 21, 2016 at 1:59 AM Alex Harui  wrote:
>
>> One more thought on this:  Right now the 'requirement' is for PMC
>>members
>> to be able to take the source package and build the binary before voting
>> +1.  What if the 'requirement' became that the PMC members must be able
>>to
>> take the source package and build both the binary and the source
>>package?
>> IOW, a source package must be able to build itself.
>>
>> Thanks,
>> -Alex



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Ease of release process and exit criteria

[Christopher]

By "source package must be able to build itself", are you suggesting that
simple projects must create scripts inside the source itself to execute a
simple tar/zip command (for example), instead of just documenting those
lines? That seems a bit frivolous to me.

On Sun, Aug 21, 2016 at 1:59 AM Alex Harui  wrote:

> One more thought on this:  Right now the 'requirement' is for PMC members
> to be able to take the source package and build the binary before voting
> +1.  What if the 'requirement' became that the PMC members must be able to
> take the source package and build both the binary and the source package?
> IOW, a source package must be able to build itself.
>
> Thanks,
> -Alex
>
> On 8/20/16, 12:59 PM, "Mark Thomas"  wrote:
>
> >All,
> >
> >It seems there is general consensus that this is a good idea. I'm
> >therefore going to do the following.
> >
> >1. Draft some text to add to
> >   http://incubator.apache.org/guides/graduation.html#releases
> >   and bring that back to this list for discussion
> >
> >2. Start a thread on dev@community about adding an item to the project
> >   maturity model.
> >
> >3. Identify somewhere to put all the good suggestions for, and links to
> >   examples of, smooth release processes and then pull all the links
> >   and suggestions from this thread to that place. I have a vague
> >   recollection of seeing such a thing previously. I'll need to do some
> >   digging to see it I can find it. Any hints?
> >
> >Mark
> >
> >
> >On 19/08/2016 21:41, Dave Fisher wrote:
> >> I know of a podling like that where the release manager gave me push
> >>back until I told him I could not vote +1 without build instructions I
> >>could at least follow on my own local.
> >>
> >> That was some years ago. The podling graduated. The instructions were
> >>not updated. The RM left. Now there is a bind.
> >>
> >> A requirement is a good idea, but it is no guarantee that the
> >>instructions remain up to date.
> >>
> >> Suggestions:
> >>
> >> Is this info for the maturity model?
> >> Should there be special and higher standards to make binary releases
> >>"official"?
> >>
> >> Regards,
> >> Dave
> >>
> >> Sent from my iPhone
> >>
> >>> On Aug 19, 2016, at 8:41 AM, Dennis E. Hamilton
> >>> wrote:
> >>>
> >>> +1 to this, including the posts from Mark and Bertrand.
> >>>
> >>> I know of a project where this would have made a serious difference
> >>>for graduation and subsequent sustainability.
> >>>
> >>> - Dennis
> >>>
>  -Original Message-
>  From: Shane Curcuru [mailto:a...@shanecurcuru.org]
>  Sent: Friday, August 19, 2016 07:08
>  To: general@incubator.apache.org
>  Subject: Re: Ease of release process and exit criteria
> 
>  Bertrand Delacretaz wrote on 8/19/16 5:57 AM:
> > Hi Mark,
> >
> > On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas 
>  wrote:
> >> ...I'm thinking of a graduation criteria long the lines of:
> >> "Is the release process clearly documented to the point that someone
>  new
> >> to the project could produce a release build?"...
> 
>  +1, this is a critical point to include.  We continue to see projects
>  struggling with releases when early volunteers leave and no-one else
>  really understands releases.
> 
>  ...snip...
> > How about also adding an RE50 item to
> > https://community.apache.org/apache-way/apache-project-maturity-
>  model.html
> > about a repeatable release process? That's a discussion for
> > community.a.o but what's your opinion?
> 
>  +1, this is both important to include philosophically as well as
>  practically.  I.e. it's an important reminder that project technical
>  procedures need to be understandable by the *whole* community, not
> just
>  the first few developers who created the project.
> 
>  - Shane
> 
>  -
>  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>  For additional commands, e-mail: general-h...@incubator.apache.org
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >>> For additional commands, e-mail: general-h...@incubator.apache.org
> >>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >
> >
> >-
> >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
>