On Sunday 25 April 2010 15:57:39 Konstantin Tokarev wrote:
25.04.10, 15:24, “Marcus D. Hanwell” marcus@cryos.org:
Hi,
I think that this is long overdue - I plan on tagging Avogadro 1.0.1 on
Tuesday, April 27. Please let me know if there is anything that needs to
go in before I tag - I just fixed a few issues and as far as I can see
everything looks good. Remember that this is bug fix only (ideally),
and I would rather be given commits to merge so that I can check them
over.
I think avopkg improvements from my git could be merged:
3cd1f6775342ba6a3ec94ba06b5cf8d83876ade1
771c4e80ef928ac34dd3a9eaa79b5887315969a6
23af0f5001d8e3d21b241fe5fac335757c7d299f
e1f910790f98ae0a87ae2cf11dafcc562cd43780
d6da4e1d48cadbba6272ac3feca60e0f43ad2256
1ca8cc6e37cad3738afb40e99424dc1b8049b0d8
dd15c0fbc80180e4f2ceefab5c8c9197a287ced7
8be117e080bef2e0faf1574d3da41a630acceee8
5a8c7c7337bd57f36726ef7f6e75e38f3a2b924c
c954424652e090f5fd08aa0f8344904224ef0f3a
e27f58d946c82b8e526a73ccab0811958ea981a1
There are some issues with several of these patches where the commits are
large, commit messages do not always describe whether these are new features,
bug fixes, trailing whitespace added, etc. Also, they have email addresses such
as “kostya@localhost.localdomain”, which I doubt are correct. I don’t want to
be overly prescriptive, but do want to keep the quality of our history as good
as possible.
I would love to see contributors develop in feature branches, and merge from
feature branches some day. Not sure if this might raise the barrier to entry a
little too high, but our git workflow has been a little lax at times.
(however, it’s getting complex and probably needs some testing)
How well tested is it? How much feedback have you had from users? I have not
had time to really look into it as yet, but looking at the man page am not
sure what I am supposed to do with it. Is it intended for end users,
developers, both? Typing avopkg it seems to try to do stuff and fail here,
shouldn’t it check its input first?
marcus@cryos:~/src/avogadro master$ avopkg
Avopkg v1.0
Unpacking …
tar (child): …/: Cannot read: Is a directory
tar (child): At beginning of tape, quitting now
tar (child): Error is not recoverable: exiting now
gzip: stdin: unexpected end of file
tar: Child returned status 2
tar: Error is not recoverable: exiting now
is not an Avogadro plugin package!
Installation failed.
Also,
33dc7364620ca191129716c9c24538bf773ba971
d5a2c808a65942f240aad1abf2db250d46fd2852
(network fetch)
So these went from SDF, to smiles, to 3D SDF (getting rid of the smiles
again)? If there are high quality 3D structures available it certainly makes
sense to use them. I know the SDFs sometimes needed optimization before they
were useful, and was meaning to take a look at this.
Maybe, additional flags for Intel compiler could be merged
ce2152f7033a4d88dcecc78b35c34dd08e8dd45e
0da67845cc674f900b25e82409e7e5506e5803a0
95efd45adfefea2014082d011f6bb14d5cf92dbe
a91c36a7d424250716818ecea4ceb57a191fed18
50466402a0affb90acf6b93df4d3344775eb7b1d
I don’t use that compiler, but they all look nicely isolated to the Intel
compiler, and so safe to merge.
Also
22dba694cc158152e573f5d5865f9934a6528976
Looks good. Thanks for all the patches and hard work, I will cherry-pick once
I have done a little more testing. Once 1.0.1 is out it would be nice to figure
out a timeline for the first 1.1.z release (which will depend on OB). I have
also been doing a lot of work with the new external project support in CMake
2.8, it is probably a better route than the super project approach to
build/package Avogadro with all of its dependencies. There are even recipes
for building Qt and Python.
Thanks,
Marcus
Kalzium in KDE 4.5 will depend on Avogadro 1.0.0, but there are a few
fixes in 1.0.1 that fix a few bugs. This has been many years in the
making, and it is a very positive move to see Kalzium move away from a
snapshot.
I cannot change the topic in the IRC channel at present. I think we need
Donald to confer superpowers on to myself and a few others.
Marcus