> On Jun 23, 2015, at 6:11 AM, Jochen Theodorou <blackd...@gmx.org> wrote:
> 
> Am 23.06.2015 07:16, schrieb Marvin Humphrey:
> [...]
>>> How am I supposed to invite all the downstream developers of the
>>> world to start integrating with my awesome feature FOO before it
>>> gets formally released when our policy makes statement like:
>>> "If the general public is being instructed to download a package,
>>> then that package has been released."
>> 
>> Rather than invite them in before you make a release, why not release
>> first and then invite them in?
> >
>>> Are we really suggesting that I can not present at conference, tweet
>>> and otherwise promote the awesomeness of my project based on
>>> 'what's coming'?
>> 
>> Why not release before presenting, tweeting, or promoting?
> 
> I am not Roman, but my interpretation in combination with the above would be, 
> that if releases require 72h+ and you cannot just upload it somewhere and say 
> it is no release, that it takes ages. Something like continuous delivery for 
> example looks for me impossible with apache.

I see statements like this frequently, and I don’t understand them.  There 
seems to be an assumption that during a 72-hour voting period, all work on a 
project has to grind to a halt, and everyone needs to focus on the release 
process.  That certainly isn’t true.  There’s no reason you can’t have a 
release process working on v3.62 (or whatever) while work proceeds on v3.63.  
Releases should be pipelined.  Move the release candidate over to the release 
candidate repository for final QA and signoff, then carry on developing in the 
development repository.

Yes, a 72-hour vote process imposes additional overall latency on the process, 
but surely the requirement to have at least three duly-empowered humans sign 
off on the release isn’t that onerous!

Greg Trasuk
> 
> <snip>
> -- 
> Jochen "blackdrag" Theodorou
> blog: http://blackdragsview.blogspot.com/
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

Reply via email to