Write .installed.cfg only once, in safe way and only if there's any change.
Also, updating a part does not put it anymore at the end of the list of installed parts, that was making .installed.cfg too big.
-
Owner
This squashes unrelated changes from the 1.x branch, and authorship is lost. The original commits should be cherry-picked again.
/cc @vpelletier
-
Owner
I confirm: I do not want commits cherry-picked from a public branch to be ever squashed, on any repository ever.
I did not try to confirm if this is a squashing commit, I trust @jm on this. I did not check the amount of work needed to set thehistory straight either, so I cannot comment on whether a re-cherry-pick (so an history rewrite ? or maybe a revert, then re-cherry-pick ?) is reasonable.
-
Owner
Not sure what you mean actually. The 1.x branch is quite messy and for some bugfixes we have many try/revert commits. Also, I hope we push some of our changes upstream so keeping a clean patch queue is more important than preserving authorship.
But surely, when original commits are clean, they should be cherry-picked properly, in particular with
-x
option.Things went wrong with this commit mainly because upstream did massive [dr]eindentation. A change that got lost is that 57f3dd73 stops putting updated part at the end of the list of installed parts, because this was breaking uninstall dependencies: in order to keep it, we'll also have to update unit tests.
In any case, there's still some work to do in this 2.x branch before using it in production.
/cc @rafael
-
Owner
In this commit, I avoided 'Indent big section of code before actual changes' commit that happend in 1.x branch and took a bit different approach to achieve the same goal. And the original file itself is quite different between 1.x and 2.x thus I did not cherry pick for this commit.
But indeed I also included non-related changes by mistake...
-
Owner
Oops, I forgot it was me who did massive indentation. I'll have to reread all this carefully.
-
Owner
The 2.x series is already part of the latest slapos package, but for software releases they are only present on a few cases for now, like ERP5TestNode and webrunner (not the current production), otherwise nobody would be able to try it (or use it earlier).
There are few things which were fixed only on 2.5.2-nexedi branch, so probably few projects (like wendelin, woelfel..) may need to use because I don't think we are going to backport changes to 1.7.x anymore... but people can adopt as soon they few confortable with it.
Feel free to review 2.5.2-nexedi branch and work to contribute back the changes on mainstream, but on our side is better not wait much (we are waiting 6 months or more to have the chance to try).