Re: [VFS] .jar named directories VFS-490

Bernd Eckenfels wrote: > Am 09.10.2013, 21:53 Uhr, schrieb Mark Fortner : > >> In your previous posting about VFS-490 you mentioned not wanting to >> browse >> JAR files as though they were directories. It would be nice if that was >> configurable -- I actually use that functionality and find it

Re: [DISCUSS] Putting several unmaintained components to dormant

On 10/10/2013 12:24 AM, Torsten Curdt wrote: Every now and then I keep getting requests via private mail asking to release javaflow as it seems to be working for people. Yet I know there is still so much essential stuff to fix for a 1.0 release. Crossing over to the other thread: I know on githu

Re: [DISCUSS] Putting several unmaintained components to dormant

Hi, Ate Douma wrote: > On 10/10/2013 12:24 AM, Torsten Curdt wrote: >> Every now and then I keep getting requests via private mail asking to >> release javaflow as it seems to be working for people. Yet I know there >> is still so much essential stuff to fix for a 1.0 release. >> >> Crossing over

Re: [DISCUSS] Putting several unmaintained components to dormant

I like the idea of releasing 0.x versions. A good example is [csv]. I would have no problem with releasing the current trunk as 0.9. At the moment [csv] is just another component we don't releaese because we want to come up with a perfect API (and I take responsibility for that :-) Benedikt Se

[DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]

I've move this into a separate [DISCUSS] thread as I think it needs separate discussion. Jörg gave some objections below about using Milestone releases, as I proposed earlier to support releasing intermediate versions of a not-yet-stabalized component. While I understand his problems with un

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

Sigh, typical mistake of forgetting to provide the link referenced further below: [1] http://commons.apache.org/releases/versioning.html#Milestone_Releases On 10/10/2013 01:26 PM, Ate Douma wrote: I've move this into a separate [DISCUSS] thread as I think it needs separate discussion. Jörg ga

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]

I'm okay with alpha/milestone/rc/whatever. Do we promote them to central or leave them local? Keeping them in-house might help keep folks from incorporating them into production code. However I'm okay with publishing too. Hibernate has done this for years (rc's). On Thursday, October 10, 2013,

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

Rookie ;). You had me at "faster"! :) On Thursday, October 10, 2013, Ate Douma wrote: > Sigh, typical mistake of forgetting to provide the link referenced further > below: > > [1] http://commons.apache.org/**releases/versioning.html#** > Milestone_Releases

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

Le 10/10/2013 13:26, Ate Douma a écrit : > Thoughts? A solution could be to change the package for every preview release. Something like: org.apache.commons.experimental. So, for CSV we could release a 0.8 and 0.9 version under the packages: org.apache.commons.experimental.csv8 org.ap

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

On 10/10/2013 01:36 PM, Emmanuel Bourg wrote: Le 10/10/2013 13:26, Ate Douma a écrit : Thoughts? A solution could be to change the package for every preview release. Something like: org.apache.commons.experimental. So, for CSV we could release a 0.8 and 0.9 version under the packages:

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

Agreed. Keep it simple. On Thursday, October 10, 2013, Ate Douma wrote: > On 10/10/2013 01:36 PM, Emmanuel Bourg wrote: > >> Le 10/10/2013 13:26, Ate Douma a écrit : >> >> Thoughts? >>> >> >> A solution could be to change the package for every preview release. >> Something like: >> >> org.a

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

Le 10/10/2013 13:47, Ate Douma a écrit : > While doing this might be somewhat automated, sure, I still would not > favor this. > I think it tries to solve more of a perceived than an actual problem. I'm afraid this is more than a perceived issue, the plexus-container example given by Jörg is a ve

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

Hi Ate, Ate Douma wrote: > On 10/10/2013 01:36 PM, Emmanuel Bourg wrote: >> Le 10/10/2013 13:26, Ate Douma a écrit : >> >>> Thoughts? >> >> A solution could be to change the package for every preview release. >> Something like: >> >> org.apache.commons.experimental. >> >> So, for CSV we could

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]

I think "milestone" releases works if you have a clear development plan and schedule. I've never seen it be the case in Commons. Calling "releases" to Maven and dist, Alphas and Betas make more sense for us IMO. Gary On Thu, Oct 10, 2013 at 7:26 AM, Ate Douma wrote: > I've move this into a separ

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

On Thu, Oct 10, 2013 at 7:36 AM, Emmanuel Bourg wrote: > Le 10/10/2013 13:26, Ate Douma a écrit : > >> Thoughts? > > A solution could be to change the package for every preview release. > Something like: > >org.apache.commons.experimental. > > So, for CSV we could release a 0.8 and 0.9 version

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

Send from my mobile device > Am 10.10.2013 um 14:44 schrieb Gary Gregory : > >> On Thu, Oct 10, 2013 at 7:36 AM, Emmanuel Bourg wrote: >> Le 10/10/2013 13:26, Ate Douma a écrit : >> >>> Thoughts? >> >> A solution could be to change the package for every preview release. >> Something like: >>

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]

On Thu, Oct 10, 2013 at 8:35 AM, Gary Gregory wrote: > I think "milestone" releases works if you have a clear development > plan and schedule. I've never seen it be the case in Commons. Calling > "releases" to Maven and dist, Alphas and Betas make more sense for us > IMO. > I don't care what we c

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg wrote: > > I'm afraid this is more than a perceived issue, the plexus-container > example given by Jörg is a very good one. Pushing drastically > incompatible versions to Maven Central is not a good service for the users. > > I think my suggestion is

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

On 10/10/2013 03:06 PM, James Carman wrote: On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg wrote: I'm afraid this is more than a perceived issue, the plexus-container example given by Jörg is a very good one. Pushing drastically incompatible versions to Maven Central is not a good service for

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]

On 10/10/2013 03:00 PM, James Carman wrote: On Thu, Oct 10, 2013 at 8:35 AM, Gary Gregory wrote: I think "milestone" releases works if you have a clear development plan and schedule. I've never seen it be the case in Commons. Calling "releases" to Maven and dist, Alphas and Betas make more sens

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]

We definitely need to make sure our naming scheme will work with maven properly. Hopefully commons-foo:1.0 would supercede commons-foo:1.0-M1. Again, I really don't care what we call it, as long as we manage expectations and don't dork up maven. On Thu, Oct 10, 2013 at 9:25 AM, Ate Douma wrote:

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

On Thu, Oct 10, 2013 at 9:06 AM, James Carman wrote: > On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg wrote: >> >> I'm afraid this is more than a perceived issue, the plexus-container >> example given by Jörg is a very good one. Pushing drastically >> incompatible versions to Maven Central is no

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]

On Thu, Oct 10, 2013 at 9:00 AM, James Carman wrote: > On Thu, Oct 10, 2013 at 8:35 AM, Gary Gregory wrote: >> I think "milestone" releases works if you have a clear development >> plan and schedule. I've never seen it be the case in Commons. Calling >> "releases" to Maven and dist, Alphas and Be

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

On 10/10/2013 03:47 PM, Gary Gregory wrote: On Thu, Oct 10, 2013 at 9:06 AM, James Carman wrote: On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg wrote: I'm afraid this is more than a perceived issue, the plexus-container example given by Jörg is a very good one. Pushing drastically incompati

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

I think the idea is that we don't break BC between an older full version and a new alpha/milestone/rc/whatever, unless of course, the new alpha/milestone/rc/whatever release is on a new major version. For example, we can have API breaks between commons-foo-1.0 and commons-foo-2.0-alpha. We can hav

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

On Thu, Oct 10, 2013 at 9:55 AM, Ate Douma wrote: > On 10/10/2013 03:47 PM, Gary Gregory wrote: >> >> On Thu, Oct 10, 2013 at 9:06 AM, James Carman >> wrote: >>> >>> On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg >>> wrote: I'm afraid this is more than a perceived issue, the plex

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

Well, alphas still shouldn't break backward compatibility with a prior *full* release within a major version number. If they do, then it's a bug we need to address it. So, it's not really "anything goes." At least, that's how I'd think about it. Any new APIs are considered "volatile" and subjec

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

On 10/10/2013 04:06 PM, Gary Gregory wrote: On Thu, Oct 10, 2013 at 9:55 AM, Ate Douma wrote: On 10/10/2013 03:47 PM, Gary Gregory wrote: On Thu, Oct 10, 2013 at 9:06 AM, James Carman wrote: On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg wrote: I'm afraid this is more than a perceived

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

On 10/10/2013 04:13 PM, James Carman wrote: Well, alphas still shouldn't break backward compatibility with a prior *full* release within a major version number. If they do, then it's a bug we need to address it. So, it's not really "anything goes." At least, that's how I'd think about it. Any

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

On Thu, Oct 10, 2013 at 10:04 AM, James Carman wrote: > I think the idea is that we don't break BC between an older full > version and a new alpha/milestone/rc/whatever, unless of course, the > new alpha/milestone/rc/whatever release is on a new major version. > For example, we can have API breaks

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

On Thu, Oct 10, 2013 at 10:19 AM, Ate Douma wrote: > > I'm a bit unfamiliar yet with the 'rules' within Commons concerning such > changes. I'm willing to create an issue for this and draft up a > documentation patch for it, but maybe this needs formal voting by the PMC > first? > I'd suggest a vo

Re: [DISCUSS] Moving to Git...

Well, we've had some lengthy discussions about this. I think there is at least enough interest to put it up to a vote. I'll start the thread here shortly. We can continue the discussion on this thread so it doesn't get fragmented. On Mon, Oct 7, 2013 at 10:10 PM, James Carman wrote: > All, > >

[VOTE] Moving to Git...

All, We have had some great discussions about moving our SCM to Git. I think it's time to put it to a vote. So, here we go: +1 - yes, move to Git -1 - no, do not move to Git The vote will be left open for 72 hours. Go! James --

Re: [VOTE] Moving to Git...

Here's my +1 (binding) On Thu, Oct 10, 2013 at 10:41 AM, James Carman wrote: > All, > > We have had some great discussions about moving our SCM to Git. I > think it's time to put it to a vote. So, here we go: > > +1 - yes, move to Git > -1 - no, do not move to Git > > The vote will be left open

Re: [VOTE] Moving to Git...

+1 *Romain Manni-Bucau* *Twitter: @rmannibucau * *Blog: **http://rmannibucau.wordpress.com/* *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/10/10 James Carman > All, > > We h

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

On 10/10/2013 04:31 PM, James Carman wrote: On Thu, Oct 10, 2013 at 10:19 AM, Ate Douma wrote: I'm a bit unfamiliar yet with the 'rules' within Commons concerning such changes. I'm willing to create an issue for this and draft up a documentation patch for it, but maybe this needs formal voting

[VOTE] Move Apache Commons to Git for SCM...

All, We have had some great discussions about moving our SCM to Git. I think it's time to put it to a vote. So, here we go: +1 - yes, move to Git -1 - no, do not move to Git The vote will be left open for 72 hours. Go! - To

Re: [VOTE] Moving to Git...

On Thu, 10 Oct 2013 10:41:11 -0400, James Carman wrote: All, We have had some great discussions about moving our SCM to Git. I think it's time to put it to a vote. So, here we go: +1 - yes, move to Git -1 - no, do not move to Git -1 Some people have indicated that this move might not addre

Re: [VOTE] Moving to Git...

I'm going to start another thread. For me, in gmail, this got combined with the [DISCUSS] thread and I don't want votes to get lost. Consider this [VOTE] canceled! Romain, please vote again in the other thread. Sorry, folks. On Thu, Oct 10, 2013 at 10:41 AM, James Carman wrote: > All, > > We

Re: [VOTE] Move Apache Commons to Git for SCM...

Here's my +1 (binding) On Thu, Oct 10, 2013 at 10:50 AM, James Carman wrote: > All, > > We have had some great discussions about moving our SCM to Git. I > think it's time to put it to a vote. So, here we go: > > +1 - yes, move to Git > -1 - no, do not move to Git > > The vote will be left open

Re: [VOTE] Move Apache Commons to Git for SCM...

+1 - yes, move to Git *Romain Manni-Bucau* *Twitter: @rmannibucau * *Blog: **http://rmannibucau.wordpress.com/* *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/10/10 James Carma

Re: [VOTE] Moving to Git...

@Gilles: that's right (and I'm part of people thinking this is not the main issue) but everybody seems happy to use git instead of svn so let's go *Romain Manni-Bucau* *Twitter: @rmannibucau * *Blog: **http://rmannibucau.wordpress.com/*

Re: [VOTE] Moving to Git...

-0 I'm fine with SVN and the time sucked by the migration could be better spent coding the components (or reviewing the pending release candidates *cough*). That said, Git is now well supported by the tools I use, so I'm not opposed to the transition. Emmanuel Bourg Le 10/10/2013 16:41, James C

Re: [VOTE] Moving to Git...

Could you please restart the thread with a [VOTE] in the subject? Gary On Thu, Oct 10, 2013 at 10:41 AM, James Carman wrote: > All, > > We have had some great discussions about moving our SCM to Git. I > think it's time to put it to a vote. So, here we go: > > +1 - yes, move to Git > -1 - no,

Re: [VOTE] Moving to Git...

Le 10/10/2013 16:49, James Carman a écrit : > I'm going to start another thread. For me, in gmail, this got > combined with the [DISCUSS] thread and I don't want votes to get lost. > Consider this [VOTE] canceled! Romain, please vote again in the > other thread. Sorry, folks. At least in Thund

Re: [VOTE] Moving to Git...

Gary, I actually did. You have to show details in Gmail to see it. For some reason it collapsed the two threads. Sorry for the confusion. There's a new thread already started. Thanks, James On Thu, Oct 10, 2013 at 10:57 AM, Gary Gregory wrote: > Could you please restart the thread with a [V

Re: [VOTE] Moving to Git...

Le 10/10/2013 16:57, Gary Gregory a écrit : > Could you please restart the thread with a [VOTE] in the subject? There is one though: http://www.mail-archive.com/dev@commons.apache.org/msg40574.html Emmanuel Bourg - To unsubscr

Re: [VOTE] Move Apache Commons to Git for SCM...

On Thu, Oct 10, 2013 at 9:50 AM, James Carman wrote: > All, > > We have had some great discussions about moving our SCM to Git. I > think it's time to put it to a vote. So, here we go: > > +1 - yes, move to Git > -1 - no, do not move to Git > > +1 (binding) Matt > The vote will be left open

Re: [VOTE] Moving to Git...

James Carman wrote: > All, > > We have had some great discussions about moving our SCM to Git. I > think it's time to put it to a vote. So, here we go: > > +1 - yes, move to Git > -1 - no, do not move to Git > > The vote will be left open for 72 hours. Go! > > James -1 We have to ensure

Re: [DISCUSS] Moving to Git...

Before I vote on this is someone volunteering to do the work? I assume Infra will take care of the actual move, but there are still web site links that have to be changed. Ralph On Oct 10, 2013, at 7:38 AM, James Carman wrote: > Well, we've had some lengthy discussions about this. I think th

Re: [VOTE] Move Apache Commons to Git for SCM...

On 10/10/2013 15:50, James Carman wrote: > All, > > We have had some great discussions about moving our SCM to Git. I > think it's time to put it to a vote. So, here we go: > > +1 - yes, move to Git > -1 - no, do not move to Git > > The vote will be left open for 72 hours. Go! -1. I'm not co

Re: [DISCUSS] Moving to Git...

Those who vote +1 (contrast with +0) are beholden to assist where needed. :| Matt On Thu, Oct 10, 2013 at 10:04 AM, Ralph Goers wrote: > Before I vote on this is someone volunteering to do the work? I assume > Infra will take care of the actual move, but there are still web site links > that h

Re: [VOTE] Moving to Git...

The ASF has already set up "official" support for Git for their projects. These technical details have already been worked out. There are MANY other projects using Git already (around 1/3 I believe). On Thu, Oct 10, 2013 at 11:04 AM, Jörg Schaible wrote: > James Carman wrote: > >> All, >> >> We

Re: [VFS] developer ping - future direction

I have been working primarily on Log4j 2 for a while. I have always planned to come back to start work on VFS 3 that will integrate with Java 7's java.nio.file support. Ralph On Oct 9, 2013, at 10:38 AM, Bernd Eckenfels wrote: > Dear [VFS] Developer and Contributors, > > Please excuse the

Re: [VOTE] Moving to Git...

On Thu, Oct 10, 2013 at 11:04 AM, Jörg Schaible wrote: > James Carman wrote: > >> All, >> >> We have had some great discussions about moving our SCM to Git. I >> think it's time to put it to a vote. So, here we go: >> >> +1 - yes, move to Git >> -1 - no, do not move to Git >> >> The vote will be

Re: [VOTE] Moving to Git...

On Thu, Oct 10, 2013 at 11:04 AM, Jörg Schaible wrote: > James Carman wrote: > >> All, >> >> We have had some great discussions about moving our SCM to Git. I >> think it's time to put it to a vote. So, here we go: >> >> +1 - yes, move to Git >> -1 - no, do not move to Git >> >> The vote will be

Re: [VOTE] Moving to Git...

How is that any different than SVN? We have to release from branches with SVN too. We don't copy our "maintenance" branches to trunk in order to do releases. On Thu, Oct 10, 2013 at 11:09 AM, Gary Gregory wrote: > On Thu, Oct 10, 2013 at 11:04 AM, Jörg Schaible > wrote: >> James Carman wrote:

Re: [VOTE] Moving to Git...

Sorry, didn't understand your question. The Apache Camel team uses Git and they release maintenance versions all the time (I believe about 3 or 4 at a time sometimes when a bug fix gets merged down). Here's a list of the current projects using Git: https://git-wip-us.apache.org/repos/asf On Th

Re: [VOTE] Moving to Git...

James Carman wrote: > How is that any different than SVN? We have to release from branches > with SVN too. We don't copy our "maintenance" branches to trunk in > order to do releases. The SCM providers in Maven were not written with Git in mind, the Git provider is quite new compared to mature

[DISCUSS] Creating Project for Release Process Testing...

Why don't we create a real project that we can cut real releases on to test our release procedures? Perhaps we can set it up so that it doesn't sync with central and just gets staged locally. This way, we can test out changes to the release process and see how they work. Also, a new release manag

Re: [DISCUSS] Creating Project for Release Process Testing...

Nice idea, but push it to central to test the whole chain. G On Thu, Oct 10, 2013 at 11:24 AM, James Carman wrote: > Why don't we create a real project that we can cut real releases on to > test our release procedures? Perhaps we can set it up so that it > doesn't sync with central and just get

Re: [DISCUSS] Creating Project for Release Process Testing...

Once it's properly in Nexus, is there any reason to push all the way to central? Matt On Thu, Oct 10, 2013 at 10:29 AM, Gary Gregory wrote: > Nice idea, but push it to central to test the whole chain. > > G > > On Thu, Oct 10, 2013 at 11:24 AM, James Carman > wrote: > > Why don't we create a r

Re: [DISCUSS] Creating Project for Release Process Testing...

Fine with me! I'm good with that. I just was worried folks would think of it as "cluttering" central On Thu, Oct 10, 2013 at 11:29 AM, Gary Gregory wrote: > Nice idea, but push it to central to test the whole chain. > > G > > On Thu, Oct 10, 2013 at 11:24 AM, James Carman > wrote: >> Why don'

Re: [DISCUSS] Creating Project for Release Process Testing...

Le 10/10/2013 17:24, James Carman a écrit : > Why don't we create a real project that we can cut real releases on to > test our release procedures? Perhaps we can set it up so that it > doesn't sync with central and just gets staged locally. This way, we > can test out changes to the release proc

Re: [DISCUSS] Creating Project for Release Process Testing...

This isn't to address Git. This is just in-general a little sandbox that folks can use to either test out change to the release process (or documentation) or just have a go at being a release manager before actually volunteering. Anyone would be free to cut a release at any time. On Thu, Oct 10

Re: [DISCUSS] Creating Project for Release Process Testing...

Emmanuel, IMO this goes beyond the SCM question. Commons releases are painful (you've just been through the process; do you disagree?) and I submit that this fact is the reason it takes so long for any of us to muster up the courage to commit himself to diving into that process with no real idea

Re: [DISCUSS] Creating Project for Release Process Testing...

Le 10/10/2013 17:36, James Carman a écrit : > This isn't to address Git. This is just in-general a little sandbox > that folks can use to either test out change to the release process > (or documentation) or just have a go at being a release manager before > actually volunteering. Anyone would be

Re: [DISCUSS] Creating Project for Release Process Testing...

Or just a multi-module only and do the worst case scenario. On Thu, Oct 10, 2013 at 11:41 AM, Emmanuel Bourg wrote: > Le 10/10/2013 17:36, James Carman a écrit : >> This isn't to address Git. This is just in-general a little sandbox >> that folks can use to either test out change to the release

Re: [DISCUSS] Creating Project for Release Process Testing...

I need to have Matt start writing my emails. What he said! ;) I'm too impatient to be so eloquent. On Thu, Oct 10, 2013 at 11:41 AM, Matt Benson wrote: > Emmanuel, > IMO this goes beyond the SCM question. Commons releases are painful > (you've just been through the process; do you disagree?)

Re: [VOTE] Moving to Git...

On Thu, Oct 10, 2013 at 10:50 AM, Gilles wrote: > -1 > > Some people have indicated that this move might not address the problem > it is supposed to. No conclusive answer has been provided. > What problem is that exactly? Perhaps that's not well understood? -

Re: [VOTE] Moving to Git...

On Thu, Oct 10, 2013 at 11:09 AM, Gary Gregory wrote: > > Great point. Sounds like someone needs to experiment and show that it > can be done. Since James started the vote,, perhaps he'd care to pick > one Commons component and try to release through git... > How about this? I'm now on the Camel

Re: [VOTE] Moving to Git...

On Thu, Oct 10, 2013 at 12:01 PM, James Carman wrote: > On Thu, Oct 10, 2013 at 11:09 AM, Gary Gregory wrote: >> >> Great point. Sounds like someone needs to experiment and show that it >> can be done. Since James started the vote,, perhaps he'd care to pick >> one Commons component and try to re

Apache Commons IRC Channel...

As a reminder, we do have an IRC channel set up on freenode. It's #asfcommons. Matt Benson and I are usually the only ones hanging out there right now, but some of these discussions would go much faster if we could discuss in real-time. Of course, no decisions are made only on IRC. If anything i

Re: Apache Commons IRC Channel...

I'll add that any Commons PMC member registered on freenode should contact one of us to be made a moderator of the IRC channel. Matt On Thu, Oct 10, 2013 at 11:15 AM, James Carman wrote: > As a reminder, we do have an IRC channel set up on freenode. It's > #asfcommons. Matt Benson and I are u

Please? WAS: Re: [JCS] Asking for advice: separate CacheAccess and GroupCacheAccess?

On 03.10.13 13:30, Thomas Vandahl wrote: > Hi folks, > > I'd like to ask for suggestions for a problem solution regarding the > typesafe handling of cache keys in JCS. > > Previously, JCS was not aware of key and value types. So it was possible > to mix cache elements having different key types w

Re: [VOTE] Move Apache Commons to Git for SCM...

On 10.10.13 16:50, James Carman wrote: > All, > > We have had some great discussions about moving our SCM to Git. I > think it's time to put it to a vote. So, here we go: > > +1 - yes, move to Git > -1 - no, do not move to Git -1 I don't see any advantages. Bye, Thomas.

Re: Please? WAS: Re: [JCS] Asking for advice: separate CacheAccess and GroupCacheAccess?

Sorry Thomas!!! I intended to have a look at this but then we started a lot of discussions here. I just forgot it. I'll try to have a look! Benedikt 2013/10/10 Thomas Vandahl > On 03.10.13 13:30, Thomas Vandahl wrote: > > Hi folks, > > > > I'd like to ask for suggestions for a problem solution

Re: [VOTE] Moving to Git...

Hi James, James Carman wrote: > Sorry, didn't understand your question. The Apache Camel team uses > Git and they release maintenance versions all the time (I believe > about 3 or 4 at a time sometimes when a bug fix gets merged down). > Here's a list of the current projects using Git: > > http

Re: [VOTE] Move Apache Commons to Git for SCM...

+1 (binding) we already have the mirrors for all proper components, so we probably will only have to deal with sandbox and the site/build stuff. I'll help where I can. 2013/10/10 James Carman > All, > > We have had some great discussions about moving our SCM to Git. I > think it's time to put

Re: [VOTE] Release JCI 1.1 based on RC1

+1, release it! On Wed, Oct 9, 2013 at 11:21 AM, Emmanuel Bourg wrote: > This is a vote to release Apache Commons JCI 1.1 based on RC1. > > This is a bug fix release and an update to work with more recent > versions of its dependencies. > > > Tag: > http://svn.apache.org/repos/asf/commons/proper/

Re: [VOTE] Move Apache Commons to Git for SCM...

-1 (binding), it's a big change, so let's try Mark's idea of one component first. On Thu, Oct 10, 2013 at 5:06 PM, Mark Thomas wrote: > On 10/10/2013 15:50, James Carman wrote: >> All, >> >> We have had some great discussions about moving our SCM to Git. I >> think it's time to put it to a vot

Re: [VOTE] Moving to Git...

+1   Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com - Original Message - > From: James Carman > To: Commons Developers List > Cc: > Sent: Thursday, October 10, 2013 11:41 AM > Subject: [VOTE] Moving to Git... > > All, > > We have had some great discussions about movin

Re: [VOTE] Move Apache Commons to Git for SCM...

Looks like I've voted on the wrong thread, here's my vote +1   Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com - Original Message - > From: James Carman > To: Commons Developers List > Cc: > Sent: Thursday, October 10, 2013 11:50 AM > Subject: [VOTE] Move Apache Commons

Re: [VOTE] Move Apache Commons to Git for SCM...

+1 Gary On Thu, Oct 10, 2013 at 1:36 PM, Bruno P. Kinoshita wrote: > Looks like I've voted on the wrong thread, here's my vote > > +1 > > Bruno P. Kinoshita > http://kinoshita.eti.br > http://tupilabs.com > > > - Original Message - >> From: James Carman >> To: Commons Developers List >

Re: [VOTE] Release JCI 1.1 based on RC1

On Thu, Oct 10, 2013 at 1:06 PM, James Carman wrote: > +1, release it! Really? What about binary compatibility? Call it 2.0 IMO. Now I'll be quiet ;) Gary > > On Wed, Oct 9, 2013 at 11:21 AM, Emmanuel Bourg wrote: >> This is a vote to release Apache Commons JCI 1.1 based on RC1. >> >> This is

Re: [VOTE] Release JCI 1.1 based on RC1

How many people are really using JCI? On Thu, Oct 10, 2013 at 2:03 PM, Gary Gregory wrote: > On Thu, Oct 10, 2013 at 1:06 PM, James Carman > wrote: >> +1, release it! > > Really? What about binary compatibility? Call it 2.0 IMO. Now I'll be quiet ;) > > Gary > >> >> On Wed, Oct 9, 2013 at 11:21

Re: [VOTE] Release JCI 1.1 based on RC1

On 2013-10-09, Emmanuel Bourg wrote: > This is a vote to release Apache Commons JCI 1.1 based on RC1. I feel incredibly sorry for having to bring up something that looks like a minor detail - the copyright year in NOTICE doesn't extend to 2013. IANAL and all that but I'd feel more comfortable to

Re: [VOTE] Release JCI 1.1 based on RC1

On Thu, Oct 10, 2013 at 2:10 PM, James Carman wrote: > How many people are really using JCI? All it takes to create jar hell is one project using it which is then a dependent of a popular project :( What's the big deal about bumping to 2.0? You get all the API deletion, additions and twiddling y

Re: [VOTE] Release JCI 1.1 based on RC1

Le 10/10/2013 20:12, Stefan Bodewig a écrit : > I feel incredibly sorry for having to bring up something that looks like > a minor detail - the copyright year in NOTICE doesn't extend to 2013. > > IANAL and all that but I'd feel more comfortable to cast a +1 if this > was fixed - in fact I've alr

Re: [VOTE] Release JCI 1.1 based on RC1

Le 10/10/2013 20:03, Gary Gregory a écrit : > Really? What about binary compatibility? Call it 2.0 IMO. Now I'll be quiet ;) Gary, it *is* binary compatible. We are just no longer releasing the module commons-jci-javac. But you can still mix the released commons-jci-javac 1.0 with the upcoming co

Re: [VOTE] Release JCI 1.1 based on RC1

FYI, trunk has been "upgraded" to 2.0 in case that's where we go with this. If not, feel free to back it out. On Thu, Oct 10, 2013 at 2:18 PM, Gary Gregory wrote: > On Thu, Oct 10, 2013 at 2:10 PM, James Carman > wrote: >> How many people are really using JCI? > > All it takes to create jar hel

Re: [VOTE] Move Apache Commons to Git for SCM...

Le 10/10/2013 19:27, Damjan Jovanovic a écrit : > -1 (binding), it's a big change, so let's try Mark's idea of one > component first. +1. I see a lot of advantages. The first one is in branches merging which could help for experimental stuff, the second is in getting contributions (for example lar

Re: [VOTE] Move Apache Commons to Git for SCM...

We could migrate our new release testing project (commons-canary :) first. Get the kinks worked out using it. Then, we migrate the rest of the projects. On Thu, Oct 10, 2013 at 3:13 PM, Luc Maisonobe wrote: > Le 10/10/2013 19:27, Damjan Jovanovic a écrit : >> -1 (binding), it's a big change, so

Re: [VOTE] Move Apache Commons to Git for SCM...

The "binding" annotations on this thread kind of bug me here - we should be deciding this kind of thing by community consensus. "Binding" is only meaningful in release votes and VOTE-ing in general should be a last resort rather than early step in getting to consensus. I have tried to keep up wit

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]

On Thu, Oct 10, 2013 at 7:26 AM, Ate Douma wrote: > I've move this into a separate [DISCUSS] thread as I think it needs separate > discussion. > > Jörg gave some objections below about using Milestone releases, as I > proposed earlier to support releasing intermediate versions of a > not-yet-staba

Re: [DISCUSS] Putting several unmaintained components to dormant

Am 09.10.2013 21:17, schrieb Benedikt Ritter: > Hi, > > I think Phil came up with the idea to try to focus on the components that > we are able to maintain and put all other stuff to dormant. Here is the > list of components that I think really are proper: > > - CLI > - Codec > - Collections > -

Re: [VOTE] Move Apache Commons to Git for SCM...

+1 to git in general, however, I also prefer the approach to do the move in a more careful way, i.e. experimenting with single components first. Oliver Am 10.10.2013 16:50, schrieb James Carman: > All, > > We have had some great discussions about moving our SCM to Git. I > think it's time to pu

Re: [LANG] Build fails with JDK 8 developer preview

Fixed the compile error, however I get some test errors: Results : Failed tests: FastDateFormat_ParserTest>FastDateParserTest.testParseZone:118 expected: but was: FastDateParserTest.testParseZone:118 expected: but was: Tests in error: LocaleUtilsTest.testParseAllLocales:570 » IllegalArgume

Re: [VOTE] Moving to Git...

An interesting bit of stats for the Apache Camel project. Here's their pull request history: Jan 3 Feb 4 Mar 6 Apr 1 May 2 Jun 4 Jul 10 Aug 6 Sep 4 They switched their repository over to Git in May. So, for the 4 months before May, they had a total of 14 pull requests. For the 4 months after M

Re: [VOTE] Release JCI 1.1 based on RC1

LICENSE and NOTICE files are present in source archive, as well as source and "artifact" jars for each module, but absent in test, test-sources and javadoc jars. Rules on LICENSE and NOTICE files are a little fuzzy for convenience binaries, so not a blocker IMO. Hashes match, PGP sigs check out,

  1   2   >