On Tue, Jun 23, 2015 at 5:06 AM, Roman Shaposhnik <r...@apache.org> wrote:
> Hi! > > let me start by saying that I feel proud about the > rigor with which ASF approaches management > of the ultimate foundation deliverables: the source > releases put out by our communities. If you read our > policy document: > http://www.apache.org/dev/release.html > and only focus on the source releases it is obvious > to me that we strike a great balance between fostering > innovation while practicing strict IP hygiene. > > Unfortunately, I can't really say the same for the parts > of the policy that covers binary convenience artifacts. > The way our policy talks about these artifacts seems to > invite different interpretations which is especially > problematic for training podlings in the "Apache Way" > (hence even though this discussion is perfectly applicable > to TLPs I'm starting it here on general@incubator). > I dont agree with your interpretation of the "release" page. It doesn't define a release as "source" - it says "anything that is published beyond the group that owns it" and specifically mentions "nightly builds". Also the following page is specific about distributing unreleased materials outside the project development community: http://www.apache.org/dev/release-distribution.html#unreleased > The biggest source of confusion that I personally witnessed > comes from interpreting 'general public' vs. 'developers'. > The problem there seems to come from the false assumption > that our projects always have a user base that is non-developer > in nature. For projects like libraries or frameworks this is simply > not the case. The end-users of such projects are always, by > definition, developers. > The ASF has had alot of projects for a long time (perhaps the majority) where the user-base are developers. But it has always been the case that "developer" here means someone who participates in the development of the project. The ASF use of the terms "User" and "Developer" are documented on the glossary page: www.apache.org/foundation/glossary.html > Think of them as downstream developers integrating with ASF > projects via binary artifacts. These folks always embed ASF > project into larger systems. They also, typically, live and die > by the level of API compatibility that the upstream ASF-produced > dependencies maintain. This, in turn, puts pressure on ASF > upstream projects to maintain a healthy and convenient channel > for managing non-release, downstream integration binary artifacts. > Unfortunately, our current release policy is extremely confusing when > it comes to this very important use case. I don't agree that its confusing - it seems clear to me that distributing unreleased material outside the development community is against the policy. > What's worse, in my opinion > it gets in the way of fostering user community for projects where > users == downstream developers. > > 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." > Release an "alpha" or "experimental" version. Also, I think its worth mentioning that this isn't just an intellectual exercise, but is a specific issue raised about the Geode PPMC publishing nightly builds to Docker Hub: * http://s.apache.org/SfK Niall > 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'? I've always assumed that we are not and the way > policy is currently worded is just sloppy. > > I know that there's been a number of threads over the years that tilted > at the windmill of clarifying our policies around binary releases. At this > point, I'm actually taking a step back and asking a bigger question: why > don't we take a more nuanced approach towards the very issue of > what makes a release a release. > > 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. > > After all, we have a really good way of communicating that type of intent > when it comes to branding: if you want to communicate that Apache > FOO is a poddling you MUST refer to it as Apache FOO (incubating). > Simple and effective. Exact opposite of our release policy that seems > to completely discount labeling for communicating intent. I'm sorry, > but a -SNAPSHOT labeling of a version ID communicates as much > (if not more) to me as a writing on a website does. Lets just recognize > that. > > Thanks, > Roman. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
