[Kalzium] [Avogadro-devel] Fwd: Final Reminder: KDE 4.2 Feature Plan Closing Tonight

[Benoît Jacob]

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