Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: dev@camel.apache.org
Cc: Willem Jiang <willem.jiang@gmail.com>
Subject: Re: [DISCUSS] Closing down for the 2.8.0 release
Date: Wed, 06 Jul 2011 22:48:11 -0400
Message-ID: <1882988.dbyx73sZnV@dilbert.dankulp.com>
User-Agent: KMail/4.6.0 (Linux/2.6.39; KDE/4.6.4; x86_64; ; )
In-Reply-To: <4E151CB2.40504@gmail.com>
References: <4DF0C0E5.8070806@gmail.com>
 <3353774.J5LnxdKZYM@dilbert.dankulp.com> <4E151CB2.40504@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

On Thursday, July 07, 2011 10:40:50 AM Willem Jiang wrote:
> OK, I see the patch rule is based on the Talend customer.

To be clear, I didn't say this is driven by a Talend customer.  Again, =
they=20
don't care if it's done here or in a private repo or something.    Howe=
ver, if=20
I'm doing some work for a Talend customer, it makes sense to me that ev=
eryone=20
can benefit from it.    This can be perfectly applied for Fuse as well.=
  I=20
know you spend a lot of time porting fixes back to 2.7.x (and 2.6.x, et=
c...)=20
for Fuse customers.   Other Camel users COULD benefit from that work as=
 well. =20
That's completely up to you guys though.

Dan


>=20
> On 7/6/11 9:32 PM, Daniel Kulp wrote:
> > One other note:
> >=20
> > Talend  has customers on 2.7.x that are not likely to move to 2.8.0=
 any
> > time soon.   As Christian pointed out, lots of companies use a 6-8
> > month cycle, Some longer, some shorter, and won't move off what the=
y
> > have for quite a bit of time.     Thus, no matter what, I am going =
to
> > have to port some bug fixes back to 2.7.x.    There isn't anyway fo=
r me
> > to avoid that (unless I tell my customers "too bad, no fixes" which=

> > would not go over well :-) ).   I COULD do the porting on some priv=
ate
> > fork of the Camel branches and deliver the fixes to the customers t=
hat
> > way.   That's definitely a perfectly valid way to do it. In that ca=
se,
> > all my work really would just benefit a small number of Camel users=
.=20
> > I'd MUCH MUCH prefer to do the porting here and allow my work to
> > benefit the entire Camel community.   It's the exact same amount of=

> > work, just in a different place.  (well, I suppose if the fork is u=
sing
> > git, it could be a little less work as merging with git is so much
> > nicer and faster, but still, that's minor)
> >=20
> > Likewise for releases.  I could create private releases and stick t=
hem
> > in a "talend" repository someplace (and in some cases, I may need t=
o do
> > that anyway), but I could also do roughly the same amount of work h=
ere
> > (calling the vote is additional work here, but that's minor) and th=
e
> > entire Camel user base benefits.   In addition, the releases here w=
ould
> > go to central which makes our customers happy. (no Nexus updates,
> > firewall rules updates, etc...)
> >=20
> > In short, the incremental cost for *ME* to continue supporting the =
fixes
> > branches that our customers are using is negligible.  There's reall=
y no
> > reason to not do it.  It has an additional benefit of making other
> > Camel users happier by providing more stable releases for them to u=
se.=20
> >  IMO, it's basically a "win-win" all around, or am I missing someth=
ing?
> >=20
> > Dan
> >=20
> > On Wednesday, July 06, 2011 7:55:16 AM Christian Schneider wrote:
> >> Hi Willem,
> >>=20
> >> I can explain a bit from my experience as a user of Camel and CXF =
at
> >> my
> >> former employer regarding patch releases.
> >>=20
> >> We updated our stack every 6 to 8 months. With CXF this mostly sim=
ply
> >> worked. When some bug was detected we could create an issue and he=
lp
> >> fix
> >> it. It went into the next patch release and we could
> >> update to this one instead of the feature release.
> >>=20
> >> With Camel it was different. Every new release had a lot of new
> >> features
> >> and changes. So we almost every time found a bug in the release th=
at
> >> prevented us to switch or that was a problem in production that ne=
eded
> >> to be addressed. What went very well in Camel was reporting and fi=
xing
> >> bugs. I think Camel is probably the project I used where fixes to =
bugs
> >> were made fastest. The problem was that the fix was only on trunk.=

> >> Then
> >> later it was incorporated into the new version. So my first strate=
gy
> >> was
> >> to update to the most current camel release when a bug was found a=
nd
> >> fixed. The problem was that we almost every time found another pro=
blem
> >> in the new release.
> >> So what I did in the end was building our own release with the pat=
ches
> >> to the bugs we had. This worked very well but not every customer w=
ants
> >> to do this.
> >>=20
> >> Patch releases like 2.7.3 give the customer the fixes they need
> >> without
> >> the breaking changes that cause new bugs. So from a customer
> >> standpoint
> >> patch releases are very valueable. Of course they make life for us=

> >> more
> >> complicated so I think we should mostly only support one patch rel=
ease
> >> and one feature release at the same time. Of course a company like=

> >> Fuse
> >> or Talend can also do patch releases on their own but I think it i=
s
> >> better to have these releases at apache so it is transparent to th=
e
> >> customer what is in each release and he has no fear of vendor lock=
 in.
> >>=20
> >> Christian
> >>=20
> >> Am 06.07.2011 04:09, schrieb Willem Jiang:
> >>> Hi Hadrian,
> >>>=20
> >>> I think we are ready for the Camel 2.8.0 release.
> >>> But I'm not sure why you are still planing to do the patch releas=
e
> >>> for
> >>> the 2.7.x as we never do this kind small patch release unless it
> >>> relates to a serious security issue before.
> >>>=20
> >>> Can we just let the people move on to Camel 2.8.0 instead of
> >>> confusing
> >>> about what's difference between the Camel 2.8.0 and Camel 2.7.3 ?=

> >>>=20
> >>> On 7/5/11 12:11 PM, Hadrian Zbarcea wrote:
> >>>> Karaf 2.2.2 is now available and Willem did the upgrade. I think=

> >>>> we
> >>>> can
> >>>> get ready to start the release. Are there any other issues that
> >>>> must
> >>>> go
> >>>> into 2.8.0?
> >>>>=20
> >>>> I would also build a 2.7.3 at the same time, there are a few fix=
es
> >>>> and
> >>>> improvements, including some around xmlsecurity.
> >>>>=20
> >>>> Thoughts?
> >>>> Hadrian
> >>>>=20
> >>>> On 06/30/2011 11:07 PM, Willem Jiang wrote:
> >>>>> Hi,
> >>>>>=20
> >>>>> I just applied the patch into trunk.
> >>>>>=20
> >>>>> On 7/1/11 12:36 AM, Donald Whytock wrote:
> >>>>>> https://issues.apache.org/jira/browse/CAMEL-3948
> >>>>>>=20
> >>>>>> On Thu, Jun 30, 2011 at 12:35 PM, Donald
> >>>>>> Whytock<dwhytock@gmail.com>
> >>>>>>=20
> >>>>>> wrote:
> >>>>>>> Just a reminder...CAMEL-3948 is marked as fixed, but the
> >>>>>>> current
> >>>>>>> trunk
> >>>>>>> still needs my final patch.
> >>>>>>>=20
> >>>>>>> Don
> >>>>>>>=20
> >>>>>>> On Thu, Jun 30, 2011 at 2:46 AM, Jean-Baptiste
> >>>>>>>=20
> >>>>>>> Onofr=E9<jb@nanthrax.net>  wrote:
> >>>>>>>> Hi Claus,
> >>>>>>>>=20
> >>>>>>>> Regarding Karaf 2.2.2, I've released OPS4J dependencies
> >>>>>>>> yesterday.
> >>>>>>>> Jamie
> >>>>>>>> will cut off the release this afternoon.
> >>>>>>>>=20
> >>>>>>>> Regards
> >>>>>>>> JB
> >>>>>>>>=20
> >>>>>>>> On 06/30/2011 08:31 AM, Claus Ibsen wrote:
> >>>>>>>>> Hi
> >>>>>>>>>=20
> >>>>>>>>> Okay the JIRA roadmap for Camel 2.8 seems good now.
> >>>>>>>>> There is
> >>>>>>>>> 2 open
> >>>>>>>>> tickets.
> >>>>>>>>> - https://issues.apache.org/jira/browse/CAMEL-3774
> >>>>>>>>> - https://issues.apache.org/jira/browse/CAMEL-4144
> >>>>>>>>>=20
> >>>>>>>>> CAMEL-3774 is about generating the manual and is
> >>>>>>>>> assigned to
> >>>>>>>>> Hadrian.
> >>>>>>>>>=20
> >>>>>>>>> CAMEL-4144 is about upgrading to Karaf 2.2.2. That
> >>>>>>>>> release
> >>>>>>>>> is in
> >>>>>>>>> progress.
> >>>>>>>>> So by good chance we should be able to pickup that
> >>>>>>>>> version
> >>>>>>>>> when its
> >>>>>>>>> released.
> >>>>>>>>> Alternatively we can stick to Karaf 2.2.1 which works
> >>>>>>>>> fine.
> >>>>>>>>> (CAMEL-4144 is about some maven validate goal that would
> >>>>>>>>> require
> >>>>>>>>> Karaf
> >>>>>>>>> 2.2.2 to pickup a fix in Karaf, but running Camel in
> >>>>>>>>> Karaf
> >>>>>>>>> is
> >>>>>>>>> absolutely fine)
> >>>>>>>>>=20
> >>>>>>>>> The CI servers also seems good. Although they tend to
> >>>>>>>>> run
> >>>>>>>>> out of
> >>>>>>>>> memory at the end, such as when testing the examples.
> >>>>>>>>> But
> >>>>>>>>> those are
> >>>>>>>>> the last piece of the build, and thus all components
> >>>>>>>>> tests
> >>>>>>>>> fine.
> >>>>>>>>>=20
> >>>>>>>>> I suggest that when Karaf 2.2.2 is out we git it a few
> >>>>>>>>> spins
> >>>>>>>>> on
> >>>>>>>>> the CI
> >>>>>>>>> servers and then start cutting the Camel 2.8 release.
> >>>>>>>>> Would
> >>>>>>>>> be
> >>>>>>>>> good to
> >>>>>>>>> get it out before the summer vacation starts. As well
> >>>>>>>>> its
> >>>>>>>>> more
> >>>>>>>>> than 3
> >>>>>>>>> months since Camel 2.7 was released.
> >>>>>>>>>=20
> >>>>>>>>>=20
> >>>>>>>>>=20
> >>>>>>>>> On Mon, Jun 27, 2011 at 9:35 AM, Claus
> >>>>>>>>> Ibsen<claus.ibsen@gmail.com>
> >>>>>>>>>=20
> >>>>>>>>> wrote:
> >>>>>>>>>> Hi
> >>>>>>>>>>=20
> >>>>>>>>>> Okay we should really start focusing on getting the
> >>>>>>>>>> last
> >>>>>>>>>> tickets
> >>>>>>>>>> which
> >>>>>>>>>> has been assigned for 2.8 release done now.
> >>>>>>>>>> There is about 350 tickets on the roadmap, so its
> >>>>>>>>>> going to
> >>>>>>>>>> be the
> >>>>>>>>>> biggest release, since 2.0 went GA.
> >>>>>>>>>>=20
> >>>>>>>>>> So please take a look at your assigned tickets and get
> >>>>>>>>>> them
> >>>>>>>>>> done, or
> >>>>>>>>>> move them for 2.9.
> >>>>>>>>>> Then keep eyes on CI servers and help fix any test
> >>>>>>>>>> failures, so we
> >>>>>>>>>> have green builds.
> >>>>>>>>>>=20
> >>>>>>>>>> The summer vacation period is approaching so we should
> >>>>>>>>>> IMHO get
> >>>>>>>>>> the
> >>>>>>>>>> 2.8 release out early next month if possible.
> >>>>>>>>>>=20
> >>>>>>>>>>=20
> >>>>>>>>>> On Thu, Jun 9, 2011 at 2:47 PM, Hadrian
> >>>>>>>>>> Zbarcea<hzbarcea@gmail.com>
> >>>>>>>>>>=20
> >>>>>>>>>> wrote:
> >>>>>>>>>>> Hi,
> >>>>>>>>>>>=20
> >>>>>>>>>>> I would propose starting to close down and prepare
> >>>>>>>>>>> for
> >>>>>>>>>>> the 2.8.0
> >>>>>>>>>>> release
> >>>>>>>>>>> in
> >>>>>>>>>>> 2-3 weeks. There are already 282 issues for 2.8.0
> >>>>>>>>>>> and
> >>>>>>>>>>> chances are
> >>>>>>>>>>> will
> >>>>>>>>>>> be
> >>>>>>>>>>> over 300 by the release time, probably setting a new
> >>>>>>>>>>> record.
> >>>>>>>>>>>=20
> >>>>>>>>>>> As of now there are 17 issues unresolved, a few of
> >>>>>>>>>>> them
> >>>>>>>>>>> almost
> >>>>>>>>>>> done, so
> >>>>>>>>>>> by
> >>>>>>>>>>> next week I assume there'll be significantly less. I
> >>>>>>>>>>> would
> >>>>>>>>>>> suggest
> >>>>>>>>>>> shifting
> >>>>>>>>>>> the focus from adding new features to stabilizing
> >>>>>>>>>>> the
> >>>>>>>>>>> build. If
> >>>>>>>>>>> there
> >>>>>>>>>>> are
> >>>>>>>>>>> any issues you know of that you think absolutely
> >>>>>>>>>>> must be
> >>>>>>>>>>> in 2.8.0
> >>>>>>>>>>> please
> >>>>>>>>>>> shout and ask for help if needed (especially non
> >>>>>>>>>>> committers
> >>>>>>>>>>> subscribing
> >>>>>>>>>>> to
> >>>>>>>>>>> this list).
> >>>>>>>>>>>=20
> >>>>>>>>>>> Thoughts?
> >>>>>>>>>>>=20
> >>>>>>>>>>> Hadrian
--=20
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com