Branch off valgrind instead of patching it

[HadrienG2]

Recently, I tried packaging verrou using Spack, and discovered that the current use of patchfiles on top of valgrind brings in some... complications in that process.

One Spack maintainer suggested that now that Valgrind has switched to Git, we could make everyone's life easier by making Verrou a branch on top of valgrind's git repository, rather than a patch which exists on its own:

• Your life would be easier, because you could easily keep your patch up to date w.r.t. valgrind using standard git tools
• The packagers' life would be easier, because there is only one source tree to be downloaded, unlike the current situation where one must keep two source trees in sync in the package file.

How would you feel about that?

[HadrienG2]

Related: spack/spack#8738 .

[ffevotte]

Here are a few quick thoughts:

• The development of Verrou has been announced on the Valgrind mailing lists (both -users and -devel), but the Valgrind community did not seem very enthusiastic about adding Verrou as another tool. If Verrou's was to be considered as a branch off Valgrind, the repositories would probably remain separated; Verrou's repository would continue being hosted on Github.

• Although we have no strictly defined policy about it, up to now we tend to base Verrou on stable Valgrind versions. Major versions of Verrou tend to be released at their own pace, and for each official Valgrind release, we try to release a minor version of Verrou based on the new Valgrind release. Again, if Verrou was to be considered a branch of Valgrind, this would probably not change.

That being said, I would see several advantages to moving to the strategy you're proposing:

• As you mentioned, it would simplify the handling of Valgrind patches

• It would simplify the installation of Verrou: no need to separately download a Valgrind version; less risk to make errors in the process

• It would simplify the testing process of Verrou against development versions of Valgrind: a Verrou branch dedicated to valgrind-dev compatibility could be defined. Testing it would be a simple matter of merging it to the current valgrind master.

We'll have to discuss that internally and think more about it, but all in all, I think it might be worth trying. And the next Valgrind release (currently planned in September) would probably be a good occasion to put it in place.