Patchmanager support for new branching system

[Alex Dumitru]

Based on discussions among rasdaman developers we are thinking of having the following branching mechanism in rasdaman
Branches:

• master - contains always the latest release of rasdaman. It's updated each x (1 or 2 should be a good number, for example on Wednesdays) weeks to include the latest fixes and based on developer agreement selected features from experimental.
• fixes - this branch contains latest fixes based on the bug reports on the rasdaman wiki.
• experimental - this branch contains all the patches in fixes + experimental features that are planned for next releases.

This means that the patchmanager has to be modified to allow submission of patches for the new system. The following features have to be added:

• The branch select dropdown should contain only two values: experimental and fixes
• Once a patch is submitted to fixes and is accepted, it is automatically committed to fixes and experimental branches. This should be done in a transactional way, meaning if the patch fails to apply to either of the two branches it is applied to neither.
• Patches to experimental are committed to the experimental branch once accepted.

@Aulon: The sources for the patchmanager can be found here: ​http://rasdaman.org/browser/patch_manager Look over them, install it locally and report back once you are ready to implement the changes.

@all: Please check that the system makes sense, I believe this is the one we agree to.

[Peter Baumann]

friendly amendment:

• update master only on tagged releases
• initially commit only to experimental (no transactions necessary)
• manually decide (when) to cascade into fixes, following code inspection

As recent incidents show we need this asap!

[Dimitar Misev]

How are experimental and fixes merged to master? Any chance to do this via the patchmanager as well?

@Aulon: The sources for the patchmanager can be found here: ​​http://rasdaman.org/browser/patch_manager Look over them, install it locally and report back once you are ready to implement the changes.

To make it clearer: you should install trac locally, and then the patchmanager as a plugin. I'd suggest to do this in a Debian 8.1 VM and install trac 0.12.5 with apt-get, in order to match the server environment of rasdaman.org. Maybe George already has such a VM btw, as he has worked on the patchmanager earlier.

[Peter Baumann]

yes, hope we can integrate with patchmgr. Say, with a column mentioning the current branch (experimental, fixes) and a dropdown menu for the target branch (fixes, master).

All notification on incoming patches should go to a separate mailing list to which we can subscribe whomever we want.

[Alex Dumitru]

Not sure how easy that(apply patches from other branches to master) would be, as patches tend to depend one on the other and the correct sequence is needed.

Maybe a button "Sync Experimental with Master" might make more sense and be a bit easier to do?

[Peter Baumann]

I see; OTOH, syncing all might overdo it (eg, one feature experimental, another to be released). Maybe then we should give up patchmgr support for this step and rely on commandline?

[Alex Dumitru]

Also, add link to CR for each patch in a different column, you can parse it from the body of the git log.

[George Merticariu]

I implemented the requirements mentioned in the ticket and there is an issue with the proposed solution.

Problem:

1. Send patch to fixes → "create file <test> with 1 line"
2. Click on "Apply patch" ⇒ patch is applied to both branch fixes and experimental. File <test>, with 1 line is created on both branches.
3. Sent patch "add new line to <test>" to experimental and apply it ⇒ branch fixes has file <test> with 1 line and branch experimental has file <test> with 2 lines
4. Sent patch "add new line to <test>" to fixes and apply it ⇒ patch fails to apply to experimental since <test> on experimental is not the same as the one on fixes ⇒ patch fails to apply

Solution 1:
Apply the patch on fixes and then merge the changes automatically on experimental. If the merge fails then don't apply the patch at all.

Solution 2:
Apply the fixes patch on fixes and experimental patches on experimental. Merge fixes into experimental on a weekly basis.

Solution 3:
Apply the fixes patch on fixes and experimental patches on experimental. Merge master into experimental on a weekly basis.

[Peter Baumann]

I like a modified (1):

• patch gets submitted against experimental
• after inspection & verification it is decided to forward the patch to either fixes (for urgent fixes to the current release) or to master (contributing to the next release) or remaining on experimental (if "nice to have" or "still to be investigated).

Note: this does not mean that any patches get inhibited, it is rather a decision on _where_ they go.

[George Merticariu]

Replying to pbaumann:

I like a modified (1):

• patch gets submitted against experimental
• after inspection & verification it is decided to forward the patch to either fixes (for urgent fixes to the current release) or to master (contributing to the next release) or remaining on experimental (if "nice to have" or "still to be investigated).

Note: this does not mean that any patches get inhibited, it is rather a decision on _where_ they go.

This implies that any patch sent to experimental can be also send to fixes ar master. This will be accomplished anyway by the manual merge of the experimental branch into master. The problem that I am confronting with is how to apply patches meant for the fixes branch to experimental.