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? 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...) > > 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 >
