On Tue, Aug 5, 2014 at 9:21 AM, Remko Popma <[email protected]> wrote:
> > > > On Tue, Aug 5, 2014 at 10:04 PM, Gary Gregory <[email protected]> > wrote: > >> On Tue, Aug 5, 2014 at 8:55 AM, Remko Popma <[email protected]> >> 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. > > 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. Gary > > >> >> Gary >> >> >>> >>> On Tue, Aug 5, 2014 at 9:51 PM, Gary Gregory <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>>> 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 <[email protected]> wrote: >>>>>> >>>>>> I think we can easily do bug fixes from the tag. >>>>>> >>>>>> >>>>>> On 4 August 2014 21:15, Remko Popma <[email protected]> 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 <[email protected]> >>>>>>> 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 <[email protected]> >>>>>>> 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 <[email protected]> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> E-Mail: [email protected] | [email protected] >>>>>>> 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 <[email protected]> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Matt Sicker <[email protected]> >>>>> >>>> >>>> >>>> >>>> -- >>>> E-Mail: [email protected] | [email protected] >>>> 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: [email protected] | [email protected] >> 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: [email protected] | [email protected] 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
