On Tue, 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 think you are abusing the term 'continuous delivery' a bit. Keeping the codebase in an 'always releasable state' is quite different from releasing every commit or every n-th commit. So I see a bit of nuance here. The project should not be promoting/advertising non-released artifacts outside of it's own developer community (e.g. the folks who actually develop Apache $foo) The developer, however, may want to show off what he is working on. He may want to tweet about it, give a presentation or two, invite people to play with an upcoming feature. He might feature that functionality at https://people.apache.org/~ke4qqqq/ or his own web space. The difference is that an individual is doing that, and not communicating as if he is providing downloads/releases on behalf of the project itself. >>> 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. > It is deliberately 'slow'. Speaking personally, I understand the frustration with having a robust CI/CD pipeline, and keeping a codebase always releasable - and then having a 72 hour voting window (which in my experience is rarely only 72 hours). And I'll also note that this isn't the first project that has felt those pains. However, that time isn't necessarily about code quality, it's about the entire community having the opportunity to make a decision to release or not, rather than a RM making decisions on behalf of the entire project - which tends to disenfranchise community, and introduce a strata of being a RM or not into the power structure. I'll also say, projects don't seem to have a problem releasing frequently. Tomcat, for instance, pushed out 4 releases in the month of May alone. It looks like they exceeded 20 releases in 2014. And there are plenty of projects doing more releases than Tomcat. --David --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
