On 6/23/15, 3: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. > >>> IOW, I would like to focus on answering the question of how can we >>> empower our communities to effectively communicate *their* intent >>> of how *they* expect an artifact to be consumed. >> >> They can communicate their intent by voting on a release. > >if every provided download is effectively a release, then you need the >voting and all before you can release... that takes ages. Imagine you do >around 13 releases per year. You will be easily busy with voting for >over two months in total. Yep, that’s the “tax” of Apache. IMO, its main reason for existing is to make users of ASF projects feel comfortable incorporating our source into their projects because we’ve done our due diligence on the IP/legal stuff on every line of source. Even for “alpha” quality code, when we say “here, go try this, it may be buggy” we are also saying “we feel pretty good it is safe to eventually be part of your production code and won’t have effects on how you license and use this code”. Yes, folks shouldn’t put alpha code into production, but you know how reality is: some manager sees your POC and suddenly you have a team adding more code on top of it. IIRC, the 72hr voting isn’t a hard rule. It is there to allow folks who aren’t paid to interact with the project every day and live in different time zones a chance to review. I’m pretty sure that if you find a way to involve volunteer folks in IP review in less time it would get ok’d and plenty of other projects would adopt such a process. There was one attempt to try to do serious IP review on every commit in order to avoid 72 hours at vote time. I’m not sure what happened to that proposal. -Alex
