Re: [DISCUSS] Moving to Git...

Benedikt Ritter wrote: > I don't understand why "SCM isn't the biggest problem" causes people to > veto this change. It's not a veto, it's a normal majority decision. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.ap

Re: [DISCUSS] Moving to Git...

I dont think it vetoes it, it is just not linked Le 11 oct. 2013 07:47, "Benedikt Ritter" a écrit : > I don't understand why "SCM isn't the biggest problem" causes people to > veto this change. > > Send from my mobile device > > > Am 11.10.2013 um 06:55 schrieb Romain Manni-Bucau >: > > > > Can

Re: [DISCUSS] Moving to Git...

I don't understand why "SCM isn't the biggest problem" causes people to veto this change. Send from my mobile device > Am 11.10.2013 um 06:55 schrieb Romain Manni-Bucau : > > Can a release guy detail what is painful and why we cant release with a > script? Git or svn are scriptable to be auto s

Re: [DISCUSS] Moving to Git...

Can a release guy detail what is painful and why we cant release with a script? Git or svn are scriptable to be auto so the scm is clearly not the release issue (maybe not fashion but not blocking) Le 11 oct. 2013 01:24, "Gary Gregory" a écrit : > On Oct 10, 2013, at 18:13, Mark Thomas wrote: >

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

On 2013-10-11, Matt Benson wrote: > We're all still talking about the release process, but in all honesty I've > not done it for several years at Commons. I think it would be immensely > helpful for those of us who have been at least part way through the process > fairly recently (Emmanuel, Gary,

Re: [SCXML] Next major version number required package rename needed?

The dots aren't decimal separators and version numbers are not true numbers. 0.9 goes to 0.10 goes to 0.11, etc. If they were true decimal numbers, you couldn't have more than one dot. 0.9 to 1.0 is a major version jump. However, 0.X usually indicates pre-release quality (i.e., not ready for produ

Re: [SCXML] Next major version number required package rename needed?

It wouldn't look so funky that way. I'm cool with that. On Thursday, October 10, 2013, Niall Pemberton wrote: > I would bump to version 2.0 because I dont think its clear that going from > 0.9 to 1.0 is a major version change - in my mind 0.9 seems to imply "we > haven't quite completed everythi

Re: [SCXML] Next major version number required package rename needed?

I would also treat 0.9 as a "real release" and act accordingly wrt API changes; the current release is far too old to do otherwise IMHO. Matt On Oct 10, 2013 7:41 PM, "Niall Pemberton" wrote: > I would bump to version 2.0 because I dont think its clear that going from > 0.9 to 1.0 is a major ver

Re: [SCXML] Next major version number required package rename needed?

I would bump to version 2.0 because I dont think its clear that going from 0.9 to 1.0 is a major version change - in my mind 0.9 seems to imply "we haven't quite completed everything we want to for 1.0" Niall On Fri, Oct 11, 2013 at 12:52 AM, James Carman wrote: > Now, this case is a bit weird,

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

Matt and I will probably have proxy2 ready very soon, too On Thu, Oct 10, 2013 at 8:10 PM, Phil Steitz wrote: > > >> On Oct 10, 2013, at 4:41 PM, Olivier Lamy wrote: >> >> Even I like git and use it daily, I will vote +0,5. >> >> Why other apache projects need to have their own commons-csv >> r

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

> On Oct 10, 2013, at 4:41 PM, Olivier Lamy wrote: > > Even I like git and use it daily, I will vote +0,5. > > Why other apache projects need to have their own commons-csv > repackaged release? why tomcat need to use a svn:external on dbcp > instead of a released version? why servicemix need t

Re: [SCXML] Next major version number required package rename needed?

Now, this case is a bit weird, since we have released code in a < 1.0 version number. So, the artifact/package will have to be scxml1, which looks funky IMHO. I guess that follows the pattern, though. On Thu, Oct 10, 2013 at 7:49 PM, Ate Douma wrote: > On 10/11/2013 01:41 AM, James Carman wrote

Re: [SCXML] Next major version number required package rename needed?

On 10/11/2013 01:41 AM, James Carman wrote: If you are breaking backward compatibility then you need to do the renames (package, and artifactId). That was my impression already. And I have no real issue with doing so. But again, when has this been decided and has it ever been formalized (writt

[SCXML] Next major version number required package rename needed?

If you are breaking backward compatibility then you need to do the renames (package, and artifactId). I don't know if we ever landed on a "rule" about the new JDK level scenario, though. On Thursday, October 10, 2013, Ate Douma wrote: > On 10/11/2013 01:16 AM, Emmanuel Bourg wrote: > >> Commons

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

Even I like git and use it daily, I will vote +0,5. Why other apache projects need to have their own commons-csv repackaged release? why tomcat need to use a svn:external on dbcp instead of a released version? why servicemix need to repackage all commons jar to have proper osgi bundles? I simply

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

We're all still talking about the release process, but in all honesty I've not done it for several years at Commons. I think it would be immensely helpful for those of us who have been at least part way through the process fairly recently (Emmanuel, Gary, others?) to present your recollections of

Re: [SCXML] Next major version number required package rename needed?

On 10/11/2013 01:16 AM, Emmanuel Bourg wrote: Commons SCXML has only one reverse dependency in Maven Central, flexistate, so I wouldn't bother with the binary compatibility and just keep the package as is. Hmm. That might be the only reverse dependency of artifacts also deployed to Maven Centr

Re: [DISCUSS] Moving to Git...

On Oct 10, 2013, at 18:13, Mark Thomas wrote: > On 10/10/2013 23:05, James Carman wrote: >> On Thu, Oct 10, 2013 at 5:48 PM, Mark Thomas wrote: >>> >>> I would suggest that a lack of releases is a much greater barrier. Folks >>> who contribute patches do so because they want to see them in a rel

Re: [SCXML] Next major version number required package rename needed?

Commons SCXML has only one reverse dependency in Maven Central, flexistate, so I wouldn't bother with the binary compatibility and just keep the package as is. http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9 Emmanuel Bourg --

[SCXML] Next major version number required package rename needed?

On 10/10/2013 09:39 PM, Rahul Akolkar wrote: On Thu, Oct 10, 2013 at 7:26 AM, Ate Douma wrote: Case in point: SCXML If we are allowed to start working on this component shortly, we intend to, and HAVE to switch to a 1.0 version first, as there already is a 0.9 version release out, while we

Re: [DISCUSS] Moving to Git...

On Thu, Oct 10, 2013 at 6:13 PM, Mark Thomas wrote: > > I disagree. We don't have releases because of an overly complex release > process. Figuring out how to do a Pool 2 release is on my TODO list. > Having seen the pain others new to the Commons release process have gone > though, I'm not lookin

Re: [DISCUSS] Moving to Git...

On 10/10/2013 23:05, James Carman wrote: > On Thu, Oct 10, 2013 at 5:48 PM, Mark Thomas wrote: >> >> I would suggest that a lack of releases is a much greater barrier. Folks >> who contribute patches do so because they want to see them in a release. >> If there are no releases (and looking back fo

Re: [DISCUSS] Moving to Git...

On Thu, Oct 10, 2013 at 5:48 PM, Mark Thomas wrote: > > I would suggest that a lack of releases is a much greater barrier. Folks > who contribute patches do so because they want to see them in a release. > If there are no releases (and looking back for the past 6 months there > have been very few

Re: [DISCUSS] Moving to Git...

On 10/10/2013 22:41, James Carman wrote: > And how did we establish that git will not address those concerns? It has not been established that the choice of git vs. svn is the biggest blocker to attracting attention and contributors. I would suggest that a lack of releases is a much greater barri

Re: [DISCUSS] Moving to Git...

And how did we establish that git will not address those concerns? On Thursday, October 10, 2013, Gilles wrote: > On Thu, 10 Oct 2013 11:58:58 -0400, James Carman wrote: > >> On Thu, Oct 10, 2013 at 10:50 AM, Gilles >> wrote: >> >>> -1 >>> >>> Some people have indicated that this move might not

Re: [VOTE] Moving to Git...

On Thu, 10 Oct 2013 11:58:58 -0400, James Carman wrote: 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 w

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,

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: [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] 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: [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: [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: [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: [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...

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] 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] 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

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

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

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

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 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] 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] 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] 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...

-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] 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) 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] 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: 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] 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.

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: 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

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: [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

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 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: [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: [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...

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...

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...

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...

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...

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...

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...

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

[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: [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

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...

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...

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: [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...

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: [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: [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] 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: [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...

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] 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: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...

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...

-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...

@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] 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] 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] 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] 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

[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: [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

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: [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

[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: [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, > >

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] 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 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 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

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

  1   2   >