logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Which direction to focus on next?
Date Tue, 05 Aug 2014 13:04:24 GMT
On Tue, Aug 5, 2014 at 8:55 AM, Remko Popma <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

Gary


>
> On Tue, Aug 5, 2014 at 9:51 PM, Gary Gregory <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> 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> 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>
>>>> 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> wrote:
>>>>
>>>> I think we can easily do bug fixes from the tag.
>>>>
>>>>
>>>> On 4 August 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.
>>>>>
>>>>> 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>
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>
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>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | 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>
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <boards@gmail.com>
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | 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 | 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