logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: Which direction to focus on next?
Date Tue, 05 Aug 2014 14:05:48 GMT
On Tuesday, August 5, 2014, Gary Gregory <garydgregory@gmail.com> wrote:

> On Tue, Aug 5, 2014 at 9:21 AM, Remko Popma <remko.popma@gmail.com
> <javascript:_e(%7B%7D,'cvml','remko.popma@gmail.com');>> wrote:
>
>>
>>
>>
>> On Tue, Aug 5, 2014 at 10:04 PM, Gary Gregory <garydgregory@gmail.com
>> <javascript:_e(%7B%7D,'cvml','garydgregory@gmail.com');>> wrote:
>>
>>> On Tue, Aug 5, 2014 at 8:55 AM, Remko Popma <remko.popma@gmail.com
>>> <javascript:_e(%7B%7D,'cvml','remko.popma@gmail.com');>> 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 <garydgregory@gmail.com
>>>> <javascript:_e(%7B%7D,'cvml','garydgregory@gmail.com');>> 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 <boards@gmail.com
>>>>> <javascript:_e(%7B%7D,'cvml','boards@gmail.com');>> 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 <rgoers@apache.org
>>>>>> <javascript:_e(%7B%7D,'cvml','rgoers@apache.org');>> 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 <garydgregory@gmail.com
>>>>>>> <javascript:_e(%7B%7D,'cvml','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
>>>>>>> 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 <boards@gmail.com
>>>>>>> <javascript:_e(%7B%7D,'cvml','boards@gmail.com');>>
wrote:
>>>>>>>
>>>>>>> I think we can easily do bug fixes from the tag.
>>>>>>>
>>>>>>>
>>>>>>> On 4 August 2014 21:15, Remko Popma <remko.popma@gmail.com
>>>>>>> <javascript:_e(%7B%7D,'cvml','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.
>>>>>>>>
>>>>>>>> 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 <garydgregory@gmail.com
>>>>>>>> <javascript:_e(%7B%7D,'cvml','garydgregory@gmail.com');>>
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 <boards@gmail.com
>>>>>>>> <javascript:_e(%7B%7D,'cvml','boards@gmail.com');>>
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 <boards@gmail.com
>>>>>>>>> <javascript:_e(%7B%7D,'cvml','boards@gmail.com');>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> E-Mail: garydgregory@gmail.com
>>>>>>>> <javascript:_e(%7B%7D,'cvml','garydgregory@gmail.com');>
| ggregory@apache.org
>>>>>>>> <javascript:_e(%7B%7D,'cvml','ggregory@apache.org');>
>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>> Home: http://garygregory.com/
>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <boards@gmail.com
>>>>>>> <javascript:_e(%7B%7D,'cvml','boards@gmail.com');>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <boards@gmail.com
>>>>>> <javascript:_e(%7B%7D,'cvml','boards@gmail.com');>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com
>>>>> <javascript:_e(%7B%7D,'cvml','garydgregory@gmail.com');> | ggregory@apache.org
>>>>> <javascript:_e(%7B%7D,'cvml','ggregory@apache.org');>
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> <http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com
>>> <javascript:_e(%7B%7D,'cvml','garydgregory@gmail.com');> | ggregory@apache.org
>>> <javascript:_e(%7B%7D,'cvml','ggregory@apache.org');>
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com
> <javascript:_e(%7B%7D,'cvml','garydgregory@gmail.com');> | ggregory@apache.org
> <javascript:_e(%7B%7D,'cvml','ggregory@apache.org');>
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Mime
View raw message