2013/10/11 Oliver Heger
> Am 11.10.2013 22:01, schrieb Benedikt Ritter:
> > 2013/10/11 Oliver Heger
> >
> >> Am 11.10.2013 02:10, schrieb Phil Steitz:
> >>>
> >>>
> On Oct 10, 2013, at 4:41 PM, Olivier Lamy wrote:
>
> Even I like git and use it daily, I will vote +0,5.
>
> >
Plus the IRC channel is the only place you'll get to hear Commons history,
Matt's music preference for 7th century heretical works and Emmanuel's
business plan for IRC log blackmail.
On Thu, Oct 10, 2013 at 9:15 AM, James Carman wrote:
> As a reminder, we do have an IRC channel set up on freenod
Am 11.10.2013 22:01, schrieb Benedikt Ritter:
> 2013/10/11 Oliver Heger
>
>> Am 11.10.2013 02:10, schrieb Phil Steitz:
>>>
>>>
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 thei
2013/10/11 Oliver Heger
> Am 11.10.2013 02:10, schrieb Phil Steitz:
> >
> >
> >> 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 tomc
> On Oct 11, 2013, at 8:23 AM, James Carman wrote:
>
>> On Fri, Oct 11, 2013 at 9:00 AM, Phil Steitz wrote:
>>
>> Question for James - how many new committers did they get? Random drive by
>> pull requests won't help us. We already get more patches than we can
>> evaluate and apply in a t
On Tue, Oct 8, 2013 at 12:10 AM, Romain Manni-Bucau
wrote:
> Never said the opposite but git or svn is not a questioin IMO, both are
> simple and usable today. I'm more attracted by features than the infra
> around a project.
>
> For me commons looks like a big sandbox where rules are more importa
Am 11.10.2013 02:10, schrieb Phil Steitz:
>
>
>> 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
>> i
+1
let's move on step by step.
On 10 Oct 2013, at 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
>
> The vote will be left ope
I am +1 on using git but I won't be able to help with the changes that will
need to be made so I am voting +0.
FWIW, I don't think git really "solves" anything. It will fix a perception
problem and it will make it easier to do distributed development.
Ralph
On Oct 10, 2013, at 8:06 AM, Mark
On 2013-10-06, Stefan Bodewig wrote:
> Should go into the release:
> * support for writing compressed 7z archives. In particular I'd love to
> have SevenZOutputFile default to LZMA2 compression with the release.
> * look into and potentially fix date and permission handling issues in
> arj.
On 2013-10-11, Emmanuel Bourg wrote:
> The parent pom currently attaches the -bin and -src archives to the
> deploy phase, which means we have to delete them manually in Nexus.
> Can we agree to change that?
Sebb did some investigation back in May, I think. IIRC this implies
they won't get sign
On 11 Oct 2013, at 15:28, Ted Dunning wrote:
I hate myself a bit for jumping in here, but as much as I prefer git,
I
really don't think that changing will make that much difference.
Well, obviously I think it matters (see my other threads).
The problem with commons is that people have much
I hate myself a bit for jumping in here, but as much as I prefer git, I
really don't think that changing will make that much difference.
The problem with commons is that people have much more energy for
interminable conversations about things that don't much matter (like this
thread).
People who
On Fri, Oct 11, 2013 at 9:00 AM, Phil Steitz wrote:
>
> Question for James - how many new committers did they get? Random drive by
> pull requests won't help us. We already get more patches than we can
> evaluate and apply in a timely fashion. The key question is will the git
> move net us n
+1
I consider this move to happen step by step and see only little risk if
we start with a single component first.
As the half of the world works with git meanwhile I see less risk in
general too.
On 10 Oct 2013, at 16:41, James Carman wrote:
All,
We have had some great discussions about
On Oct 11, 2013, at 6:37 AM, Torsten Curdt wrote:
>> There is no proof that more contributors will suddenly appear just
>> because the tool has changed.
>
> The numbers James brought tell a different story.
> Maybe just a very specific indicator and not scientific - but so is your
> claim that
On 10 Oct 2013, at 18:43, Jörg Schaible wrote:
> 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).
>>
> On Oct 10, 2013, at 11:55 PM, Romain Manni-Bucau
> wrote:
>
> Can a release guy detail what is painful and why we cant release with a
> script?
That is what I have always ended up doing. The problems start when we try to
get everything to work for all components automagically from maven a
> Maybe for tiny fixes it's that easy - for longer contribution where you
>> follow development it's not.
>>
>
> How often does that happen (within Commons)?
>
Not often enough because then we would have more people working on commons
;)
> How often will a new contributor embark in a long rewri
The parent pom currently attaches the -bin and -src archives to the
deploy phase, which means we have to delete them manually in Nexus.
Can we agree to change that?
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commo
On Fri, 11 Oct 2013 13:37:03 +0200, Torsten Curdt wrote:
There is no proof that more contributors will suddenly appear just
because the tool has changed.
The numbers James brought tell a different story.
Maybe just a very specific indicator and not scientific - but so is
your
claim that it d
Did not test very thoroughly but looks good enough to warrant a +1
cheers,
Torsten
On Thu, Oct 10, 2013 at 11:28 PM, Matt Benson wrote:
> 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
> java
> There is no proof that more contributors will suddenly appear just
> because the tool has changed.
>
The numbers James brought tell a different story.
Maybe just a very specific indicator and not scientific - but so is your
claim that it does not change anything at all.
> As people noted, a c
big +1 for the the move from me (I guess that does not come as a surprise)
"SCM isn't the biggest problem" is certainly true but given my experience I
am inclined to say it will help.
But with so many hesitant people I think we need a good plan on how it will
look like.
We especially need to check
On Fri, 11 Oct 2013 07:47:05 +0200, Benedikt Ritter wrote:
I don't understand why "SCM isn't the biggest problem" causes people
to veto this change.
There is no proof that more contributors will suddenly appear just
because the tool has changed.
As people noted, a contributor can fairly easily
On Thu, 10 Oct 2013 18:35:07 -0500, 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
On 2013-10-11, Stefan Bodewig wrote:
> Unfortunately LZMA2OutputStream is not public in XZ for Java
But LZMA2Options#getOutputStream is - looks as if there was a way.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apa
Le 11/10/2013 01:35, Matt Benson a écrit :
> 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 (Emmanue
Hi all,
I've made some progress:
On 2013-10-11, wrote:
> Author: bodewig
> Date: Fri Oct 11 09:13:42 2013
> New Revision: 1531235
> URL: http://svn.apache.org/r1531235
> Log:
> add bzip2/deflate compression support when writing 7z archives
Unfortunately LZMA2OutputStream is not public in XZ f
2013/10/11 Ate Douma
> On 10/11/2013 02:54 AM, James Carman wrote:
>
>> It wouldn't look so funky that way. I'm cool with that.
>>
>
> I'm leaning to this solution as well, going for scxml2 with version
> 2.0(-xx).
>
> While this would 'skip' the 1.0 range, I think not only doesn't it look so
>
Hi guys,
James and I have the plan of setting up our projects at the ASF jenkins [1]
and sonar [2] instances. How can we get the necessary karma?
Benedikt
[1] http://builds.apache.org
[2] http://analysis.apache.org
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://tw
On 10/11/2013 02:54 AM, James Carman wrote:
It wouldn't look so funky that way. I'm cool with that.
I'm leaning to this solution as well, going for scxml2 with version 2.0(-xx).
While this would 'skip' the 1.0 range, I think not only doesn't it look so
funky (scxml1) but also better indicate
On 10/10/2013 03:31 PM, James Carman wrote:
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.
Sin
+1 from me for anything that makes the release process sane.
I'd be committing again if preparing a release was simple enough. As it is,
I don't have the blocks of time needed to push out a release and committing
to projects with no apparent release manager becomes an exercise in
futility.
Hen
On 11/10/2013 00:41, Olivier Lamy wrote:
> 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?
Tomcat does not use an svn:external of any Commons component.
Tomcat releases depend only
Default Maven 2 Build Definition (1.5)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Continuum-Build-Host: vmbuild
X-Continuum-Project-Id: 286
X-Continuum-Project-Name: Commons JCS
Online report :
http://vmbuild.apache.org/continuum/build
36 matches
Mail list logo
