"The time has come," the Walrus said, "To talk of many things: Of shoes — and ships — and sealing-wax— Of cabbages — and kings — And why the sea is boiling hot—
And whether Inkscape should switch to gitlab or github or entirely other things."
At Hackfest 2015 we broached the topic of moving to git, and while recognizing it as probably inevitable, decided to take care of a few other things like switching to cmake first, and getting a release out the door, and getting going with Gtk3 and C++-11.
That release is out the door, cmake is done, Gtk3 is landed in trunk, C++-11 work is under way, and so I think it's time we start on tackling git.
When we last visited this discussion, there was a consensus that yes we should move to git, and that rather than self-hosting a plain git repo (ala freedesktop), we would be better to look at an integrated platform like github or gitlab. But there was not a consensus as to which of those two to pick.
So the task at hand is to discuss and deliberate the two and decide which should be our focus. Both have interesting pros and cons, and I don't think the decision is clear cut.
Where should we go?
In github's favor is that it holds the greater mindshare. Where we to go with it we'd potentially tap into a larger community of developers, which potentially could translate into a greater level of new participation in the project. github also seems like it's received a greater amount of polish and has some feature advantages (github's CI was seen as a huge pro last time we looked).
gitlab is an up-and-comer and is actively acquiring analogous features to github. A big pro for us is that gitlab is FOSS whereas gitlab is free but proprietary. With gitlab we'd also hold the option of self-hosting, which might not matter or might be a huge advantage, it's hard to say.
Both services provide broadly similar functionality and user experiences. The differences between them will be small compared with the differences we'll be facing moving from bzr+launchpad. Also, migration from github to gitlab or vice versa if we change our minds doesn't look like it'd be all that difficult.
Those may be the best two options but they're not the only ones we have. There's other services, and of course git can be used serverside all on its own purely as commandline, or with cgit to provide a minimal web service.
-- faqs -------------------------------------------------------------------
Why the need to move from bzr? One of the reasons why we switched from svn to bzr rather than git was because it was easier to learn; these days so many people know git and don't know bzr (and probably don't care to learn bzr) that this isn't quite such an advantage any more. git is also more actively maintained than bzr, and has a far bigger ecosystem of tutorials, tools and services. We also liked the integration between bzr and the LP bug tracker -- we'll lose this, although github/gitlab provide different integration opportunities that might compensate a bit.
What services would we move? What we've discussed in the past is to keep the migration limited to VCS, branch management, and code review. The issue tracking in github/gitlab is quite different from what we've grown accustomed to in LP so changing that might be too much disruption. bzr->git is the main thing we're concerned with; transition of other services can be handled on a case by case basis.
How would we undertake the transition? suv made a good point today that migration of smaller codebases first can be helpful so that the learning curve can be digested in pieces rather than in one big go. So perhaps we should begin by moving some of our more peripheral bzr repos, then maybe things like the website and then 2geom, and then do inkscape last.
What about people who don't yet know git? I suspect a lot of us either already know git or have been working on learning it, that this isn't an issue. However, this transition is important enough I'd be willing to propose to the board that we fund book purchases and/or other forms of training for members that might need it.
When would the transition be done? We've done some initial experimentation already. I would propose as soon as we have a strong consensus for github or gitlab that we proceed with moving the board's repository, inkscape-docs, and any other small / lesser-used repositories still relevant to Inkscape. Then second in perhaps a few months migrate inkscape-web and 2geom over. Once those are complete then migrate the inkscape repository itself over, with the goal of having the migration done. I'd like to see the transition completed prior to when we start getting heavily into the 0.93 release.
Let me know your thoughts, and help us drive towards a consensus for github or gitlab.
Thanks, Bryce
Since issue tracking stays on launchpad, I don't think the gitlab or github choice matters much as moving the repositories from one to the other without any issue tracking to worry about is a much smaller thing both in mindshare and technically.
I concur with suv that moving smaller repos first is a good idea for smoother learning curves. What about moving one small repo to github and another to gitlab so more eyeballs get to see both? Moving the small repos between the two is even simpler of course, so it could be a way to get a little more Pro/Con research done.
On a general regard I think this has good value for the Inkscape project - gaining a lot more developer traction - as bzr is, even though it hurts me to say as it was my first experience with dvcs systems, quite arcane these days. :(
On 6 Jan 2017 09:53, "Bryce Harrington" <bryce@...961...> wrote:
"The time has come," the Walrus said, "To talk of many things: Of shoes — and ships — and sealing-wax— Of cabbages — and kings — And why the sea is boiling hot— And whether Inkscape should switch to gitlab or github or entirelyother things."
At Hackfest 2015 we broached the topic of moving to git, and while recognizing it as probably inevitable, decided to take care of a few other things like switching to cmake first, and getting a release out the door, and getting going with Gtk3 and C++-11.
That release is out the door, cmake is done, Gtk3 is landed in trunk, C++-11 work is under way, and so I think it's time we start on tackling git.
When we last visited this discussion, there was a consensus that yes we should move to git, and that rather than self-hosting a plain git repo (ala freedesktop), we would be better to look at an integrated platform like github or gitlab. But there was not a consensus as to which of those two to pick.
So the task at hand is to discuss and deliberate the two and decide which should be our focus. Both have interesting pros and cons, and I don't think the decision is clear cut.
Where should we go?
In github's favor is that it holds the greater mindshare. Where we to go with it we'd potentially tap into a larger community of developers, which potentially could translate into a greater level of new participation in the project. github also seems like it's received a greater amount of polish and has some feature advantages (github's CI was seen as a huge pro last time we looked).
gitlab is an up-and-comer and is actively acquiring analogous features to github. A big pro for us is that gitlab is FOSS whereas gitlab is free but proprietary. With gitlab we'd also hold the option of self-hosting, which might not matter or might be a huge advantage, it's hard to say.
Both services provide broadly similar functionality and user experiences. The differences between them will be small compared with the differences we'll be facing moving from bzr+launchpad. Also, migration from github to gitlab or vice versa if we change our minds doesn't look like it'd be all that difficult.
Those may be the best two options but they're not the only ones we have. There's other services, and of course git can be used serverside all on its own purely as commandline, or with cgit to provide a minimal web service.
-- faqs ------------------------------------------------------------
Why the need to move from bzr? One of the reasons why we switched from svn to bzr rather than git was because it was easier to learn; these days so many people know git and don't know bzr (and probably don't care to learn bzr) that this isn't quite such an advantage any more. git is also more actively maintained than bzr, and has a far bigger ecosystem of tutorials, tools and services. We also liked the integration between bzr and the LP bug tracker -- we'll lose this, although github/gitlab provide different integration opportunities that might compensate a bit.
What services would we move? What we've discussed in the past is to keep the migration limited to VCS, branch management, and code review. The issue tracking in github/gitlab is quite different from what we've grown accustomed to in LP so changing that might be too much disruption. bzr->git is the main thing we're concerned with; transition of other services can be handled on a case by case basis.
How would we undertake the transition? suv made a good point today that migration of smaller codebases first can be helpful so that the learning curve can be digested in pieces rather than in one big go. So perhaps we should begin by moving some of our more peripheral bzr repos, then maybe things like the website and then 2geom, and then do inkscape last.
What about people who don't yet know git? I suspect a lot of us either already know git or have been working on learning it, that this isn't an issue. However, this transition is important enough I'd be willing to propose to the board that we fund book purchases and/or other forms of training for members that might need it.
When would the transition be done? We've done some initial experimentation already. I would propose as soon as we have a strong consensus for github or gitlab that we proceed with moving the board's repository, inkscape-docs, and any other small / lesser-used repositories still relevant to Inkscape. Then second in perhaps a few months migrate inkscape-web and 2geom over. Once those are complete then migrate the inkscape repository itself over, with the goal of having the migration done. I'd like to see the transition completed prior to when we start getting heavily into the 0.93 release.
Let me know your thoughts, and help us drive towards a consensus for github or gitlab.
Thanks, Bryce
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
A couple comments:
1. lib2geom already uses git 2. The biggest problem with git is the lack of human readable sequential revision numbering... but it seems this can be worked around. See, for example:
https://cd34.com/blog/programming/using-git-to-generate-an-automatic- version-number/
On Fri, 2017-01-06 at 00:51 -0800, Bryce Harrington wrote:
"The time has come," the Walrus said, "To talk of many things: Of shoes — and ships — and sealing-wax— Of cabbages — and kings — And why the sea is boiling hot—
And whether Inkscape should switch to gitlab or github or entirely other things."
At Hackfest 2015 we broached the topic of moving to git, and while recognizing it as probably inevitable, decided to take care of a few other things like switching to cmake first, and getting a release out the door, and getting going with Gtk3 and C++-11.
That release is out the door, cmake is done, Gtk3 is landed in trunk, C++-11 work is under way, and so I think it's time we start on tackling git.
When we last visited this discussion, there was a consensus that yes we should move to git, and that rather than self-hosting a plain git repo (ala freedesktop), we would be better to look at an integrated platform like github or gitlab. But there was not a consensus as to which of those two to pick.
So the task at hand is to discuss and deliberate the two and decide which should be our focus. Both have interesting pros and cons, and I don't think the decision is clear cut.
Where should we go?
In github's favor is that it holds the greater mindshare. Where we to go with it we'd potentially tap into a larger community of developers, which potentially could translate into a greater level of new participation in the project. github also seems like it's received a greater amount of polish and has some feature advantages (github's CI was seen as a huge pro last time we looked).
gitlab is an up-and-comer and is actively acquiring analogous features to github. A big pro for us is that gitlab is FOSS whereas gitlab is free but proprietary. With gitlab we'd also hold the option of self-hosting, which might not matter or might be a huge advantage, it's hard to say.
Both services provide broadly similar functionality and user experiences. The differences between them will be small compared with the differences we'll be facing moving from bzr+launchpad. Also, migration from github to gitlab or vice versa if we change our minds doesn't look like it'd be all that difficult.
Those may be the best two options but they're not the only ones we have. There's other services, and of course git can be used serverside all on its own purely as commandline, or with cgit to provide a minimal web service.
-- faqs -----------------------------------------------------------
Why the need to move from bzr? One of the reasons why we switched from svn to bzr rather than git was because it was easier to learn; these days so many people know git and don't know bzr (and probably don't care to learn bzr) that this isn't quite such an advantage any more. git is also more actively maintained than bzr, and has a far bigger ecosystem of tutorials, tools and services. We also liked the integration between bzr and the LP bug tracker -- we'll lose this, although github/gitlab provide different integration opportunities that might compensate a bit.
What services would we move? What we've discussed in the past is to keep the migration limited to VCS, branch management, and code review. The issue tracking in github/gitlab is quite different from what we've grown accustomed to in LP so changing that might be too much disruption. bzr->git is the main thing we're concerned with; transition of other services can be handled on a case by case basis.
How would we undertake the transition? suv made a good point today that migration of smaller codebases first can be helpful so that the learning curve can be digested in pieces rather than in one big go. So perhaps we should begin by moving some of our more peripheral bzr repos, then maybe things like the website and then 2geom, and then do inkscape last.
What about people who don't yet know git? I suspect a lot of us either already know git or have been working on learning it, that this isn't an issue. However, this transition is important enough I'd be willing to propose to the board that we fund book purchases and/or other forms of training for members that might need it.
When would the transition be done? We've done some initial experimentation already. I would propose as soon as we have a strong consensus for github or gitlab that we proceed with moving the board's repository, inkscape-docs, and any other small / lesser-used repositories still relevant to Inkscape. Then second in perhaps a few months migrate inkscape-web and 2geom over. Once those are complete then migrate the inkscape repository itself over, with the goal of having the migration done. I'd like to see the transition completed prior to when we start getting heavily into the 0.93 release.
Let me know your thoughts, and help us drive towards a consensus for github or gitlab.
Thanks, Bryce
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Thanks for initialising this one Bryce,
In github's favor is that it holds the greater mindshare. Where we to go with it we'd potentially tap into a larger community of developers, which potentially could translate into a greater level of new participation in the project. github also seems like it's received a greater amount of polish and has some feature advantages (github's CI was seen as a huge pro last time we looked).
gitlab is an up-and-comer and is actively acquiring analogous features to github. A big pro for us is that gitlab is FOSS whereas github is free but proprietary. With gitlab we'd also hold the option of self-hosting, which might not matter or might be a huge advantage, it's hard to say.
One advantage to GitLab is a contact on the inside. If we need to, we can ask questions directly.
I've worked with Github, Gitlab, and a few others in my contracting work, as well as private Gitorious and self-hosted gitlab. I'm currently in favour of GitLab as the most in keeping with our Free Software ideals, as capable as GitHub and the possibilities of lending a hand with improvements to things like the issues tracker in the future to make it work better for us.
GitHub is decent, but it's fashionable but with some downsides. At least they recently fixed their "nothing has a license" bug.
I should add that both GitHub and GitLab have weak project control. I don't believe there's an advantage to either and misappropriation of the inkscape brand is highly likely on both. This is probably a personal bug bear as they both go for the "repository is king" model.
Best Regards, Martin Owens
On Fri, 2017-01-06 at 10:24 +0100, Olof Bjarnason wrote:
What about moving one small repo to github and another to gitlab so more eyeballs get to see both?
I see that metric as a bit biased. We know Github is the monopoly de- jure, so just by force of numbers it'll discount any other concerns or benefits in favour of one.
Do we really have a lack of eyeballs? Inkscape is insanely popular already. What we need is better tools, not just the most popular one.
Martin,
On Fri, 2017-01-06 at 00:51 -0800, Bryce Harrington wrote:
"The time has come," the Walrus said, "To talk of many things: Of shoes — and ships — and sealing-wax— Of cabbages — and kings — And why the sea is boiling hot—
And whether Inkscape should switch to gitlab or github or entirely other things."
We need a requirement that all e-mail threads are started with poetry ;-)
In github's favor is that it holds the greater mindshare. Where we to go with it we'd potentially tap into a larger community of developers, which potentially could translate into a greater level of new participation in the project. github also seems like it's received a greater amount of polish and has some feature advantages (github's CI was seen as a huge pro last time we looked).
I think where this mindshare comes into play is less with drive-by contributions as much as integrations with other services. There are a lot of cool tools built that "just work" with Github. Some only support that as a backend (even though they probably just grab git and work on it, they just don't have an option in the UI) What I'm not sure about is whether we'd end up using any of those services anyway.
Since we last discussed it Gitlab's CI has really stepped up the game. I'd say that if we're just looking at the core services Gitlab wins there today. Github/Travis becomes a more interesting discussion.
gitlab is an up-and-comer and is actively acquiring analogous features to github. A big pro for us is that gitlab is FOSS whereas gitlab is free but proprietary. With gitlab we'd also hold the option of self-hosting, which might not matter or might be a huge advantage, it's hard to say.
And they also seem to be pushing for adoption into the FOSS community. They're showing up at our conferences and stuff like that. Easy to get stickers ;-)
We also liked the integration between bzr and the LP bug tracker -- we'll lose this, although github/gitlab provide different integration opportunities that might compensate a bit.
Since the last time we've discussed it LP's Git features have matured a lot. I don't think that they're on par with Github/Gitlab yet, but we should probably put into consideration just moving to Git and sticking with LP, as it might be a simpler transition.
How would we undertake the transition? suv made a good point today that migration of smaller codebases first can be helpful so that the learning curve can be digested in pieces rather than in one big go.
+1, go suv!
Let me know your thoughts, and help us drive towards a consensus for github or gitlab.
For me, right now, my feelings are towards Gitlab. I think that we should stick with a FOSS solution overall and Github doesn't have enough advantages to override that.
Ted
An advantage of GitHub that was not mentioned here is Travis CI, which allows to run unit tests before merging every branch.
GitLab also has a CI solution, but its public runner servers do not support C++ - we would need to self-host that part.
Best regards, Krzysztof
On Jan 6, 2017 01:42, "Martin Owens" <doctormo@...400...> wrote:
On Fri, 2017-01-06 at 10:24 +0100, Olof Bjarnason wrote:
What about moving one small repo to github and another to gitlab so more eyeballs get to see both?
I see that metric as a bit biased. We know Github is the monopoly de- jure, so just by force of numbers it'll discount any other concerns or benefits in favour of one.
Do we really have a lack of eyeballs? Inkscape is insanely popular already. What we need is better tools, not just the most popular one.
Martin,
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I will say as much as I want a FLOSS solution, it's not a religious issue for me. I lean towards GitHub because of the larger pool of developers and Travis CI integration (not something I've used personally, but heard a lot of positive reports on).
Cheers, Josh
On Fri, Jan 6, 2017 at 9:11 AM, Krzysztof Kosiński <tweenk.pl@...1063....> wrote:
An advantage of GitHub that was not mentioned here is Travis CI, which allows to run unit tests before merging every branch.
GitLab also has a CI solution, but its public runner servers do not support C++ - we would need to self-host that part.
Best regards, Krzysztof
On Jan 6, 2017 01:42, "Martin Owens" <doctormo@...400...> wrote:
On Fri, 2017-01-06 at 10:24 +0100, Olof Bjarnason wrote:
What about moving one small repo to github and another to gitlab so more eyeballs get to see both?
I see that metric as a bit biased. We know Github is the monopoly de- jure, so just by force of numbers it'll discount any other concerns or benefits in favour of one.
Do we really have a lack of eyeballs? Inkscape is insanely popular already. What we need is better tools, not just the most popular one.
Martin,
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I don't know if this is a concern or perhaps a bonus, but I do know that github encourages a lot of forking and hacking and contributions from coders on the "sideline". This may also produce some interested hackers creating unique changes that might not otherwise have happened - also because primarily it's something they get to put on their github page as "popular repositories" and "contributions" within the last 6 months. I know there is some software out there I've contributed to that was on github that I might not have contributed had it not been on there, because they make PRs really really easy.
As an aside, I get the warm and fuzzies when I hear "Inkscape is already insanely popular" even though I had nothing to do with it. It's great software, you guys are great. Keep it up!
On Fri, Jan 6, 2017 at 9:11 AM, Krzysztof Kosiński <tweenk.pl@...1063....> wrote:
An advantage of GitHub that was not mentioned here is Travis CI, which allows to run unit tests before merging every branch.
GitLab also has a CI solution, but its public runner servers do not support C++ - we would need to self-host that part.
Best regards, Krzysztof
On Jan 6, 2017 01:42, "Martin Owens" <doctormo@...400...> wrote:
On Fri, 2017-01-06 at 10:24 +0100, Olof Bjarnason wrote:
What about moving one small repo to github and another to gitlab so more eyeballs get to see both?
I see that metric as a bit biased. We know Github is the monopoly de- jure, so just by force of numbers it'll discount any other concerns or benefits in favour of one.
Do we really have a lack of eyeballs? Inkscape is insanely popular already. What we need is better tools, not just the most popular one.
Martin,
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
GitLab also has a CI solution, but its public runner servers do not support C++ - we would need to self-host that part.
This might have been in the past, but current GitLab CI has C++, see this example ironically hosted on GitHub:
https://github.com/olindata/sample-gitlabci-cpp-project
I think we're right to strongly want good CI support and if we have any trouble, I would lean strongly on our GitLab contact to see what could be done.
Martin,
On Fri, Jan 06, 2017 at 10:28:35AM +0100, Tavmjong Bah wrote:
A couple comments:
- lib2geom already uses git
- The biggest problem with git is the lack of human readable
sequential revision numbering... but it seems this can be worked around. See, for example:
https://cd34.com/blog/programming/using-git-to-generate-an-automatic- version-number/
The lack of sequential numbering of commits is indeed a bit annoying. I've found that in at least some of the cases where I needed that, actually what I was concerned with was a range of commits, or the previous N commits, and git does have some syntax to do that. E.g.:
git diff HEAD~5..HEAD~2 # diff a range of recent commits
git show beb97e5f~1 # Show commit prior to beb97e5f
Bryce
On Fri, 2017-01-06 at 00:51 -0800, Bryce Harrington wrote:
"The time has come," the Walrus said, "To talk of many things: Of shoes — and ships — and sealing-wax— Of cabbages — and kings — And why the sea is boiling hot—
And whether Inkscape should switch to gitlab or github or entirely other things."
At Hackfest 2015 we broached the topic of moving to git, and while recognizing it as probably inevitable, decided to take care of a few other things like switching to cmake first, and getting a release out the door, and getting going with Gtk3 and C++-11.
That release is out the door, cmake is done, Gtk3 is landed in trunk, C++-11 work is under way, and so I think it's time we start on tackling git.
When we last visited this discussion, there was a consensus that yes we should move to git, and that rather than self-hosting a plain git repo (ala freedesktop), we would be better to look at an integrated platform like github or gitlab. But there was not a consensus as to which of those two to pick.
So the task at hand is to discuss and deliberate the two and decide which should be our focus. Both have interesting pros and cons, and I don't think the decision is clear cut.
Where should we go?
In github's favor is that it holds the greater mindshare. Where we to go with it we'd potentially tap into a larger community of developers, which potentially could translate into a greater level of new participation in the project. github also seems like it's received a greater amount of polish and has some feature advantages (github's CI was seen as a huge pro last time we looked).
gitlab is an up-and-comer and is actively acquiring analogous features to github. A big pro for us is that gitlab is FOSS whereas gitlab is free but proprietary. With gitlab we'd also hold the option of self-hosting, which might not matter or might be a huge advantage, it's hard to say.
Both services provide broadly similar functionality and user experiences. The differences between them will be small compared with the differences we'll be facing moving from bzr+launchpad. Also, migration from github to gitlab or vice versa if we change our minds doesn't look like it'd be all that difficult.
Those may be the best two options but they're not the only ones we have. There's other services, and of course git can be used serverside all on its own purely as commandline, or with cgit to provide a minimal web service.
-- faqs -----------------------------------------------------------
Why the need to move from bzr? One of the reasons why we switched from svn to bzr rather than git was because it was easier to learn; these days so many people know git and don't know bzr (and probably don't care to learn bzr) that this isn't quite such an advantage any more. git is also more actively maintained than bzr, and has a far bigger ecosystem of tutorials, tools and services. We also liked the integration between bzr and the LP bug tracker -- we'll lose this, although github/gitlab provide different integration opportunities that might compensate a bit.
What services would we move? What we've discussed in the past is to keep the migration limited to VCS, branch management, and code review. The issue tracking in github/gitlab is quite different from what we've grown accustomed to in LP so changing that might be too much disruption. bzr->git is the main thing we're concerned with; transition of other services can be handled on a case by case basis.
How would we undertake the transition? suv made a good point today that migration of smaller codebases first can be helpful so that the learning curve can be digested in pieces rather than in one big go. So perhaps we should begin by moving some of our more peripheral bzr repos, then maybe things like the website and then 2geom, and then do inkscape last.
What about people who don't yet know git? I suspect a lot of us either already know git or have been working on learning it, that this isn't an issue. However, this transition is important enough I'd be willing to propose to the board that we fund book purchases and/or other forms of training for members that might need it.
When would the transition be done? We've done some initial experimentation already. I would propose as soon as we have a strong consensus for github or gitlab that we proceed with moving the board's repository, inkscape-docs, and any other small / lesser-used repositories still relevant to Inkscape. Then second in perhaps a few months migrate inkscape-web and 2geom over. Once those are complete then migrate the inkscape repository itself over, with the goal of having the migration done. I'd like to see the transition completed prior to when we start getting heavily into the 0.93 release.
Let me know your thoughts, and help us drive towards a consensus for github or gitlab.
Thanks, Bryce
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, Jan 06, 2017 at 09:11:23AM -0800, Krzysztof Kosiński wrote:
An advantage of GitHub that was not mentioned here is Travis CI, which allows to run unit tests before merging every branch.
Right. I did actually mention that - I do remember that was a key point in its favor ("github's CI was seen as a huge pro last time we looked"). But gitlab has improved in this particular area, and also shows that we're dealing with moving targets, and weight feature-by-feature comparisons knowing a deficiency today may not exist tomorrow.
Bryce
GitLab also has a CI solution, but its public runner servers do not support C++ - we would need to self-host that part.
Best regards, Krzysztof
On Jan 6, 2017 01:42, "Martin Owens" <doctormo@...400...> wrote:
On Fri, 2017-01-06 at 10:24 +0100, Olof Bjarnason wrote:
What about moving one small repo to github and another to gitlab so more eyeballs get to see both?
I see that metric as a bit biased. We know Github is the monopoly de- jure, so just by force of numbers it'll discount any other concerns or benefits in favour of one.
Do we really have a lack of eyeballs? Inkscape is insanely popular already. What we need is better tools, not just the most popular one.
Martin,
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, Jan 06, 2017 at 08:56:50AM -0600, Ted Gould wrote:
I think where this mindshare comes into play is less with drive-by contributions as much as integrations with other services. There are a lot of cool tools built that "just work" with Github. Some only support that as a backend (even though they probably just grab git and work on it, they just don't have an option in the UI) What I'm not sure about is whether we'd end up using any of those services anyway.
True, good points. And yeah, most of the services I actually have in mind for us just require git, so should work equally well regardless of what we pick.
I've used both gitlab and github for medium-sized projects, and found them both to be usable and performant. Inkscape is larger and more complex, but so far I haven't seen any reason that either of those options wouldn't do the basic job as well as the other.
We also liked the integration between bzr and the LP bug tracker -- we'll lose this, although github/gitlab provide different integration opportunities that might compensate a bit.
Since the last time we've discussed it LP's Git features have matured a lot. I don't think that they're on par with Github/Gitlab yet, but we should probably put into consideration just moving to Git and sticking with LP, as it might be a simpler transition.
You're right it should be included as an option. If nothing else it has familiarity and inertia to change working in its favor. I'm not sure how compelling a case can be made for it beyond that though.
A large chunk of our transition pain will be developers adapting to git, and we'll have that regardless of any of the options. The other chunk is the web interface and I suppose there's some advantage with Launchpad of sticking with the familiar.
However, Launchpad has remained understaffed for years, and unfortunately it really shows. The chances of reaching parity with github/gitlab seem slim to none. And once their development attention moves on to the next feature development effort, ongoing maintenance of the service is going to become an issue, as it already has in so many other places.
Like gitlab, launchpad is open source. I've contributed LP code myself. I don't know if we're likely to invest development energy here, but both gitlab and LP seem on the same level here. gitlab seems to have a more active development community though.
Let me know your thoughts, and help us drive towards a consensus for github or gitlab.
For me, right now, my feelings are towards Gitlab. I think that we should stick with a FOSS solution overall and Github doesn't have enough advantages to override that.
There was a ticket on our github account with people pushing for github adoption. I'll touch base with them to gather their input, but at this point I agree with you it seems gitlab is looking the better option for Inkscape.
Bryce
On Fri, Jan 06, 2017 at 10:28:35AM +0100, Tavmjong Bah wrote:
A couple comments:
- lib2geom already uses git
- The biggest problem with git is the lack of human readable
sequential revision numbering... but it seems this can be worked around. See, for example:
https://cd34.com/blog/programming/using-git-to-generate-an-automatic- version-number/
Hi Tav, have you had a chance to look at or play with github and gitlab enough to form an opinion? If not, what aspects of the change would you feel to be important for us to keep in consideration?
Bryce
On Fri, 2017-01-06 at 00:51 -0800, Bryce Harrington wrote:
"The time has come," the Walrus said, "To talk of many things: Of shoes — and ships — and sealing-wax— Of cabbages — and kings — And why the sea is boiling hot—
And whether Inkscape should switch to gitlab or github or entirely other things."
At Hackfest 2015 we broached the topic of moving to git, and while recognizing it as probably inevitable, decided to take care of a few other things like switching to cmake first, and getting a release out the door, and getting going with Gtk3 and C++-11.
That release is out the door, cmake is done, Gtk3 is landed in trunk, C++-11 work is under way, and so I think it's time we start on tackling git.
When we last visited this discussion, there was a consensus that yes we should move to git, and that rather than self-hosting a plain git repo (ala freedesktop), we would be better to look at an integrated platform like github or gitlab. But there was not a consensus as to which of those two to pick.
So the task at hand is to discuss and deliberate the two and decide which should be our focus. Both have interesting pros and cons, and I don't think the decision is clear cut.
Where should we go?
In github's favor is that it holds the greater mindshare. Where we to go with it we'd potentially tap into a larger community of developers, which potentially could translate into a greater level of new participation in the project. github also seems like it's received a greater amount of polish and has some feature advantages (github's CI was seen as a huge pro last time we looked).
gitlab is an up-and-comer and is actively acquiring analogous features to github. A big pro for us is that gitlab is FOSS whereas gitlab is free but proprietary. With gitlab we'd also hold the option of self-hosting, which might not matter or might be a huge advantage, it's hard to say.
Both services provide broadly similar functionality and user experiences. The differences between them will be small compared with the differences we'll be facing moving from bzr+launchpad. Also, migration from github to gitlab or vice versa if we change our minds doesn't look like it'd be all that difficult.
Those may be the best two options but they're not the only ones we have. There's other services, and of course git can be used serverside all on its own purely as commandline, or with cgit to provide a minimal web service.
-- faqs -----------------------------------------------------------
Why the need to move from bzr? One of the reasons why we switched from svn to bzr rather than git was because it was easier to learn; these days so many people know git and don't know bzr (and probably don't care to learn bzr) that this isn't quite such an advantage any more. git is also more actively maintained than bzr, and has a far bigger ecosystem of tutorials, tools and services. We also liked the integration between bzr and the LP bug tracker -- we'll lose this, although github/gitlab provide different integration opportunities that might compensate a bit.
What services would we move? What we've discussed in the past is to keep the migration limited to VCS, branch management, and code review. The issue tracking in github/gitlab is quite different from what we've grown accustomed to in LP so changing that might be too much disruption. bzr->git is the main thing we're concerned with; transition of other services can be handled on a case by case basis.
How would we undertake the transition? suv made a good point today that migration of smaller codebases first can be helpful so that the learning curve can be digested in pieces rather than in one big go. So perhaps we should begin by moving some of our more peripheral bzr repos, then maybe things like the website and then 2geom, and then do inkscape last.
What about people who don't yet know git? I suspect a lot of us either already know git or have been working on learning it, that this isn't an issue. However, this transition is important enough I'd be willing to propose to the board that we fund book purchases and/or other forms of training for members that might need it.
When would the transition be done? We've done some initial experimentation already. I would propose as soon as we have a strong consensus for github or gitlab that we proceed with moving the board's repository, inkscape-docs, and any other small / lesser-used repositories still relevant to Inkscape. Then second in perhaps a few months migrate inkscape-web and 2geom over. Once those are complete then migrate the inkscape repository itself over, with the goal of having the migration done. I'd like to see the transition completed prior to when we start getting heavily into the 0.93 release.
Let me know your thoughts, and help us drive towards a consensus for github or gitlab.
Thanks, Bryce
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, Jan 06, 2017 at 12:51:18AM -0800, Bryce Harrington wrote:
"The time has come," the Walrus said, "To talk of many things: Of shoes — and ships — and sealing-wax— Of cabbages — and kings — And why the sea is boiling hot— And whether Inkscape should switch to gitlab or github or entirely other things."At Hackfest 2015 we broached the topic of moving to git, and while recognizing it as probably inevitable, decided to take care of a few other things like switching to cmake first, and getting a release out the door, and getting going with Gtk3 and C++-11.
That release is out the door, cmake is done, Gtk3 is landed in trunk, C++-11 work is under way, and so I think it's time we start on tackling git.
When we last visited this discussion, there was a consensus that yes we should move to git, and that rather than self-hosting a plain git repo (ala freedesktop), we would be better to look at an integrated platform like github or gitlab. But there was not a consensus as to which of those two to pick.
So the task at hand is to discuss and deliberate the two and decide which should be our focus. Both have interesting pros and cons, and I don't think the decision is clear cut.
Where should we go?
In github's favor is that it holds the greater mindshare. Where we to go with it we'd potentially tap into a larger community of developers, which potentially could translate into a greater level of new participation in the project. github also seems like it's received a greater amount of polish and has some feature advantages (github's CI was seen as a huge pro last time we looked).
gitlab is an up-and-comer and is actively acquiring analogous features to github. A big pro for us is that gitlab is FOSS whereas gitlab is free but proprietary. With gitlab we'd also hold the option of self-hosting, which might not matter or might be a huge advantage, it's hard to say.
Both services provide broadly similar functionality and user experiences. The differences between them will be small compared with the differences we'll be facing moving from bzr+launchpad. Also, migration from github to gitlab or vice versa if we change our minds doesn't look like it'd be all that difficult.
Those may be the best two options but they're not the only ones we have. There's other services, and of course git can be used serverside all on its own purely as commandline, or with cgit to provide a minimal web service.
Thanks everyone so far for providing your input. We're still missing input from a number of folk that will be affected by this change so don't think we're ready to finalize a decision.
Some things are easy to quantify, like whether each option supports a given feature, or how widely used one service is, or whether the option matches our open source values. Those are straightforward factors to judge.
Other things are harder to quantify. However, based on feedback these seem to be of genuinely high interest. For instance, we expect github's significantly higher mindshare to translate into significantly more new developers, but we don't know for sure that would happen or how many more that would be. Similarly, gitlab clearly is open source and welcomes contributions, but is that something we would be positioned to take advantage of? (Launchpad has been open source but I don't know that we've taken any advantage of that.)
However, while hard to quantify these would be straightforward to test: We could simply pick one or the other and then document our assumptions about what we expect, then revisit the decision after some period of time to see if our expectations were met. Then, if not, we try the other option (the good news is it appears migrating from one to the other is fairly trivial.)
2geom has been on github already for some time, and we could use it as a data point to test the assumptions. Has it seen an influx of new contributors? Has the number of branches or merge proposals increased since before it was hosted there? What benefits and problems has it encountered in its use of github?
We could test gitlab by migrating, say, inkscape_web to it, and host it there for some period to test the assumptions we have around gitlab. I.e. is the performance and UX ok? Is there a tangible benefit to gitlab being open source, that inkscape_web can take advantage of? Does our "large fish in a small pond" result in better attention from the gitlab development community?
Another idea might be to select an option, and then just plan to revisit that decision once 1.0.0 is out the door.
Whatever we end up deciding to do, I'd really like to see a strong consensus favoring our plan.
Bryce
-- faqs -------------------------------------------------------------------
Why the need to move from bzr? One of the reasons why we switched from svn to bzr rather than git was because it was easier to learn; these days so many people know git and don't know bzr (and probably don't care to learn bzr) that this isn't quite such an advantage any more. git is also more actively maintained than bzr, and has a far bigger ecosystem of tutorials, tools and services. We also liked the integration between bzr and the LP bug tracker -- we'll lose this, although github/gitlab provide different integration opportunities that might compensate a bit.
What services would we move? What we've discussed in the past is to keep the migration limited to VCS, branch management, and code review. The issue tracking in github/gitlab is quite different from what we've grown accustomed to in LP so changing that might be too much disruption. bzr->git is the main thing we're concerned with; transition of other services can be handled on a case by case basis.
How would we undertake the transition? suv made a good point today that migration of smaller codebases first can be helpful so that the learning curve can be digested in pieces rather than in one big go. So perhaps we should begin by moving some of our more peripheral bzr repos, then maybe things like the website and then 2geom, and then do inkscape last.
What about people who don't yet know git? I suspect a lot of us either already know git or have been working on learning it, that this isn't an issue. However, this transition is important enough I'd be willing to propose to the board that we fund book purchases and/or other forms of training for members that might need it.
When would the transition be done? We've done some initial experimentation already. I would propose as soon as we have a strong consensus for github or gitlab that we proceed with moving the board's repository, inkscape-docs, and any other small / lesser-used repositories still relevant to Inkscape. Then second in perhaps a few months migrate inkscape-web and 2geom over. Once those are complete then migrate the inkscape repository itself over, with the goal of having the migration done. I'd like to see the transition completed prior to when we start getting heavily into the 0.93 release.
Let me know your thoughts, and help us drive towards a consensus for github or gitlab.
Thanks, Bryce
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Jan 10, 2017 at 11:32:20PM -0800, Bryce Harrington wrote:
Similarly, gitlab clearly is open source and welcomes contributions, but is that something we would be positioned to take advantage of? (Launchpad has been open source but I don't know that we've taken any advantage of that.)
GitLab is very very smaller than Launchpad, and find a random Ruby developer with some time to tackle a small bug ought to not be so hard. Also AFAIK GitLab developers/maintainers are very receptive to patches; instead Launchpad is very large and complex, and there are only 2 active developers working on it (they are doing great, but they are still only 2, and there is always the fear that Canonical might reassign them to another team (personally I see this as improbable to happen soon though)).
I.e. is the performance and UX ok?
I find github visibly outperforms gitlab, sadly. I think gitlab is now moving from Azure cloud into their own DC just to improve this; I don't know how far they are with that plan.
Another idea is to keep the main repository on launchpad, which can now do git too, and maintain mirrors accepting pull requests from both gitlab and github, or some other combination. Git is a *D*VCS, there is no real need to keep only one upstream copy.
On Tue, 2017-01-10 at 23:32 -0800, Bryce Harrington wrote:
We could test gitlab by migrating, say, inkscape_web to it, and host it there for some period to test the assumptions we have around gitlab. I.e. is the performance and UX ok? Is there a tangible benefit to gitlab being open source, that inkscape_web can take advantage of? Does our "large fish in a small pond" result in better attention from the gitlab development community?
Thanks Bryce,
I've set the wheels in motion to move inkscape-web to GitLab here:
https://gitlab.com/inkscape/inkscape-web
No new commits to the bzr branch will be accepted, and we'll tidy up the launchpad project as we go. Upgrade should be possible by moving your existing checkout aside and doing a fresh git checkout, move any data and pythonenv directories you have back into the new git repository.
The next items are for the bugs, milestones and other bits of data I have that need to be put away in the new GitLab project page. I'll post any scripts or other bits of code that make that process possible.
A good example of some hanging threads are any remaining changes to the projects branch you have open bryce, and the separate translations repository.
Best Regards, Martin Owens
Hi,
my thoughts:
- The switch from bzr to git was supposed to potentially attract new contributors because git is more widely used than bazaar. Even if it's true, I don't think people interested in contributing to inkscape will have any problem finding the code. Inkscape is an insanely popular and known project, and whatever option we choose, the code will never be further away than a google search for "inkscape official code repository"*. Many projects are on code repos way less known than gitlab, for instance git.gnome.org for gimp, and that will not prevent any potential developper to find in 15 seconds she will have to type "git clone git://git.gnome.org/gimp" to get started. So the "popularity" of github vs gitlab should, imo, not matter much.
- I think we are right to pride ourselves for being FLOSS. In my opinion, advocating in favor of open source, being part of SFC, etc, means I would always favor using a FLOSS tool over a not-opensourced one. So, philosophically speaking, Gitlab is a clear winner (but I'm not religious about it, I won't stop contributing if we decide on github).
- Also, I do think the "big fish in a small pond" would actually be an argument *in favor* of gitlab. It means that we might have more possibilities of interactions with the gitlab people, more opportunities to talk with them about our needs and what works great and works less great, while if we find any quirks with github, we'll probably have to stay with "that's how it works". That may also help gitlab itself improve. So I agree we might find some things less "polished" than github, but (1) we can do something about it, and/or (2) we probably can talk to the people taking care of it.
- Whatever the choice, migrating after a while if it ends being a bad choice (say, if we go to gitlab, but it timeouts all the time and no one cares) will be easy.
- The big plus of github afaiu is/was the Travis CI, but if gitlab has it too now ... maybe we should try it ?
- "Git is a *D*VCS, there is no real need to keep only one upstream copy." => I'm a bit curious about how it would work if there are CI stuff involved... can github reject a commit while testing it on travis, even if the commit was originally pushed to lp and gitlab's tests accepted it ?
Is git on lp an option? https://help.launchpad.net/Code/Git
Adib.
Marc Jeanmougin <marc@...3062...> schrieb am Mi., 11. Jan. 2017 um 23:52:
Hi,
my thoughts:
- The switch from bzr to git was supposed to potentially attract new
contributors because git is more widely used than bazaar. Even if it's
true, I don't think people interested in contributing to inkscape will
have any problem finding the code. Inkscape is an insanely popular and
known project, and whatever option we choose, the code will never be
further away than a google search for "inkscape official code
repository"*. Many projects are on code repos way less known than
gitlab, for instance git.gnome.org for gimp, and that will not prevent
any potential developper to find in 15 seconds she will have to type
"git clone git://git.gnome.org/gimp" to get started. So the "popularity"
of github vs gitlab should, imo, not matter much.
- I think we are right to pride ourselves for being FLOSS. In my
opinion, advocating in favor of open source, being part of SFC, etc,
means I would always favor using a FLOSS tool over a not-opensourced
one. So, philosophically speaking, Gitlab is a clear winner (but I'm not
religious about it, I won't stop contributing if we decide on github).
- Also, I do think the "big fish in a small pond" would actually be an
argument *in favor* of gitlab. It means that we might have more
possibilities of interactions with the gitlab people, more opportunities
to talk with them about our needs and what works great and works less
great, while if we find any quirks with github, we'll probably have to
stay with "that's how it works". That may also help gitlab itself
improve. So I agree we might find some things less "polished" than
github, but (1) we can do something about it, and/or (2) we probably can
talk to the people taking care of it.
- Whatever the choice, migrating after a while if it ends being a bad
choice (say, if we go to gitlab, but it timeouts all the time and no one
cares) will be easy.
- The big plus of github afaiu is/was the Travis CI, but if gitlab has
it too now ... maybe we should try it ?
- "Git is a *D*VCS, there is no real need to keep only one upstream
copy." => I'm a bit curious about how it would work if there are CI
stuff involved... can github reject a commit while testing it on travis,
even if the commit was originally pushed to lp and gitlab's tests
accepted it ?
--
Marc
- I'm also in favor of keeping an up-to-date mirror in github anyway so
that people with no googling skills can find it too ;) The README.md can
explain how to contribute
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
Inkscape-devel mailing list
Inkscape-devel@lists.sourceforge.net
On Thu, Jan 12, 2017 at 08:29:00PM +0000, the Adib wrote:
Is git on lp an option? https://help.launchpad.net/Code/Git
Certainly (see my comments about it on Jan 6th, this thread).
Is that the option you would favor the most? If so, what aspects of that option currently influence your view the most?
Thanks, Bryce
Adib.
Marc Jeanmougin <marc@...3062...> schrieb am Mi., 11. Jan. 2017 um 23:52:
Hi,
my thoughts:
- The switch from bzr to git was supposed to potentially attract new
contributors because git is more widely used than bazaar. Even if it's
true, I don't think people interested in contributing to inkscape will
have any problem finding the code. Inkscape is an insanely popular and
known project, and whatever option we choose, the code will never be
further away than a google search for "inkscape official code
repository"*. Many projects are on code repos way less known than
gitlab, for instance git.gnome.org for gimp, and that will not prevent
any potential developper to find in 15 seconds she will have to type
"git clone git://git.gnome.org/gimp" to get started. So the "popularity"
of github vs gitlab should, imo, not matter much.
- I think we are right to pride ourselves for being FLOSS. In my
opinion, advocating in favor of open source, being part of SFC, etc,
means I would always favor using a FLOSS tool over a not-opensourced
one. So, philosophically speaking, Gitlab is a clear winner (but I'm not
religious about it, I won't stop contributing if we decide on github).
- Also, I do think the "big fish in a small pond" would actually be an
argument *in favor* of gitlab. It means that we might have more
possibilities of interactions with the gitlab people, more opportunities
to talk with them about our needs and what works great and works less
great, while if we find any quirks with github, we'll probably have to
stay with "that's how it works". That may also help gitlab itself
improve. So I agree we might find some things less "polished" than
github, but (1) we can do something about it, and/or (2) we probably can
talk to the people taking care of it.
- Whatever the choice, migrating after a while if it ends being a bad
choice (say, if we go to gitlab, but it timeouts all the time and no one
cares) will be easy.
- The big plus of github afaiu is/was the Travis CI, but if gitlab has
it too now ... maybe we should try it ?
- "Git is a *D*VCS, there is no real need to keep only one upstream
copy." => I'm a bit curious about how it would work if there are CI
stuff involved... can github reject a commit while testing it on travis,
even if the commit was originally pushed to lp and gitlab's tests
accepted it ?
--
Marc
- I'm also in favor of keeping an up-to-date mirror in github anyway so
that people with no googling skills can find it too ;) The README.md can
explain how to contribute
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
Inkscape-devel mailing list
Inkscape-devel@lists.sourceforge.net
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Am 11.01.2017 um 17:50 schrieb Martin Owens:
I've set the wheels in motion to move inkscape-web to GitLab here:
https://gitlab.com/inkscape/inkscape-web
No new commits to the bzr branch will be accepted, and we'll tidy up the launchpad project as we go. Upgrade should be possible by moving your existing checkout aside and doing a fresh git checkout, move any data and pythonenv directories you have back into the new git repository.
- Is the code on gitlab yet? I can't find it, but the original on lp is indeed closed.
I can only see the Wiki page for website contributions, so it seems you tested the Wiki-to-md conversion tool.
The next items are for the bugs, milestones and other bits of data I have that need to be put away in the new GitLab project page. I'll post any scripts or other bits of code that make that process possible.
A good example of some hanging threads are any remaining changes to the projects branch you have open bryce, and the separate translations repository.
- Moving the translation repo will require code changes in the main inkscape-web repo (just as moving the main repo will, for the contributors page, which parses the commits).
I assume it will live in parallel to inkscape-web in the inkscape group's realm?
Will it be integrated into the inkscape-web repo directly? I've never really used it, but I know that in git, you can have nested repos (aka submodules)... (my git repo always told me something was 'dirty' until I found a way to silence it...).
Is there anything specific that you'd like help with at the current stage?
Regards, Maren
Thanks for testing Maren,
- Is the code on gitlab yet? I can't find it, but the original on lp
is indeed closed.
It is, many of your commits have an odd youtube email address, so aren't assigned to your account but to this email address. Let me know if you'd like to do a re-import of the code with your email address changed to your Moini address. There's enough to commits to make it worthwhile to fix.
As for it not being visible. That sounds like the config in gitlab isn't quite right. Are you in the inkscape group yet?
I can only see the Wiki page for website contributions, so it seems you tested the Wiki-to-md conversion tool.
I did test one of the tools, there's a couple of them. As well as a couple of markdown formats, I chose github md. There is one issue, the images in gitlab wiki are uploaded to a separate space and not the wiki repository (which is dumb) but one can commit all images into the repository directly and that will work. I just wish it was all together as it'd make backups easier.
- Moving the translation repo will require code changes in the main
inkscape-web repo (just as moving the main repo will, for the contributors page, which parses the commits).
I'm thinking of having it as a separate repository/project on GitLab. Maybe inkscape-web-i18n or something similar. Would you like to create the project? I can help you do the repository translation.
Will it be integrated into the inkscape-web repo directly? I've never really used it, but I know that in git, you can have nested repos (aka submodules)... (my git repo always told me something was 'dirty' until I found a way to silence it...).
I've never really found a use for a sub-module, I mean it is a sub repository in that it belongs inside the inkscape-web. But I don't have a clue really how to set that up or if that means the repository lives in the inkscape-web project or a seperate project on GitLab.
Is there anything specific that you'd like help with at the current stage?
I'm working on bugs and milestones, launchpad's API is truely slow, but the code I've got here makes some mistakes which can fix and make it a little faster. But 200 bugs an hour is REALLY SLOW if we ever want to export inkscape's own bug list. (inkscape-web is 617 bug reports)
Other than looking into the i18n repository and sub-module repositories. Those are the most useful items. Thanks Maren!
Best Regards, Martin Owens
On Wed, Jan 11, 2017 at 11:50:31AM -0500, Martin Owens wrote:
On Tue, 2017-01-10 at 23:32 -0800, Bryce Harrington wrote:
We could test gitlab by migrating, say, inkscape_web to it, and host it there for some period to test the assumptions we have around gitlab. I.e. is the performance and UX ok? Is there a tangible benefit to gitlab being open source, that inkscape_web can take advantage of? Does our "large fish in a small pond" result in better attention from the gitlab development community?
Thanks Bryce,
I've set the wheels in motion to move inkscape-web to GitLab here:
https://gitlab.com/inkscape/inkscape-web
No new commits to the bzr branch will be accepted, and we'll tidy up the launchpad project as we go. Upgrade should be possible by moving your existing checkout aside and doing a fresh git checkout, move any data and pythonenv directories you have back into the new git repository.
The next items are for the bugs, milestones and other bits of data I have that need to be put away in the new GitLab project page. I'll post any scripts or other bits of code that make that process possible.
A good example of some hanging threads are any remaining changes to the projects branch you have open bryce, and the separate translations repository.
Don't worry about the projects branch, I already need to rebase it, and I know how to do that on git better than on bzr anyway.
Bryce
On Fri, Jan 13, 2017 at 09:14:10PM -0500, Martin Owens wrote:
I can only see the Wiki page for website contributions, so it seems you tested the Wiki-to-md conversion tool.
I did test one of the tools, there's a couple of them. As well as a couple of markdown formats, I chose github md. There is one issue, the images in gitlab wiki are uploaded to a separate space and not the wiki repository (which is dumb) but one can commit all images into the repository directly and that will work. I just wish it was all together as it'd make backups easier.
Report back when you have a scheme for doing backups, ideally one we could follow for all inkscape projects.
- Moving the translation repo will require code changes in the main
inkscape-web repo (just as moving the main repo will, for the contributors page, which parses the commits).
I'm thinking of having it as a separate repository/project on GitLab. Maybe inkscape-web-i18n or something similar. Would you like to create the project? I can help you do the repository translation.
In Launchpad we have multiple projects all linked to a master 'Inkscape Project' record. Is there something analogous that can be done in gitlab?
Will it be integrated into the inkscape-web repo directly? I've never really used it, but I know that in git, you can have nested repos (aka submodules)... (my git repo always told me something was 'dirty' until I found a way to silence it...).
I've never really found a use for a sub-module, I mean it is a sub repository in that it belongs inside the inkscape-web. But I don't have a clue really how to set that up or if that means the repository lives in the inkscape-web project or a seperate project on GitLab.
I've used submodules in other VCS's. They add some complexity for what is essentially just convenience. In an open source project where not everyone is familiar with them, I feel the cons outweigh the pros...
Is there anything specific that you'd like help with at the current stage?
I'm working on bugs and milestones, launchpad's API is truely slow, but the code I've got here makes some mistakes which can fix and make it a little faster. But 200 bugs an hour is REALLY SLOW if we ever want to export inkscape's own bug list. (inkscape-web is 617 bug reports)
Other than looking into the i18n repository and sub-module repositories. Those are the most useful items. Thanks Maren!
Best Regards, Martin Owens
Bryce
On Fri, 2017-01-13 at 23:10 -0800, Bryce Harrington wrote:
In Launchpad we have multiple projects all linked to a master 'Inkscape Project' record. Is there something analogous that can be done in gitlab?
The best I can see is that each project is tied to a group. So membership of groups directly seem to be the way these things work.
Groups can have things like todo lists and other pieces, so that's useful.
Martin,
Am 14.01.2017 um 03:14 schrieb Martin Owens:
Thanks for testing Maren,
- Is the code on gitlab yet? I can't find it, but the original on lp
is indeed closed.
It is, many of your commits have an odd youtube email address, so aren't assigned to your account but to this email address. Let me know if you'd like to do a re-import of the code with your email address changed to your Moini address. There's enough to commits to make it worthwhile to fix.
- Yes, that would be good. I thought of adding that email address as an alias to my profile, but that could also open committing up to someone who actually creates that (currently invalid) email account.
As for it not being visible. That sounds like the config in gitlab isn't quite right. Are you in the inkscape group yet?
- No. Wasn't sure if I should request access, as gl doesn't yet have support for subgroups (but does have per project permissions and group permissions, and the highest level that is applicable seems to be used).
https://gitlab.com/gitlab-org/gitlab-ce/issues/2772 https://docs.gitlab.com/ee/user/permissions.html
New projects/repos are 'private' by default. This can be changed in the repo's settings.
Should I request access?
- Moving the translation repo will require code changes in the main
inkscape-web repo (just as moving the main repo will, for the contributors page, which parses the commits).
I'm thinking of having it as a separate repository/project on GitLab. Maybe inkscape-web-i18n or something similar. Would you like to create the project? I can help you do the repository translation.
- If possible, I'd prefer to not see it tied to my account, but rather to Inkscape (or Inkscape-web, if we move there permanently, and subgroups become available some day). As the website pulls from it, it would probably be good to have the namespace set up correctly from the start.
This would mean that I'd need to transfer the project to the Inkscape group, and I wouldn't be able to do that (directly).
Workaround:
Transfer project from me to another person, who is an owner of Inkscape, would mean to do this: https://gitlab.com/gitlab-org/gitlab-ce/issues/18423
Then that other person could move the project into the group 'Inkscape': https://docs.gitlab.com/ce/workflow/groups.html
Do you want to do it this way?
Will it be integrated into the inkscape-web repo directly? I've never really used it, but I know that in git, you can have nested repos (aka submodules)... (my git repo always told me something was 'dirty' until I found a way to silence it...).
I've never really found a use for a sub-module, I mean it is a sub repository in that it belongs inside the inkscape-web. But I don't have a clue really how to set that up or if that means the repository lives in the inkscape-web project or a seperate project on GitLab.
- It would probably just complicate things at the moment, then, when none of us knows how it works. We can still try that out later.
Is there anything specific that you'd like help with at the current stage?
I'm working on bugs and milestones, launchpad's API is truely slow, but the code I've got here makes some mistakes which can fix and make it a little faster. But 200 bugs an hour is REALLY SLOW if we ever want to export inkscape's own bug list. (inkscape-web is 617 bug reports)
- Mmh. Yes, that's slow :/ The bug tracker would need to be closed for that time. Can it be parallelized?
Regards, Maren
On Sat, Jan 14, 2017 at 12:53:10PM -0500, Martin Owens wrote:
On Fri, 2017-01-13 at 23:10 -0800, Bryce Harrington wrote:
In Launchpad we have multiple projects all linked to a master 'Inkscape Project' record. Is there something analogous that can be done in gitlab?
The best I can see is that each project is tied to a group. So membership of groups directly seem to be the way these things work.
Groups can have things like todo lists and other pieces, so that's useful.
Ok, github had something similar. That actually sounds like a better model for what we want.
Bryce
On Sat, 2017-01-14 at 18:59 +0100, Maren Hachmann wrote:
- Yes, that would be good. I thought of adding that email address as
an alias to my profile, but that could also open committing up to someone who actually creates that (currently invalid) email account.
Right then I'll do a re-import.
New projects/repos are 'private' by default. This can be changed in the repo's settings.
Should I request access?
Yes, you'll need group access in order to create the i18n project as stated below. So getting access is step one and I think I'm owner enough to put you in the group.
This would mean that I'd need to transfer the project to the Inkscape group, and I wouldn't be able to do that (directly).
See above, creating project is step two.
- Mmh. Yes, that's slow :/ The bug tracker would need to be closed
for that time. Can it be parallelized?
I'm planning a zeno cheat pattern. That is where you download the bulk of everything while it's live and then close it and then run it again to pick up the rest of the changes (if any).
Best Regards, Martin Owens
Am 14.01.2017 um 20:37 schrieb Martin Owens:
See above, creating project is step two.
- Okay, I'm in the group, and I've 'gitified' the translation bzr branch, following https://design.canonical.com/2015/01/converting-projects-between-git-and-baz...
and updated the email address following https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History, so commits can be correctly associated with my account, and I don't need to use a real mail address.
What's next?
Could you use moini@...3468... for the mail address, please?
Sorry for being late with the concrete address to use. Fortunately, it's a really quick operation...
Regards, Maren
participants (12)
-
Bryce Harrington -
Chris Tooley -
Josh Andler -
Krzysztof Kosiński -
Marc Jeanmougin -
Maren Hachmann -
Martin Owens -
Mattia Rizzolo -
Olof Bjarnason -
Tavmjong Bah -
Ted Gould -
the Adib