On Mon, 2008-10-27 at 02:45 +0100, Niclas Hedhman wrote:
On Sun, Oct 26, 2008 at 9:45 PM, Paul Querna [EMAIL PROTECTED] wrote:
Related to this, perhaps our labeling of 'incubating' is not effective.
Why not just call all releases from incubator 'alpha'?
The 'incubating' tag doesn't
On Sun, Oct 26, 2008 at 9:45 PM, Paul Querna [EMAIL PROTECTED] wrote:
Related to this, perhaps our labeling of 'incubating' is not effective.
Why not just call all releases from incubator 'alpha'?
The 'incubating' tag doesn't seem to set expectations correctly in the wider
open source
of incubating releases.
The cause is that Apache Incubator projects and releases are not
fully endorsed by the ASF until graduation.
Change that. Then everything else falls into place.
Upayavira made a good point about the difference between endorsing a
release and endorsing a project. The way I see
On Fri, Oct 3, 2008 at 3:53 PM, Jukka Zitting [EMAIL PROTECTED] wrote:
...Upayavira made a good point about the difference between endorsing a
release and endorsing a project. The way I see it, the ASF endorses a
release when the binding release vote passes. A project is endorsed
when it
On Fri, Oct 3, 2008 at 2:53 PM, Jukka Zitting [EMAIL PROTECTED]wrote:
Do people think that we shouldn't make such a distinction, or that we
should perhaps explicitly consider community quality as a release
criteria?
Getting releases out of the incubator is difficult and subjective enough as
What about allowing podlings to do release without using the
org.apache.* packages or the apache brand anywhere in the release ?
These would be just plain Apache Licensed releases without any ties to
the Apache brand. Such releases, not endorsed by the ASF could be
synced to the central repo
So the first thing that happens post graduation is that you piss off the
entire community by breaking all backwords compatibility by changing all
the package names? Ick. Not a good first experience once out of the
incubator.
We put incubator in all the artifact names.IMO, that is
So the first thing that happens post graduation is that you piss off the
entire community by breaking all backwords compatibility by changing all
the package names? Ick. Not a good first experience once out of the
incubator.
We (JSPWiki) will do this by taking advantage of the package
Though I'm not in favor of dropping the community requirements for
graduation, I must disagree with the following, based on our license:
On Wed, Oct 1, 2008 at 1:32 AM, Upayavira [EMAIL PROTECTED] wrote:
We are not yet confident that there will be a community actively
developing that code, so
On Thu, 2008-10-02 at 10:49 +0200, Martijn Dashorst wrote:
Though I'm not in favor of dropping the community requirements for
graduation, I must disagree with the following, based on our license:
On Wed, Oct 1, 2008 at 1:32 AM, Upayavira [EMAIL PROTECTED] wrote:
We are not yet confident
Hi,
On Tue, Sep 30, 2008 at 7:01 AM, Henning Schmiedehausen
[EMAIL PROTECTED] wrote:
I did vote -1 not because I think that the current position is all fun and
games, but because it is the adopted policy of the incubator as stated
on the incubator pages. Changing it on a whim through a vote
While I agree, I still feel, that you are doctoring on the symptoms
(release distribution channels) and not the cause. The cause is that
Apache Incubator projects and releases are not fully endorsed by the
ASF until graduation.
Change that. Then everything else falls into place. Personally, I
Henning Schmiedehausen wrote:
The cause is that
Apache Incubator projects and releases are not fully endorsed by the
ASF until graduation.
Is that true? They're releases by a PMC, just like any other, no? They
generally have more oversight than other releases, not less.
Change that. Then
On Tue, 2008-09-30 at 15:50 -0700, Henning Schmiedehausen wrote:
While I agree, I still feel, that you are doctoring on the symptoms
(release distribution channels) and not the cause. The cause is that
Apache Incubator projects and releases are not fully endorsed by the
ASF until graduation.
a much deeper
disagreement over the status of incubating releases, and that we
really should reach some consensus on that before nailing down
decisions on release distribution.
AFAUI there are three positions that people are advocating:
a) Releases with no other strings than the ALv2 attached
On Sep 29, 2008, at 10:03 AM, Matt Hogstrom wrote:
Thinking about this as the thread has drawn on has caused me to
change my mind from a -1 to a +1. The reason for the shift is my
own twisted rationale that
a) users most likely don't care about dependencies a project uses
but are more
On Fri, 2008-09-26 at 14:41 +0200, Jukka Zitting wrote:
Hi,
Branching off from the release distribution vote.
On Fri, Sep 26, 2008 at 2:31 PM, Jukka Zitting [EMAIL PROTECTED] wrote:
This vote has made it quite clear that we have a much deeper
disagreement over the status of incubating
On Sun, Sep 28, 2008 at 9:12 AM, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
Davanum Srinivas wrote:
Fine...Please state your *specific* use case scenario that is
problematic right now
The problem set is that this thread now exceeds 500 posts in four
years, with only one technically
You mean the Maven Way or the high way.
We did the VOTE and everyone has stated their opinions. Why bring it
up again and again?
-- dims
On Sat, Sep 27, 2008 at 9:12 PM, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
Davanum Srinivas wrote:
Fine...Please state your *specific* use case scenario
On 27-Sep-08, at 9:05 PM, Davanum Srinivas wrote:
Unfortunately a typical response from you. Guess there's no point in
even trying..
Where the line of reasoning is unsound and shows a cavalier disregard
for users there would be no point.
I am a practical person above all else, and I
On 28-Sep-08, at 7:33 AM, Davanum Srinivas wrote:
You mean the Maven Way or the high way.
I think Bill is referring to the ASL Way.
We did the VOTE and everyone has stated their opinions. Why bring it
up again and again?
-- dims
On Sat, Sep 27, 2008 at 9:12 PM, William A. Rowe, Jr.
Hi,
On Sun, Sep 28, 2008 at 1:33 PM, Davanum Srinivas [EMAIL PROTECTED] wrote:
We did the VOTE and everyone has stated their opinions. Why bring it
up again and again?
I'm keeping this alive to better understand and perhaps somehow
address the concerns of the people who opposed the change.
Looks like we need a place to show case the people who don't get the
apache way. namely the folks who voted -1
-1 Ant Elder
-1 Craig Russell
-1 Emmanuel Lecharny
-1 Henning Schmiedehausen
-1 Jim Jagielski
-1 Justin Erenkrantz
-1 Kevan Miller
-1 Matt Hogstrom
-1
Jukka,
I'll repeat again. The solution currently imposed is not ideal. It's
not working. Problem is there is no other way.
For example, If the releases were signed and maven had a way for folks
to add say a gpg key before they could use artifacts from a repo, we
could put up a web page for the
Hi,
On Sun, Sep 28, 2008 at 4:19 PM, Davanum Srinivas [EMAIL PROTECTED] wrote:
I'll repeat again. The solution currently imposed is not ideal. It's
not working. Problem is there is no other way.
Thanks for the patience! :-)
I'm not that interested in the technical issues. I just don't
On Sat, Sep 27, 2008 at 10:45 AM, Jukka Zitting [EMAIL PROTECTED]wrote:
Hi,
On Sat, Sep 27, 2008 at 7:10 PM, Davanum Srinivas [EMAIL PROTECTED]
wrote:
Since disclaimers are not part of the Apache License, they are no
obligated to. All we are trying to do here is to not let our folks use
Hi,
On Sun, Sep 28, 2008 at 7:48 PM, Matthieu Riou [EMAIL PROTECTED] wrote:
On Sat, Sep 27, 2008 at 10:45 AM, Jukka Zitting [EMAIL PROTECTED]wrote:
Why should things be more complex for the users of project B?
It wouldn't. Project B would have the incubator repository included in its
list.
On Sun, Sep 28, 2008 at 11:05 AM, Jukka Zitting [EMAIL PROTECTED]wrote:
Hi,
On Sun, Sep 28, 2008 at 7:48 PM, Matthieu Riou [EMAIL PROTECTED]
wrote:
On Sat, Sep 27, 2008 at 10:45 AM, Jukka Zitting [EMAIL PROTECTED]
wrote:
Why should things be more complex for the users of project B?
Hi,
On Sun, Sep 28, 2008 at 8:14 PM, Matthieu Riou [EMAIL PROTECTED] wrote:
On Sun, Sep 28, 2008 at 11:05 AM, Jukka Zitting [EMAIL PROTECTED]wrote:
If that's the case, then what's the point of having a separate repository?
That the project B would have to, as much as possible, conscientiously
On Sun, Sep 28, 2008 at 11:27 AM, Jukka Zitting [EMAIL PROTECTED]wrote:
Hi,
On Sun, Sep 28, 2008 at 8:14 PM, Matthieu Riou [EMAIL PROTECTED]
wrote:
On Sun, Sep 28, 2008 at 11:05 AM, Jukka Zitting [EMAIL PROTECTED]
wrote:
If that's the case, then what's the point of having a separate
Hi,
On Sun, Sep 28, 2008 at 9:40 PM, Matthieu Riou [EMAIL PROTECTED] wrote:
On Sun, Sep 28, 2008 at 11:27 AM, Jukka Zitting [EMAIL PROTECTED]wrote:
That person would already have seen the incubating web site, the
release notes and most likely also the README, all of which come with
our
there now).
But then we have comments like the following that make me believe that
quite a few people *did* vote based on that objection.
Craig:
With Maven, it is too easy to depend on a release with transitive
dependencies on incubating releases without even knowing it.
Noel:
Maven is *too
:
With Maven, it is too easy to depend on a release with transitive
dependencies on incubating releases without even knowing it.
Noel:
Maven is *too* transparent in what it does: it hides the disclaimer,
preventing the POLICY of ensuring that users are explicitly aware of
and agree to use
Hi,
On Sat, Sep 27, 2008 at 1:53 PM, Davanum Srinivas [EMAIL PROTECTED] wrote:
Because we (Apache) control the distribution channel?
Do you meant that if someone else distributes our releases, then they
don't need to make the end user explicitly aware of the incubation
disclaimers?
BR,
Jukka
Jukka,
Since disclaimers are not part of the Apache License, they are no
obligated to. All we are trying to do here is to not let our folks use
a channel where it's not explicit.
Even if all the other channels strip out all the incubator
disclaimers, there's nothing we can do about it. and is
Hi,
On Sat, Sep 27, 2008 at 7:10 PM, Davanum Srinivas [EMAIL PROTECTED] wrote:
Since disclaimers are not part of the Apache License, they are no
obligated to. All we are trying to do here is to not let our folks use
a channel where it's not explicit.
Even if all the other channels strip out
Davanum Srinivas wrote:
Because we (Apache) control the distribution channel?
Nope. We control several distribution channels; offhand...
www.apache.org/dist/{tlp}/
- ASF-wide policies (TLP 3x +1, more +1 than -1)
www.apache.org/dist/incubator/podling/
- Incubator policies (+
Right, that's why my VOTE was the way it was. Please check my VOTE :)
-- dims
On Sat, Sep 27, 2008 at 4:43 PM, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
Davanum Srinivas wrote:
Because we (Apache) control the distribution channel?
Nope. We control several distribution channels;
I know...hence my VOTE was what it was.
-- dims
On Sat, Sep 27, 2008 at 1:45 PM, Jukka Zitting [EMAIL PROTECTED] wrote:
Hi,
On Sat, Sep 27, 2008 at 7:10 PM, Davanum Srinivas [EMAIL PROTECTED] wrote:
Since disclaimers are not part of the Apache License, they are no
obligated to. All we are
Hi,
On Sat, Sep 27, 2008 at 11:21 PM, Davanum Srinivas [EMAIL PROTECTED] wrote:
I know...hence my VOTE was what it was.
So my questions go out to people who opposed the proposed policy change:
1) Is it OK for project A to bundle the incubating dependency?
2) If yes, why should things be more
Davanum Srinivas wrote:
Right, that's why my VOTE was the way it was. Please check my VOTE :)
Didn't argue with your vote; argued with your statement/query :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Bill,
It's an opinion. People are allowed to have them :)
-- dims
On Sat, Sep 27, 2008 at 5:38 PM, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
Davanum Srinivas wrote:
Right, that's why my VOTE was the way it was. Please check my VOTE :)
Didn't argue with your vote; argued with your
I'll bite again :)
My earlier reasoning was that for folks who use Ant, there's an
off-chance that they will see the jars and possibly the disclaimers
when they are creating their build or deployment environment.
Maven makes it too easy and hides too much that they will not get a
chance to run
On 27-Sep-08, at 4:43 PM, William A. Rowe, Jr. wrote:
Davanum Srinivas wrote:
Because we (Apache) control the distribution channel?
Nope. We control several distribution channels; offhand...
www.apache.org/dist/{tlp}/
- ASF-wide policies (TLP 3x +1, more +1 than -1)
Jason van Zyl wrote:
maven repository
- Maven TLP (now that ASF has absorbed Maven server)
The ASF has not absorbed the Maven server.
Color me confused for having approved colocation expenses some
2 meetings back. This did not happen or will not happen?
And since we are paying for it...who (maven pmc?) exactly is tasked
with taking care of it?
thanks,
dims
On Sat, Sep 27, 2008 at 6:13 PM, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
Jason van Zyl wrote:
maven repository
- Maven TLP (now that ASF has absorbed Maven server)
The ASF has
On 27-Sep-08, at 6:13 PM, William A. Rowe, Jr. wrote:
Jason van Zyl wrote:
maven repository
- Maven TLP (now that ASF has absorbed Maven server)
The ASF has not absorbed the Maven server.
Color me confused for having approved colocation expenses some
2 meetings back. This did not
Let me explain...Control - Telling folks not to copy artifacts into
m2-ibiblio-rsync-repository/ Nothing more, nothing less.
-- dims
On Sat, Sep 27, 2008 at 6:37 PM, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
Strike one
William A. Rowe, Jr. wrote:
Davanum Srinivas wrote:
Because we
Davanum Srinivas wrote:
And since we are paying for it...who (maven pmc?) exactly is tasked
with taking care of it?
As Jason (and Paul in a side channel) confirm, ASF is not paying for
it at this point. That was my confusion based on an earlier board
resolution.
Jukka,
I see where you are going with this. But what i cannot for the life of
me understand is why adding a tiny snippet of xml to project B's pom
is so objectionable (adding another repo)? No one has yet answered
that question for me.
thanks,
dims
On Sat, Sep 27, 2008 at 5:36 PM, Jukka Zitting
Am asking because, the way the situation is being portrayed is that
anyone using maven is totally unable to use the incubator
artifacts...that's wrong.
thanks,
dims
On Sat, Sep 27, 2008 at 6:46 PM, Davanum Srinivas [EMAIL PROTECTED] wrote:
Jukka,
I see where you are going with this. But what
On 27-Sep-08, at 6:37 PM, Davanum Srinivas wrote:
And since we are paying for it...who (maven pmc?) exactly is tasked
with taking care of it?
I pay for it (which I don't mind, as I consider it part of my
obligation to the Maven user base), and Contegix is responsible for
taking care of
Thanks Jason!! Sorry i had not kept up with the discussion.
-- dims
On Sat, Sep 27, 2008 at 7:08 PM, Jason van Zyl [EMAIL PROTECTED] wrote:
On 27-Sep-08, at 6:37 PM, Davanum Srinivas wrote:
And since we are paying for it...who (maven pmc?) exactly is tasked
with taking care of it?
I pay
0) Ant users do go thru extra steps...no? Technical issues is for
Maven folks to address, not our problem. We add extra steps just so
that users know what they are getting to (exactly as intended)
1) Is that a maven limitation? I don't remember running into that.
Either way, it's for maven to fix
Hi,
On Sun, Sep 28, 2008 at 1:23 AM, Davanum Srinivas [EMAIL PROTECTED] wrote:
0) Ant users do go thru extra steps...no? Technical issues is for
Maven folks to address, not our problem. We add extra steps just so
that users know what they are getting to (exactly as intended)
And then you
Jason,
Exactly why in previous discussions i already asked...Can the maven
folks provide another way to do this? (not showing disclaimers
necessarily, something that the user has to do one time works too.
Example: apt-get and keys)
-- dims
On Sat, Sep 27, 2008 at 7:30 PM, Jason van Zyl [EMAIL
Davanum Srinivas wrote:
Exactly why in previous discussions i already asked...Can the maven
folks provide another way to do this? (not showing disclaimers
necessarily, something that the user has to do one time works too.
Example: apt-get and keys)
WHY do you keep conflating the idea of
Fine...Please state your *specific* use case scenario that is
problematic right now
-- dims
On Sat, Sep 27, 2008 at 8:17 PM, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
Davanum Srinivas wrote:
Exactly why in previous discussions i already asked...Can the maven
folks provide another way to
On 27-Sep-08, at 7:46 PM, Davanum Srinivas wrote:
Jason,
Exactly why in previous discussions i already asked...Can the maven
folks provide another way to do this? (not showing disclaimers
necessarily, something that the user has to do one time works too.
Example: apt-get and keys)
We could
Unfortunately a typical response from you. Guess there's no point in
even trying..
-- dims
On Sat, Sep 27, 2008 at 8:25 PM, Jason van Zyl [EMAIL PROTECTED] wrote:
On 27-Sep-08, at 7:46 PM, Davanum Srinivas wrote:
Jason,
Exactly why in previous discussions i already asked...Can the maven
Davanum Srinivas wrote:
Fine...Please state your *specific* use case scenario that is
problematic right now
The problem set is that this thread now exceeds 500 posts in four
years, with only one technically appropriate conclusion.
Bill
On Fri, 2008-09-26 at 14:41 +0200, Jukka Zitting wrote:
Hi,
Branching off from the release distribution vote.
On Fri, Sep 26, 2008 at 2:31 PM, Jukka Zitting [EMAIL PROTECTED] wrote:
This vote has made it quite clear that we have a much deeper
disagreement over the status of incubating
Hi,
On Fri, Sep 26, 2008 at 3:05 PM, Upayavira [EMAIL PROTECTED] wrote:
* Do we want users to have easy access to these releases, or to make
it difficult? Users need to know about the fact that Apache does not
yet vouch for the community behind these releases. How do we go
about
that a downstream project should not be able to have an
incubating dependency that gets automatically downloaded and used
without manual intervention by the user. See comments like it is too
easy to depend on a release with transitive dependencies on incubating
releases without even knowing it. As far
it quite clear that we have a much deeper
disagreement over the status of incubating releases, and that we
really should reach some consensus on that before nailing down
decisions on release distribution.
AFAUI there are three positions that people are advocating:
a) Releases
on a release with transitive dependencies on incubating
releases without even knowing it. As far as I understand this
objection covers not only the Maven repository but any bundling of
incubating releases. The end user should always explicitly download or
at least acknowledge an incubating dependency
66 matches
Mail list logo
