Request for Merge: fix for bug #771957
Johan Engelen has "signed-off" in the bugtracker this fix for exporting multilayer pdf+latex output, but we need someone with appropriate privileges to please merge it.
Bugtracker: https://bugs.launchpad.net/inkscape/+bug/771957 Fix: https://code.launchpad.net/~drbild/inkscape/multilayer-pdf-latex-output
Thanks much, David
On Fri, 2013-08-30 at 12:32 -0600, David R. Bild wrote:
Johan Engelen has "signed-off" in the bugtracker this fix for exporting multilayer pdf+latex output, but we need someone with appropriate privileges to please merge it.
Bugtracker: https://bugs.launchpad.net/inkscape/+bug/771957 Fix: https://code.launchpad.net/~drbild/inkscape/multilayer-pdf-latex-output
Merging now,
Don't be scared to make a merge request in launchpad, I've made one as a formality and set Johan Englen as the reviewer.
Martin,
On 08/30/2013 03:56 PM, Martin Owens wrote:
Merging now,
Don't be scared to make a merge request in launchpad
Thanks much.
I didn't know launchpad had such a feature. Will use it in the future!
-- David
On 30-8-2013 23:59, David R. Bild wrote:
On 08/30/2013 03:56 PM, Martin Owens wrote:
Merging now,
Don't be scared to make a merge request in launchpad
Thanks much.
I didn't know launchpad had such a feature. Will use it in the future!
Thanks for the patch David. We require only two accepted patches before granting commit access to trunk, so then you can do the merges yourself ! ;-)
Cheers, Johan
On Sat, 2013-08-31 at 09:58 +0200, Johan Engelen wrote:
We require only two accepted patches before granting commit access to trunk, so then you can do the merges yourself
Usually merges are done by the reviewer, but flexibility is good. What you should have said was "so then you can do the reviews too" ;-)
Martin,
On 31-8-2013 15:00, Martin Owens wrote:
On Sat, 2013-08-31 at 09:58 +0200, Johan Engelen wrote:
We require only two accepted patches before granting commit access to trunk, so then you can do the merges yourself
Usually merges are done by the reviewer, but flexibility is good. What you should have said was "so then you can do the reviews too" ;-)
I meant: at that point, there is no need for merge reviews anymore.
:) Johan
On Sat, 2013-08-31 at 16:18 +0200, Johan Engelen wrote:
there is no need for merge reviews anymore.
I feared that's what you meant. For medium-large code though, it's always helpful to have a review from fellow coders. None of us are perfect and lots of us know C++ like some foreign land.
Encouraging more with commit access to do review isn't such a bad idea.
Martin,
On 31-8-2013 17:11, Martin Owens wrote:
On Sat, 2013-08-31 at 16:18 +0200, Johan Engelen wrote:
there is no need for merge reviews anymore.
I feared that's what you meant. For medium-large code though, it's always helpful to have a review from fellow coders. None of us are perfect and lots of us know C++ like some foreign land.
Encouraging more with commit access to do review isn't such a bad idea.
Reviewing code is not related to the use of branches or not.
I follow trunk changes [1] very closely and I'm not the only one. Merge requests are much less noticeable. Also, testing a branch for functionality is more effort than simply running trunk and see. For this particular example of the pdf+tex output change, I would have much preferred a commit to trunk, then a mail to the devlist asking for a quick check, etc.
Cheers, Johan
(I see the value of branches, but in a human-resources-starving project like ours, I feel that branches carry a lot of weight and have large disadvantages. Being with the project for so long makes me quite conservative I guess, but I think we've done very well without branches and other fanciness. ;)
[1] http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/changes
On Sat, 2013-08-31 at 22:12 +0200, Johan Engelen wrote:
For this particular example of the pdf+tex output change, I would have much preferred a commit to trunk, then a mail to the devlist asking for a quick check, etc.
If you're not getting emails for merge requests, that could be fixed. I get them and they're very handy for knowing when code is ready.
To branch or not to branch is a quandary, I've committed to trunk and liked the results, I've also committed and wished I could undo it. This PDF work is a good candidate for a branch, anything with a likely or guaranteed multiple commits or possible shared collaboration on a block of work should be branched for sanity.
The branch merge request process is just a tool, we can use it or not use it. But we can't really expect people to commit to trunk and then email to get a code review... that strikes me as tool avoidance. Are you not using the lp tools because you don't know how yet? I could help if you want.
Martin,
On 1-9-2013 6:14, Martin Owens wrote:
On Sat, 2013-08-31 at 22:12 +0200, Johan Engelen wrote:
For this particular example of the pdf+tex output change, I would have much preferred a commit to trunk, then a mail to the devlist asking for a quick check, etc.
If you're not getting emails for merge requests, that could be fixed. I get them and they're very handy for knowing when code is ready.
There is too much Launchpad mailflow. Sometimes I do see the merge requests. But because they involve too much effort anyway, I mostly ignore it.
To branch or not to branch is a quandary, I've committed to trunk and liked the results, I've also committed and wished I could undo it.
??
This PDF work is a good candidate for a branch, anything with a likely or guaranteed multiple commits or possible shared collaboration on a block of work should be branched for sanity.
I disagree. For me, branches actually also prohibit easy-entry collaboration.
The branch merge request process is just a tool, we can use it or not use it. But we can't really expect people to commit to trunk and then email to get a code review... that strikes me as tool avoidance. Are you not using the lp tools because you don't know how yet? I could help if you want.
Yes, I avoid using bzr too much, because time.
-Johan
participants (3)
-
David R. Bild -
Johan Engelen -
Martin Owens