"Craig McClanahan" <[EMAIL PROTECTED]> writes:
> Is everyone in ASF willing to be comfortable with the ASF stamp of
> approval on a project that might still be in the process of vetting
> code provenance, or still checking licenses, but chooses to do an
> incubating release anyway?
No, of course
On Saturday 17 March 2007 11:40, Noel J. Bergman wrote:
> One significant difference between ASF projects and those in the Incubator
> is that the ASF projects are communities that have already demonstrated
> their ability to operate under ASF policy *and* sustain a development
> community. Once
Let's be clear, the central repo can host apache incubating artifacts,
it's not its business, it's an ASF business.
Now, only the ASF can publish under org.apache groupId through the
repos setup in the ASF boxes that are automatically setup
But if John Doe decides to publish an incubator artifac
Martijn Dashorst wrote:
> Noel J. Bergman wrote:
> > Incubator releases are considerably different from those of every
> > other ASF PMC. A ASF Community is expected to stand behind and
> > maintain its releases.
> But even those communities can dry out and grind to a halt. It is not
> that the
On Mar 16, 2007, at 10:03 AM, Craig McClanahan wrote:
On 3/16/07, Yoav Shapira <[EMAIL PROTECTED]> wrote:
Hi,
On 3/16/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> Is everyone in ASF willing to be comfortable with the ASF stamp of
> approval on a project that might still be in the process
On 3/16/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
Incubator releases are considerably different from those of every other ASF
PMC. A ASF Community is expected to stand behind and maintain its releases.
But even those communities can dry out and grind to a halt. It is not
that the foundati
Craig McClanahan wrote:
> we have a bunch of other hoops that we still force on incubating
> podlings that should be removed as well.
Such as?
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional command
Craig McClanahan wrote:
> The policy I'm most concerned with in this thread is whether
> incubating project releases are "official" Apache releases, that
> provide the ASF legal protections to the authors, and assurances to
> the downstream users that ASF has done its usual vetting of these
> relea
On 3/16/07, Yoav Shapira <[EMAIL PROTECTED]> wrote:
Hi,
On 3/16/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> Is everyone in ASF willing to be comfortable with the ASF stamp of
> approval on a project that might still be in the process of vetting
> code provenance, or still checking licenses
Hi,
On 3/16/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
Is everyone in ASF willing to be comfortable with the ASF stamp of
approval on a project that might still be in the process of vetting
code provenance, or still checking licenses, but chooses to do an
incubating release anyway?
I don'
On 3/16/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
The policy I'm most concerned with in this thread is whether
incubating project releases are "official" Apache releases, that
provide the ASF legal protections to the authors, and assurances to
the downstream users that ASF has done its usua
On Mar 16, 2007, at 8:42 AM, Craig McClanahan wrote:
Is everyone in ASF willing to be comfortable with the ASF stamp of
approval on a project that might still be in the process of vetting
code provenance, or still checking licenses, but chooses to do an
incubating release anyway?
As Dims, said
On 3/16/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
Is everyone in ASF willing to be comfortable with the ASF stamp of
approval on a project that might still be in the process of vetting
code provenance, or still checking licenses, but chooses to do an
incubating release anyway?
Hell No!.
Looks like the request from Jochen was already acted upon.
http://www.mail-archive.com/dev@maven.apache.org/msg62065.html
thanks,
dims
On 3/16/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
On 3/16/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> ASL may give you the right as an individual to
On 3/16/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:
Craig, the point is that downstream users may not be required to add a
setting. If I depend on A, and A depends on IncubatorB, I
would get IncubatorB without needing a setting if the pom
for A has that setting in it.
An argument for dumpin
On 3/16/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
ASL may give you the right as an individual to do something with the code,
but it does not give you the right, as an ASF Committer, to violate ASF
policy. Nor the right to distribute something as an ASF artifact that is
not one.
As I alre
Jochen Wiedmann wrote:
> Craig McClanahan wrote:
> > * Some Apache folks are violating our own rules by pushing
> > these artifacts into our own dist directory (which gets mirrored
> > there).
> Guilty. I have personally uploaded Woden jar files. And I see no
> reason why I should stop doing
On Friday 16 March 2007 10:55, Craig McClanahan wrote:
> On 3/15/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
> > In other words, your intention that users have "to configure any
> > repository" is lost. You cannot prevent that. Or are you telling me
> > that the owner of the incubator artifacts
On 3/16/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
* Some Apache folks are violating our own rules by pushing
these artifacts into our own dist directory (which gets mirrored
there).
Guilty. I have personally uploaded Woden jar files. And I see no
reason why I should stop doing so. T
On 3/15/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
On 3/16/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
[...]
> using the normal Apache distribution network to make them available,
> and (for Maven users) not even making it visible that you're using a
> non-official release because they d
On 3/16/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
[...]
using the normal Apache distribution network to make them available,
and (for Maven users) not even making it visible that you're using a
non-official release because they didn't have to configure any
repository, you blur the distinct
21 matches
Mail list logo