Hi Pete,
Peter Lavender wrote:
>> There's this branch in branches/Padre-slave-driver that has the memory
>> consumption/threading optimizations that Adam blogged about. It works
>> well on my computer (linux), but it's a pretty devious and significant
>> change. To the best of my knowledge, it's also only been tested by me
>> despite my multiple suggestions on IRC that others should give it a
>> shot. Now, I guess our development model or our developers mindset is
>> such that it won't get a lot of testing time *unless* I just dump it
>> into the trunk and let Murphy figure it out. I'm certain there'll be
>> breakage.
> Right.. it's a bit like that.. I had a patch waiting for ages for
> someone to check out in the end I added it to trunk. It was very simple
> really, nothing like what you're doing, but it's the same end result..
> it's not noticed until it hits trunk and then a release.
It's not really surprising either. We're a volunteer group. I think all
of us are in it for our own enjoyment. Testing branches is no fun.
>> This suggests two possible routes:
>> a) Make a release now, then merge the branch into trunk. Buys us time to
>> fix things.
>> b) Merge the branch into trunk and delay the release until we're certain
>> we've fixed the most serious issues. Could make Padre 0.56 an even more
>> significant release (cf. Adam's blog entry).
>>
>> I'd love to have this in the upcoming (hyped) 0.56 release. But it's
>> quite risky and it might be better to stick with a). What do you guys think?
>
> Ok, I'll do a switch here and try it out myself.
Thanks! The branch may be behind trunk by a few revisions (check svn
info if in doubt).
> I'm quite open on this matter myself. If we want to wait that's fine.
>
> I'm quite a fan of least changes at once to make sure we can at least
> see what's going on at the time a major change comes in.
Given that we're usually using the frequent Padre releases to whittle
out bugs ("the problem manifested between 0.38 and 0.39." vs. the more
usual "bisection tells me the problem manifested with change 10000") and
that's probably a difficult to break habit (cf. comment about volunteer
groups) it's probably better to push out a 0.56 release without my
dubious changes.
> In the recent past many of the 'big' changes we've seen to Padre has
> come from Adam where incremental changes aren't overly an issue and I
> know I've done releases with Adam's changes only partially applied, with
> major gains seen up to 2 releases later.
>
> Given what I understand of the changes from Adams Blog, I will say that
> making it for 0.56 make sense, but it means we need the time to do it.
Yes. If we were to merge my branch to trunk, we'd have to delay 0.56 for
sure. Anything else would be unfair to the beta testers^W^W users.
> The only issue I see is that there are already a large number of changes
> listed already, and Sebastian's concern with problems he's seeing means
> merging now just to squeeze in before 0.56 might make sorting out any
> issues harder than it needs to be.
Agreed.
> While it might hurt a little bit in terms of the "marketing" done for
> 0.56, I think we could make 0.56 with what's already done, with the
> merge to trunk after the release being your changes - and two weeks to
> get it ironed out, keeping major changes out until your changes are
> stabilised.
Adam's changes have impacted the apparent performance *a lot*. When I
tried them for the first time, I really was amazed. Just as he's written
in his blog, 0.56 is going to be *the* release to try out and to upgrade
to. My changes are quite different if still important. They wouldn't
really be visible to the users (modulo Scalars Leaked) unless they're
very memory bottlenecked.
> This gives us a fairly clear and visible progression with major changes
> to Padre.
Agreed!
Best regards,
Steffen
PS: I'd particularly appreciate testing with Padre::Service related
functionality. Not sure where that's used. For sure in ::Plugin::Swarm,
though.
_______________________________________________
Padre-dev mailing list
[email protected]
http://mail.perlide.org/mailman/listinfo/padre-dev
