On Sunday 16 November 2008 07:19:30 Marcus D. Hanwell wrote:
On Sunday 16 November 2008 00:35:50 Benoît Jacob wrote:
Here’s the latest episode of this comedy…
So you are saying we can’t port any kalzium stuff now due to local fixes in
KDE? I was working on a port locally but if that is not feasible then I
will continue to work on getting Avogadro into a state where the API should
be something we can stabilise. I have some local changes but if this would
cause more issues then I can leave this.
I wouldn’t say we “can’t” but I would say that most of it would take a couple
of hours to get right, and some of it would takes days as it requires
discussion with the kde-windows team:
I tried generating diffs for chehrlich’s commits and apply these to avo trunk,
and that failed, so his modifications have to be applied line by line. Plus,
some of his changes are kalzium-specific (like a kalzium-specific env
variable for plugins) and in this respect is nontrivial to make avo upstream
work for them when we have only 2 days to communicate with them…
I didn’t realize you were working on a port locally. I pinged you on IRC, but
of course just because you were logged doesn’t mean you were watching IRC,
sorry.
If you have an update of the libavogadro snapshot in your local changes, then
of course it’s a better solution for the user than what I made, but I think
that before committing it is needed to apply chehrlich’s changes, we don’t
want to make him work twice fixing our snapshots. For the ones about the
kalzium-specific env variable, I’m not sure why they need it at all since avo
itself works fine under windows, perhaps keep it in kalzium until they can
explain us the problem…
My rationale generally is, since this is more work than expected, and this
only affects 4.2 which will be the latest version for less than 6 months,
let’s go for the easiest path…
Your time is precious – all the more as you are working on avo trunk towards
stabilising the API – so I figured that you wouldn’t mind too much my
solution sparing you the work on 4.2.
I realized that our libavogadro snapshot contains fixes (especially by
the kde-windows guys) that would be lost if we updated it from avo trunk,
and that can’t be easily forwardported to avo trunk anymore since we
didn’t do it in time.
I thought the hard freeze was on Monday? Are you saying changes like this
require more time?
Yes it is monday! Given my limited time and skill, for me it may require more
time. Another reason why it may require more time is if it involves
communicating with the kde-windows guys. If you take care of it, things are
different.
I thought Monday was the day all new features must be in
and then they were stabilised after that? I certainly don’t want to cause
headaches for people.
That’s right, we can stabilise after… I didn’t think of that. So the windows
fixes can be done after, good point.
Of course that’s a completely unsustainable thing to do in the long term,
and the fact that our libavo snapshot contains changes that now are
difficult to forwardport is another proof that it is more than time to
get rid of any snapshot, so in 4.3, I really really hope that libavogadro
1.0 is out, otherwise we will have to remove the molecular editor from
/trunk/KDE (playground would then be a good temporary home for it).
Personally, I think that it would probably be better for several reasons to
split of the molecular editor into a separate app.
100% agree.
If you do it early enough (finish 2 weeks before hard freeze for 4.3 to let
some time for kdereview) then it can be part of kdeedu already in 4.3.
That way
bugs/regressions in that can be looked at in isolation. If you look in the
Primitive branwch I have been doing a lot of work to give us an API that we
can stabilise. I am working towards merging this branch into trunk once I
have ported the extensions.
That’s great, I’m looking forward to that. It’s good to have you working on
this.
I am right there with you on having a stable API but I don’t think our core
data classes were really up to the task and so I have put a lot of time
into improving them.This has the side benefit that the API is much more
C++/Qt in style too and so should hopefully be easier to use.
OK I understand. I play the role of the user knocking on the table asking for
stability but I understand that it’s much more subtle than just saying that
after some date one doesn’t make incompatible changes.
I have been traveling, then ill and busy catching up and so this has
delayed my progress.
Hey, sorry to hear that.
To be honest I thought I was free to work on stuff
this weekend and commit it too. May be just working in a git branch during
the freeze would be the best policy?
Well even if you can’t finish that by monday, then anyway the next release 4.3
will (I understand) rely directly on avo trunk…
I want to ensure Kalzium has really nice features in it and am committed to
ensuring that is the case. If I can’t commit updates I won’t. I hadn’t
thought of having people commit local changes to our snapshot of
libavogadro without emailing upstream/sending patches on.
I agree I didn’t expect it either and I would have liked too to receive
notifications. I suppose that for someone not familiar with the project it
was not too obvious that this was a snapshot.
Cheers,
Benoit
