Return-Path: X-Original-To: apmail-logging-log4j-dev-archive@www.apache.org Delivered-To: apmail-logging-log4j-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2F4F811623 for ; Tue, 5 Aug 2014 14:06:15 +0000 (UTC) Received: (qmail 69127 invoked by uid 500); 5 Aug 2014 14:06:15 -0000 Delivered-To: apmail-logging-log4j-dev-archive@logging.apache.org Received: (qmail 69078 invoked by uid 500); 5 Aug 2014 14:06:15 -0000 Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Log4J Developers List" Reply-To: "Log4J Developers List" Delivered-To: mailing list log4j-dev@logging.apache.org Received: (qmail 69067 invoked by uid 99); 5 Aug 2014 14:06:14 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Aug 2014 14:06:14 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of remko.popma@gmail.com designates 209.85.219.52 as permitted sender) Received: from [209.85.219.52] (HELO mail-oa0-f52.google.com) (209.85.219.52) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Aug 2014 14:06:10 +0000 Received: by mail-oa0-f52.google.com with SMTP id o6so698054oag.25 for ; Tue, 05 Aug 2014 07:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zE5NXPU75KD+fC1moFuztRo6uAumyOXJsudflUi9wGQ=; b=sNqznajfnTHu5/YdeZyGY1Uoh5aPlxUNtN5f+P+964mmaEKzqn69R87bW/pZc/d8Vr vUvp8VuARIx1uoIoL2EqF/hF8fGg29qOokhcg3NY7Y2kMOADyHbrGptR5F37RVJa8Ang 0G1or+o7wZ5rGDqDwNfJNuQtpT6vDeU9sLO+peZ0bIEhb9VNIxo2mp1AM4UF8QXee9Ns tOLaq9VZ5t5TqmACScZ7Fu+pRTu/82DLKpdOjKj3is1fy2XlnvmTfQfIg7kblI8wvQQ7 204eEdmsIVu0zBQq+JQe1vLwatbEBJi1s4McFd/l7n/c+e/ocJev0BmulKB3tUB4hajt 0+Ng== MIME-Version: 1.0 X-Received: by 10.60.175.138 with SMTP id ca10mr5993583oec.15.1407247549065; Tue, 05 Aug 2014 07:05:49 -0700 (PDT) Received: by 10.76.75.10 with HTTP; Tue, 5 Aug 2014 07:05:48 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Aug 2014 23:05:48 +0900 Message-ID: Subject: Re: Which direction to focus on next? From: Remko Popma To: Log4J Developers List Content-Type: multipart/alternative; boundary=047d7bd761a445ee4304ffe25ac5 X-Virus-Checked: Checked by ClamAV on apache.org --047d7bd761a445ee4304ffe25ac5 Content-Type: text/plain; charset=UTF-8 On Tuesday, August 5, 2014, Gary Gregory wrote: > On Tue, Aug 5, 2014 at 9:21 AM, Remko Popma > wrote: > >> >> >> >> On Tue, Aug 5, 2014 at 10:04 PM, Gary Gregory > > wrote: >> >>> On Tue, Aug 5, 2014 at 8:55 AM, Remko Popma >> > wrote: >>> >>>> I have only used git a little, not much experience with it, but I've >>>> heard good things about it. >>>> >>>> Please don't misunderstand, I don't mind having another bugfix release. >>>> I also don't mind fixing bugs and supporting users. I think I have a >>>> solid track record in that regard. >>>> >>>> I just think that new bug reports will keep coming in forever, and we >>>> should have some sort of structure for dealing with that that does not >>>> prevent working on new features in parallel. >>>> >>>> If git makes branching/merging easier then perhaps that would be a good >>>> solution for this? >>>> >>> >>> Branching is for this kind of work of course. I just do not want to >>> incur the overhead of dealing with branches unless I have to. So to put in >>> in concrete terms I propose to keep it simple like this: >>> >>> - 2.0.2: a bug fix release where the vote starts 8/18 >>> - 2.1.0: start work after 2.0.2 (which includes bug fixes of course). >>> - All in trunk >>> >> >> Okay, I can live with that. To clarify, the work for 2.1 would be done in >> trunk, correct? >> > > Right, I would just ask for patience before firing up 2.1 code in trunk to > after 2.0.2. This will let us all focus on 2.0.2 which can only be a good > thing IMO. > Okay, understood. > >> Would be be an idea to look at moving to git anyway? (I'm kind of +0.5 on >> that, I think it might be a good idea to move to git anyway, just not sure >> how much effort it would be...) >> > > Can you start a separate thread? We can [discuss], then [vote]; or you can > put up a [vote] thread right away. Up to you. > Will do. > > Gary > > > >> >>> >>> Gary >>> >>> >>>> >>>> On Tue, Aug 5, 2014 at 9:51 PM, Gary Gregory >>> > wrote: >>>> >>>>> I think we can keep our lives simpler WRT development process by >>>>> putting out a patch release or two (as Ralph and I suggest), then moving to >>>>> 2.1. This will leaving branch only to developers who really need/want it. >>>>> >>>>> Gary >>>>> >>>>> >>>>> On Tue, Aug 5, 2014 at 8:45 AM, Matt Sicker >>>> > wrote: >>>>> >>>>>> I'm perfectly fine with moving to git, but that's mainly because it's >>>>>> what I use every day as it is. >>>>>> >>>>>> >>>>>> On 5 August 2014 07:26, Ralph Goers >>>>> > wrote: >>>>>> >>>>>>> I think this makes sense. As a general practice having at least two >>>>>>> or three patch releases after a major or minor release is probably a good >>>>>>> idea. It is also fair to point out that it is highly unlikely that we would >>>>>>> generate a patch release for an older version - once 2.1 is released it is >>>>>>> unlikely we would go back and release 2.0.2. >>>>>>> >>>>>>> Ralph >>>>>>> >>>>>>> On Aug 5, 2014, at 4:19 AM, Gary Gregory >>>>>> > wrote: >>>>>>> >>>>>>> I should have been clearer, sorry. I am suggesting we take a week >>>>>>> (or two) and have a round of bug fixing for a 2.0.2, even if those are just >>>>>>> low hanging fruits. This will give us a "better 2.0", then we do new >>>>>>> features. As a user, that would give me confidence the log4j team is >>>>>>> listening to bug reports before going back to having fun adding new >>>>>>> features. >>>>>>> >>>>>>> 2c, >>>>>>> Gary >>>>>>> >>>>>>> Gary >>>>>>> >>>>>>> >>>>>>> -------- Original message -------- >>>>>>> From: Remko Popma >>>>>>> Date:08/05/2014 00:48 (GMT-05:00) >>>>>>> To: Log4J Developers List >>>>>>> Subject: Re: Which direction to focus on next? >>>>>>> >>>>>>> Thanks, Matt. >>>>>>> >>>>>>> Gary, Ralph, what do you think? >>>>>>> Where should we work on new features? I see these options: >>>>>>> >>>>>>> 1. Don't work on new features, or keep new features on our local >>>>>>> machines, don't commit to apache svn. (TBD: until when?) >>>>>>> >>>>>>> 2. Everyone creates separate branches for new features they want to >>>>>>> work on. So Remko would have a binary logging/memmap branch, and a branch >>>>>>> for deleting old rolled-over files, Matt would have a jdbc-batched-inserts >>>>>>> branch, etc. Bugfixes go into trunk. Everyone is free to sync their >>>>>>> branch(es) with trunk's bugfixes or not. >>>>>>> >>>>>>> 3. We create a shared 2.1 branch for new features. Bugfixes go into >>>>>>> trunk as well as the 2.1 branch. >>>>>>> >>>>>>> 4. Both new features and bugfixes are committed to trunk. No >>>>>>> branches needed. >>>>>>> >>>>>>> 5. The opposite of option 3: we create a 2.0.2 branch that holds >>>>>>> bugfixes only. Trunk has both new features and bugfixes. >>>>>>> >>>>>>> 6. Any alternatives that I missed? >>>>>>> >>>>>>> Gary, in the past you mentioned you don't like the busywork of >>>>>>> maintaining two branches. I'm fine with that, but to me that means new >>>>>>> features can go into trunk, because I really don't like option 1... >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>> On 2014/08/05, at 11:31, Matt Sicker >>>>>> > wrote: >>>>>>> >>>>>>> I think we can easily do bug fixes from the tag. >>>>>>> >>>>>>> >>>>>>> On 4 August 2014 21:15, Remko Popma >>>>>> > wrote: >>>>>>> >>>>>>>> Well, the thing is, I've been holding back on this and prioritized >>>>>>>> bugfixes for over a year now in order to get 2.0 out the door. I've really >>>>>>>> been looking forward to working on these new things. >>>>>>>> >>>>>>>> So what am I supposed to do? There will never be an end to new bugs >>>>>>>> being reported. >>>>>>>> >>>>>>>> Not happy, >>>>>>>> Remko... >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On 2014/08/05, at 10:24, Gary Gregory >>>>>>> > wrote: >>>>>>>> >>>>>>>> It seems that there are some fixes and pending bugs since we >>>>>>>> started the 2.0.1 vote that would justify a 2.0.2. Then we could do 2.1. My >>>>>>>> feeling is that our priority should be to fix 2.0.x as much as possible >>>>>>>> before adding more features for a 2.1. IOW, let's stabilize the current >>>>>>>> features in 2.0.x, then add complexity and possible bugs with new features. >>>>>>>> >>>>>>>> Gary >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Aug 4, 2014 at 8:10 PM, Matt Sicker >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Are there any outstanding issues we'd like to address in a 2.0.2 >>>>>>>>> release, or should we just start working toward 2.1 now instead? Because if >>>>>>>>> we go the 2.1 route of focus, I've got a few branches to merge back >>>>>>>>> together (thankfully, git-svn will help a lot in that regard) into trunk. >>>>>>>>> >>>>>>>>> As Ralph (IIRC) pointed out, we don't need to make an explicit 2.0 >>>>>>>>> branch since we can just branch from the 2.0.1 tag itself if necessary. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Matt Sicker >>>>>>>> > >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> E-Mail: garydgregory@gmail.com >>>>>>>> | ggregory@apache.org >>>>>>>> >>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>> >>>>>>>> JUnit in Action, Second Edition >>>>>>>> Spring Batch in Action >>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>> Home: http://garygregory.com/ >>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matt Sicker >>>>>> > >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matt Sicker >>>>> > >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> E-Mail: garydgregory@gmail.com >>>>> | ggregory@apache.org >>>>> >>>>> Java Persistence with Hibernate, Second Edition >>>>> >>>>> JUnit in Action, Second Edition >>>>> Spring Batch in Action >>>>> Blog: http://garygregory.wordpress.com >>>>> Home: http://garygregory.com/ >>>>> Tweet! http://twitter.com/GaryGregory >>>>> >>>> >>>> >>> >>> >>> -- >>> E-Mail: garydgregory@gmail.com >>> | ggregory@apache.org >>> >>> Java Persistence with Hibernate, Second Edition >>> >>> JUnit in Action, Second Edition >>> Spring Batch in Action >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >> >> > > > -- > E-Mail: garydgregory@gmail.com > | ggregory@apache.org > > Java Persistence with Hibernate, Second Edition > > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > --047d7bd761a445ee4304ffe25ac5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, August 5, 2014, Gary Gregory <garydgregory@gmail.com> wrote:
On T= ue, Aug 5, 2014 at 9:21 AM, Remko Popma <remko.popma@gmail.com> wrote:



On Tue, Aug 5, 2014 at 10:04 PM= , Gary Gregory <garydgregory= @gmail.com> wrote:
=
On Tue, Aug 5, 2014 at 8:55 AM, Remko Popma= <remko.popma@gmail.com&g= t; wrote:
I have only used git a litt= le, not much experience with it, but I've heard good things about it.
Please don't misunderstand, I don't mind having another bugfix= release.
I also don= 't mind fixing bugs and supporting users. I think I have a solid track = record in that regard.

I just think that new bug reports w= ill keep coming in forever, and we should have some sort of=C2=A0structure for deal= ing with that that does not prevent working on new features in parallel.=C2=A0

=
If git makes branching/merging easier then perhaps that would be a good = solution for this?

Branching is for this kind of = work of course. I just do not want to incur the overhead of dealing with br= anches unless I have to. So to put in in concrete terms I propose to keep i= t simple like this:

- 2.0.2: a bug fix release where the vote starts 8/18
- 2.1.0: start work after 2.0.2 (which includes bug fixes of course= ).
- All in trunk

Okay, I can live with that. To clarify, the work = for 2.1 would be done in trunk, correct?

Right, I would just ask for patience before firing up= 2.1 code in trunk to after 2.0.2. This will let us all focus on 2.0.2 whic= h can only be a good thing IMO.
Okay, understood.=C2=A0
=C2= =A0
=

Would be be an idea to look = at moving to git anyway? (I'm kind of +0.5 on that, I think it might be= a good idea to move to git anyway, just not sure how much effort it would = be...)

Can you start a separate= thread? We can [discuss], then [vote]; or you can put up a [vote] thread r= ight away. Up to you.
Will do.=C2= =A0=C2=A0
=

Gary
=C2=A0
=C2=A0
=C2=A0

G= ary



On Tue, Aug 5, 2014 at 9:51 PM, Gary Gregory <garydgregory@gmail.com> wrote:
I think we can keep our liv= es simpler WRT development process by putting out a patch release or two (a= s Ralph and I suggest), then moving to 2.1. This will leaving branch only t= o developers who really need/want it.

Gary

On Tue, Aug 5, 2014 at 8:45 AM, Matt Sicker <boards@gmail.com> wro= te:
I'm perfectly fine with= moving to git, but that's mainly because it's what I use every day= as it is.


On 5 August 2014 07:26, Ralph Goers <rgoers@apache.org> wrote:
I think this makes se= nse. As a general practice having at least two or three patch releases afte= r a major or minor release is probably a good idea. It is also fair to poin= t out that it is highly unlikely that we would generate a patch release for= an older version - once 2.1 is released it is unlikely we would go back an= d release 2.0.2.

Ralph

On Aug 5, 2014, at 4:19 AM,= Gary Gregory <garydgregory@gmail.com> = wrote:

I should have been clearer, sorry. I am suggesting we take a week (or = two) and have a round of bug fixing for a 2.0.2, even if those are just low= hanging fruits. This will give us a "better 2.0", then we do new= features. As a user, that would give me confidence the log4j team is liste= ning to bug reports before going back to having fun adding new features.=C2= =A0

2c,
Gary

Gary

-------- Original message --------
From: Remko Popma <= u>
Date:08/05/2014 00:48 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Which dire= ction to focus on next?

<= div>Thanks, Matt.=C2=A0

Gary, Ralph, what do you t= hink?
Where should we work on new features? I see these options:
<= br>
1. Don't work on new features, or keep new features on ou= r local machines, don't commit to apache svn. (TBD: until when?)

2. Everyone creates separate branches for new features = they want to work on. So Remko would have a binary logging/memmap branch, a= nd a branch for deleting old rolled-over files, Matt would have a jdbc-batc= hed-inserts branch, etc. Bugfixes go into trunk. Everyone is free to sync t= heir branch(es) with trunk's bugfixes or not.=C2=A0

3. We create a shared 2.1 branch for new features. Bugf= ixes go into trunk as well as the 2.1 branch.=C2=A0

4. Both new features and bugfixes are committed to trunk. No branches nee= ded.=C2=A0

5. The opposite of option 3: we create a 2.0.2 branch t= hat holds bugfixes only. Trunk has both new features and bugfixes.=C2=A0

6. Any alternatives that I missed?

Gary, in the past you mentioned you don't like the busywork of mai= ntaining two branches. I'm fine with that, but to me that means new fea= tures can go into trunk, because I really don't like option 1...

Thoughts?

Sent from my iPhone
<= br>On 2014/08/05, at 11:31, Matt Sicker <boards@gmai= l.com> wrote:

I think we can easily do bug fixes from the tag.
<= /div>


On 4 Aug= ust 2014 21:15, Remko Popma <= remko.popma@gmail.com> wrote:
Well, the thing is, I= 've been holding back on this and prioritized bugfixes for over a year = now in order to get 2.0 out the door. I've really been looking forward = to working on these new things.=C2=A0

So what am I supposed to do? There will never be an end= to new bugs being reported.=C2=A0

Not happy,
Remko...

Sent from my iPhone

On 2014/08/05, at 10:24, Gary Gregory <garydgregory@gmail.com> wrote:

It seems that there are some fixes and pending bugs s= ince we started the 2.0.1 vote that would justify a 2.0.2. Then we could do= 2.1. My feeling is that our priority should be to fix 2.0.x as much as pos= sible before adding more features for a 2.1. IOW, let's stabilize the c= urrent features in 2.0.x, then add complexity and possible bugs with new fe= atures.

Gary


On Mon, Aug 4, 2014 at 8:10 PM, Matt Sicker <boards@gmail.com> wrote:
Are there any outstanding i= ssues we'd like to address in a 2.0.2 release, or should we just start = working toward 2.1 now instead? Because if we go the 2.1 route of focus, I&= #39;ve got a few branches to merge back together (thankfully, git-svn will = help a lot in that regard) into trunk.

As Ralph (IIRC) pointed out, we don't need to make an explicit 2.0 = branch since we can just branch from the 2.0.1 tag itself if necessary.

--
Matt Sicker <boards@gmail.com>



--



--
Matt Sicker <boards@gmail.com>
=



-= -
Matt Sicker <boards@gmail.com>



--





--
--047d7bd761a445ee4304ffe25ac5--