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 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
