You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Roman Shaposhnik <rv...@apache.org> on 2015/06/23 06:06:38 UTC
[DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
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).
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.
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. 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."
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Niall Pemberton <ni...@gmail.com>.
On Tue, Jun 23, 2015 at 5:06 AM, Roman Shaposhnik <rv...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Jun 23, 2015 at 3:21 PM, David Nalley <da...@gnsa.us> wrote:
> ...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...
Yes. Grepping for "source-release.zip.sha1.*2014-" at
http://archive.apache.org/dist/sling/ shows 179 modules released for
Sling in 2014 for example. Not as many votes though, as we sometimes
have one vote for several related modules.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Tue, Jun 23, 2015 at 6:21 AM, David Nalley <da...@gnsa.us> wrote:
> 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.
That's definitely part of what I'm after, thanks! Acknowledging this need of
individuals is an extremely useful intermediate step to understanding
how the progressions goes:
0. starts with an individual working on cool, clearly pre-release
stuff and inviting the whole world to pay attention
1. progresses to a subset of the project itself now recognizing
how cool it is and collaborating with that individual on a feature
branch. Still promoting to everybody, but now as a subset of PMC/committers
2. PMC agreeing that it is the most valuable feature in the next release
and the project lives or dies by getting it right. Hence the
project as a whole
now needs to make binary, non-release artifacts available.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by David Nalley <da...@gnsa.us>.
On Tue, Jun 23, 2015 at 6:11 AM, Jochen Theodorou <bl...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
Posted by Greg Trasuk <tr...@stratuscom.com>.
> On Jun 23, 2015, at 6:11 AM, Jochen Theodorou <bl...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
2015-06-23 9:22 GMT-04:00 Alex Harui <ah...@adobe.com>:
> 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.
One related thread was http://markmail.org/message/jyicon7nkmfnf322
I never really followed up on that due to a career move that has
reduced my time here, but the thread has some good ideas (and
important concerns to address) for anyone who's interested in
exploring alternatives.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Alex Harui <ah...@adobe.com>.
On 6/23/15, 4:16 PM, "shaposhnik@gmail.com on behalf of Roman Shaposhnik"
<shaposhnik@gmail.com on behalf of roman@shaposhnik.org> wrote:
>On Tue, Jun 23, 2015 at 6:22 AM, Alex Harui <ah...@adobe.com> wrote:
>> 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.
>
>I think I just got it! Let me continue the tax analogy: at this point ASF
>has
>a flat one-size-fits-all tax of putting something, anything out there. We
>optimize for the most demanding case: the case of guaranteeing clean
>IP AND reasonably stable functionality.
>
>What I'm suggesting here is that perhaps we should think about having
>a progressive tax. A tax that starts small for things that have very
>little
>potential to cause ASF trouble and culminate with the most demanding
>one. The one we currently have today.
>
>Does this make sense?
Well, IMO, a progressive tax doesn’t make sense. Since you like my first
analogy, let me try another one: peanuts.
Many people have severe peanut allergies. Even trace amounts, like
chocolate made in a factory where peanuts are processed can be a problem.
If you advertise that your restaurant is completely safe for these folks,
you cannot afford to experiment on the general public with new ingredient
suppliers. Because if you screw up, not only have you harmed someone,
your reputation is screwed up for a long time, if not forever. There is
no progressive way of introducing peanuts into your menu.
Roughly speaking, GPL and other category X licenses are peanuts. So until
your product team has done its due diligence that there are no peanuts in
the ingredients from your suppliers, don’t serve that food to anyone who
walks in the door, and don’t advertise telling everybody to come in and
try it.
Now you can invite folks to help you prove that the food tastes good and
doesn’t have peanuts in it. You can even go to conferences and invite
these folks. They subscribe to your dev list and taste the nightly
builds. But they are signing up to be a taste tester. They are not the
general public.
This is how I think about these things. I wish there was a better word
than “release” because “release” has other meanings in other places which
I think is the root cause of this sort of confusion on this topic.
-Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Tue, Jun 23, 2015 at 6:22 AM, Alex Harui <ah...@adobe.com> wrote:
> 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.
I think I just got it! Let me continue the tax analogy: at this point ASF has
a flat one-size-fits-all tax of putting something, anything out there. We
optimize for the most demanding case: the case of guaranteeing clean
IP AND reasonably stable functionality.
What I'm suggesting here is that perhaps we should think about having
a progressive tax. A tax that starts small for things that have very little
potential to cause ASF trouble and culminate with the most demanding
one. The one we currently have today.
Does this make sense?
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Alex Harui <ah...@adobe.com>.
On 6/23/15, 3:11 AM, "Jochen Theodorou" <bl...@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
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Jochen Theodorou <bl...@gmx.org>.
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.
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 24.06.2015 14:04, schrieb Marvin Humphrey:
[...]
> What differentiates the "general public" from "developers" is whether they are
> aware of the conditions placed on the artifacts and thus exercising informed
> consent.
What I don't understand is, why I am "exercising informed consent" if I
read the something on a dev list, if I got there through google, a blog
post, nabble or whatever. I mean I may not have searched for a snaphost
for example, and only found a page explaining that may issue is solved
if I do this and that. That could be on a blog for example.
The dev list restriction is for me just serving as fig leaf to have
something defining this exercised consent.
Plus there are a ton of pages that link to nightly builds and snapshot
on the official apache websites. There are only normally not on the top
page, but in some "developer" or "how to build" section. From what I did
read, I would have thought that this is not allowed.
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Sean Busbey <bu...@cloudera.com>.
On Thu, Jun 25, 2015 at 11:06 AM, Bertrand Delacretaz <
bdelacretaz@apache.org> wrote:
> On Thu, Jun 25, 2015 at 3:13 PM, Sean Busbey <bu...@cloudera.com> wrote:
> > ...My understanding is that the Docker Hub page is under the control of
> the
> > Geode PMC....
>
> There's no Geode PMC, as it's a podling the Incubator PMC is in charge
> of their releases.
>
Too right. Sorry for misspeaking; I meant the Geode PPMC.
--
Sean
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jun 25, 2015 at 3:13 PM, Sean Busbey <bu...@cloudera.com> wrote:
> ...My understanding is that the Docker Hub page is under the control of the
> Geode PMC....
There's no Geode PMC, as it's a podling the Incubator PMC is in charge
of their releases.
Even if you ignore the fact that projects are not supposed to
advertise non-releases outside of their dev list, the
https://registry.hub.docker.com/u/apachegeode/geode/ page doesn't show
any disclaimer that it's a nightly unstable build or anything like
that - it looks exactly like an official, supported release.
There's just the "apachegeode/geode:nightly" name that hints at a
nightly build, but that's far from sufficient. Even if we agreed that
having that binary there is ok, it would have to at least prominently
display the standard DISCLAIMER for podlings, as well as a clear
warning that it's meant for developers who accept the risk of running
a nightly build.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by David Nalley <da...@gnsa.us>.
On Thu, Jun 25, 2015 at 1:00 PM, Jochen Theodorou <bl...@gmx.org> wrote:
> Am 25.06.2015 15:13, schrieb Sean Busbey:
> [...]
>>
>> If the Docker Hub page wasn't under the control of the Geode PMC, then I'd
>> say it was a marks violation and they'd have to seek out control of it or
>> removal.
>
>
> can you explain me how that is a marks violation?
>
The average consumer can't tell that isn't coming from the Apache
Geode project. As a matter of fact, the 'organization' listed on the
page isn't $random_individual, it's 'ApacheGeode' distributing a
docker image by the name of Geode. So if the PPMC does not control
that organization the IPMC needs to make a trademark infringement
complaint to Docker.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 25.06.2015 15:13, schrieb Sean Busbey:
[...]
> If the Docker Hub page wasn't under the control of the Geode PMC, then I'd
> say it was a marks violation and they'd have to seek out control of it or
> removal.
can you explain me how that is a marks violation?
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Sean Busbey <bu...@cloudera.com>.
On Jun 25, 2015 3:01 AM, "Emmanuel Lécharny" <el...@gmail.com> wrote:
>
> Le 25/06/15 09:21, Jochen Theodorou a écrit :
> > Am 24.06.2015 22:32, schrieb Emmanuel Lécharny:
> >> Le 24/06/15 22:28, David Nalley a écrit :
> > [...]
> >>> More generally to the underlying issue that prompted this discussion:
> >>> With the concrete example of Geode's DockerHub presence, I don't think
> >>> it's acceptable:
> >>> https://registry.hub.docker.com/u/apachegeode/geode/
> >>>
> >>> Specifically, it's promoting folks consume a nightly build.
> >>> There's no warning that this hasn't met the ASF standards for
> >>> software, or that this project hasn't even pushed out a release yet.
> >>> Then there's the fact that the dockerfile isn't even coming from the
> >>> ASF it's coming from: https://github.com/markito/geode-docker
> >>
> >> That is a clear breach of The ASF release policy, I agree.
> >
> > Just to clarify this... as far as I can see, both pages are not under
> > the control of apache. The github page is not a mirror page from the
> > apache organization as well. Why does the apache policy extend to
> > non-apache pages?
>
> Good question ! My perception is that it is an ASF policy breach,
> assuming the team providing such a package is a member of the Apache
> community.
>
> If it's not the case, then, there is no problem, or nothing we can do.
>
> However, when you look at the link [1], the page says : " If you have
> any problems with or questions about this image, please contact us using
> dev@geode.incubator.org <ma...@geode.incubator.org> or join our
> HipChat <http://s.apache.org/geodechat> channel.". Although the mail is
> wrong (it should be dev@geode.incubator.apache.org), the hipchat channel
> link referes to http://s.apache.org/geodechat, clearly an Apache resource.
>
>
> [1] https://registry.hub.docker.com/u/apachegeode/geode/
My understanding is that the Docker Hub page is under the control of the
Geode PMC. (Roman please correct me if this is wrong.)
The Geode PMC also points downstream users to the Docker Hub page from
other resources it controls (e.g. their twitter account and ASF blog)
If the Docker Hub page wasn't under the control of the Geode PMC, then I'd
say it was a marks violation and they'd have to seek out control of it or
removal.
--
Sean
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 25/06/15 09:21, Jochen Theodorou a écrit :
> Am 24.06.2015 22:32, schrieb Emmanuel Lécharny:
>> Le 24/06/15 22:28, David Nalley a écrit :
> [...]
>>> More generally to the underlying issue that prompted this discussion:
>>> With the concrete example of Geode's DockerHub presence, I don't think
>>> it's acceptable:
>>> https://registry.hub.docker.com/u/apachegeode/geode/
>>>
>>> Specifically, it's promoting folks consume a nightly build.
>>> There's no warning that this hasn't met the ASF standards for
>>> software, or that this project hasn't even pushed out a release yet.
>>> Then there's the fact that the dockerfile isn't even coming from the
>>> ASF it's coming from: https://github.com/markito/geode-docker
>>
>> That is a clear breach of The ASF release policy, I agree.
>
> Just to clarify this... as far as I can see, both pages are not under
> the control of apache. The github page is not a mirror page from the
> apache organization as well. Why does the apache policy extend to
> non-apache pages?
Good question ! My perception is that it is an ASF policy breach,
assuming the team providing such a package is a member of the Apache
community.
If it's not the case, then, there is no problem, or nothing we can do.
However, when you look at the link [1], the page says : " If you have
any problems with or questions about this image, please contact us using
dev@geode.incubator.org <ma...@geode.incubator.org> or join our
HipChat <http://s.apache.org/geodechat> channel.". Although the mail is
wrong (it should be dev@geode.incubator.apache.org), the hipchat channel
link referes to http://s.apache.org/geodechat, clearly an Apache resource.
[1] https://registry.hub.docker.com/u/apachegeode/geode/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 24.06.2015 22:32, schrieb Emmanuel Lécharny:
> Le 24/06/15 22:28, David Nalley a écrit :
[...]
>> More generally to the underlying issue that prompted this discussion:
>> With the concrete example of Geode's DockerHub presence, I don't think
>> it's acceptable:
>> https://registry.hub.docker.com/u/apachegeode/geode/
>>
>> Specifically, it's promoting folks consume a nightly build.
>> There's no warning that this hasn't met the ASF standards for
>> software, or that this project hasn't even pushed out a release yet.
>> Then there's the fact that the dockerfile isn't even coming from the
>> ASF it's coming from: https://github.com/markito/geode-docker
>
> That is a clear breach of The ASF release policy, I agree.
Just to clarify this... as far as I can see, both pages are not under
the control of apache. The github page is not a mirror page from the
apache organization as well. Why does the apache policy extend to
non-apache pages?
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 24/06/15 22:28, David Nalley a écrit :
> On Wed, Jun 24, 2015 at 12:01 PM, Ross Gardler (MS OPEN TECH)
> <Ro...@microsoft.com> wrote:
>> +1 (to this and Jochen's response)
>>
>> Roman was explicit in his question about "clearly identifiable non-release artifacts available to the general public". We can debate words on a page forever, or we can work with the intent and get on with producing software.
>>
>> There is plenty of precedent here (including the oldest project in the foundation).
> Link please? because I can't find it, and a couple of folks from the
> httpd PMC tell me this isn't the case.
>
> I don't think there's a problem with snapshots or nightly builds being
> available. I do think there is a problem with promoting nightly
> builds, or even promoting them from the website.
> I do think that the Release Policy is binding on projects, and more so
> on podlings that haven't kicked out a release yet.
>
>
>
> More generally to the underlying issue that prompted this discussion:
> With the concrete example of Geode's DockerHub presence, I don't think
> it's acceptable:
> https://registry.hub.docker.com/u/apachegeode/geode/
>
> Specifically, it's promoting folks consume a nightly build.
> There's no warning that this hasn't met the ASF standards for
> software, or that this project hasn't even pushed out a release yet.
> Then there's the fact that the dockerfile isn't even coming from the
> ASF it's coming from: https://github.com/markito/geode-docker
That is a clear breach of The ASF release policy, I agree.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 26.06.2015 11:39, schrieb Jochen Theodorou:
> Am 26.06.2015 09:19, schrieb Branko Čibej:
>> On 25.06.2015 09:17, Jochen Theodorou wrote:
> [...]
>>> nightly source tarballs? Is that really a thing?
>>
>> Yes, it is, why wouldn't it be? Httpd isn't even written in Java, and
>> yet it can actually run on computers! :)
>
> I was asking because whoever is able to setup an environment to build
> httpd is surely also able to use the repository directly to get exactly
> the version they want... in the Java world it can be more easy thanks to
> Ivy, gradle and maven and you can go with almost no setup
I want to add, that it looks like httpd is a bad example for nightly
builds, since (unless I am wrong) it seems there has been no activity in
repository that I could call by anything daily recently. So if they
should have nightly builds, I doubt their use.
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 26.06.2015 09:19, schrieb Branko Čibej:
> On 25.06.2015 09:17, Jochen Theodorou wrote:
[...]
>> nightly source tarballs? Is that really a thing?
>
> Yes, it is, why wouldn't it be? Httpd isn't even written in Java, and
> yet it can actually run on computers! :)
I was asking because whoever is able to setup an environment to build
httpd is surely also able to use the repository directly to get exactly
the version they want... in the Java world it can be more easy thanks to
Ivy, gradle and maven and you can go with almost no setup
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Branko Čibej <br...@apache.org>.
On 25.06.2015 09:17, Jochen Theodorou wrote:
> Am 24.06.2015 23:32, schrieb Ross Gardler (MS OPEN TECH):
>> For HTTPd I was referring to the assertion from Justin earlier in
>> this thread " FWIW, httpd always had nightly tarballs available for
>> consumption and testing." (though reading that now I wonder if he
>> meant source tarballs - which is an easy way of resolving this whole
>> issue)
I don't see how that makes anything "easier": it doesn't matter if the
package contains source or binaries or pictures of kittens, the only
question is whether it's a release or not.
> nightly source tarballs? Is that really a thing?
Yes, it is, why wouldn't it be? Httpd isn't even written in Java, and
yet it can actually run on computers! :)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 24.06.2015 23:32, schrieb Ross Gardler (MS OPEN TECH):
> For HTTPd I was referring to the assertion from Justin earlier in this thread " FWIW, httpd always had nightly tarballs available for consumption and testing." (though reading that now I wonder if he meant source tarballs - which is an easy way of resolving this whole issue)
nightly source tarballs? Is that really a thing?
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
For HTTPd I was referring to the assertion from Justin earlier in this thread " FWIW, httpd always had nightly tarballs available for consumption and testing." (though reading that now I wonder if he meant source tarballs - which is an easy way of resolving this whole issue)
Ross
-----Original Message-----
From: David Nalley [mailto:david@gnsa.us]
Sent: Wednesday, June 24, 2015 1:29 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
On Wed, Jun 24, 2015 at 12:01 PM, Ross Gardler (MS OPEN TECH) <Ro...@microsoft.com> wrote:
> +1 (to this and Jochen's response)
>
> Roman was explicit in his question about "clearly identifiable non-release artifacts available to the general public". We can debate words on a page forever, or we can work with the intent and get on with producing software.
>
> There is plenty of precedent here (including the oldest project in the foundation).
Link please? because I can't find it, and a couple of folks from the httpd PMC tell me this isn't the case.
I don't think there's a problem with snapshots or nightly builds being available. I do think there is a problem with promoting nightly builds, or even promoting them from the website.
I do think that the Release Policy is binding on projects, and more so on podlings that haven't kicked out a release yet.
More generally to the underlying issue that prompted this discussion:
With the concrete example of Geode's DockerHub presence, I don't think it's acceptable:
https://registry.hub.docker.com/u/apachegeode/geode/
Specifically, it's promoting folks consume a nightly build.
There's no warning that this hasn't met the ASF standards for software, or that this project hasn't even pushed out a release yet.
Then there's the fact that the dockerfile isn't even coming from the ASF it's coming from: https://github.com/markito/geode-docker
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by David Nalley <da...@gnsa.us>.
On Wed, Jun 24, 2015 at 12:01 PM, Ross Gardler (MS OPEN TECH)
<Ro...@microsoft.com> wrote:
> +1 (to this and Jochen's response)
>
> Roman was explicit in his question about "clearly identifiable non-release artifacts available to the general public". We can debate words on a page forever, or we can work with the intent and get on with producing software.
>
> There is plenty of precedent here (including the oldest project in the foundation).
Link please? because I can't find it, and a couple of folks from the
httpd PMC tell me this isn't the case.
I don't think there's a problem with snapshots or nightly builds being
available. I do think there is a problem with promoting nightly
builds, or even promoting them from the website.
I do think that the Release Policy is binding on projects, and more so
on podlings that haven't kicked out a release yet.
More generally to the underlying issue that prompted this discussion:
With the concrete example of Geode's DockerHub presence, I don't think
it's acceptable:
https://registry.hub.docker.com/u/apachegeode/geode/
Specifically, it's promoting folks consume a nightly build.
There's no warning that this hasn't met the ASF standards for
software, or that this project hasn't even pushed out a release yet.
Then there's the fact that the dockerfile isn't even coming from the
ASF it's coming from: https://github.com/markito/geode-docker
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 24/06/15 19:21, Marvin Humphrey a écrit :
> On Wed, Jun 24, 2015 at 9:01 AM, Ross Gardler (MS OPEN TECH)
> <Ro...@microsoft.com> wrote:
>
>> We can debate words on a page forever, or we can work with the intent and
>> get on with producing software.
> Amen. So when's that Geode release coming?
Ask the Geode fellosws ;-)
>
>> My summary of the intent: Don't advertise automated "non-release" artifacts
>> in such a way that people may accidentally stumble across them and believe
>> them to be production releases. That's it.
> Apache projects have to *release*. Snapshots are not a substitute.
Are we discussing such a fact ? Not that I know.
>
> This goes double for any podling which has not yet demonstrated that its
> codebase is clean enough and its community mature enough to withstand the
> release process.
That is crystal clear. And this is part of the incubator exit criteria.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Wed, Jun 24, 2015 at 9:01 AM, Ross Gardler (MS OPEN TECH)
<Ro...@microsoft.com> wrote:
> We can debate words on a page forever, or we can work with the intent and
> get on with producing software.
Amen. So when's that Geode release coming?
> My summary of the intent: Don't advertise automated "non-release" artifacts
> in such a way that people may accidentally stumble across them and believe
> them to be production releases. That's it.
Apache projects have to *release*. Snapshots are not a substitute.
This goes double for any podling which has not yet demonstrated that its
codebase is clean enough and its community mature enough to withstand the
release process.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
+1 (to this and Jochen's response)
Roman was explicit in his question about "clearly identifiable non-release artifacts available to the general public". We can debate words on a page forever, or we can work with the intent and get on with producing software.
There is plenty of precedent here (including the oldest project in the foundation).
My summary of the intent: Don't advertise automated "non-release" artifacts in such a way that people may accidentally stumble across them and believe them to be production releases. That's it.
Ross
Sent from my Windows Phone
________________________________
From: Emmanuel Lécharny<ma...@gmail.com>
Sent: 6/24/2015 7:38 AM
To: general@incubator.apache.org<ma...@incubator.apache.org>
Subject: Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
Le 24/06/15 14:04, Marvin Humphrey a écrit :
> On Tue, Jun 23, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH)
> <Ro...@microsoft.com> wrote:
>> There is nothing preventing "clearly identifiable non-release artifacts
>> available to the general public".
> The Releases Policy page forbids it explicitly:
>
> During the process of developing software and preparing a release, various
> packages are made available to the developer community for testing
> purposes. **Do not include any links on the project website that might
> encourage non-developers to download and use nightly builds, snapshots,
> release candidates, or any other similar package.** The only people who are
> supposed to know about such packages are the people following the dev list
> (or searching its archives) and thus aware of the conditions placed on the
> package. If you find that the general public are downloading such test
> packages, then remove them.
>
> Under no circumstances are unapproved builds a substitute for releases. If
> this policy seems inconvenient, then release more often. Proper release
> management is a key aspect of Apache software development.
>
> What differentiates the "general public" from "developers" is whether they are
> aware of the conditions placed on the artifacts and thus exercising informed
> consent.
>
> Those conditions are are not limited to instability of the codebase, but also
> whether the artifacts meet Apache's licensing and legal requirements for
> releases.
IMO, 'public' here means : 'exposed on the project's web site'.
Whatever is built, and pushed on temporary spaces that are not
mentionned on the project's web site does not enter in this category.
The release policy does not state this is forbidden to produce those
non-release builds, nor to push it somewhere reachable to anyone, but
forbid advertizing about it (announce@a.o, or a news on the project's
web site).
What is important here is the spirit, not the letter : we want to be
sure that those who download those non-release packages *know* what they
are doing and what they are exposing themselves to.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 24/06/15 14:04, Marvin Humphrey a écrit :
> On Tue, Jun 23, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH)
> <Ro...@microsoft.com> wrote:
>> There is nothing preventing "clearly identifiable non-release artifacts
>> available to the general public".
> The Releases Policy page forbids it explicitly:
>
> During the process of developing software and preparing a release, various
> packages are made available to the developer community for testing
> purposes. **Do not include any links on the project website that might
> encourage non-developers to download and use nightly builds, snapshots,
> release candidates, or any other similar package.** The only people who are
> supposed to know about such packages are the people following the dev list
> (or searching its archives) and thus aware of the conditions placed on the
> package. If you find that the general public are downloading such test
> packages, then remove them.
>
> Under no circumstances are unapproved builds a substitute for releases. If
> this policy seems inconvenient, then release more often. Proper release
> management is a key aspect of Apache software development.
>
> What differentiates the "general public" from "developers" is whether they are
> aware of the conditions placed on the artifacts and thus exercising informed
> consent.
>
> Those conditions are are not limited to instability of the codebase, but also
> whether the artifacts meet Apache's licensing and legal requirements for
> releases.
IMO, 'public' here means : 'exposed on the project's web site'.
Whatever is built, and pushed on temporary spaces that are not
mentionned on the project's web site does not enter in this category.
The release policy does not state this is forbidden to produce those
non-release builds, nor to push it somewhere reachable to anyone, but
forbid advertizing about it (announce@a.o, or a news on the project's
web site).
What is important here is the spirit, not the letter : we want to be
sure that those who download those non-release packages *know* what they
are doing and what they are exposing themselves to.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Jun 23, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH)
<Ro...@microsoft.com> wrote:
> There is nothing preventing "clearly identifiable non-release artifacts
> available to the general public".
The Releases Policy page forbids it explicitly:
During the process of developing software and preparing a release, various
packages are made available to the developer community for testing
purposes. **Do not include any links on the project website that might
encourage non-developers to download and use nightly builds, snapshots,
release candidates, or any other similar package.** The only people who are
supposed to know about such packages are the people following the dev list
(or searching its archives) and thus aware of the conditions placed on the
package. If you find that the general public are downloading such test
packages, then remove them.
Under no circumstances are unapproved builds a substitute for releases. If
this policy seems inconvenient, then release more often. Proper release
management is a key aspect of Apache software development.
What differentiates the "general public" from "developers" is whether they are
aware of the conditions placed on the artifacts and thus exercising informed
consent.
Those conditions are are not limited to instability of the codebase, but also
whether the artifacts meet Apache's licensing and legal requirements for
releases.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Jun 23, 2015 at 11:06 PM, Sean Busbey <bu...@cloudera.com> wrote:
> While I agree that this is a general issue that should be discussed, an
> example might help. This discussion started because the Geode PMC is
> publishing a docker artifact from their nightly builds and then pointing
> the general public to make use of that image. They have no released
> artifacts, so any downstream user necessarily will be using those
> non-vetted artifacts.
Once releases are made, then I think any Geode documentation would
definitely shift to referring to the released versions. However,
Geode isn't yet ready to cut a release.
I do doubt that anyone who picks up a nightly Geode build right now is
going to put it into production. So, I'm not overly worried.
By the time the project is ready to graduate, there will be several
releases (if not more) and I fully expect that this'll be a moot
point.
> Downstream developers and users *will* take the path of lease resistance.
> If that PMC wanted to continue relying on a binary docker image for
> community outreach indefinitely, would that be okay? If they wanted to rely
> on it and only have PMC blessed releases quarterly?
As I mentioned in my other email, as long as it's automated and
producing a nightly artifact that is appropriately labeled, then, sure
go for it, IMO.
Cheers. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Sean Busbey <bu...@cloudera.com>.
On Tue, Jun 23, 2015 at 5:20 PM, Ross Gardler (MS OPEN TECH) <
Ross.Gardler@microsoft.com> wrote:
> There is nothing preventing "clearly identifiable non-release artifacts
> available to the general public". Many projects make automated nightly
> builds available for example.
>
>
The release policy expressly says that nightly builds must not be made
available to general public.
It's my understanding that the reason the foundation can provide
indemnification (to both commiters/PMC and downstream) is the fact that
PMCs vote on releases under their delegated authority from the board.
If the boundary for public use moves from "voted on by a PMC" to "voted on
by a PMC or labeled as non-release" what are the ramifications?
While I agree that this is a general issue that should be discussed, an
example might help. This discussion started because the Geode PMC is
publishing a docker artifact from their nightly builds and then pointing
the general public to make use of that image. They have no released
artifacts, so any downstream user necessarily will be using those
non-vetted artifacts.
Downstream developers and users *will* take the path of lease resistance.
If that PMC wanted to continue relying on a binary docker image for
community outreach indefinitely, would that be okay? If they wanted to rely
on it and only have PMC blessed releases quarterly?
--
Sean
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Cédric Champeau <ce...@gmail.com>.
>
> +1
>
> Personally I think the policy should be clarified such that nightly builds
> MUST only live on ASF infrastructure (whether that be the Nexus SNAPSHOTs
> repo, committer web space etc). As soon as you start putting them on
> external services like DockerHub then they are potentially widely visible
> to the general public.
>
Please do NOT do this. The policy is already painful enough. I can
understand why SOURCES must live
under the Apache organization infrastructure, because they are the ONLY
thing that legal cares about, but
please, for the sake of my mental sanity, do NOT impose any kind of
arbitrary rules like this for binaries/
distribution. It's total madness. Projects like Groovy have been using a
well working infrastructure for a
long time: snapshots published on a snapshot repository, releases pushed
onto Bintray, and we have good reasons
to do this. Our community *loves* to test snapshots, and they are not
stupid. They know that testing something
which is NOT an official release gives no guarantee whatsoever. I think we
should trust our community, and
not try to impose some kind of arbitrary process for the sake of having a
process.
I see no reason why one would like to impose using something like Nexus, it
should be the choice
of each project like it is today. Binaries/distributions are a convenience
and official releases *must* stay sources. For
anything else, it should be up to the project to decide.
I echo what Jochen said already: the move is towards continuous
integration. There's technically no difference between
a snapshot and a release. Apache makes it clear that some releases are
official and that an official release means that
sources for that release are voted and stamped as compliant. That's more
than enough. Toolchains, release process,
how we make binaries/distributions available for testing to our community
should remain under control of the project.
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 24/06/15 22:14, David Nalley a écrit :
>
>>> Going back to the example of libraries published as Maven artifacts
>>> for those projects already publishing SNAPSHOTs these only get
>>> published to the Apache Nexus server (repository.apache.org) and are
>>> not synced to Maven central.
>> So ? SNAPSHOTs are visible, anyone can download them, and they are not
>> endorsed by apache. They are just stored there because it's convenient,
>> not because it's official or whatever makes an ASF release.
>>
> The reasoning is that artifacts on repository.a.o are hard to find,
> hard to come across. It's not in Maven Central.
> We aren't hiding them, but for someone to consume them would require
> them taking explicit action that short of them being in the project
> community they won't know about.
> We don't publish those artifacts to central, because people would
> easily find and consume them.
That does not make a policy. You are just making it a bit more
complicated for our user to fool themselves, which is always good. In
any case, everything is still plainly visible to anyone, hopefully.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by David Nalley <da...@gnsa.us>.
On Wed, Jun 24, 2015 at 3:22 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 24/06/15 09:19, Rob Vesse a écrit :
>> Personally I think the policy should be clarified such that nightly
>> builds MUST only live on ASF infrastructure
>
> Non sense. Nightly built can stay wherever is suitable. It's not The ASF
> business anyway, The ASF does not endorse nighly build or non-release
> packages.
>
>> (whether that be the Nexus SNAPSHOTs repo, committer web space etc).
>> As soon as you start putting them on external services like DockerHub
>> then they are potentially widely visible to the general public.
> Not a problem, as soon as you don't advertize them. People are grown up
> adults that know what to do with such builds, would they found them
> somwhere which is not advertized as an Apache official release.
>
>
>> Going back to the example of libraries published as Maven artifacts
>> for those projects already publishing SNAPSHOTs these only get
>> published to the Apache Nexus server (repository.apache.org) and are
>> not synced to Maven central.
> So ? SNAPSHOTs are visible, anyone can download them, and they are not
> endorsed by apache. They are just stored there because it's convenient,
> not because it's official or whatever makes an ASF release.
>
The reasoning is that artifacts on repository.a.o are hard to find,
hard to come across. It's not in Maven Central.
We aren't hiding them, but for someone to consume them would require
them taking explicit action that short of them being in the project
community they won't know about.
We don't publish those artifacts to central, because people would
easily find and consume them.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 24/06/15 09:19, Rob Vesse a écrit :
> Personally I think the policy should be clarified such that nightly
> builds MUST only live on ASF infrastructure
Non sense. Nightly built can stay wherever is suitable. It's not The ASF
business anyway, The ASF does not endorse nighly build or non-release
packages.
> (whether that be the Nexus SNAPSHOTs repo, committer web space etc).
> As soon as you start putting them on external services like DockerHub
> then they are potentially widely visible to the general public.
Not a problem, as soon as you don't advertize them. People are grown up
adults that know what to do with such builds, would they found them
somwhere which is not advertized as an Apache official release.
> Going back to the example of libraries published as Maven artifacts
> for those projects already publishing SNAPSHOTs these only get
> published to the Apache Nexus server (repository.apache.org) and are
> not synced to Maven central.
So ? SNAPSHOTs are visible, anyone can download them, and they are not
endorsed by apache. They are just stored there because it's convenient,
not because it's official or whatever makes an ASF release.
Pushing your reasoning to its limit would force any Apache project to
push non-release packages to a protected area, for committers only. Not
even close to what's going to happen, any time soon, I hope.
> People who want to consume those artifacts have to explicitly
> configure their Maven setup to enable Apache SNAPSHOTs. For me this is
> a sufficient barrier to distinguish between "developers" and "users".
Users download official releases from the Apache web site, and The ASF
is only responsible for what is inside those released packages. It's
enough to avoid pretending that a non-release package or a SNAPSHOT is
*not* a release to protect The ASF *and* its users, which is the only
important thing so far.
> FWIW if someone has made the effort to join the mailing list and
> report a bug which we then want to ask them to test a fix for then
> they are clearly in the developer category (or more accurately they
> are a contributor) and I would have no problem to pointing them to the
> nightly builds so they could do this. However putting stuff out there
> on an external hosting service that is widely accessible seems to go
> against the spirit (and likely the letter) of the policy Rob
This is just against *your* perception of what is the spirit. Pushing
some SNAPSHOT or non-release package somwhere convenient for people to
check that it's correct is just part of the dev process, as far as we
don't claim it's a release and we don't push people to use it as
official releases. Adding another layer by asking those packages to be
pushed on a ASF infrastructure is just making things harder for the
developpers. We don't need that, The ASF does not require that.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Rob Vesse <rv...@dotnetrdf.org>.
On 24/06/2015 18:02, "Markus Weimer" <ma...@weimo.de> wrote:
>> Personally I think the policy should be clarified such that nightly
>>builds
>> MUST only live on ASF infrastructure (whether that be the Nexus
>>SNAPSHOTs
>> repo, committer web space etc). As soon as you start putting them on
>> external services like DockerHub then they are potentially widely
>>visible
>> to the general public.
>
>This is very tricky for projects outside the Java ecosystem. For .NET,
>NuGet is the established way to get packages, and the ASF doesn't
>provide a NuGet repository in the same way it does provide Maven
>repositories.
Sontatype Nexus Professional 2 onwards (which the ASF runs) supports NuGet
repositories so if ASF projects wanted to use that capability to
distribute pre-release builds then they should start a discussion with
infrastructure
http://books.sonatype.com/nexus-book/reference/nuget.html
>
>NuGet is just one example, each of the major language ecosystems now
>offers at least one (binary) artifact and dependency management
>approach. Following through on the above would mean either an incredible
>workload for the ASF to support it all, the exclusion of whole languages
>from ASF projects or treating some as second class citizens because
>their nightly builds wouldn't be testable. Neither of those strike me as
>great results.
Good points, ultimately I think I did not express what I meant precisely
enough
Nightly builds generated by a project e.g. by a projects nightly build job
on Jenkins MUST live on ASF Infrastructure
If there is sufficient mass of projects needing a specific kind of
repository service available that isn't currently then there is nothing
stopping those projects from starting the appropriate discussions with
Infra as to whether such a service could be provided
OTOH individuals are free to do whatever they want without their ASF hats
on and publish their own personal nightly builds wherever and however they
want provided that they appropriately distinguish them from ASF actions
and releases. However if individuals start publishing stuff to popular
public central repository services then clearly there is a danger of
confusion as to the source of the package(s).
Rob
>
>Markus
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Guillaume Laforge <gl...@gmail.com>.
Good point.
Furthermore, for users of those project, it might be more painful to get
binaries in an usual Apache place compared to a community / blessed
approach.
Le mercredi 24 juin 2015, Markus Weimer <ma...@weimo.de> a écrit :
> > Personally I think the policy should be clarified such that nightly
> builds
> > MUST only live on ASF infrastructure (whether that be the Nexus SNAPSHOTs
> > repo, committer web space etc). As soon as you start putting them on
> > external services like DockerHub then they are potentially widely visible
> > to the general public.
>
> This is very tricky for projects outside the Java ecosystem. For .NET,
> NuGet is the established way to get packages, and the ASF doesn't
> provide a NuGet repository in the same way it does provide Maven
> repositories.
>
> NuGet is just one example, each of the major language ecosystems now
> offers at least one (binary) artifact and dependency management
> approach. Following through on the above would mean either an incredible
> workload for the ASF to support it all, the exclusion of whole languages
> from ASF projects or treating some as second class citizens because
> their nightly builds wouldn't be testable. Neither of those strike me as
> great results.
>
> Markus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> <javascript:;>
> For additional commands, e-mail: general-help@incubator.apache.org
> <javascript:;>
>
>
--
Guillaume Laforge
Groovy Project Manager
Product Ninja & Advocate at Restlet <http://restlet.com>
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
RE: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
People wanting to use snapshot releases can be expected to jump through hoops to install those snapshots. NuGet, like all package management solutions, is a convenience not a requirement. People can still manually download and install libraries manually. Putting snapshots in public repositories, in my opinion, crosses the boundary of clearly differentiating releases from non-releases.
Ross
-----Original Message-----
From: Markus Weimer [mailto:markus@weimo.de]
Sent: Wednesday, June 24, 2015 10:03 AM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
> Personally I think the policy should be clarified such that nightly
> builds MUST only live on ASF infrastructure (whether that be the Nexus
> SNAPSHOTs repo, committer web space etc). As soon as you start
> putting them on external services like DockerHub then they are
> potentially widely visible to the general public.
This is very tricky for projects outside the Java ecosystem. For .NET, NuGet is the established way to get packages, and the ASF doesn't provide a NuGet repository in the same way it does provide Maven repositories.
NuGet is just one example, each of the major language ecosystems now offers at least one (binary) artifact and dependency management approach. Following through on the above would mean either an incredible workload for the ASF to support it all, the exclusion of whole languages from ASF projects or treating some as second class citizens because their nightly builds wouldn't be testable. Neither of those strike me as great results.
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Markus Weimer <ma...@weimo.de>.
> Personally I think the policy should be clarified such that nightly builds
> MUST only live on ASF infrastructure (whether that be the Nexus SNAPSHOTs
> repo, committer web space etc). As soon as you start putting them on
> external services like DockerHub then they are potentially widely visible
> to the general public.
This is very tricky for projects outside the Java ecosystem. For .NET,
NuGet is the established way to get packages, and the ASF doesn't
provide a NuGet repository in the same way it does provide Maven
repositories.
NuGet is just one example, each of the major language ecosystems now
offers at least one (binary) artifact and dependency management
approach. Following through on the above would mean either an incredible
workload for the ASF to support it all, the exclusion of whole languages
from ASF projects or treating some as second class citizens because
their nightly builds wouldn't be testable. Neither of those strike me as
great results.
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Rob Vesse <rv...@dotnetrdf.org>.
On 24/06/2015 04:12, "Justin Erenkrantz" <justin.erenkrantz@gmail.com on
behalf of justin@erenkrantz.com> wrote:
>On Tue, Jun 23, 2015 at 10:48 PM, Roman Shaposhnik <ro...@shaposhnik.org>
>wrote:
>> On Tue, Jun 23, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH)
>> <Ro...@microsoft.com> wrote:
>>> There is nothing preventing "clearly identifiable non-release artifacts
>>> available to the general public". Many projects make automated nightly
>>>builds available for example.
>>
>> This! Honestly this has always been my personal interpretation of the
>>policy
>> (although now that I'm re-reading it I see how it could be interpreted
>>in a
>> radically different way).
>>
>> IOW, I've been mentoring a lot of poddlings and advising them that as
>> long as they go out of their way to label 'nightly' artifacts as NON
>>RELEASE,
>> DON'T TRY IT AT HOME, DANGER!!! it is ok to make them available to
>> "general public" (*). I have always though that, for example, -SNAPSHOT
>>version
>> designation is enough to communicate that type of intent. Same as
>> SNAPSHOT/NONRELEASE tag on Docker image, etc.
>
>I agree. As long as the version designation of the artifact includes
>-SNAPSHOT or -DEV or whatever, I think that's sufficient to qualify as
>a "clearly identifiable non-release artifact".
>
>FWIW, httpd always had nightly tarballs available for consumption and
>testing.
>
>I do think that the threshold is that it needs to come from an
>automated process blessed by the [P]PMC. If it requires a human to
>publish the "nightly" into the distribution channel, then I think
>that's probably where the line gets crossed and our voting rules
>apply.
>
>Nightly builds shouldn't be "easily" found - except deep inside
>developer-facing documentations. All obvious materials should point
>at the official, blessed releases. But, it's important to provide a
>channel for downstream people to test trunk/master/develop (whatever
>shiny name the project calls it).
+1
Personally I think the policy should be clarified such that nightly builds
MUST only live on ASF infrastructure (whether that be the Nexus SNAPSHOTs
repo, committer web space etc). As soon as you start putting them on
external services like DockerHub then they are potentially widely visible
to the general public.
Going back to the example of libraries published as Maven artifacts for
those projects already publishing SNAPSHOTs these only get published to
the Apache Nexus server (repository.apache.org) and are not synced to
Maven central. People who want to consume those artifacts have to
explicitly configure their Maven setup to enable Apache SNAPSHOTs. For me
this is a sufficient barrier to distinguish between "developers" and
"users".
FWIW if someone has made the effort to join the mailing list and report a
bug which we then want to ask them to test a fix for then they are clearly
in the developer category (or more accurately they are a contributor) and
I would have no problem to pointing them to the nightly builds so they
could do this.
However putting stuff out there on an external hosting service that is
widely accessible seems to go against the spirit (and likely the letter)
of the policy
Rob
>
>In today's day and age, producing Docker-like thingys is akin to
>producing RPMs. I won't go into why I think the centralized Docker
>Hub is a huge mistake - it's simply how you consume Docker thingys. I
>do wish that we could point folks at a specific Docker registries (a
>la an apt or yum repos), but having a single global registry is how
>Docker, Inc. apparently thinks that it'll justify its valuations.
>Sigh.
>
>Cheers. -- justin
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Jun 23, 2015 at 10:48 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> On Tue, Jun 23, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH)
> <Ro...@microsoft.com> wrote:
>> There is nothing preventing "clearly identifiable non-release artifacts
>> available to the general public". Many projects make automated nightly builds available for example.
>
> This! Honestly this has always been my personal interpretation of the policy
> (although now that I'm re-reading it I see how it could be interpreted in a
> radically different way).
>
> IOW, I've been mentoring a lot of poddlings and advising them that as
> long as they go out of their way to label 'nightly' artifacts as NON RELEASE,
> DON'T TRY IT AT HOME, DANGER!!! it is ok to make them available to
> "general public" (*). I have always though that, for example, -SNAPSHOT version
> designation is enough to communicate that type of intent. Same as
> SNAPSHOT/NONRELEASE tag on Docker image, etc.
I agree. As long as the version designation of the artifact includes
-SNAPSHOT or -DEV or whatever, I think that's sufficient to qualify as
a "clearly identifiable non-release artifact".
FWIW, httpd always had nightly tarballs available for consumption and testing.
I do think that the threshold is that it needs to come from an
automated process blessed by the [P]PMC. If it requires a human to
publish the "nightly" into the distribution channel, then I think
that's probably where the line gets crossed and our voting rules
apply.
Nightly builds shouldn't be "easily" found - except deep inside
developer-facing documentations. All obvious materials should point
at the official, blessed releases. But, it's important to provide a
channel for downstream people to test trunk/master/develop (whatever
shiny name the project calls it).
In today's day and age, producing Docker-like thingys is akin to
producing RPMs. I won't go into why I think the centralized Docker
Hub is a huge mistake - it's simply how you consume Docker thingys. I
do wish that we could point folks at a specific Docker registries (a
la an apt or yum repos), but having a single global registry is how
Docker, Inc. apparently thinks that it'll justify its valuations.
Sigh.
Cheers. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Tue, Jun 23, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH)
<Ro...@microsoft.com> wrote:
> There is nothing preventing "clearly identifiable non-release artifacts
> available to the general public". Many projects make automated nightly builds available for example.
This! Honestly this has always been my personal interpretation of the policy
(although now that I'm re-reading it I see how it could be interpreted in a
radically different way).
IOW, I've been mentoring a lot of poddlings and advising them that as
long as they go out of their way to label 'nightly' artifacts as NON RELEASE,
DON'T TRY IT AT HOME, DANGER!!! it is ok to make them available to
"general public" (*). I have always though that, for example, -SNAPSHOT version
designation is enough to communicate that type of intent. Same as
SNAPSHOT/NONRELEASE tag on Docker image, etc.
>From what you're telling me it sounds like this should be acceptable to ASF
(I know you're just voicing your viewpoint, not the official ASF). That still
leaves the question of updating the policy which I'd love to collaborate
with somebody to update -- but I don't think I can sign up for that job all
by myself.
Thanks,
Roman.
(*) an come on, do you really think that *general* public consumes something
like apache common? These are our fellow developers -- they really don't
have to be told what -SNAPSHOT designation means.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
There is nothing preventing "clearly identifiable non-release artifacts
available to the general public". Many projects make automated nightly builds available for example.
Sent from my Windows Phone
________________________________
From: Roman Shaposhnik<ma...@shaposhnik.org>
Sent: 6/23/2015 12:23 PM
To: general@incubator.apache.org<ma...@incubator.apache.org>
Subject: Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
On Mon, Jun 22, 2015 at 10:16 PM, Marvin Humphrey
<ma...@rectangular.com> wrote:
> The distinction is between people who develop the Apache product, and
> those who use the Apache product.
Well, that's part of the reason behind me starting this thread: I think
it is time for us to explicitly acknowledge a third role: an downstream
project developer integrating with Apache *project*. I believe we have
enough evidence that this group of people has unique requirements.
>> 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?
Because I want their feedback during the release cycle, not after. IOW,
I need them to download and integrate with half-baked functionality
that I may be not comfortable putting into a release.
>> 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?
See above.
>> 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.
>
> If artifacts are being consumed by people other than those who develop
> the Apache product, those artifacts need to be vetted and voted.
Like I said -- I'm 100% with you when it come to source artifacts. Can
somebody please explain to me what is a the danger to the foundation
is a [P]PMC wants to make a clearly identifiable non-release artifacts
available to the general public?
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Jun 22, 2015 at 10:16 PM, Marvin Humphrey
<ma...@rectangular.com> wrote:
> The distinction is between people who develop the Apache product, and
> those who use the Apache product.
Well, that's part of the reason behind me starting this thread: I think
it is time for us to explicitly acknowledge a third role: an downstream
project developer integrating with Apache *project*. I believe we have
enough evidence that this group of people has unique requirements.
>> 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?
Because I want their feedback during the release cycle, not after. IOW,
I need them to download and integrate with half-baked functionality
that I may be not comfortable putting into a release.
>> 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?
See above.
>> 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.
>
> If artifacts are being consumed by people other than those who develop
> the Apache product, those artifacts need to be vetted and voted.
Like I said -- I'm 100% with you when it come to source artifacts. Can
somebody please explain to me what is a the danger to the foundation
is a [P]PMC wants to make a clearly identifiable non-release artifacts
available to the general public?
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream
integration binary artifacts
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Jun 22, 2015 at 9:06 PM, Roman Shaposhnik <rv...@apache.org> wrote:
> 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 distinction is between people who develop the Apache product, and
those who use the Apache product.
> 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?
> 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.
> 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.
If artifacts are being consumed by people other than those who develop
the Apache product, those artifacts need to be vetted and voted.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org