Hi,
The merge of the latest features from Liam into the Experimental branch raises the question of best practices for merging. In particular, I am not sure that merging multiple features at one time is a good idea. Other projects seem to divide commits into the smallest possible pieces. I think that this is good practice as it better documents what is being committed, allows for better reviews, and makes it easier to cherry-pick from one branch to another.
In particular, the commit message:
"Merge in ponyscape features by Theo and worked on my LiamW"
doesn't give any information about what are the purpose of the changes. It takes reading the code and/or searching the web to find this information. (See: http://liamwhite1.deviantart.com/journal/ ) As far as I can tell, the commit:
1. Adds the new LPE's:
* Attach path * Bounding box * Ellipse * Fill between many * Fill between strokes * Joint type * Taper stroke
2. A tagging system.
3. Objects dialog.
4. Multi-path manipulator
5. Filter effects chooser.
I think these should have been committed separately with a line or two explaining what each does. Also, each LPE should be a separate commit.
As an additional question: is the experimental branch going to become 0.92? I think there have been too many changes to the experimental branch to try to merge it with trunk.
Tav
At the risk of displaying my ignorance of the overall release process, I have to confess that I do not actually understand what is the purpose of the experimental branch. Rather than having an experimental branch, why would one not simply wait for the normal branching to occur during the release of 0.91 and then submit new features to the trunk as has always been done in the past as far as I can tell?
Alvin
-- View this message in context: http://inkscape.13.x6.nabble.com/Merging-Policy-tp4971538p4971539.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Hi Tav,
On Sun, 2014-09-14 at 12:55 +0200, Tavmjong Bah wrote:
The merge of the latest features from Liam into the Experimental branch raises the question of best practices for merging. In particular, I am not sure that merging multiple features at one time is a good idea. Other projects seem to divide commits into the smallest possible pieces. I think that this is good practice as it better documents what is being committed, allows for better reviews, and makes it easier to cherry-pick from one branch to another.
I agree and it's one of the items I brought up with Liam. So this is my logic: This branch is going to be such a pita to wrangle into multiple merges and has been kicking around for some time. We have the opportunity to be a little more risky with the experimental branch, so after a code review I decided it was worth merging.
"Merge in ponyscape features by Theo and worked on my LiamW"
I was really hoping the tree commit messages would be available. I guess I should re-document it. Sorry branch!
I think these should have been committed separately with a line or two explaining what each does. Also, each LPE should be a separate commit.
Agreed.
As an additional question: is the experimental branch going to become 0.92? I think there have been too many changes to the experimental branch to try to merge it with trunk.
That was always my understanding. Experimental will become trunk later. I always assumed that fixes were making their way into both branches. (although looking at the commit counts, this is a little worrying)
Sorry again for any ruffling. Hopefully we'll be able to digest this large patch (or pull it out if needed, but bzr manager will have to do that)
Best Regards, Martin Owens
On Sun, Sep 14, 2014 at 10:02:55AM -0400, Martin Owens wrote:
Hi Tav,
On Sun, 2014-09-14 at 12:55 +0200, Tavmjong Bah wrote:
I think these should have been committed separately with a line or two explaining what each does. Also, each LPE should be a separate commit.
Agreed.
Yeah, several small merges each implemeting a conceptually distinct change will be easier to manage (for forward porting, testing, and so on) than one large merge.
As an additional question: is the experimental branch going to become 0.92? I think there have been too many changes to the experimental branch to try to merge it with trunk.
That was always my understanding. Experimental will become trunk later. I always assumed that fixes were making their way into both branches. (although looking at the commit counts, this is a little worrying)
Well, the plan was that it was an experimental branch for people to try out more radical development ideas without us committing to them longer term. This implies trunk would be split from the current (stable) trunk, and selected changes from experimental forward ported to the new trunk.
We don't *have* to do that, but that was the original intent. In any case, we need to be in consensus on this soon, as it's nearly time to split off the stable branch.
Bryce
Can I also, please, remind everyone to (a) check the build using both Gtk+ 2 and 3 and (b) run the test-suite "make check" before merging a branch? The PPA will do this automatically for trunk/stable, but there is no experimental-branch build in place at the moment.
Cheers,
AV
On 14 September 2014 18:11, Bryce Harrington <bryce@...961...> wrote:
On Sun, Sep 14, 2014 at 10:02:55AM -0400, Martin Owens wrote:
Hi Tav,
On Sun, 2014-09-14 at 12:55 +0200, Tavmjong Bah wrote:
I think these should have been committed separately with a line or two explaining what each does. Also, each LPE should be a separate commit.
Agreed.
Yeah, several small merges each implemeting a conceptually distinct change will be easier to manage (for forward porting, testing, and so on) than one large merge.
As an additional question: is the experimental branch going to become 0.92? I think there have been too many changes to the experimental branch to try to merge it with trunk.
That was always my understanding. Experimental will become trunk later. I always assumed that fixes were making their way into both branches. (although looking at the commit counts, this is a little worrying)
Well, the plan was that it was an experimental branch for people to try out more radical development ideas without us committing to them longer term. This implies trunk would be split from the current (stable) trunk, and selected changes from experimental forward ported to the new trunk.
We don't *have* to do that, but that was the original intent. In any case, we need to be in consensus on this soon, as it's nearly time to split off the stable branch.
Bryce
Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sep 15, 2014 7:15 AM, "Alex Valavanis" <valavanisalex@...400...> wrote:
Can I also, please, remind everyone to (a) check the build using both Gtk+ 2 and 3 and (b) run the test-suite "make check" before merging a branch? The PPA will do this automatically for trunk/stable, but there is no experimental-branch build in place at the moment.
I already had my own build recipe set up for that branch. It should build cleanly with gtk3.
On Sun, Sep 14, 2014 at 6:55 AM, Tavmjong Bah <tavmjong@...8...> wrote:
The merge of the latest features from Liam into the Experimental branch raises the question of best practices for merging. In particular, I am not sure that merging multiple features at one time is a good idea. Other projects seem to divide commits into the smallest possible pieces. I think that this is good practice as it better documents what is being committed, allows for better reviews, and makes it easier to cherry-pick from one branch to another.
In particular, the commit message:
"Merge in ponyscape features by Theo and worked on my LiamW"
doesn't give any information about what are the purpose of the changes. It takes reading the code and/or searching the web to find this information.
If you update your experimental branch and ran 'bzr log' you'd see this:
liam$ bzr log -r13545 ------------------------------------------------------------ revno: 13545 [merge] committer: Martin Owens <doctormo@...400...> branch nick: experimental timestamp: Sun 2014-09-14 02:27:21 -0400 message: Merge in ponyscape features by Theo and worked on my LiamW ------------------------------------------------------------ Use --include-merged or -n0 to see merged revisions.
If I ran 'bzr log -r13545 -n0' I can see all merged revisions.
Or, if you'd prefer the web interface, you can see older (merged) revisions here: http://bazaar.launchpad.net/~inkscape.dev/inkscape/experimental/changes/1309...
participants (6)
-
Alex Valavanis -
alvinpenner -
Bryce Harrington -
Liam White -
Martin Owens -
Tavmjong Bah