Fwd: Final Reminder: KDE 4.2 Feature Plan Closing Tonight

Nobody replied… confirms my fear that Kalzium is seriously lacking love.

Beware: provocative phrasing below this point.

Look, we’re not going to keep eigen1 alongside eigen2 in kdesupport forever,
just because nobody cares to deal with the old libavogadro snapshot used by
Kalzium.

Apparently libavogadro hasn’t reached ABI stability. That’s a big problem.
When we made kalzium rely on libavogadro, the assumption was that we could
rely on libavogadro in KDE 4.1. Now the feature freeze of KDE 4.2 is coming
real soon.

I don’t have the time to split the viewer away from kalzium and move it to
playground.

For 4.2 the least painful thing to do is to update once again the libavogadro
snapshot. That’s all I can offer to do. Agree?

For 4.3 i think it’s out of question to keep a snapshot again.

I want to state two big problems clearly:

  1. we need badly libavogadro to stabilize.

  2. we need fresh blood in the Kalzium developer team. Kalzium is currently in
    a state of minimal life support, that’s not good enough for a project with
    such potential and which got a SOC project in 2007 and another one in 2008. I
    would like you Carsten to tackle this problem. If you don’t take care to find
    a new maintainer, Kalzium will keep rotting. Only you can write the Kalzium
    internals documentation that is needed to let someone else help you.

Maybe it’d be interesting to hear from Frederik’s experience getting
acquainted with the old KVocTrain codebase and overhauling it.

Cheers,
Benoit

On Sunday 19 October 2008 19:03:03 Benoît Jacob wrote:

Hi,

Tonight the feature plan is closing and I suspect that this change should
be filed in it. So I edit the wiki to leave us the possibility of doing
something about the libavogadro snapshot which IMO must go away from KDE
4.2.

Marcus, is libavogadro API-stable? How about the subset that Kalzium needs?
If yes we let kalzium depend on it.

If no then we should just separate completely the 3D viewer part from the
rest of kalzium and move it to playground (“mikrogadro” ?), so it can
currently depend on libavogadro even if it’s not API stable.

Cheers,
Benoit

Am Monday 27 October 2008 18:23:17 schrieb Benoît Jacob:

Nobody replied… confirms my fear that Kalzium is seriously lacking love.

Indeed it is.

Look, we’re not going to keep eigen1 alongside eigen2 in kdesupport
forever, just because nobody cares to deal with the old libavogadro
snapshot used by Kalzium.

For 4.2 the least painful thing to do is to update once again the
libavogadro snapshot. That’s all I can offer to do. Agree?

I am fine with that!

For 4.3 i think it’s out of question to keep a snapshot again.

I want to state two big problems clearly:

  1. we need badly libavogadro to stabilize.

  2. we need fresh blood in the Kalzium developer team. Kalzium is currently
    in a state of minimal life support, that’s not good enough for a project
    with such potential and which got a SOC project in 2007 and another one in

  1. I would like you Carsten to tackle this problem. If you don’t take
    care to find a new maintainer, Kalzium will keep rotting.

Yes, currently I really don’t have much time as beside being a full time
teacher I am the system admin of my school which sucks up the rest of the
time I am willing to spend with computers.

Maybe it’d be interesting to hear from Frederik’s experience getting
acquainted with the old KVocTrain codebase and overhauling it.

I CC’ed him.

Carsten


“Of course, in Perl culture, almost nothing is prohibited. My feeling
is that the rest of the world already has plenty of perfectly good
prohibitions, so why invent more?”

– Larry Wall (Open Sources, 1999 O’Reilly and Associates)

I want to state two big problems clearly:

  1. we need badly libavogadro to stabilize.

This is the most important goal in Avogadro right now too. There’s a
bit of upheaval right now with animation and Marcus’s new frameworks.
The benefits are really big – for example OB2 -> OB3 wouldn’t affect
our ABI with Marcus’s changes.

  1. we need fresh blood in the Kalzium developer team.

One problem I can say as a maintainer is that it’s often difficult to
make this realization yourself. Usually what happens is that the
maintainer or active developers get busy doing other things (e.g.,
life). When you’re that busy, you can’t easily make such executive
decisions. :slight_smile:

The best situation is if there are always developers coming through.
But IMHO open source development is often a "punctuated equilibrium"
in all but the largest projects. KDE as a whole, for example, doesn’t
have the problem because there are enough people working that anyone
can disappear for a month or two and not slow the project.

Cheers,
-Geoff

On Monday 27 October 2008 13:23:17 Benoît Jacob wrote:

Nobody replied… confirms my fear that Kalzium is seriously lacking love.

I did not reply as I was traveling (left 15 October) - perhaps I should have
posted this somewhere? I was only checking my personal email accounts and not
really monitoring mailing lists as I had limited Internet connectivity along
with a limited amount of time. I only just got back home yesterday and so have
been reading through mailing lists etc.

Beware: provocative phrasing below this point.

Look, we’re not going to keep eigen1 alongside eigen2 in kdesupport
forever, just because nobody cares to deal with the old libavogadro
snapshot used by Kalzium.

This was certainly on my list and should not take too long. I am still feeling
very jet lagged today having just crossed the Atlantic. The changes I have
been making to libavogadro are to allow for stabilization of the Avogadro API
independent of the OpenBabel API. I am not finished but hope to be soon.

I will certainly try to help as I have in the past. These six month cycles
seem to be tough to work in and may be working in git branches or similar
would be easier? I had talked about the possibility of splitting the
viewer/editor off and I think it has many benefits including reducing the
impact of the libavogadro changes on Kalzium.

I am not sure how long it will take getting over jet lag, catching up at work
etc and so don’t feel like I can make any promises about this week but will do
what I can in the spare time I have. With work, travel plans, sorting out KDE
4.1 in Gentoo and other things I had lost track of the KDE 4.2 schedule a
little but was hoping to make some improvements before the freeze.

Thanks,

Marcus

Thanks for your reply, obviously you don’t have to tell us in advance when you
are traveling, but here what made me grow afraid that nobody would take care
of that is that nobody added that to the KDE 4.2 feature plan until I did it
the last day before the soft freeze.

It is very helpful to me that you plan to take care of the kalzium 3D editor
for 4.2, as that lets me focus on finalizing the eigen2 API. I hope to do
what I have to in this respect in the next few days and adapt libavogadro
accordingly so that when you take care of kalzium 4.2 this is behind us.

Cheers,
Benoit

On Monday 03 November 2008 12:17:48 Marcus D. Hanwell wrote:

On Monday 27 October 2008 13:23:17 Benoît Jacob wrote:

Nobody replied… confirms my fear that Kalzium is seriously lacking
love.

I did not reply as I was traveling (left 15 October) - perhaps I should
have posted this somewhere? I was only checking my personal email accounts
and not really monitoring mailing lists as I had limited Internet
connectivity along with a limited amount of time. I only just got back home
yesterday and so have been reading through mailing lists etc.

Beware: provocative phrasing below this point.

Look, we’re not going to keep eigen1 alongside eigen2 in kdesupport
forever, just because nobody cares to deal with the old libavogadro
snapshot used by Kalzium.

This was certainly on my list and should not take too long. I am still
feeling very jet lagged today having just crossed the Atlantic. The changes
I have been making to libavogadro are to allow for stabilization of the
Avogadro API independent of the OpenBabel API. I am not finished but hope
to be soon.

I will certainly try to help as I have in the past. These six month cycles
seem to be tough to work in and may be working in git branches or similar
would be easier? I had talked about the possibility of splitting the
viewer/editor off and I think it has many benefits including reducing the
impact of the libavogadro changes on Kalzium.

I am not sure how long it will take getting over jet lag, catching up at
work etc and so don’t feel like I can make any promises about this week but
will do what I can in the spare time I have. With work, travel plans,
sorting out KDE 4.1 in Gentoo and other things I had lost track of the KDE
4.2 schedule a little but was hoping to make some improvements before the
freeze.

Thanks,

Marcus

On Monday 03 November 2008 07:20:54 Benoît Jacob wrote:

Thanks for your reply, obviously you don’t have to tell us in advance when
you are traveling, but here what made me grow afraid that nobody would take
care of that is that nobody added that to the KDE 4.2 feature plan until I
did it the last day before the soft freeze.

I don’t have any problems giving people an idea of when I am unlikely to be
around. I thought that was on the feature plan but it had slipped my mind -
thanks for adding it. Regardless of my status we really do not at least two or
three interested people for just these situations…

It is very helpful to me that you plan to take care of the kalzium 3D
editor for 4.2, as that lets me focus on finalizing the eigen2 API. I hope
to do what I have to in this respect in the next few days and adapt
libavogadro accordingly so that when you take care of kalzium 4.2 this is
behind us.

That sounds like a good plan. I have been working hard on big changes to the
Avogadro core in order to allow us to have a stable and uniform API that fits
in the Qt/KDE style too. I don’t think it will realistically be stable before
4.2 but hope to have it basically there with a request for comments on any
blockers to stabilising it.

The new API allows me to verify what is actually being used and should make
the transition to OpenBabel 3 mostly a transparent exercise to Avogadro users.

Thanks,

Marcus

On Monday 03 November 2008 13:49:20 Marcus D. Hanwell wrote:

That sounds like a good plan. I have been working hard on big changes to
the Avogadro core in order to allow us to have a stable and uniform API
that fits in the Qt/KDE style too. I don’t think it will realistically be
stable before 4.2 but hope to have it basically there with a request for
comments on any blockers to stabilising it.

The new API allows me to verify what is actually being used and should make
the transition to OpenBabel 3 mostly a transparent exercise to Avogadro
users.

This sounds very interesting!
Benoit

Marcus,

It turns out that the last incompatible changes in Eigen are fewer than
expected and we can provide a smooth transition. This means that you can
proceed at any time you like with the kalzium changes, and I’ll take care of
eigen-related changes if any; these are so little that it’s not a problem to
have to do them twice (in avo trunk and in kalzium).

Cheers,
Benoit

On Monday 03 November 2008 13:49:20 Marcus D. Hanwell wrote:

On Monday 03 November 2008 07:20:54 Benoît Jacob wrote:

Thanks for your reply, obviously you don’t have to tell us in advance
when you are traveling, but here what made me grow afraid that nobody
would take care of that is that nobody added that to the KDE 4.2 feature
plan until I did it the last day before the soft freeze.

I don’t have any problems giving people an idea of when I am unlikely to be
around. I thought that was on the feature plan but it had slipped my mind -
thanks for adding it. Regardless of my status we really do not at least two
or three interested people for just these situations…

It is very helpful to me that you plan to take care of the kalzium 3D
editor for 4.2, as that lets me focus on finalizing the eigen2 API. I
hope to do what I have to in this respect in the next few days and adapt
libavogadro accordingly so that when you take care of kalzium 4.2 this is
behind us.

That sounds like a good plan. I have been working hard on big changes to
the Avogadro core in order to allow us to have a stable and uniform API
that fits in the Qt/KDE style too. I don’t think it will realistically be
stable before 4.2 but hope to have it basically there with a request for
comments on any blockers to stabilising it.

The new API allows me to verify what is actually being used and should make
the transition to OpenBabel 3 mostly a transparent exercise to Avogadro
users.

Thanks,

Marcus

Here’s the latest episode of this comedy…

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.

So what I finally did, was to put a eigen1 snapshot inside kalzium’s libavo
snapshot. I then removed eigen1 from /trunk/kdesupport (there is
now /tags/eigen/1.0.5).

Notice that the size of eigen1 is small anyway compared to the size of libavo.

That allows kalzium 4.2 's molecular editor to work like in 4.1, without
forcing /trunk/kdesupport to keep eigen1, and without forcing the user to
grab another dependency.

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

Cheers,
Benoit

On Monday 03 November 2008 13:20:54 Benoît Jacob wrote:

Thanks for your reply, obviously you don’t have to tell us in advance when
you are traveling, but here what made me grow afraid that nobody would take
care of that is that nobody added that to the KDE 4.2 feature plan until I
did it the last day before the soft freeze.

It is very helpful to me that you plan to take care of the kalzium 3D
editor for 4.2, as that lets me focus on finalizing the eigen2 API. I hope
to do what I have to in this respect in the next few days and adapt
libavogadro accordingly so that when you take care of kalzium 4.2 this is
behind us.

Cheers,
Benoit

On Monday 03 November 2008 12:17:48 Marcus D. Hanwell wrote:

On Monday 27 October 2008 13:23:17 Benoît Jacob wrote:

Nobody replied… confirms my fear that Kalzium is seriously lacking
love.

I did not reply as I was traveling (left 15 October) - perhaps I should
have posted this somewhere? I was only checking my personal email
accounts and not really monitoring mailing lists as I had limited
Internet connectivity along with a limited amount of time. I only just
got back home yesterday and so have been reading through mailing lists
etc.

Beware: provocative phrasing below this point.

Look, we’re not going to keep eigen1 alongside eigen2 in kdesupport
forever, just because nobody cares to deal with the old libavogadro
snapshot used by Kalzium.

This was certainly on my list and should not take too long. I am still
feeling very jet lagged today having just crossed the Atlantic. The
changes I have been making to libavogadro are to allow for stabilization
of the Avogadro API independent of the OpenBabel API. I am not finished
but hope to be soon.

I will certainly try to help as I have in the past. These six month
cycles seem to be tough to work in and may be working in git branches or
similar would be easier? I had talked about the possibility of splitting
the viewer/editor off and I think it has many benefits including reducing
the impact of the libavogadro changes on Kalzium.

I am not sure how long it will take getting over jet lag, catching up at
work etc and so don’t feel like I can make any promises about this week
but will do what I can in the spare time I have. With work, travel plans,
sorting out KDE 4.1 in Gentoo and other things I had lost track of the
KDE 4.2 schedule a little but was hoping to make some improvements before
the freeze.

Thanks,

Marcus


Kalzium mailing list
Kalzium@kde.org
https://mail.kde.org/mailman/listinfo/kalzium

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

So what I finally did, was to put a eigen1 snapshot inside kalzium’s libavo
snapshot. I then removed eigen1 from /trunk/kdesupport (there is
now /tags/eigen/1.0.5).

Notice that the size of eigen1 is small anyway compared to the size of
libavo.

That allows kalzium 4.2 's molecular editor to work like in 4.1, without
forcing /trunk/kdesupport to keep eigen1, and without forcing the user to
grab another dependency.

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. That way bugs/regressions
in that can be looked at in isolation. If you look in the Primitive branch 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.

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.

I have been traveling, then ill and busy catching up and so this has delayed
my progress. 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?

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. This is certainly not a good situation
and ideally we would have integrated these patches. After the freeze is over I
will see about removing the snapshot and depending on an external libavogadro.

Thanks,

Marcus

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