Again: The Maven Repository

[Jukka Zitting]

Hi,

So far, despite lots of discussion, we haven't come up with a
consensus on this issue. I plan to start a majority vote on this to
settle the debate one way or another, but before that (and to avoid
dissolving the vote thread into another debate) I'd like to ask anyone
interested to bring up any new insight that hasn't yet been discussed.

Much of the debate so far has been rather abstract, so I think it
would help to highlight two concrete examples of what issues this
policy causes:

a) The incubating Apache Sling project just released a set of
artifacts in the m2-incubating-repository. Since these artifacts are
not in the standard repository, we end up with issues [1] and need to
document workarounds [2]. Is this really necessary?

b) The incubating Apache PDFBox project will sooner or later make an
incubating release. Previous PDFBox releases are already in the
central Maven repository and are being heavily used from there. Do we
really need to require (and instruct) downstream users to modify their
Maven settings just to get a PDFBox version upgrade?

The current Maven repository policy makes life more difficult for many
incubating projects and their users. Are these drawbacks worth the
benefits?

[1] https://issues.apache.org/jira/browse/SLING-555
[2] http://incubator.apache.org/sling/site/getting-and-building-sling.html

BR,

Jukka Zitting

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[dims]

Jukka,

My guess is this issue will keep coming up *TILL* the folks who want
this to happen get their way! sigh! :(

-- dims

On 6/26/08, Jukka Zitting <jukka.zitting@...> wrote:

> Hi,
>
> So far, despite lots of discussion, we haven't come up with a
> consensus on this issue. I plan to start a majority vote on this to
> settle the debate one way or another, but before that (and to avoid
> dissolving the vote thread into another debate) I'd like to ask anyone
> interested to bring up any new insight that hasn't yet been discussed.
>
> Much of the debate so far has been rather abstract, so I think it
> would help to highlight two concrete examples of what issues this
> policy causes:
>
> a) The incubating Apache Sling project just released a set of
> artifacts in the m2-incubating-repository. Since these artifacts are
> not in the standard repository, we end up with issues [1] and need to
> document workarounds [2]. Is this really necessary?
>
> b) The incubating Apache PDFBox project will sooner or later make an
> incubating release. Previous PDFBox releases are already in the
> central Maven repository and are being heavily used from there. Do we
> really need to require (and instruct) downstream users to modify their
> Maven settings just to get a PDFBox version upgrade?
>
> The current Maven repository policy makes life more difficult for many
> incubating projects and their users. Are these drawbacks worth the
> benefits?
>
> [1] https://issues.apache.org/jira/browse/SLING-555
> [2] http://incubator.apache.org/sling/site/getting-and-building-sling.html
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@...
> For additional commands, e-mail: general-help@...
>
>

--
Davanum Srinivas :: http://davanum.wordpress.com

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[lhazlewood]

JSecurity also meets condition b)

Our users will scream bloody murder if they can no longer access
JSecurity from the central repository.  So we'll continue to publish
there, even if it means publishing under the old org.jsecurity group
id.

On Thu, Jun 26, 2008 at 8:35 AM, Davanum Srinivas <davanum@...> wrote:

> Jukka,
>
> My guess is this issue will keep coming up *TILL* the folks who want
> this to happen get their way! sigh! :(
>
> -- dims
>
> On 6/26/08, Jukka Zitting <jukka.zitting@...> wrote:
>> Hi,
>>
>> So far, despite lots of discussion, we haven't come up with a
>> consensus on this issue. I plan to start a majority vote on this to
>> settle the debate one way or another, but before that (and to avoid
>> dissolving the vote thread into another debate) I'd like to ask anyone
>> interested to bring up any new insight that hasn't yet been discussed.
>>
>> Much of the debate so far has been rather abstract, so I think it
>> would help to highlight two concrete examples of what issues this
>> policy causes:
>>
>> a) The incubating Apache Sling project just released a set of
>> artifacts in the m2-incubating-repository. Since these artifacts are
>> not in the standard repository, we end up with issues [1] and need to
>> document workarounds [2]. Is this really necessary?
>>
>> b) The incubating Apache PDFBox project will sooner or later make an
>> incubating release. Previous PDFBox releases are already in the
>> central Maven repository and are being heavily used from there. Do we
>> really need to require (and instruct) downstream users to modify their
>> Maven settings just to get a PDFBox version upgrade?
>>
>> The current Maven repository policy makes life more difficult for many
>> incubating projects and their users. Are these drawbacks worth the
>> benefits?
>>
>> [1] https://issues.apache.org/jira/browse/SLING-555
>> [2] http://incubator.apache.org/sling/site/getting-and-building-sling.html
>>
>> BR,
>>
>> Jukka Zitting
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@...
>> For additional commands, e-mail: general-help@...
>>
>>
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@...
> For additional commands, e-mail: general-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[lhazlewood]

I'll just append that I, and I'm sure the huge majority of people in
the world that use Maven, would find it incredibly irritating if
incubator releases were not automatically available in the central
repository.

So a huge +1 to enable this.

On Thu, Jun 26, 2008 at 9:23 AM, Les Hazlewood <les@...> wrote:

> JSecurity also meets condition b)
>
> Our users will scream bloody murder if they can no longer access
> JSecurity from the central repository.  So we'll continue to publish
> there, even if it means publishing under the old org.jsecurity group
> id.
>
> On Thu, Jun 26, 2008 at 8:35 AM, Davanum Srinivas <davanum@...> wrote:
>> Jukka,
>>
>> My guess is this issue will keep coming up *TILL* the folks who want
>> this to happen get their way! sigh! :(
>>
>> -- dims
>>
>> On 6/26/08, Jukka Zitting <jukka.zitting@...> wrote:
>>> Hi,
>>>
>>> So far, despite lots of discussion, we haven't come up with a
>>> consensus on this issue. I plan to start a majority vote on this to
>>> settle the debate one way or another, but before that (and to avoid
>>> dissolving the vote thread into another debate) I'd like to ask anyone
>>> interested to bring up any new insight that hasn't yet been discussed.
>>>
>>> Much of the debate so far has been rather abstract, so I think it
>>> would help to highlight two concrete examples of what issues this
>>> policy causes:
>>>
>>> a) The incubating Apache Sling project just released a set of
>>> artifacts in the m2-incubating-repository. Since these artifacts are
>>> not in the standard repository, we end up with issues [1] and need to
>>> document workarounds [2]. Is this really necessary?
>>>
>>> b) The incubating Apache PDFBox project will sooner or later make an
>>> incubating release. Previous PDFBox releases are already in the
>>> central Maven repository and are being heavily used from there. Do we
>>> really need to require (and instruct) downstream users to modify their
>>> Maven settings just to get a PDFBox version upgrade?
>>>
>>> The current Maven repository policy makes life more difficult for many
>>> incubating projects and their users. Are these drawbacks worth the
>>> benefits?
>>>
>>> [1] https://issues.apache.org/jira/browse/SLING-555
>>> [2] http://incubator.apache.org/sling/site/getting-and-building-sling.html
>>>
>>> BR,
>>>
>>> Jukka Zitting
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@...
>>> For additional commands, e-mail: general-help@...
>>>
>>>
>>
>>
>> --
>> Davanum Srinivas :: http://davanum.wordpress.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@...
>> For additional commands, e-mail: general-help@...
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[Martijn Dashorst]

On Thu, Jun 26, 2008 at 3:23 PM, Les Hazlewood <les@...> wrote:
> JSecurity also meets condition b)
>
> Our users will scream bloody murder if they can no longer access
> JSecurity from the central repository.  So we'll continue to publish
> there, even if it means publishing under the old org.jsecurity group
> id.

Which is perfectly fine IMO. Wicket did the same, just not the Apache
Wicket code. It is the aim to stay in the incubator as short as
possible. This means that you need to focus on meeting the graduation
criteria: create a diverse open meritocratic community, ensure all
legal bits are resolved and release your code (at least once). I would
therefore continue maintaining the old jsecurity code, and release
those outside the incubator, just as normal business for your project.
This provides the necessary stability for your users, and prevent them
from screaming bloody murder. New development (pick enough features to
keep you busy for a couple of months - year) should happen in the
incubator code base, so you can add new developers, and learn to work
the Apache Way (tm). I'd suggest also to rename the packages only when
you are almost ready to graduate. This allows you to merge current
development and maintenance quite easily.

THe WIcket project did have all code imported into the incubator repo,
so we could easily backport features/bug fixes. We just released the
artifacts on sourceforge and uploaded them ourselves to the central
repo using the outside channels. We *did* make perfectly clear that
even though Wicket is in the incubator, that the release wasn't
endorsed by nor associated with Apache. You can look at the releases
for Wicket 1.2 (http://wicketframework.org/wicket-1.2) to see how we
did this.

The Apache based development (org.apache.wicket) happened in parallel,
but for the most part in the same namespace as the old wicket code. We
did create a couple of releases inside the incubator to learn how to
perform an Apache release. But iirc we never actually published those
releases to the greater public.

This process worked great for Wicket, but your mileage may vary.

Martijn

--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[lhazlewood]

Martijn,

This is excellent feedback, thanks very much!

That being said, it would make everyone's lives easier if incubator
releases were in the central repository, so I still vote +1 on that ;)

On Thu, Jun 26, 2008 at 9:39 AM, Martijn Dashorst
<martijn.dashorst@...> wrote:

> On Thu, Jun 26, 2008 at 3:23 PM, Les Hazlewood <les@...> wrote:
>> JSecurity also meets condition b)
>>
>> Our users will scream bloody murder if they can no longer access
>> JSecurity from the central repository.  So we'll continue to publish
>> there, even if it means publishing under the old org.jsecurity group
>> id.
>
> Which is perfectly fine IMO. Wicket did the same, just not the Apache
> Wicket code. It is the aim to stay in the incubator as short as
> possible. This means that you need to focus on meeting the graduation
> criteria: create a diverse open meritocratic community, ensure all
> legal bits are resolved and release your code (at least once). I would
> therefore continue maintaining the old jsecurity code, and release
> those outside the incubator, just as normal business for your project.
> This provides the necessary stability for your users, and prevent them
> from screaming bloody murder. New development (pick enough features to
> keep you busy for a couple of months - year) should happen in the
> incubator code base, so you can add new developers, and learn to work
> the Apache Way (tm). I'd suggest also to rename the packages only when
> you are almost ready to graduate. This allows you to merge current
> development and maintenance quite easily.
>
> THe WIcket project did have all code imported into the incubator repo,
> so we could easily backport features/bug fixes. We just released the
> artifacts on sourceforge and uploaded them ourselves to the central
> repo using the outside channels. We *did* make perfectly clear that
> even though Wicket is in the incubator, that the release wasn't
> endorsed by nor associated with Apache. You can look at the releases
> for Wicket 1.2 (http://wicketframework.org/wicket-1.2) to see how we
> did this.
>
> The Apache based development (org.apache.wicket) happened in parallel,
> but for the most part in the same namespace as the old wicket code. We
> did create a couple of releases inside the incubator to learn how to
> perform an Apache release. But iirc we never actually published those
> releases to the greater public.
>
> This process worked great for Wicket, but your mileage may vary.
>
> Martijn
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.3 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@...
> For additional commands, e-mail: general-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[Jukka Zitting]

Hi,

On Thu, Jun 26, 2008 at 3:35 PM, Davanum Srinivas <davanum@...> wrote:
> My guess is this issue will keep coming up *TILL* the folks who want
> this to happen get their way! sigh! :(

That's why I plan to call a vote on the matter. That should close the issue.

BR,

Jukka Zitting

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[Emmanuel Lecharny]

Hi Martijn,

Martijn Dashorst wrote:
> I would
> therefore continue maintaining the old jsecurity code, and release
> those outside the incubator, just as normal business for your project.
>  
There are options. Maintaining the old repo can be tough, as the
repository will be different, and make merges difficult. Another
possibility is to deploy the new jars into more than one maven repo :
incubator's and current jsecurity's repo.
> <snip/>
> I'd suggest also to rename the packages only when
> you are almost ready to graduate. This allows you to merge current
> development and maintenance quite easily.
>  
This is only if you intent to keep both subversion repo alive in //. But
if users base their development on apache Jsecurity version, they will
find it painfull to change the package at the very last moment. Don't
know ... What if they release a preliminary version on Apache with the
new packages, and make it the base for the incubator developments, so
that users can use it straight away and benefit from the new features
JSecurity will implement in the near future ? It can alleviate the
burden of maintaining two different code bases, out of which one is
known to be dead...
> THe WIcket project did have all code imported into the incubator repo,
> so we could easily backport features/bug fixes. We just released the
> artifacts on sourceforge and uploaded them ourselves to the central
> repo using the outside channels. We *did* make perfectly clear that
> even though Wicket is in the incubator, that the release wasn't
> endorsed by nor associated with Apache. You can look at the releases
> for Wicket 1.2 (http://wicketframework.org/wicket-1.2) to see how we
> did this.
>  
This work too. Depends on the existing user's base, I guess ?
> The Apache based development (org.apache.wicket) happened in parallel,
> but for the most part in the same namespace as the old wicket code. We
> did create a couple of releases inside the incubator to learn how to
> perform an Apache release. But iirc we never actually published those
> releases to the greater public.
>
> This process worked great for Wicket, but your mileage may vary.
>  
In any case, Wicket team made it solid. A valuable experience for sure !

Thanks Martijn !


--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[Martijn Dashorst]

On Thu, Jun 26, 2008 at 4:58 PM, Emmanuel Lecharny <elecharny@...> wrote:
>> I'd suggest also to rename the packages only when
>> you are almost ready to graduate. This allows you to merge current
>> development and maintenance quite easily.
>
> This is only if you intent to keep both subversion repo alive in //. But if
> users base their development on apache Jsecurity version, they will find it
> painfull to change the package at the very last moment. Don't know ...

In the Wicket case we migrated the committers to Apache, but left the
user community at sourceforge (our user list was migrated when we
graduated). I think for existing projects that start incubation it is
wise to move the committers first, and users upon graduation. Which
doesn't say that users shouldn't use incubator code, but I'd rather
not depend too heavily on podlings. Not only is there a risk of failed
incubation, the podling will have a different focus while in the
incubator: learning the Apache Way. So during this learning things
will slow down a bit or speed up, depending on how incubation goes.
But you'll see different stages: community building, legal vetting,
release building, etc. These will slow down the podling's feature
matrix implementation.

I think moving to the apache namespace early is not advisable. If the
incubation fails for whatever reason, your users need to migrate their
code twice. For users it it not too big a problem to rename their
packages once. With Wicket we did it at the last possible moment iirc
(at least when we got our act together and started our serious
graduation effort)

> What
> if they release a preliminary version on Apache with the new packages, and
> make it the base for the incubator developments, so that users can use it
> straight away and benefit from the new features JSecurity will implement in
> the near future ? It can alleviate the burden of maintaining two different
> code bases, out of which one is known to be dead...

That is not nice for your existing users that depend on jsecurity in
production systems. The Wicket devs have recently released Wicket
1.2.7 outside the foundation for those systems that are dependent on
wicket 1.2.x code, while we already had 1.3.2 out. Not everybody has
the luxury to migrate with the latest and greatest. Though we did
end-of-life our wicket 1.2.x branch with 1.2.7.

> This work too. Depends on the existing user's base, I guess ?

Which was in the thousands for Wicket at the time, with numerous
systems in production.

Martijn

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[Emmanuel Lecharny]

Martijn Dashorst wrote:
>
>> This work too. Depends on the existing user's base, I guess ?
>>    
>
> Which was in the thousands for Wicket at the time, with numerous
> systems in production.
>  
and it makes perfect sense to follow your way in this case. How many
users does JSecurity has ?

Regarding the potential incubation failure, I would say that the cost of
a double migration will be overwhelmed by the killing effect of this
failure. It's a little bit like picking the lawyer to manage your
divorce before the wedding :).

However, with thousands existing users, like for wicket, it makes sense
too (I don't know how many lawyers Bill Gates consulted before being
married ;)

At this point, the JSecurity team will have to make the best choice.

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[lhazlewood]

I don't know the exact usage, but I'm sure it is in lower thousands -
many people use our .jars directly, but probably many more use it via
3rd party plugins (Grails plugin, etc) that is built on top of
JSecurity.

It sounds as if waiting at the last possible second to move from
org.jsecurity.* to org.apache.jsecurity.* is the best option for us.
That way we can move over to the Apache SVN as soon as possible, but
impact the existing community only when absolutely necessary.

Great advice again Martijn, thanks!

On Thu, Jun 26, 2008 at 11:28 AM, Emmanuel Lecharny
<elecharny@...> wrote:

> Martijn Dashorst wrote:
>>
>>> This work too. Depends on the existing user's base, I guess ?
>>>
>>
>> Which was in the thousands for Wicket at the time, with numerous
>> systems in production.
>>
>
> and it makes perfect sense to follow your way in this case. How many users
> does JSecurity has ?
>
> Regarding the potential incubation failure, I would say that the cost of a
> double migration will be overwhelmed by the killing effect of this failure.
> It's a little bit like picking the lawyer to manage your divorce before the
> wedding :).
>
> However, with thousands existing users, like for wicket, it makes sense too
> (I don't know how many lawyers Bill Gates consulted before being married ;)
>
> At this point, the JSecurity team will have to make the best choice.
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@...
> For additional commands, e-mail: general-help@...
>
>

[Emmanuel Lecharny]

Les Hazlewood wrote:

> I don't know the exact usage, but I'm sure it is in lower thousands -
> many people use our .jars directly, but probably many more use it via
> 3rd party plugins (Grails plugin, etc) that is built on top of
> JSecurity.
>
> It sounds as if waiting at the last possible second to move from
> org.jsecurity.* to org.apache.jsecurity.* is the best option for us.
> That way we can move over to the Apache SVN as soon as possible, but
> impact the existing community only when absolutely necessary.
>  

Sounds reasonnable too. Thanks to modern IDE, package renaming is just a
matter of minutes (as soon as you don't forget to modify the Spring
files - or any other container using class names - :)

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[lhazlewood]

Thanks to IntelliJ Idea, which updates our Spring and Hibernate files
automatically during refactoring already, even this isn't an issue for
us (thankfully).  We should be good!

On Thu, Jun 26, 2008 at 11:49 AM, Emmanuel Lecharny
<elecharny@...> wrote:

> Les Hazlewood wrote:
>>
>> I don't know the exact usage, but I'm sure it is in lower thousands -
>> many people use our .jars directly, but probably many more use it via
>> 3rd party plugins (Grails plugin, etc) that is built on top of
>> JSecurity.
>>
>> It sounds as if waiting at the last possible second to move from
>> org.jsecurity.* to org.apache.jsecurity.* is the best option for us.
>> That way we can move over to the Apache SVN as soon as possible, but
>> impact the existing community only when absolutely necessary.
>>
>
> Sounds reasonnable too. Thanks to modern IDE, package renaming is just a
> matter of minutes (as soon as you don't forget to modify the Spring files -
> or any other container using class names - :)
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@...
> For additional commands, e-mail: general-help@...
>
>

[lhazlewood]

Oops, I feel this hijacked Jukka's thread.

So, what about the following Maven repo statement?

Incubating projects won't be published to the main repository under
the org.apache group ID, but they are free to publish to other group
ids of their choosing.

This means existing projects that enter the incubator who already
publish to the main repo would probably retain their source code
packaging namespaces until the project graduates.

Is that acceptable?

On Thu, Jun 26, 2008 at 12:02 PM, Les Hazlewood <les@...> wrote:

> Thanks to IntelliJ Idea, which updates our Spring and Hibernate files
> automatically during refactoring already, even this isn't an issue for
> us (thankfully).  We should be good!
>
> On Thu, Jun 26, 2008 at 11:49 AM, Emmanuel Lecharny
> <elecharny@...> wrote:
>> Les Hazlewood wrote:
>>>
>>> I don't know the exact usage, but I'm sure it is in lower thousands -
>>> many people use our .jars directly, but probably many more use it via
>>> 3rd party plugins (Grails plugin, etc) that is built on top of
>>> JSecurity.
>>>
>>> It sounds as if waiting at the last possible second to move from
>>> org.jsecurity.* to org.apache.jsecurity.* is the best option for us.
>>> That way we can move over to the Apache SVN as soon as possible, but
>>> impact the existing community only when absolutely necessary.
>>>
>>
>> Sounds reasonnable too. Thanks to modern IDE, package renaming is just a
>> matter of minutes (as soon as you don't forget to modify the Spring files -
>> or any other container using class names - :)
>>
>> --
>> --
>> cordialement, regards,
>> Emmanuel Lécharny
>> www.iktek.com
>> directory.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@...
>> For additional commands, e-mail: general-help@...
>>
>>
>

[dims]

I'd be very surprised if it does close the issue :)

On Thu, Jun 26, 2008 at 10:07 AM, Jukka Zitting <jukka.zitting@...> wrote:

> Hi,
>
> On Thu, Jun 26, 2008 at 3:35 PM, Davanum Srinivas <davanum@...> wrote:
>> My guess is this issue will keep coming up *TILL* the folks who want
>> this to happen get their way! sigh! :(
>
> That's why I plan to call a vote on the matter. That should close the issue.
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@...
> For additional commands, e-mail: general-help@...
>
>

--
Davanum Srinivas :: http://davanum.wordpress.com

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[Bertrand Delacretaz]

On Thu, Jun 26, 2008 at 6:45 PM, Davanum Srinivas <davanum@...> wrote:
> I'd be very surprised if it does close the issue :)...

IMHO voting about where to put incubator Maven artifacts is a majority
vote among of the Incubator PMC, so that should allow us to move
forward, even if we're not unanimous.

-Bertrand

>
> On Thu, Jun 26, 2008 at 10:07 AM, Jukka Zitting <jukka.zitting@...> wrote:
>> Hi,
>>
>> On Thu, Jun 26, 2008 at 3:35 PM, Davanum Srinivas <davanum@...> wrote:
>>> My guess is this issue will keep coming up *TILL* the folks who want
>>> this to happen get their way! sigh! :(
>>
>> That's why I plan to call a vote on the matter. That should close the issue.
>>
>> BR,
>>
>> Jukka Zitting
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: