Eventually we probably need to move to Git. The user interface is completely atrocious, but the fact it works from a single directory by default is very convenient when using Eclipse, and Eclipse is an elephantine monstrosity but has good code navigation. This could also encourage more people to contribute, since almost all OSS developers know Git, while a very limited number know Bazaar at this point.
The bug tracker and answer tracker should definitely stay on Launchpad, but what about the code? Should we use Launchpad's nascent Git support, or some other site like Github? What people think?
We can convert lib2geom first and apply the lessons learned to Inkscape.
Best regards, Krzysztof
Yes please. This would make it easier for me to eventually contribute code and bug fixes as well. :)
-C On 5 Feb 2016 6:17 am, "Krzysztof Kosiński" <tweenk.pl@...400...> wrote:
Eventually we probably need to move to Git. The user interface is completely atrocious, but the fact it works from a single directory by default is very convenient when using Eclipse, and Eclipse is an elephantine monstrosity but has good code navigation. This could also encourage more people to contribute, since almost all OSS developers know Git, while a very limited number know Bazaar at this point.
The bug tracker and answer tracker should definitely stay on Launchpad, but what about the code? Should we use Launchpad's nascent Git support, or some other site like Github? What people think?
We can convert lib2geom first and apply the lessons learned to Inkscape.
Best regards, Krzysztof
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Temporary test imports are here: https://github.com/tweenk/lib2geom https://github.com/tweenk/inkscape
Everything imports cleanly with Git's git-remote-bzr plugin and the commit history seems to be fully intact, but take a look and let me know if you spot any problems. I'll try out making commits to Launchpad branches through the Git frontend tomorrow.
Best regards, Krzysztof
2016-02-04 23:31 GMT-08:00 C R <cajhne@...400...>:
Yes please. This would make it easier for me to eventually contribute code and bug fixes as well. :)
-C
On 5 Feb 2016 6:17 am, "Krzysztof Kosiński" <tweenk.pl@...400...> wrote:
Eventually we probably need to move to Git. The user interface is completely atrocious, but the fact it works from a single directory by default is very convenient when using Eclipse, and Eclipse is an elephantine monstrosity but has good code navigation. This could also encourage more people to contribute, since almost all OSS developers know Git, while a very limited number know Bazaar at this point.
The bug tracker and answer tracker should definitely stay on Launchpad, but what about the code? Should we use Launchpad's nascent Git support, or some other site like Github? What people think?
We can convert lib2geom first and apply the lessons learned to Inkscape.
Best regards, Krzysztof
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I haven't tried launchpad's git support so can't comment on that.
Most people I have worked with have used Github, it has organization support and groups within organizations can get specific rights to specific repositories e.g. "inkscape developers" could get commit rights to Inkscape repository. Jenkins integration with Github is high priority for CloudBees, so that is a good choice from that perspective. The downside pointed out by many is that Github is a closed source service but I have no opinion on that. The second viable option as I see it is Gitlab.com. It runs Gitlab enterprise which is closed source _but_ Gitlab Community Edition is also available for us to install ourself. I wouldn't recommend running our own Gitlab CE instance at this point in time due to limited time to manage it. For organization and group support in Gitlab I believe it works just fine but haven't tried it myself.
As I see it both Github and Gitlab will work just fine for our needs. From my perspective the important part for Inkscape project is to keep the simple trunk-based workflow independent of SCM e.g. we shouldn't adopt git-flow workflow nor requirements that all merges go through a separate feature/bug fix branch.
If the move was today I would say Github is our best choice.
2016-02-05 7:16 GMT+01:00 Krzysztof Kosiński <tweenk.pl@...400...>:
Eventually we probably need to move to Git. The user interface is completely atrocious, but the fact it works from a single directory by default is very convenient when using Eclipse, and Eclipse is an elephantine monstrosity but has good code navigation. This could also encourage more people to contribute, since almost all OSS developers know Git, while a very limited number know Bazaar at this point.
The bug tracker and answer tracker should definitely stay on Launchpad, but what about the code? Should we use Launchpad's nascent Git support, or some other site like Github? What people think?
We can convert lib2geom first and apply the lessons learned to Inkscape.
Best regards, Krzysztof
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2016-02-05 0:09 GMT-08:00 Christoffer Holmstedt <christoffer.holmstedt@...400...>:
Most people I have worked with have used Github, it has organization support and groups within organizations can get specific rights to specific repositories e.g. "inkscape developers" could get commit rights to Inkscape repository. Jenkins integration with Github is high priority for CloudBees, so that is a good choice from that perspective. The downside pointed out by many is that Github is a closed source service but I have no opinion on that. The second viable option as I see it is Gitlab.com. It runs Gitlab enterprise which is closed source _but_ Gitlab Community Edition is also available for us to install ourself. I wouldn't recommend running our own Gitlab CE instance at this point in time due to limited time to manage it. For organization and group support in Gitlab I believe it works just fine but haven't tried it myself.
For us as a project, Launchpad being open source doesn't change much, since we have neither the infrastructure nor the manpower to run it ourselves.
Best regards, Krzysztof
2016-02-05 10:11 GMT+01:00 Krzysztof Kosiński <tweenk.pl@...400...>:
2016-02-05 0:09 GMT-08:00 Christoffer Holmstedt <christoffer.holmstedt@...400...>:
Most people I have worked with have used Github, it has organization
support
and groups within organizations can get specific rights to specific repositories e.g. "inkscape developers" could get commit rights to
Inkscape
repository. Jenkins integration with Github is high priority for
CloudBees,
so that is a good choice from that perspective. The downside pointed out
by
many is that Github is a closed source service but I have no opinion on that. The second viable option as I see it is Gitlab.com. It runs Gitlab enterprise which is closed source _but_ Gitlab Community Edition is also available for us to install ourself. I wouldn't recommend running our own Gitlab CE instance at this point in time due to limited time to manage
it.
For organization and group support in Gitlab I believe it works just fine but haven't tried it myself.
For us as a project, Launchpad being open source doesn't change much, since we have neither the infrastructure nor the manpower to run it ourselves.
Best regards, Krzysztof
Spot on, that is my take on it as well.
On Fri, 2016-02-05 at 01:11 -0800, Krzysztof Kosiński wrote:
For us as a project, Launchpad being open source doesn't change much, since we have neither the infrastructure nor the manpower to run it ourselves.
I think that while we might not be able to host it ourselves, we are giving a vote for the type of world that we want to see. That being said, one of the biggest issues in using a non-OSS service would be data lock-in which is not the case here. I think that a big strength of Github is the number of integrations of external services. Things like TavisCI and code coverage tools become easy to enable since everyone is targeting Github already. Ted
On Fri, Feb 05, 2016 at 09:09:36AM +0100, Christoffer Holmstedt wrote:
I haven't tried launchpad's git support so can't comment on that.
Most people I have worked with have used Github, it has organization support and groups within organizations can get specific rights to specific repositories e.g. "inkscape developers" could get commit rights to Inkscape repository. Jenkins integration with Github is high priority for CloudBees, so that is a good choice from that perspective. The downside pointed out by many is that Github is a closed source service but I have no opinion on that. The second viable option as I see it is Gitlab.com. It runs Gitlab enterprise which is closed source _but_ Gitlab Community Edition is also available for us to install ourself. I wouldn't recommend running our own Gitlab CE instance at this point in time due to limited time to manage it. For organization and group support in Gitlab I believe it works just fine but haven't tried it myself.
As I see it both Github and Gitlab will work just fine for our needs. From my perspective the important part for Inkscape project is to keep the simple trunk-based workflow independent of SCM e.g. we shouldn't adopt git-flow workflow nor requirements that all merges go through a separate feature/bug fix branch.
If the move was today I would say Github is our best choice.
I have been actively contributing to projects hosted on both Github and Gitlab. These projects don't heavily use all the features, but at least the git service itself seems to be more or less equivalent. The git service is quite fungible, so the open source benefit of gitlab is more about the associated tools (bug tracker, branch review/merging, etc.) and also the general philosophy of supporting open source. This last reason is the main point for why I'd pick gitlab over github.
A third choice that I haven't seen mentioned yet is to move to freedesktop.org, which is where a number of other open source projects are hosted. If we *only* need the core git service, this could be an option. A major downside though is that user registration is done manually through bugzilla tickets; this fact alone may kill the idea. But worth mentioning as an option. (On a positive note, said registration would also open the option to allow contribution to a lot of other open source upstream projects...)
I know self-hosting something like gitlab (or even just a plain git service) has a number of costs to it, so may not be worth considering. One benefit it has is it'd allow us to better unify our user registration system. This could be helpful in various things that need to map our website user account to our actual git user account, and might enable the web team to automate other things that just can't be integrated presently.
Anyway, I don't know what the best solution should be, or even what I'd recommend personally. But I'm a strong +1 to moving to git as a future goal. I also worry hearing about potential new devs opting to not participate due to bzr, as a risk to the project's long term health.
Bryce
2016-02-05 7:16 GMT+01:00 Krzysztof Kosiński <tweenk.pl@...400...>:
Eventually we probably need to move to Git. The user interface is completely atrocious, but the fact it works from a single directory by default is very convenient when using Eclipse, and Eclipse is an elephantine monstrosity but has good code navigation. This could also encourage more people to contribute, since almost all OSS developers know Git, while a very limited number know Bazaar at this point.
The bug tracker and answer tracker should definitely stay on Launchpad, but what about the code? Should we use Launchpad's nascent Git support, or some other site like Github? What people think?
We can convert lib2geom first and apply the lessons learned to Inkscape.
Best regards, Krzysztof
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
-- Christoffer Holmstedt
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 5 February 2016 at 06:16, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
Eventually we probably need to move to Git.
If it's a datapoint, the only reason you guys got a patch for the recent AppData addition was because I found the unofficial git mirror of the bzr repo. If there was just bzr I'm not sure I could have provided a patch.
Richard.
Hi all,
On Thu, 4 Feb 2016 22:16:27 -0800 Krzysztof Kosiński <tweenk.pl@...400...> wrote:
Eventually we probably need to move to Git. The user interface is completely atrocious, but the fact it works from a single directory by default is very convenient when using Eclipse, and Eclipse is an elephantine monstrosity but has good code navigation. This could also encourage more people to contribute, since almost all OSS developers know Git, while a very limited number know Bazaar at this point.
I would support a move to Git, not because I use Eclipse (which I don't) but because I could never quite figure out bzr's UI and internal model. Git took me quite a long time to learn as well, but I already did it, and I guess it was worth it, because it is commonly used. bzr however seems not worth to learn at this point because it never really took off outside of the limited Ubuntu/Launchpad/GNU-Arch community.
The bug tracker and answer tracker should definitely stay on Launchpad, but what about the code? Should we use Launchpad's nascent Git support, or some other site like Github? What people think?
We can convert lib2geom first and apply the lessons learned to Inkscape.
Best regards, Krzysztof
Regards,
Shlomi Fish
On Feb 5, 2016 01:17, "Krzysztof Kosiński" <tweenk.pl@...400...> wrote:
Eventually we probably need to move to Git. The user interface is completely atrocious, but the fact it works from a single directory by default is very convenient when using Eclipse, and Eclipse is an elephantine monstrosity but has good code navigation. This could also encourage more people to contribute, since almost all OSS developers know Git, while a very limited number know Bazaar at this point.
The bug tracker and answer tracker should definitely stay on Launchpad, but what about the code? Should we use Launchpad's nascent Git support, or some other site like Github? What people think?
We can convert lib2geom first and apply the lessons learned to Inkscape.
Best regards, Krzysztof
I find it an amusing coincidence that this topic came up on the mailing list mere hours after I tried converting the repo to a local git repository myself :P
I approve strongly of converting to git, if only because it is considerably easier for me personally to use.
There is one feature of bzr that git doesn't have that would maybe be a deal-breaker for some, and that is the ability to maintain separate branches in separate directories: for example, to make custom builds for each branch without needing to reconfigure and fully recompile each time.
As for a host, GitHub would be IMO ideal for several reasons:
* Speed: GitHub (website and gitd) is very fast. Launchpad (both website and bzrd) is rather slow, and has very limited clone bandwidth. Full repository checkouts can take a very long time even on fast internet connections.
* Functionality: Has everything that Launchpad has, but is also in rapid development, and has functionality like webhooks, commit comments, mentions, notifications, etc.
* External maintenance: just like with Launchpad, hosting on GitHub would move the burden of responsibility for downtimes, bandwidth, attacks, etc. onto them and not us; self-hosting our own GitLab instance, while certainly possible, would require regular maintenance and attention to keep running.
Keep in mind that these are just my ideas on this subject. I don't want to force this down anyone's throat at this point, and I am open any to outside experiences and opinions.
2016-02-05 4:42 GMT-08:00 Liam White <inkscapebrony@...400...>:
There is one feature of bzr that git doesn't have that would maybe be a deal-breaker for some, and that is the ability to maintain separate branches in separate directories: for example, to make custom builds for each branch without needing to reconfigure and fully recompile each time.
Git can put the work tree in a different directory if you want, but it needs extra parameters. http://stackoverflow.com/questions/6073507/git-checkout-branch-from-outside
Also, I know it's possible to make a .git file with the following content: gitdir: /home/jrandomhacker/src/project/.git
This will make a directory that will work like a normal Git repository in every respect, except the local repository will in fact be stored elsewhere. This feature is used by submodules.
Best regards, Krzysztof
A lot of projects use Git. I've already done an experimental conversion of inkscape-web to git (it had a few issues that had to be fixed manually, see but not a lot)
There's a lot of support for Git, but I do have reservations about Github. It's a lot more like a cult than a platform and it's very much a monopoly at this point and I remember Bitkeeper. At least the repository is movable and they have an api for exporting issues and a wiki.
It's would enforce using a more code-review style model, no matter how many people we make a part of an Inkscape organisation.
Although on the positive side, it'll probably increase participation. Something the project could do with having. We're currently experiencing 40TB of downloads a month and our software is used by millions of people, but translating that into developers is meeting more resistance.
Best Regards, Martin Owens
On Thu, 2016-02-04 at 22:16 -0800, Krzysztof Kosiński wrote:
Eventually we probably need to move to Git. The user interface is completely atrocious, but the fact it works from a single directory by default is very convenient when using Eclipse, and Eclipse is an elephantine monstrosity but has good code navigation. This could also encourage more people to contribute, since almost all OSS developers know Git, while a very limited number know Bazaar at this point.
The bug tracker and answer tracker should definitely stay on Launchpad, but what about the code? Should we use Launchpad's nascent Git support, or some other site like Github? What people think?
We can convert lib2geom first and apply the lessons learned to Inkscape.
Best regards, Krzysztof
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2016-02-05 14:00 GMT+01:00 Martin Owens <doctormo@...400...>:
A lot of projects use Git. I've already done an experimental conversion of inkscape-web to git (it had a few issues that had to be fixed manually, see but not a lot)
There's a lot of support for Git, but I do have reservations about Github. It's a lot more like a cult than a platform and it's very much a monopoly at this point and I remember Bitkeeper. At least the repository is movable and they have an api for exporting issues and a wiki.
It's would enforce using a more code-review style model, no matter how many people we make a part of an Inkscape organisation.
Could you elaborate on what you mean with "enforce using a more
code-review style model"?
Although on the positive side, it'll probably increase participation. Something the project could do with having. We're currently experiencing 40TB of downloads a month and our software is used by millions of people, but translating that into developers is meeting more resistance.
Best Regards, Martin Owens
On Thu, 2016-02-04 at 22:16 -0800, Krzysztof Kosiński wrote:
Eventually we probably need to move to Git. The user interface is completely atrocious, but the fact it works from a single directory by default is very convenient when using Eclipse, and Eclipse is an elephantine monstrosity but has good code navigation. This could also encourage more people to contribute, since almost all OSS developers know Git, while a very limited number know Bazaar at this point.
The bug tracker and answer tracker should definitely stay on Launchpad, but what about the code? Should we use Launchpad's nascent Git support, or some other site like Github? What people think?
We can convert lib2geom first and apply the lessons learned to Inkscape.
Best regards, Krzysztof
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, 2016-02-05 at 14:07 +0100, Christoffer Holmstedt wrote:
Could you elaborate on what you mean with "enforce using a more code-review style model"?
GitHub invites users to fork projects at any time, much more so than launchpad (even though you could fork, it's not in the UI) so the experienced developer who isn't an inkscape developer will pop in, fork, make a fix and do a pull request. They won't be committing to trunk.
So our behaviour must move from assuming everything is auto-trunked to actively reviewing pull requests and sharing that job between us.
Martin,
2016-02-05 19:44 GMT+01:00 Martin Owens <doctormo@...400...>:
On Fri, 2016-02-05 at 14:07 +0100, Christoffer Holmstedt wrote:
Could you elaborate on what you mean with "enforce using a more code-review style model"?
GitHub invites users to fork projects at any time, much more so than launchpad (even though you could fork, it's not in the UI) so the experienced developer who isn't an inkscape developer will pop in, fork, make a fix and do a pull request. They won't be committing to trunk.
So our behaviour must move from assuming everything is auto-trunked to actively reviewing pull requests and sharing that job between us.
Martin,
Correct and I see that as good thing, but we don't want to enforce that workflow for all existing and future Inkscape developers. Everyone that is allowed to commit to trunk today and future developers, should be able to do that in the future as well. It was just the wording "enforcing" that sounding like you wanted that workflow for everyone instead of the trunk-based we use today.
On Fri, 2016-02-05 at 08:00 -0500, Martin Owens wrote:
A lot of projects use Git. I've already done an experimental conversion of inkscape-web to git (it had a few issues that had to be fixed manually, see but not a lot)
The SVG WG has moved its specification repository to GitHub (as has most W3C working groups) and it has increased participation from people not in the working group. The shift from Mercurial to Git wasn't too bad. Switching from Bazaar also shouldn't be that bad.
We have just started to use the issue tracker in GitHub and initial impressions are good. Have a look at:
https://github.com/w3c/svgwg/issues
Other W3C groups already do all their issue tracking on GitHub.
There's a lot of support for Git, but I do have reservations about Github. It's a lot more like a cult than a platform and it's very much a monopoly at this point and I remember Bitkeeper. At least the repository is movable and they have an api for exporting issues and a wiki.
I don't know about exporting; we should check. I asked about the SVG WG reliance on GitHub (mentioning our experience with SourceForge) and the response was that it wouldn't be hard for the W3C to switch to its own servers if necessary or find an alternative host.
It's would enforce using a more code-review style model, no matter how many people we make a part of an Inkscape organisation.
Although on the positive side, it'll probably increase participation. Something the project could do with having. We're currently experiencing 40TB of downloads a month and our software is used by millions of people, but translating that into developers is meeting more resistance.
Best Regards, Martin Owens
On Thu, 2016-02-04 at 22:16 -0800, Krzysztof Kosiński wrote:
Eventually we probably need to move to Git. The user interface is completely atrocious, but the fact it works from a single directory by default is very convenient when using Eclipse, and Eclipse is an elephantine monstrosity but has good code navigation. This could also encourage more people to contribute, since almost all OSS developers know Git, while a very limited number know Bazaar at this point.
The bug tracker and answer tracker should definitely stay on Launchpad, but what about the code? Should we use Launchpad's nascent Git support, or some other site like Github? What people think?
We can convert lib2geom first and apply the lessons learned to Inkscape.
Best regards, Krzysztof
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2016-02-05 5:00 GMT-08:00 Martin Owens <doctormo@...400...>:
There's a lot of support for Git, but I do have reservations about Github. It's a lot more like a cult than a platform and it's very much a monopoly at this point and I remember Bitkeeper. At least the repository is movable and they have an api for exporting issues and a wiki.
I have no opinion on the bug tracker / issue tracker problem yet. It would be a fairly strong argument for staying on Launchpad, since moving that over is a lot more complex. Can you attach arbitrary files to Github comments directly, or do you need to use some external site and post links?
It's would enforce using a more code-review style model, no matter how many people we make a part of an Inkscape organisation.
The main reason we rarely do that on Launchpad is that Launchpad makes it rather tedious (e.g. no single-click merge from the Web UI). Code reviews are very valuable, and in our situation where we have lots of accumulated technical debt, making them easier to use would be a win.
Although on the positive side, it'll probably increase participation. Something the project could do with having. We're currently experiencing 40TB of downloads a month and our software is used by millions of people, but translating that into developers is meeting more resistance.
Wow! These metrics are pretty impressive, I didn't know we are downloaded that much.
PS - I was just given admin access to the "inkscape" organization on Github by the guy who registered it, so we can use the obvious name if we want.
Best regards, Krzysztof
On Fri, 2016-02-05 at 12:19 -0800, Krzysztof Kosiński wrote:
PS - I was just given admin access to the "inkscape" organization on Github by the guy who registered it, so we can use the obvious name if we want.
Oh great. We should get the board installed there, spread around the access.
Martin,
On 5 February 2016 at 21:19, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
Can you attach arbitrary files to Github comments directly, or do you need to use some external site and post links?
GitHub only allows a rather small subset of file types as attachments. Important for Inkscape: SVG files are *not* allowed, as well as HTML, CSS and JavaScript files, videos and archives except ZIP.
Sebastian
2016-02-06 19:56 GMT+01:00 Sebastian Zartner <sebastianzartner@...400...>:
On 5 February 2016 at 21:19, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
Can you attach arbitrary files to Github comments directly, or do you need to use some external site and post links?
GitHub only allows a rather small subset of file types as attachments. Important for Inkscape: SVG files are *not* allowed, as well as HTML, CSS and JavaScript files, videos and archives except ZIP.
Sebastian
This is the main reason for keeping issue tracking on launchpad for the time being in my opinion, just move the code and see how it works. Not being able to upload SVG files so they can be used for debugging is a big problem...everyone would have to zip the images and then upload, an annoying extra step.
On 7 February 2016 at 06:58, Christoffer Holmstedt <christoffer.holmstedt@...400...> wrote:
2016-02-06 19:56 GMT+01:00 Sebastian Zartner <sebastianzartner@...400...>:
On 5 February 2016 at 21:19, Krzysztof Kosiński <tweenk.pl@...1063....> wrote:
Can you attach arbitrary files to Github comments directly, or do you need to use some external site and post links?
GitHub only allows a rather small subset of file types as attachments. Important for Inkscape: SVG files are *not* allowed, as well as HTML, CSS and JavaScript files, videos and archives except ZIP.
Sebastian
This is the main reason for keeping issue tracking on launchpad for the time being in my opinion, just move the code and see how it works. Not being able to upload SVG files so they can be used for debugging is a big problem...everyone would have to zip the images and then upload, an annoying extra step.
FWIW, I already sent a feature request to the GitHub people some time ago to add support for those file types and also asked why the allowed types are restricted to this specific subset. The response from one of their team members was:
I'll pass it along to the team. We don't discuss product decisions or timelines publicly like that, so I can't share more information about why this particular subset was chosen. I do hope it can be expanded in the future, though.
Sebastian
On Mon, 2016-02-08 at 11:44 +0100, Sebastian Zartner wrote:
I'll pass it along to the team. We don't discuss product decisions
or timelines publicly like that, so I can't share more information about why this particular subset was chosen. I do hope it can be expanded in the future, though.
That's the biggest difference between open source projects and proprietary ones. Not just the code freedom, but the willingness to be open about product development, internal thoughts, attempts and failures. Keeping things hidden from customers isn't healthy IMO[1]
I'm not really happy about any of these solutions to be honest.
But we should keep looking and testing different possible solutions.
Best Regards, Martin Owens
[1] Something Canonical got wrong a lot.
2016-02-08 13:37 GMT+01:00 Martin Owens <doctormo@...400...>:
On Mon, 2016-02-08 at 11:44 +0100, Sebastian Zartner wrote:
I'll pass it along to the team. We don't discuss product decisions
or timelines publicly like that, so I can't share more information about why this particular subset was chosen. I do hope it can be expanded in the future, though.
That's the biggest difference between open source projects and proprietary ones. Not just the code freedom, but the willingness to be open about product development, internal thoughts, attempts and failures. Keeping things hidden from customers isn't healthy IMO[1]
I'm not really happy about any of these solutions to be honest.
But we should keep looking and testing different possible solutions.
Best Regards, Martin Owens
[1] Something Canonical got wrong a lot.
"Any of these solutions [...]"...Do you mean both Github and Gitlab?
Yea, keeping product development plans behind closed door leaves users in a sort of powerlessness state. You don't get any response about the future, if there is any hope at all for the feature to be implemented nor have you the ability to fix it yourself due to closed source. For JIRA I had a similar case with Atlassian, no response at all if the bug fix was prioritized. I know I needed a feature in Gitlab a year or so ago also; but it was only available in Gitlab Enterprise but others needed that feature as well in Community edition and implemented it themselves. The end result was that Gitlab developers open sourced their closed source version of it.
I will keep testing Gitlab CE and gitlab.com, gitlab seems to have better issue management than Github.
Maybe officially run everything on Gitlab with a official github mirror that we can connect to travis-ci?
I made a spreadsheet comparing GitHub, GitLab and Launchpad issue trackers. https://docs.google.com/spreadsheets/d/1Ig16AVpkrdjMTcgy3RPm4GCxY6Vx9lzggGFC...
I also looked into making Jenkins spawn builders in a cloud on demand. This appears to be simple to do with the JClouds plugin, and we could run Windows builds this way. However, OSX is not available in any of the JClouds-supported clouds. As I understand, this is purely due the OSX license not allowing virtualization on non-Apple hardware. (Although the urge is strong, I will spare you an anti-Apple rant.)
Best regards, Krzysztof
2016-02-08 22:11 GMT-08:00 Christoffer Holmstedt <christoffer.holmstedt@...400...>:
2016-02-08 13:37 GMT+01:00 Martin Owens <doctormo@...400...>:
On Mon, 2016-02-08 at 11:44 +0100, Sebastian Zartner wrote:
I'll pass it along to the team. We don't discuss product decisions
or timelines publicly like that, so I can't share more information about why this particular subset was chosen. I do hope it can be expanded in the future, though.
That's the biggest difference between open source projects and proprietary ones. Not just the code freedom, but the willingness to be open about product development, internal thoughts, attempts and failures. Keeping things hidden from customers isn't healthy IMO[1]
I'm not really happy about any of these solutions to be honest.
But we should keep looking and testing different possible solutions.
Best Regards, Martin Owens
[1] Something Canonical got wrong a lot.
"Any of these solutions [...]"...Do you mean both Github and Gitlab?
Yea, keeping product development plans behind closed door leaves users in a sort of powerlessness state. You don't get any response about the future, if there is any hope at all for the feature to be implemented nor have you the ability to fix it yourself due to closed source. For JIRA I had a similar case with Atlassian, no response at all if the bug fix was prioritized. I know I needed a feature in Gitlab a year or so ago also; but it was only available in Gitlab Enterprise but others needed that feature as well in Community edition and implemented it themselves. The end result was that Gitlab developers open sourced their closed source version of it.
I will keep testing Gitlab CE and gitlab.com, gitlab seems to have better issue management than Github.
Maybe officially run everything on Gitlab with a official github mirror that we can connect to travis-ci?
-- Christoffer Holmstedt
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Nice summary.
I think this boils down to a balance between issue tracker that fits Inkscapes community (Launchpad's fit Inkscape very well), and developer preference (git is almost de facto standard nowadays).
Of course, it the two tools would "marry" (using github/gitlab for repo+ci and Launchpad for issues) it would be great.
Mvh
/Olof ----------------- 3-5-åriga småttingar i närheten? Lek & lär siffror och bokstäver via mobilen m.h.a. Alfamem till Android. https://play.google.com/store/search?q=alfamem
On 9 February 2016 at 10:34, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
I made a spreadsheet comparing GitHub, GitLab and Launchpad issue trackers.
https://docs.google.com/spreadsheets/d/1Ig16AVpkrdjMTcgy3RPm4GCxY6Vx9lzggGFC...
I also looked into making Jenkins spawn builders in a cloud on demand. This appears to be simple to do with the JClouds plugin, and we could run Windows builds this way. However, OSX is not available in any of the JClouds-supported clouds. As I understand, this is purely due the OSX license not allowing virtualization on non-Apple hardware. (Although the urge is strong, I will spare you an anti-Apple rant.)
Best regards, Krzysztof
2016-02-08 22:11 GMT-08:00 Christoffer Holmstedt <christoffer.holmstedt@...400...>:
2016-02-08 13:37 GMT+01:00 Martin Owens <doctormo@...400...>:
On Mon, 2016-02-08 at 11:44 +0100, Sebastian Zartner wrote:
I'll pass it along to the team. We don't discuss product decisions
or timelines publicly like that, so I can't share more information about why this particular subset was chosen. I do hope it can be expanded in the future, though.
That's the biggest difference between open source projects and proprietary ones. Not just the code freedom, but the willingness to be open about product development, internal thoughts, attempts and failures. Keeping things hidden from customers isn't healthy IMO[1]
I'm not really happy about any of these solutions to be honest.
But we should keep looking and testing different possible solutions.
Best Regards, Martin Owens
[1] Something Canonical got wrong a lot.
"Any of these solutions [...]"...Do you mean both Github and Gitlab?
Yea, keeping product development plans behind closed door leaves users
in a
sort of powerlessness state. You don't get any response about the
future, if
there is any hope at all for the feature to be implemented nor have you
the
ability to fix it yourself due to closed source. For JIRA I had a similar case with Atlassian, no response at all if the bug fix was prioritized. I know I needed a feature in Gitlab a year or so ago also; but it was only available in Gitlab Enterprise but others needed that feature as well in Community edition and implemented it themselves. The end result was that Gitlab developers open sourced their closed source version of it.
I will keep testing Gitlab CE and gitlab.com, gitlab seems to have
better
issue management than Github.
Maybe officially run everything on Gitlab with a official github mirror
that
we can connect to travis-ci?
-- Christoffer Holmstedt
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 9 February 2016 at 07:11, Christoffer Holmstedt < christoffer.holmstedt@...400...> wrote:
2016-02-08 13:37 GMT+01:00 Martin Owens <doctormo@...400...>:
On Mon, 2016-02-08 at 11:44 +0100, Sebastian Zartner wrote:
I'll pass it along to the team. We don't discuss product decisions
or timelines publicly like that, so I can't share more information about why this particular subset was chosen. I do hope it can be expanded in the future, though.
That's the biggest difference between open source projects and proprietary ones. Not just the code freedom, but the willingness to be open about product development, internal thoughts, attempts and failures. Keeping things hidden from customers isn't healthy IMO[1]
I'm not really happy about any of these solutions to be honest.
But we should keep looking and testing different possible solutions.
Best Regards, Martin Owens
[1] Something Canonical got wrong a lot.
"Any of these solutions [...]"...Do you mean both Github and Gitlab?
Yea, keeping product development plans behind closed door leaves users in a sort of powerlessness state. You don't get any response about the future, if there is any hope at all for the feature to be implemented nor have you the ability to fix it yourself due to closed source.
I need to add that every request I made against GitHub so far (~25) got answered within one or two days and some of my suggestions were already implemented in the meantime. So, at least I have the feeling that they are somewhat listening to their users.
Having said that, of course the GitHub team never promises anything (and they always say so in their responses), so you don't have any influence on what get's implemented.
Sebastian
On Sat, Feb 06, 2016 at 07:56:26PM +0100, Sebastian Zartner wrote:
On 5 February 2016 at 21:19, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
Can you attach arbitrary files to Github comments directly, or do you need to use some external site and post links?
GitHub only allows a rather small subset of file types as attachments. Important for Inkscape: SVG files are *not* allowed, as well as HTML, CSS and JavaScript files, videos and archives except ZIP.
gitlab seems to to accept SVG. There is a 10MB file limit but otherwise I could upload SVGs there.
I didn't try other file types but the file selector didn't appear to impose any particular limitations as to type.
Sebastian
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, Feb 05, 2016 at 12:19:27PM -0800, Krzysztof Kosiński wrote:
2016-02-05 5:00 GMT-08:00 Martin Owens <doctormo@...400...>:
There's a lot of support for Git, but I do have reservations about Github. It's a lot more like a cult than a platform and it's very much a monopoly at this point and I remember Bitkeeper. At least the repository is movable and they have an api for exporting issues and a wiki.
I have no opinion on the bug tracker / issue tracker problem yet. It would be a fairly strong argument for staying on Launchpad, since moving that over is a lot more complex. Can you attach arbitrary files to Github comments directly, or do you need to use some external site and post links?
I've used the bug tracker on github pretty intently for one smallish project. For that it was quite serviceable. gitlab and other git hosters seem to be on par with github's capabilities.
For Inkscape I'd worry it'd be a mis-fit culturally, as we've come to rely pretty deeply on Launchpad-specific functionality that doesn't have an easy analog in github. Also I'm not sure how we'd physically move the bugs, given what a volume we have.
I'd love to see us upgrade our bug tracking capabilities, but I don't think what any of the current git hosts provide is going to be suitable.
I suppose that begs the question that if we don't move the bug tracker off Launchpad, then should we give a stronger weighting to Launchpad's git service? Launchpad has a little integration between bzr and the bug tracker, but last I checked that integration hadn't been done for git? If it isn't, then there's probably not a whole lot to make us prefer LP git over other options. If it is, well then the question would be whether that integration's benefit is significant versus benefits we'd gain from switching.
It's would enforce using a more code-review style model, no matter how many people we make a part of an Inkscape organisation.
The main reason we rarely do that on Launchpad is that Launchpad makes it rather tedious (e.g. no single-click merge from the Web UI). Code reviews are very valuable, and in our situation where we have lots of accumulated technical debt, making them easier to use would be a win.
The one click merges are indeed quite nifty, and definitely make merging very, very easy.
HOWEVER, these merges don't rebase the branches, and as a result some consider the results of the merges to be kind of trashy. If you're trying to stick with "proper" git history, you wouldn't use this feature. I don't know whether it's acceptable for Inkscape or not (since we accept the bzr merge philosophy maybe we wouldn't consider these merges quite so "trashy"), but I admit on projects where I have used it, I've regretted lazily using the button merges more than a couple times...
So yes, it's a cool and handy feature but be forewarned it may not prove to be quite the panacea it seems to promise.
Bryce
Am 05.02.2016 um 07:16 schrieb Krzysztof Kosiński:
The bug tracker and answer tracker should definitely stay on Launchpad, but what about the code? Should we use Launchpad's nascent Git support, or some other site like Github? What people think?
I'm of the opinion that community features (issue tracking and pull requests) are the strong suite of GitHub (which seems to be a popular possibility at this point in the discussion). I we don't want to use these features we give away most of the advantages GitHub would offer. Obviously GitHub has no such thing as an answer tracker. That might be an issue...
In general I would avoid splitting the code repository from the bug tracker as those two are closely related and often intertwined. It hinders efficiency a lot when tracking bugs elsewhere.
Regards, Eduard
Am 05.02.2016 um 07:16 schrieb Krzysztof Kosiński:
Eventually we probably need to move to Git. The user interface is completely atrocious, but the fact it works from a single directory by default is very convenient when using Eclipse, and Eclipse is an elephantine monstrosity but has good code navigation. This could also encourage more people to contribute, since almost all OSS developers know Git, while a very limited number know Bazaar at this point.
The bug tracker and answer tracker should definitely stay on Launchpad, but what about the code? Should we use Launchpad's nascent Git support, or some other site like Github? What people think?
We can convert lib2geom first and apply the lessons learned to Inkscape.
Best regards, Krzysztof
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 05-Feb-2016 05:40, Eduard Braun wrote:
In general I would avoid splitting the code repository from the bug tracker as those two are closely related and often intertwined. It hinders efficiency a lot when tracking bugs elsewhere.
I agree with that - everything in one place. Moving to git is fine so long as the entire history of the project makes the transition, all the bugs, all the revisions, and so forth. There shouldn't be anything "left behind" on launchpad. Not that I have any idea how one would go about doing this sort of migration, never having used git except to download entire projects for a local build.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On Fri, Feb 05, 2016 at 09:16:36AM -0800, mathog wrote:
On 05-Feb-2016 05:40, Eduard Braun wrote:
In general I would avoid splitting the code repository from the bug tracker as those two are closely related and often intertwined. It hinders efficiency a lot when tracking bugs elsewhere.
I agree with that - everything in one place. Moving to git is fine so long as the entire history of the project makes the transition, all the bugs, all the revisions, and so forth. There shouldn't be anything "left behind" on launchpad. Not that I have any idea how one would go about doing this sort of migration, never having used git except to download entire projects for a local build.
The git repository itself should be straightforward. I've done bzr -> git on a bunch of trees without any trouble. I've not attempted on Inkscape itself, but others have already reported they've experimented and it went straightforward.
Bugs I think will be much harder to transition. There is no standardized storage for bugs like there is with git, and not really any established data spec, so unless a target site advertises a specific "Launchpad bug import" function, it's going to be a fair bit of work to write a converter.
Launchpad's data sources have an API so exporting the bugs should not be a problem technically, just a lot of python coding. Whatever we would move them to would obviously need an import API (and ideally an export API in case we decide to change providers down the road!) So if we want to keep things together, we would HAVE to have someone own this coding project. (Unless someone knows of an existing converter tool?)
I do see the value in keeping bug tracking and vcs hosting together - it was one of the selling points to move to Launchpad to begin with after all. And frankly I'd say its one of the reasons we've stuck with bzr longer than we probably should have... But I think there's a point where the benefit of moving to git is strong enough to do it regardless of whether the bug tracker follows. I don't know where we are on that scale, but I do think we're going to eventually hit a point where we just gotta move, and handle the bug tracker as a separate problem.
I'm also really skeptical that github/gitlab's bug hosting is going to cut the mustard for our bug folks. And like I said, even if it does, I'm really worried that transferring the bug data promises would be a huge amount of work.
There seems to be some organizational drama going on at Github right now:
http://www.businessinsider.com/github-the-full-inside-story-2016-2
Bryce
2016-02-07 2:54 GMT+01:00 Bryce Harrington <bryce@...961...>:
On Fri, Feb 05, 2016 at 09:16:36AM -0800, mathog wrote:
On 05-Feb-2016 05:40, Eduard Braun wrote:
In general I would avoid splitting the code repository from the bug tracker as those two are closely related and often intertwined. It hinders efficiency a lot when tracking bugs elsewhere.
I agree with that - everything in one place. Moving to git is fine so long as the entire history of the project makes the transition, all the bugs, all the revisions, and so forth. There shouldn't be anything "left behind" on launchpad. Not that I have any idea how one would go about doing this sort of migration, never having used git except to download entire projects for a local build.
The git repository itself should be straightforward. I've done bzr -> git on a bunch of trees without any trouble. I've not attempted on Inkscape itself, but others have already reported they've experimented and it went straightforward.
Bugs I think will be much harder to transition. There is no standardized storage for bugs like there is with git, and not really any established data spec, so unless a target site advertises a specific "Launchpad bug import" function, it's going to be a fair bit of work to write a converter.
Launchpad's data sources have an API so exporting the bugs should not be a problem technically, just a lot of python coding. Whatever we would move them to would obviously need an import API (and ideally an export API in case we decide to change providers down the road!) So if we want to keep things together, we would HAVE to have someone own this coding project. (Unless someone knows of an existing converter tool?)
I took a look at it yesterday. For the IPython project a basic python script was created 5 years ago with limited error handling [1]. It exports LP bugs to JSON and then uses Github issues API to import, inbetween there is a step for mapping accounts, bug id:s and what not.
I started exporting Inkscape LP bugs to local JSON file but got stuck at issue #212921 due the bug reporter account is gone, so some fixing is needed on that side (add error handling); others have had the same issue [2]. The last step is to import to Github which can cause some blocking due to some "abuse triggers" from github's servers, but others have already fixed that problem, pull requests are available [3].
If anyone else finds an up to date tool that would be better; if we decide to move bug tracking to github.
[1] https://github.com/termie/lp2gh [2] https://github.com/MetricsGrimoire/Bicho/issues/135#issuecomment-94892370 [3] https://github.com/termie/lp2gh/pulls
On Sun, Feb 7, 2016 at 11:40 AM, Christoffer Holmstedt < christoffer.holmstedt@...400...> wrote:
If anyone else finds an up to date tool that would be better; if we decide to move bug tracking to github.
Another ostensibly working tool: https://github.com/johnf/github-issue-importer
-- et.
One thing that wasn't mentioned so far is the broader hosted tools ecosystem. GitHub works with Travis CI - this means we wouldn't need to maintain our Jenkins installation, which suffers from space constraints. (It stopped working again a couple of weeks ago.)
Another very useful thing is that Github can be used to easily publish HTML Doxygen documentation with the gh-pages feature. It can even be done from Travis CI. Maybe we can use our website and a Launchpad commit hook to do that, though.
Best regards, Krzysztof
Observations regarding Launchpad Git support.
1. They have a gitweb installation and it's possible to browse the code online. 2. Overall support seems rather poor at the moment. There is no way to make a release series point to a Git branch. It's also not possible to make the lp:project link on a project's page to point to a Git branch. I had to set up a Bazaar import from the Git branch on Launchpad (!). The lp:lib2geom link leads to the Bazaar import while the Code link at the top leads to the true Git repository. 3. Branch subscriptions (getting an e-mail after each commit) don't seem to work. 4. It's not not possible to transfer ownership of a repository to a different user or team. (I had to manually re-push as lib2geom-hackers.) This was not possible with Bazaar branches either. 5. It's not possible to delete Bazaar branches if anyone uploaded any code that was derived from that branch.
2016-02-06 23:30 GMT-08:00 Krzysztof Kosiński <tweenk.pl@...400...>:
One thing that wasn't mentioned so far is the broader hosted tools ecosystem. GitHub works with Travis CI - this means we wouldn't need to maintain our Jenkins installation, which suffers from space constraints. (It stopped working again a couple of weeks ago.)
Another very useful thing is that Github can be used to easily publish HTML Doxygen documentation with the gh-pages feature. It can even be done from Travis CI. Maybe we can use our website and a Launchpad commit hook to do that, though.
Best regards, Krzysztof
On Sun, Feb 07, 2016 at 02:56:57AM -0800, Krzysztof Kosiński wrote:
Observations regarding Launchpad Git support.
- They have a gitweb installation and it's possible to browse the code online.
- Overall support seems rather poor at the moment. There is no way to
make a release series point to a Git branch. It's also not possible to make the lp:project link on a project's page to point to a Git branch. I had to set up a Bazaar import from the Git branch on Launchpad (!). The lp:lib2geom link leads to the Bazaar import while the Code link at the top leads to the true Git repository. 3. Branch subscriptions (getting an e-mail after each commit) don't seem to work. 4. It's not not possible to transfer ownership of a repository to a different user or team. (I had to manually re-push as lib2geom-hackers.) This was not possible with Bazaar branches either. 5. It's not possible to delete Bazaar branches if anyone uploaded any code that was derived from that branch.
Thanks for experimenting and gathering this feedback.
I do know some LP limitations like these are work aroundable via contacting the LP admins. Obviously that is no solution for anything we would want to do frequently or on short turnaround.
Bryce
2016-02-06 23:30 GMT-08:00 Krzysztof Kosiński <tweenk.pl@...400...>:
One thing that wasn't mentioned so far is the broader hosted tools ecosystem. GitHub works with Travis CI - this means we wouldn't need to maintain our Jenkins installation, which suffers from space constraints. (It stopped working again a couple of weeks ago.)
Another very useful thing is that Github can be used to easily publish HTML Doxygen documentation with the gh-pages feature. It can even be done from Travis CI. Maybe we can use our website and a Launchpad commit hook to do that, though.
Best regards, Krzysztof
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, Feb 06, 2016 at 11:30:52PM -0800, Krzysztof Kosiński wrote:
One thing that wasn't mentioned so far is the broader hosted tools ecosystem. GitHub works with Travis CI - this means we wouldn't need to maintain our Jenkins installation, which suffers from space constraints. (It stopped working again a couple of weeks ago.)
Running out of space is not the issue, it's just a symptom.
The real problem is more that we don't have anyone looking after it. (The person that set it up left the project, and the task sort of devolved to me but I've had zero time for it since, and evidently it's bitrotting quickly.) I'm also not sure if anyone's actually acting on the issues it's flagging, which makes running it a bit pointless I suppose.
Note that it's probably possible to set up a bzr->git import on our current tree without having to wait on transitioning, and then set up travis or jenkins or whatever on top of that.
Anyway, if someone(s) is willing to adopt this task, and someone can follow up on fixing the issues, I'd love to hand over the responsibility, and let you implement and drive it however you want.
Another very useful thing is that Github can be used to easily publish HTML Doxygen documentation with the gh-pages feature. It can even be done from Travis CI. Maybe we can use our website and a Launchpad commit hook to do that, though.
Right, there are many ways to skin that particular cat. I seem to recall we were thinking of doing this with Jenkins, too.
Bryce
Hi,
On Sun, Feb 7, 2016 at 7:24 AM, Bryce Harrington <bryce@...961...> wrote:
Bugs I think will be much harder to transition. There is no standardized storage for bugs like there is with git, and not really any established data spec, so unless a target site advertises a specific "Launchpad bug import" function, it's going to be a fair bit of work to write a converter.
Launchpad's data sources have an API so exporting the bugs should not be a problem technically, just a lot of python coding. Whatever we would move them to would obviously need an import API (and ideally an export API in case we decide to change providers down the road!) So if we want to keep things together, we would HAVE to have someone own this coding project. (Unless someone knows of an existing converter tool?)
https://lp2gh.readthedocs.org/en/latest/moving_issues.html?highlight=import
-- et.
2016-02-06 17:54 GMT-08:00 Bryce Harrington <bryce@...961...>:
The git repository itself should be straightforward. I've done bzr -> git on a bunch of trees without any trouble. I've not attempted on Inkscape itself, but others have already reported they've experimented and it went straightforward.
I converted the Inkscape repository using git-remote-bzr and it was flawless. It's available here, as I mentioned. The branches converted correctly as well, though I had to specify them manually.
https://github.com/tweenk/inkscape
However, the Bazaar history has outdated contributor names and e-mails, which screws up Github graphs, since commits by people not known to Github are not counted and it looks like the project started in 2010. I experimented with git filter-branch and it generally gives good results. I am 80% done with compiling a mapping from old names and e-mails to current ones. (The e-mails are not visible in the web interface, only when you clone the repo, so it's OK to use real ones.)
I went ahead and converted lib2geom to Git on Launchpad, fixing commit authors in the process. (Factoid: there were 24 unique authors.) https://code.launchpad.net/lib2geom
I'm also really skeptical that github/gitlab's bug hosting is going to cut the mustard for our bug folks. And like I said, even if it does, I'm really worried that transferring the bug data promises would be a huge amount of work.
I also have this impression. Here is what I found.
1. Cannot attach SVG files to bugs. This would not be a dealbreaker on its own, since we can just point users to a pastebin or a file host, but...
2. No issue template, no voting system / "heat meter" like on Launchpad, and practically no control over what the new issue page looks like. This is in fact a very common gripe, so much so that over 1500 people have signed an open letter.
https://github.com/dear-github/dear-github
1+2 mean that users can't attach problematic files to bugs, and we cannot point them to an external pastebin-like site. Even if the migration from Launchpad was effortless, Github's bug management is simply worse for a project like Inkscape.
There only two things that Launchpad doesn't have: if a commit message contains something like "Fix #12345", Github will automatically mark the issue as closed, however I don't see a distinction between "Fix Commited" and "Fix Released". Another useful thing is that issue numbers are project-local instead of global, so the numbers are easier to remember. Finally, the styling on Github is nicer, but that's a personal preference.
Best regards, Krzysztof
Nice work.
Why not move lib2geom to github? On 7 Feb 2016 07:13, "Krzysztof Kosiński" <tweenk.pl@...400...> wrote:
2016-02-06 17:54 GMT-08:00 Bryce Harrington <bryce@...961...>:
The git repository itself should be straightforward. I've done bzr -> git on a bunch of trees without any trouble. I've not attempted on Inkscape itself, but others have already reported they've experimented and it went straightforward.
I converted the Inkscape repository using git-remote-bzr and it was flawless. It's available here, as I mentioned. The branches converted correctly as well, though I had to specify them manually.
https://github.com/tweenk/inkscape
However, the Bazaar history has outdated contributor names and e-mails, which screws up Github graphs, since commits by people not known to Github are not counted and it looks like the project started in 2010. I experimented with git filter-branch and it generally gives good results. I am 80% done with compiling a mapping from old names and e-mails to current ones. (The e-mails are not visible in the web interface, only when you clone the repo, so it's OK to use real ones.)
I went ahead and converted lib2geom to Git on Launchpad, fixing commit authors in the process. (Factoid: there were 24 unique authors.) https://code.launchpad.net/lib2geom
I'm also really skeptical that github/gitlab's bug hosting is going to cut the mustard for our bug folks. And like I said, even if it does, I'm really worried that transferring the bug data promises would be a huge amount of work.
I also have this impression. Here is what I found.
- Cannot attach SVG files to bugs. This would not be a dealbreaker on
its own, since we can just point users to a pastebin or a file host, but...
- No issue template, no voting system / "heat meter" like on
Launchpad, and practically no control over what the new issue page looks like. This is in fact a very common gripe, so much so that over 1500 people have signed an open letter.
https://github.com/dear-github/dear-github
1+2 mean that users can't attach problematic files to bugs, and we cannot point them to an external pastebin-like site. Even if the migration from Launchpad was effortless, Github's bug management is simply worse for a project like Inkscape.
There only two things that Launchpad doesn't have: if a commit message contains something like "Fix #12345", Github will automatically mark the issue as closed, however I don't see a distinction between "Fix Commited" and "Fix Released". Another useful thing is that issue numbers are project-local instead of global, so the numbers are easier to remember. Finally, the styling on Github is nicer, but that's a personal preference.
Best regards, Krzysztof
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2016-02-06 23:30 GMT-08:00 Olof Bjarnason <olof.bjarnason@...400...>:
Nice work.
Why not move lib2geom to github?
https://github.com/inkscape/lib2geom
I'll try to set up travis-ci and make it push documentation to gh-pages. If that works out I will officially move the project.
Best regards, Krzysztof
On Sun, Feb 07, 2016 at 04:26:34AM -0800, Krzysztof Kosiński wrote:
2016-02-06 23:30 GMT-08:00 Olof Bjarnason <olof.bjarnason@...400...>:
Nice work.
Why not move lib2geom to github?
https://github.com/inkscape/lib2geom
I'll try to set up travis-ci and make it push documentation to gh-pages. If that works out I will officially move the project.
Best regards, Krzysztof
Please, before doing so, one important question.
github and gitlab seem to be relatively equivalent in terms of functionality. github is better known/established but gitlab is open source.
An article I read via Slashdot yesterday suggested that changes may be afoot at github corporate. A red flag for me is that a number of existing developers have left, apparently.
Do we have strong rationale for why we prefer github over gitlab?
Bryce
2016-02-07 8:24 GMT-08:00 Bryce Harrington <bryce@...961...>:
On Sun, Feb 07, 2016 at 04:26:34AM -0800, Krzysztof Kosiński wrote:
2016-02-06 23:30 GMT-08:00 Olof Bjarnason <olof.bjarnason@...400...>:
Nice work.
Why not move lib2geom to github?
https://github.com/inkscape/lib2geom
I'll try to set up travis-ci and make it push documentation to gh-pages. If that works out I will officially move the project.
Best regards, Krzysztof
Please, before doing so, one important question.
github and gitlab seem to be relatively equivalent in terms of functionality. github is better known/established but gitlab is open source.
OK. I will try out Gitlab today.
First look: Gitlab has Windows builds in its CI system, which is very important. On GitHub we would need to use at least 2 different CI tools: Travis CI does not support Windows, and AppVeyor is Windows-only and uses the MS toolchain.
Gitlab also has a static pages feature that is already integrated with the CI system (very nice).
Wherever we end up, I think there is some value in having an official mirror at GitHub, even if we do not accept issues or pull requests posted there. (It's possible to disable the issue tracker but not pull requests, so if we get something sensible on GitHub we can merge it manually.)
Best regards, Krzysztof
2016-02-07 15:17 GMT-08:00 Krzysztof Kosiński <tweenk.pl@...400...>:
First look: Gitlab has Windows builds in its CI system, which is very important. On GitHub we would need to use at least 2 different CI tools: Travis CI does not support Windows, and AppVeyor is Windows-only and uses the MS toolchain.
Correction: the runner software for Gitlab CI can be installed on those platforms, and you can easily add those runners to build projects on Gitlab, but there are no public Windows or OSX builders. In fact, Gitlab's public runners only support Ruby.
Best regards, Krzysztof
Continuing the CI tools investigation, I took a stab at setting up lib2geom builds on Travis CI. This was totally trivial and took maybe 10 minutes. I only needed to figure out the correct APT commands to install the dependencies.
https://travis-ci.org/inkscape/lib2geom/jobs/107693602
GitLab does not have anything comparable. GitLab CI supports only Ruby, and for anything else you need to maintain your own runner that executes the builds. A downside is that Travis CI is tightly coupled to GitHub and we cannot use it to build projects from repositories that are not on GitHub.
I also looked at AppVeyor, which is a CI tool specifically for building on Windows. It's not tied to GitHub at all - it can pull sources from any public Git repository. It can run builds on multiple versions of Visual Studio, as well as under MinGW. It seems that it could work. However, I'll need a Windows machine to figure out the correct incantations for setting up lib2geom's dependencies, since figuring this out via test commits and the Web UI is very tedious.
AppVeyor integrates with NuGet, which is a bit like APT for Windows development packages. It has Boost 1.60, glib 2.32 and cairo 1.12, but it does not have GTK. It should be possible to push the rest of our dependencies to NuGet, but it's a fair amount of work.
Best regards, Krzysztof
2016-02-07 18:18 GMT-08:00 Krzysztof Kosiński <tweenk.pl@...400...>:
2016-02-07 15:17 GMT-08:00 Krzysztof Kosiński <tweenk.pl@...400...>:
First look: Gitlab has Windows builds in its CI system, which is very important. On GitHub we would need to use at least 2 different CI tools: Travis CI does not support Windows, and AppVeyor is Windows-only and uses the MS toolchain.
Correction: the runner software for Gitlab CI can be installed on those platforms, and you can easily add those runners to build projects on Gitlab, but there are no public Windows or OSX builders. In fact, Gitlab's public runners only support Ruby.
Best regards, Krzysztof
I just want to say: great effort doing these investigations Krzysztof! On 8 Feb 2016 04:50, "Krzysztof Kosiński" <tweenk.pl@...400...> wrote:
Continuing the CI tools investigation, I took a stab at setting up lib2geom builds on Travis CI. This was totally trivial and took maybe 10 minutes. I only needed to figure out the correct APT commands to install the dependencies.
https://travis-ci.org/inkscape/lib2geom/jobs/107693602
GitLab does not have anything comparable. GitLab CI supports only Ruby, and for anything else you need to maintain your own runner that executes the builds. A downside is that Travis CI is tightly coupled to GitHub and we cannot use it to build projects from repositories that are not on GitHub.
I also looked at AppVeyor, which is a CI tool specifically for building on Windows. It's not tied to GitHub at all - it can pull sources from any public Git repository. It can run builds on multiple versions of Visual Studio, as well as under MinGW. It seems that it could work. However, I'll need a Windows machine to figure out the correct incantations for setting up lib2geom's dependencies, since figuring this out via test commits and the Web UI is very tedious.
AppVeyor integrates with NuGet, which is a bit like APT for Windows development packages. It has Boost 1.60, glib 2.32 and cairo 1.12, but it does not have GTK. It should be possible to push the rest of our dependencies to NuGet, but it's a fair amount of work.
Best regards, Krzysztof
2016-02-07 18:18 GMT-08:00 Krzysztof Kosiński <tweenk.pl@...400...>:
2016-02-07 15:17 GMT-08:00 Krzysztof Kosiński <tweenk.pl@...400...>:
First look: Gitlab has Windows builds in its CI system, which is very important. On GitHub we would need to use at least 2 different CI tools: Travis CI does not support Windows, and AppVeyor is Windows-only and uses the MS toolchain.
Correction: the runner software for Gitlab CI can be installed on those platforms, and you can easily add those runners to build projects on Gitlab, but there are no public Windows or OSX builders. In fact, Gitlab's public runners only support Ruby.
Best regards, Krzysztof
Bryce Harrington <bryce@...961...> writes:
On Fri, Feb 05, 2016 at 09:16:36AM -0800, mathog wrote:
On 05-Feb-2016 05:40, Eduard Braun wrote:
In general I would avoid splitting the code repository from the bug tracker as those two are closely related and often intertwined. It hinders efficiency a lot when tracking bugs elsewhere.
I agree with that - everything in one place. Moving to git is fine so long as the entire history of the project makes the transition, all the bugs, all the revisions, and so forth. There shouldn't be anything "left behind" on launchpad. Not that I have any idea how one would go about doing this sort of migration, never having used git except to download entire projects for a local build.
The git repository itself should be straightforward. I've done bzr -> git on a bunch of trees without any trouble. I've not attempted on Inkscape itself, but others have already reported they've experimented and it went straightforward.
Emacs converted from Bzr to Git. The conversion wasn't straightforward, but the tool "reposurgeon" helped solve the issues. Inkscape is probably a more straightforward conversion, as evidenced by the conversions already demonstrated in this thread.
Bugs I think will be much harder to transition. There is no standardized storage for bugs like there is with git, and not really any established data spec, so unless a target site advertises a specific "Launchpad bug import" function, it's going to be a fair bit of work to write a converter.
Launchpad's data sources have an API so exporting the bugs should not be a problem technically, just a lot of python coding. Whatever we would move them to would obviously need an import API (and ideally an export API in case we decide to change providers down the road!) So if we want to keep things together, we would HAVE to have someone own this coding project. (Unless someone knows of an existing converter tool?)
I do see the value in keeping bug tracking and vcs hosting together - it was one of the selling points to move to Launchpad to begin with after all. And frankly I'd say its one of the reasons we've stuck with bzr longer than we probably should have... But I think there's a point where the benefit of moving to git is strong enough to do it regardless of whether the bug tracker follows. I don't know where we are on that scale, but I do think we're going to eventually hit a point where we just gotta move, and handle the bug tracker as a separate problem.
I'm also really skeptical that github/gitlab's bug hosting is going to cut the mustard for our bug folks. And like I said, even if it does, I'm really worried that transferring the bug data promises would be a huge amount of work.
There seems to be some organizational drama going on at Github right now:
http://www.businessinsider.com/github-the-full-inside-story-2016-2
My dystopian prediction is that Github will eventually turn into Sourceforge.
In my view, moving to Gitlab would avoid that risk. Gitlabs core feature set is free software. If Gitlab also turns into sourceforge, Inkskape can set up its own Gitlab instance, at least in principle. (I have set up a Gitlab instance, and it is fairly straghtforward)
Bryce
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140________... Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Feb 09, 2016 at 11:55:28AM +0100, joakim@...1974... wrote:
Bryce Harrington <bryce@...961...> writes:
On Fri, Feb 05, 2016 at 09:16:36AM -0800, mathog wrote:
On 05-Feb-2016 05:40, Eduard Braun wrote:
In general I would avoid splitting the code repository from the bug tracker as those two are closely related and often intertwined. It hinders efficiency a lot when tracking bugs elsewhere.
I agree with that - everything in one place. Moving to git is fine so long as the entire history of the project makes the transition, all the bugs, all the revisions, and so forth. There shouldn't be anything "left behind" on launchpad. Not that I have any idea how one would go about doing this sort of migration, never having used git except to download entire projects for a local build.
I'll throw out another thing maybe worth considering is Phabricator
This is a very powerful platform, and highly customizable, providing an integrated solution for bugs, patchreview, and a heap of other stuff as well as git hosting. I've had some limited experience using it on Enlightenment and Wayland, and it gets very high marks from people who use it.
Personally I find it much more on the complex side compared with github/gitlab, with a bit more of a learning curve to it. But it has a ton of functionality; I've only barely scratched the surface as a user but what I've seen has been quite powerful and well implemented. It also has a JSON API for making our own tools or apps to interface directly with it. The out-of-the-box defaults are also not quite what we'd want (e.g. bug tracker is not public by default). So it'd require a fair bit of setup and tuning.
But if it's felt that we need integrated bug/patch tracking and are worried that gitlab might not be up to snuff, Phabricator might be the next thing to look at.
There seems to be some organizational drama going on at Github right now:
http://www.businessinsider.com/github-the-full-inside-story-2016-2
My dystopian prediction is that Github will eventually turn into Sourceforge.
In my view, moving to Gitlab would avoid that risk. Gitlabs core feature set is free software. If Gitlab also turns into sourceforge, Inkskape can set up its own Gitlab instance, at least in principle. (I have set up a Gitlab instance, and it is fairly straghtforward)
There do seem to be a lot of parallels between github today and sourceforge back when. SourceForge was also "the standard" at one point, then turned focus entirely to commercialization and kind of stagnated.
Bryce
2016-02-10 22:45 GMT-08:00 Bryce Harrington <bryce@...961...>:
On Tue, Feb 09, 2016 at 11:55:28AM +0100, joakim@...1974... wrote:
Bryce Harrington <bryce@...961...> writes:
On Fri, Feb 05, 2016 at 09:16:36AM -0800, mathog wrote:
On 05-Feb-2016 05:40, Eduard Braun wrote:
In general I would avoid splitting the code repository from the bug tracker as those two are closely related and often intertwined. It hinders efficiency a lot when tracking bugs elsewhere.
I agree with that - everything in one place. Moving to git is fine so long as the entire history of the project makes the transition, all the bugs, all the revisions, and so forth. There shouldn't be anything "left behind" on launchpad. Not that I have any idea how one would go about doing this sort of migration, never having used git except to download entire projects for a local build.
I'll throw out another thing maybe worth considering is Phabricator
http://phabricator.org/This is a very powerful platform, and highly customizable, providing an integrated solution for bugs, patchreview, and a heap of other stuff as well as git hosting. I've had some limited experience using it on Enlightenment and Wayland, and it gets very high marks from people who use it.
This is just a software package. We would need our own hosting for that. The company that develops it does not have free hosting plans.
There do seem to be a lot of parallels between github today and sourceforge back when. SourceForge was also "the standard" at one point, then turned focus entirely to commercialization and kind of stagnated.
This is a valid concern, but it doesn't look too terrible yet. The distributed nature of Git ensures that should anything troublesome start happening, moving the repository elsewhere is trivial.
On the other hand, the GitHub + Travis CI + AppVeyor + Launchpad bug tracker looks like the best combination for now, as long as Inkscape can reliably build on Travis CI servers within their 50 minute time limit. Installation of dependencies is not counted against the time limit on Ubuntu, but is on OSX.
Best regards, Krzysztof
2016-02-11 8:07 GMT+01:00 Krzysztof Kosiński <tweenk.pl@...400...>:
2016-02-10 22:45 GMT-08:00 Bryce Harrington <bryce@...961...>:
On Tue, Feb 09, 2016 at 11:55:28AM +0100, joakim@...1974... wrote:
Bryce Harrington <bryce@...961...> writes:
On Fri, Feb 05, 2016 at 09:16:36AM -0800, mathog wrote:
On 05-Feb-2016 05:40, Eduard Braun wrote:
In general I would avoid splitting the code repository from the bug tracker as those two are closely related and often intertwined. It hinders efficiency a lot when tracking bugs elsewhere.
I agree with that - everything in one place. Moving to git is fine
so
long as the entire history of the project makes the transition, all
the
bugs, all the revisions, and so forth. There shouldn't be anything "left behind" on launchpad. Not that I have any idea how one would
go
about doing this sort of migration, never having used git except to download entire projects for a local build.
I'll throw out another thing maybe worth considering is Phabricator
http://phabricator.org/This is a very powerful platform, and highly customizable, providing an integrated solution for bugs, patchreview, and a heap of other stuff as well as git hosting. I've had some limited experience using it on Enlightenment and Wayland, and it gets very high marks from people who use it.
Thanks for the link Bryce, I was looking around for JIRA alternatives for non-Inkscape stuff and phabricator seems like a good candidate.
There do seem to be a lot of parallels between github today and sourceforge back when. SourceForge was also "the standard" at one point, then turned focus entirely to commercialization and kind of stagnated.
This is a valid concern, but it doesn't look too terrible yet. The distributed nature of Git ensures that should anything troublesome start happening, moving the repository elsewhere is trivial.
On the other hand, the GitHub + Travis CI + AppVeyor + Launchpad bug tracker looks like the best combination for now, as long as Inkscape can reliably build on Travis CI servers within their 50 minute time limit. Installation of dependencies is not counted against the time limit on Ubuntu, but is on OSX.
Best regards, Krzysztof
I'm on the same page with you Krzysztof the "GitHub + Travis CI + AppVeyor + Launchpad bug tracker" combination seems like the best option at the moment.
I also asked for suggestions in a Swedish DevOps facebook-group and the feedback I got was to buy a Mac-mini. On that mac-mini OS X builds can be built as well as run Windows VMs and build windows versions of Inkscape. I was already planning to setup some kind CI infrastructure at home so I can build Inkscape on it as well, but I don't have any time estimate when it will be up and running.
2016-02-11 20:05 GMT+01:00 Christoffer Holmstedt < christoffer.holmstedt@...400...>:
2016-02-11 8:07 GMT+01:00 Krzysztof Kosiński <tweenk.pl@...400...>:
2016-02-10 22:45 GMT-08:00 Bryce Harrington <bryce@...961...>:
On Tue, Feb 09, 2016 at 11:55:28AM +0100, joakim@...1974... wrote:
Bryce Harrington <bryce@...961...> writes:
On Fri, Feb 05, 2016 at 09:16:36AM -0800, mathog wrote:
On 05-Feb-2016 05:40, Eduard Braun wrote: > In general I would avoid splitting the code repository from the
bug
> tracker as those two are closely related and often intertwined. It > hinders efficiency a lot when tracking bugs elsewhere.
I agree with that - everything in one place. Moving to git is fine
so
long as the entire history of the project makes the transition, all
the
bugs, all the revisions, and so forth. There shouldn't be anything "left behind" on launchpad. Not that I have any idea how one would
go
about doing this sort of migration, never having used git except to download entire projects for a local build.
I'll throw out another thing maybe worth considering is Phabricator
http://phabricator.org/This is a very powerful platform, and highly customizable, providing an integrated solution for bugs, patchreview, and a heap of other stuff as well as git hosting. I've had some limited experience using it on Enlightenment and Wayland, and it gets very high marks from people who use it.
Thanks for the link Bryce, I was looking around for JIRA alternatives for non-Inkscape stuff and phabricator seems like a good candidate.
I've been able to look into Phabricator and run a local test environment for some time now and for sure Phabricator is really powerful. The downside is as you say Bryce it would take a lot of configuration and administration to set up properly for our needs, especially when it comes to bug tracking. It might be worth it but I don't think so. Phabricator is more for bigger organizations which requires alot of flexibility between different projects, teams and workflows.
The biggest drawback as I see it is the requirement to use "arc" command line tool when you want to use the code review features of the platform. I really see it as an annoying extra step when I just want to push a git branch to remote repository for review, even sending email with linux kernel patches is easier, straight from git cli.
At the moment Gitlab + Jenkins seems to be the best option if we want to host our code and CI ourselves.
Regards
I would like to see an experiment done:
Import inkscape or lib2geom to GitHub and then import from GitHub into GitLab. This would help answer the question of what we do if GitHub (or GigLab) goes the way of SourceForge. (In other words... how portable is code/issues/bugs between one GitXXX and another GitYYY. If it isn't a problem, then I doen't need to think too hard about which we pick.)
Tav
Am Mittwoch, 10. Februar 2016, 20:49:24 schrieb Tavmjong Bah:
I would like to see an experiment done:
Import inkscape or lib2geom to GitHub and then import from GitHub into GitLab. This would help answer the question of what we do if GitHub (or GigLab) goes the way of SourceForge. (In other words... how portable is code/issues/bugs between one GitXXX and another GitYYY. If it isn't a problem, then I doen't need to think too hard about which we pick.)
At least for code that is trivial with git. Just add a new remote location, then push to that and reove the old one afterwards. If you clean up .git/config you can even keep the nice names you were used to (origin/ for example). See [0].
Tav
Tobias
[0] https://stackoverflow.com/questions/1484648/how-to-migrate-git-repository-fr...
2016-02-10 20:49 GMT+01:00 Tavmjong Bah <tavmjong@...8...>:
I would like to see an experiment done:
Import inkscape or lib2geom to GitHub and then import from GitHub into GitLab. This would help answer the question of what we do if GitHub (or GigLab) goes the way of SourceForge. (In other words... how portable is code/issues/bugs between one GitXXX and another GitYYY. If it isn't a problem, then I doen't need to think too hard about which we pick.)
Tav
Moving code is not an issue as shown by Krzysztof, the big elephant in the room is the issue history. As I said in earlier email lp2gh is available but needs some error handling to properly export a big project from Launchpad.
Although, before I start patching up lp2gh, is Github/Gitlab issue tracker really good enough? The more I keep my eyes open for lessons learned on this topic and the more I read I don't think so. Keeping issue tracking at launchpad seems to be the best option (if we don't want to run our own, like phabricator mentioned by Bryce in separate mail thread).
Just now I stumbled on a hackernews discussion about moving away from Github due to poor issue tracker [1] and [2]. Other projects have similar problems with the issue system on Github, [3] and [4]. If we feel that keeping code and issue tracking together at all costs I think HuBoard [5] and ZenHub [6] could be alternatives to "add on top" of github.
[1] https://news.ycombinator.com/item?id=11082745 [2] https://github.com/eslint/eslint/issues/5205 [3] https://github.com/dear-github/dear-github [4] https://github.com/dear-github/dear-github/issues [5] https://huboard.com/pricing [6] https://www.zenhub.io/open-source
Regards
2016-02-11 21:29 GMT-08:00 Christoffer Holmstedt <christoffer.holmstedt@...400...>:
2016-02-10 20:49 GMT+01:00 Tavmjong Bah <tavmjong@...8...>:
I would like to see an experiment done:
Import inkscape or lib2geom to GitHub and then import from GitHub into GitLab. This would help answer the question of what we do if GitHub (or GigLab) goes the way of SourceForge. (In other words... how portable is code/issues/bugs between one GitXXX and another GitYYY. If it isn't a problem, then I doen't need to think too hard about which we pick.)
Although, before I start patching up lp2gh, is Github/Gitlab issue tracker really good enough? The more I keep my eyes open for lessons learned on this topic and the more I read I don't think so. Keeping issue tracking at launchpad seems to be the best option (if we don't want to run our own, like phabricator mentioned by Bryce in separate mail thread).
I also think that GitHub's issue tracker is completely inadequate for us.
Just now I stumbled on a hackernews discussion about moving away from Github due to poor issue tracker [1] and [2]. Other projects have similar problems with the issue system on Github, [3] and [4]. If we feel that keeping code and issue tracking together at all costs I think HuBoard [5] and ZenHub [6] could be alternatives to "add on top" of github.
[1] https://news.ycombinator.com/item?id=11082745 [2] https://github.com/eslint/eslint/issues/5205 [3] https://github.com/dear-github/dear-github [4] https://github.com/dear-github/dear-github/issues [5] https://huboard.com/pricing [6] https://www.zenhub.io/open-source
These GitHub extensions are geared towards developers and do not solve two fundamental user-facing problems in the issue tracker: 1. Very restrictive set of allowed attachments, 2. Not possible to configure an issue template. These are absolute showstoppers and we can't use GitHub issues because of this.
GitLab's issue tracker does not have these problems, but it doesn't integrate with Travis CI. However, Travis CI is open source, so someone could theoretically add that integration.
Best regards, Krzysztof
I think GitHubs issue tracker is bad for Inkscape, but it might just enough for lib2geom.
Would hosting lib2geom on github, utilizing TravisCI, be an option...? lib2geom is just a support library of Inkscape, so I don't see the "must be on same host" so important. And Krzysztof has already tested out GitHub/TravisCI quite a lot, so we know it works.
I think that combination is really good for productivity, as it's a popular combination in open source world of today.
Mvh
/Olof ----------------- 3-5-åriga småttingar i närheten? Lek & lär siffror och bokstäver via mobilen m.h.a. Alfamem till Android. https://play.google.com/store/search?q=alfamem
On 12 February 2016 at 07:42, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
2016-02-11 21:29 GMT-08:00 Christoffer Holmstedt <christoffer.holmstedt@...400...>:
2016-02-10 20:49 GMT+01:00 Tavmjong Bah <tavmjong@...8...>:
I would like to see an experiment done:
Import inkscape or lib2geom to GitHub and then import from GitHub into GitLab. This would help answer the question of what we do if GitHub (or GigLab) goes the way of SourceForge. (In other words... how portable is code/issues/bugs between one GitXXX and another GitYYY. If it isn't a problem, then I doen't need to think too hard about which we pick.)
Although, before I start patching up lp2gh, is Github/Gitlab issue
tracker
really good enough? The more I keep my eyes open for lessons learned on
this
topic and the more I read I don't think so. Keeping issue tracking at launchpad seems to be the best option (if we don't want to run our own,
like
phabricator mentioned by Bryce in separate mail thread).
I also think that GitHub's issue tracker is completely inadequate for us.
Just now I stumbled on a hackernews discussion about moving away from
Github
due to poor issue tracker [1] and [2]. Other projects have similar
problems
with the issue system on Github, [3] and [4]. If we feel that keeping
code
and issue tracking together at all costs I think HuBoard [5] and ZenHub
[6]
could be alternatives to "add on top" of github.
[1] https://news.ycombinator.com/item?id=11082745 [2] https://github.com/eslint/eslint/issues/5205 [3] https://github.com/dear-github/dear-github [4] https://github.com/dear-github/dear-github/issues [5] https://huboard.com/pricing [6] https://www.zenhub.io/open-source
These GitHub extensions are geared towards developers and do not solve two fundamental user-facing problems in the issue tracker: 1. Very restrictive set of allowed attachments, 2. Not possible to configure an issue template. These are absolute showstoppers and we can't use GitHub issues because of this.
GitLab's issue tracker does not have these problems, but it doesn't integrate with Travis CI. However, Travis CI is open source, so someone could theoretically add that integration.
Best regards, Krzysztof
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2016-02-11 22:42 GMT-08:00 Krzysztof Kosiński <tweenk.pl@...400...>:
These GitHub extensions are geared towards developers and do not solve two fundamental user-facing problems in the issue tracker: 1. Very restrictive set of allowed attachments, 2. Not possible to configure an issue template. These are absolute showstoppers and we can't use GitHub issues because of this.
Looks like number 2 was just solved. https://github.com/blog/2111-issue-and-pull-request-templates
Honestly, I think Gitlab is the better option. While it doesn't have Travis CI. It does have it own CI. http://doc.gitlab.com/ce/ci/quick_start/README.html . The community edition is open source but self-hosting is only one option. Gitlab does offer free hosting as well. There several managed services including https://githost.io which is a Gitlab service and others https://vpsineu.com/managed-gitlab-vps-hosting.html . I don't think Github is going away anytime soon and they are rather generous with FLOSS project hosting. I would rather have more control over our own destiny then depending on the generosity of a large company. http://doc.gitlab.com/ce/ci/quick_start/README.html
On Wed, Feb 17, 2016 at 3:45 PM Krzysztof Kosiński <tweenk.pl@...1063....> wrote:
2016-02-11 22:42 GMT-08:00 Krzysztof Kosiński <tweenk.pl@...400...>:
These GitHub extensions are geared towards developers and do not solve two fundamental user-facing problems in the issue tracker: 1. Very restrictive set of allowed attachments, 2. Not possible to configure an issue template. These are absolute showstoppers and we can't use GitHub issues because of this.
Looks like number 2 was just solved. https://github.com/blog/2111-issue-and-pull-request-templates
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Feb 17, 2016 19:59, "Joshua Blocher" <verbalshadow@...400...> wrote:
Honestly, I think Gitlab is the better option. While it doesn't have
Travis CI. It does have it own CI. http://doc.gitlab.com/ce/ci/quick_start/README.html
GitLab CI's public builders ("runners") only support Ruby, so we would need to maintain our own builders.
Best regards, Krzysztof
participants (18)
-
unknown＠example.com -
Bryce Harrington -
C R -
Christoffer Holmstedt -
Eduard Braun -
Eternal Tyro -
Joshua Blocher -
Krzysztof Kosiński -
Liam White -
Martin Owens -
mathog -
Olof Bjarnason -
Richard Hughes -
Sebastian Zartner -
Shlomi Fish -
Tavmjong Bah -
Ted Gould -
Tobias Ellinghaus