suggestion box - cummulative patch

Hi,

I have a suggestion - offer a cummulative patch file for all the patches
since the last stable version. This seems straightforward to create from
a repo and would simplify the process of building for those not using the
repo although i do not know how large of a group that is.

thanks,
scott

Hi,

I have a suggestion - offer a cummulative patch file for all the patches
since the last stable version. This seems straightforward to create from
a repo and would simplify the process of building for those not using the
repo although i do not know how large of a group that is.

i don't see much of a benefit there. downloading the individual
patches from a webbrowser or using wget or curl is not really time
consuming compared to the time it takes to configure and build LAMMPS
and applying the patches one after the other is fast as well. i've
done this a lot in the past before there was a public repository.

as our continuous integration and regression testing coverage
increases, there is an increasing benefit to follow the svn/git
repository instead.

axel.

Hi,

>
> I have a suggestion - offer a cummulative patch file for all the patches
> since the last stable version. This seems straightforward to create from
> a repo and would simplify the process of building for those not using the
> repo although i do not know how large of a group that is.

i don't see much of a benefit there. downloading the individual
patches from a webbrowser or using wget or curl is not really time
consuming compared to the time it takes to configure and build LAMMPS
and applying the patches one after the other is fast as well. i've
done this a lot in the past before there was a public repository.

as our continuous integration and regression testing coverage
increases, there is an increasing benefit to follow the svn/git
repository instead.

Regarding the repo, that is probably the case for lammps users;
I am in an unusual position of installing but not using lammps.

Regarding the patching, it is tedious and time consuming to get the
distribution into a state ready for configuring/building/testing
when that process happens several times as it has for me for the
14May16 stable version and only a couple of patch files.
Of course, if i had know that i would have had to do it so many times,
mainly to track down issues, then i would have scripted it.

Between the 16Feb to 14May stable versions there were 19 plus or minus 2
patch files. (So many that i put in errors bars because of that
axing acident i had with my digits :slight_smile:
That is definitely in the range of tedious and error prone human activity.

scott

Hi,

>
> I have a suggestion - offer a cummulative patch file for all the patches
> since the last stable version. This seems straightforward to create from
> a repo and would simplify the process of building for those not using the
> repo although i do not know how large of a group that is.

i don't see much of a benefit there. downloading the individual
patches from a webbrowser or using wget or curl is not really time
consuming compared to the time it takes to configure and build LAMMPS
and applying the patches one after the other is fast as well. i've
done this a lot in the past before there was a public repository.

as our continuous integration and regression testing coverage
increases, there is an increasing benefit to follow the svn/git
repository instead.

Regarding the repo, that is probably the case for lammps users;
I am in an unusual position of installing but not using lammps.

Regarding the patching, it is tedious and time consuming to get the
distribution into a state ready for configuring/building/testing
when that process happens several times as it has for me for the
14May16 stable version and only a couple of patch files.
Of course, if i had know that i would have had to do it so many times,
mainly to track down issues, then i would have scripted it.

i cannot follow you there. i have been and am in the same situation of
building binaries for other people and have done manual patching with
10s of patches regularly.
there must be something in your procedure of downloading and applying
patches that is inefficient that can be avoided. but that is besides
the point.

if you want to conveniently jump from patch to patch, using a checkout
from the git repository is the way to go.
since the creation of patches is automated, you have a simple pattern
that you can follow. a patchlevel release has two characteristic
commits to the repo: an update of src/version.h followed by an update
of the Manual.txt and Manual.html files for the new version number. so
doing:

git log version.h

will list only commits signifying a new patch level. if you don't care
about building the documentation, you can just look up the hash of the
patch that you want and to a "git checkout <commit-id>" and you have
the version that you want ready to co. afterwards you can go back with
git reset, update with git pull as needed and then pick whatever else
you are looking for.

if you want to have the guarantee that a build will succeed, then
using the lammps-icms branch instead of master is the recommended
option, as then you can follow the build status on the TravisCI
webpage and will know beforehand, whether a build will be successful.
FYI, this branch has been used since 2014 to build binary RPM packages
and Windows installers of LAMMPS and - as you have seen - it is often
more reliable and tested than patchlevel releases from upstream as the
build tests are done for a larger variety of platforms and
configurations as well as installed packages.

axel.