gitlab migration plan
Thanks everyone who provided feedback on the plan to migrate to gitlab. I've updated the plan to incorporate all the feedback (see attached diff for what changed). With 0.92.1 now out the door, this seems like an opportune time to proceed with Step 2 of the migration, if no one objects?
So, Martin, Maren, jazzynico, and others who have been maintaining inkscape-related products on gitlab, would you mind sharing your experiences with gitlab, and whether you recommend for or against migrating inkscape itself at this time?
Bryce
------------------------------------------------------------------------
[DONE] Migrate inkscape_web.
+ Keep a particular eye on performance. + Evaluate code review UX + Evaluate CI + Experiment with other features
2. Once 0.92.1 is released, we'll have a first checkpoint Checkpoint for inkscape_web.
+ Make recommendations for utilization of code review, CI, and other gitlab functionality. + Was performance a hinderance? Is the user experience acceptable? In general do the inkscape_web participants still feel as supportive of gitlab? + Retrospective on the 2/1/2017 hack + loss of backups - https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/ - Issue itself is bad. Transparency they showed is good. - It's been a month, have they adequately sorted things out? + Is gitlab's CI build system up to the task for Inkscape? What provisions will we need to make (e.g. supplying our own build hosts) + What concerns or issues remain, that should be watched during our initial migration? + We'll ask everyone involved in inkscape_web for a thumb's up or down. If there are thumb's down, we'll halt and re-evaluate.
3. Migrate inkscape to gitlab.
+ All bzr committers are eligible for gitlab commit access, but will need to place a request for access + tweenk has a script to fix up discrepant author names and e-mails. Can't be shared publically since has personal info (but could be passed to a board member via pgp encrypt). + At least one dry run should be done, to ensure that revision history, branches, tags, etc. are successfully converted. + Functionality that uses 'bzr revno' (like the about screen) will need modified to use git. - Formatting for about screen should be something resembling: "Inkscape 0.92+devel (2017-01-18 f0e47570)" - git describe --tags --dirty will tell the last tag, whether there are changes to the checkout (the --dirty), the short hash of the last commit and also the number of commits since the tag. It's not too hard to clean up the tag name (remove "release-") and add the commit date. - Use the commit date rather than the author date + Issues encountered with gitlab will be recorded in our bug tracker with the 'gitlab-migration' tag. + Transition of wiki pages can start as desired (see separate plan proposal). + Bugs stay on LP for now
4. Outreach effort to bring in contributors
+ Assemble an outreach/advocacy team + Leverage our release marketing procedures and contacts + Coordinate with GSoC, releases, hackfests + Ensure we have reviewers/mentors on hand
5. Following the 0.93.0 release is a second checkpoint.
+ Review the recorded issues encountered. Collect further feedback. + How has use of gitlab affected contribution levels to the Inkscape codebase? If contribution levels have not grown then we need to reassess. + All active users of the service are asked to give thumbs up/down on their experience using gitlab. If most everyone gives thumb's up, we will proceed and stick with gitlab at least until 1.0.0. Otherwise, we need to re-evaluate our plans. + Plan follow-on work to investigate/address top issues.
6. Following the 1.0.0 release, we have another reassessment of all project technologies and services. cmake, git, gitlab, C++11, gtk3, and so on. We should then plan transitions from those to whatever is next, over the course of several 1.x releases.
On Tue, Feb 28, 2017 at 07:12:20PM -0800, Bryce Harrington wrote:
Thanks everyone who provided feedback on the plan to migrate to gitlab. I've updated the plan to incorporate all the feedback (see attached diff for what changed).
diff is attached now...
With 0.92.1 now out the door, this seems like an opportune time to proceed with Step 2 of the migration, if no one objects?
So, Martin, Maren, jazzynico, and others who have been maintaining inkscape-related products on gitlab, would you mind sharing your experiences with gitlab, and whether you recommend for or against migrating inkscape itself at this time?
Bryce
[DONE] Migrate inkscape_web.
+ Keep a particular eye on performance. + Evaluate code review UX + Evaluate CI + Experiment with other features
Once 0.92.1 is released, we'll have a first checkpoint Checkpoint for inkscape_web.
- Make recommendations for utilization of code review, CI, and other gitlab functionality.
- Was performance a hinderance? Is the user experience acceptable? In general do the inkscape_web participants still feel as supportive of gitlab?
- Retrospective on the 2/1/2017 hack + loss of backups
- https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/
- Issue itself is bad. Transparency they showed is good.
- It's been a month, have they adequately sorted things out?
- Is gitlab's CI build system up to the task for Inkscape? What provisions will we need to make (e.g. supplying our own build hosts)
- What concerns or issues remain, that should be watched during our initial migration?
- We'll ask everyone involved in inkscape_web for a thumb's up or down. If there are thumb's down, we'll halt and re-evaluate.
Migrate inkscape to gitlab.
- All bzr committers are eligible for gitlab commit access, but will need to place a request for access
- tweenk has a script to fix up discrepant author names and e-mails. Can't be shared publically since has personal info (but could be passed to a board member via pgp encrypt).
- At least one dry run should be done, to ensure that revision history, branches, tags, etc. are successfully converted.
- Functionality that uses 'bzr revno' (like the about screen) will need modified to use git.
- Formatting for about screen should be something resembling: "Inkscape 0.92+devel (2017-01-18 f0e47570)"
- git describe --tags --dirty will tell the last tag, whether there are changes to the checkout (the --dirty), the short hash of the last commit and also the number of commits since the tag. It's not too hard to clean up the tag name (remove "release-") and add the commit date.
- Use the commit date rather than the author date
- Issues encountered with gitlab will be recorded in our bug tracker with the 'gitlab-migration' tag.
- Transition of wiki pages can start as desired (see separate plan proposal).
- Bugs stay on LP for now
Outreach effort to bring in contributors
- Assemble an outreach/advocacy team
- Leverage our release marketing procedures and contacts
- Coordinate with GSoC, releases, hackfests
- Ensure we have reviewers/mentors on hand
Following the 0.93.0 release is a second checkpoint.
- Review the recorded issues encountered. Collect further feedback.
- How has use of gitlab affected contribution levels to the Inkscape codebase? If contribution levels have not grown then we need to reassess.
- All active users of the service are asked to give thumbs up/down on their experience using gitlab. If most everyone gives thumb's up, we will proceed and stick with gitlab at least until 1.0.0. Otherwise, we need to re-evaluate our plans.
- Plan follow-on work to investigate/address top issues.
Following the 1.0.0 release, we have another reassessment of all project technologies and services. cmake, git, gitlab, C++11, gtk3, and so on. We should then plan transitions from those to whatever is next, over the course of several 1.x releases.
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
Am 01.03.2017 um 22:19 schrieb Bryce Harrington:
On Tue, Feb 28, 2017 at 07:12:20PM -0800, Bryce Harrington wrote:
Thanks everyone who provided feedback on the plan to migrate to gitlab. I've updated the plan to incorporate all the feedback (see attached diff for what changed).
Thank you, Bryce (and sorry for delay - mail server issues...)
Once 0.92.1 is released, we'll have a first checkpoint Checkpoint for inkscape_web.
- Make recommendations for utilization of code review, CI, and other gitlab functionality.
- It just worked as expected. The code review pages are very similar to github's. To see the code that has changed (in a merge request) you need to click on a tab at the bottom, and I didn't find it right away, but it's just a different interface that one would need to get used to.
+ Was performance a hinderance?
- No. I know they currently have (or had? development is so fast) an issue with issue threads that are too long slowing down the browser (and were working on it), but ours don't pose a problem. The site loads fast enough, and the command line interactions didn't seem to take longer or shorter than those with github or launchpad.
Is the user experience acceptable?
- For me, it's fine - after Martin added a webhook that sends an email with a diff on push events. I felt blind without that (but it seems to be the norm, it's the same on github).
Their permission settings are very fine-grained. That's nice. Issues work as expected, labels can replace the functionality of the missing sorting options. Their issue boards (where one can create work lists from labels) seem to be a nice addition. Comparison between branches is easily accessible. Branches can be locked, and groups and single people can be allowed access. There is no such concept as a team, only projects, and overarching groups with multiple projects inside, and people with different permissions on them. The online editor worked as expected.
Martin used the Wiki for drafting a blueprint.
Accessing the code seems to be easy enough for new contributors, inkscape-web already has a couple of forks, and we've had the same number of regulars as usual (which is 3 - Sylvain joined us there, too.).
For setting up the 'view' permissions (yes, there are separate permissions for just looking at different functionality), it was good that su_v was already a long-time gitlab user and was able to help us there. The phrasing of some of the options was a bit misleading. The settings interface is currently being reworked, though. I assume that setup is a one-time thing, so not a very relevant problem, once you know what it means.
Setting up the translations repo for inkscape-web was straightforward, and after permission issues were cleared up (make sure to check for branch protections), as Martin already said, I even played with their CI. With my level of knowledge and their documentation, it was easy enough to set up a script that is run on each commit and checks if po files compile.
New releases are frequent events (see blog archive for overview: https://about.gitlab.com/blog/archives.html). Usually, there was no noticable downtime. Gitlab development appears to be extremely active.
We didn't use milestones, release tags, any of the issue templates, push rules, rules for merging (like: how many approvals are needed), hosting of own container images at gitlab, and probably a lot more, but there exists an unbelievable amount of possibilities.
In general do the inkscape_web participants still feel as supportive of gitlab?
- I do, yes.
+ Retrospective on the 2/1/2017 hack + loss of backups - https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/ - Issue itself is bad. Transparency they showed is good. - It's been a month, have they adequately sorted things out?
- It wasn't exactly a hack, more human error, plus nobody checking if backups worked. Transparency was amazing, and still is (they're now providing records of their team meetings online). Postmortem is here: https://about.gitlab.com/2017/02/10/postmortem-of-database-outage-of-january...
9 of 14 issues that were connected to the data loss (linked from the postmortem) are closed now. I can't tell how important the respective issues are. Some of the open ones didn't get an update within the last two or three weeks, but work on all of them has been started.
(If I were a twitter user, I'd just have asked them for a general overview of current backup state, but I'm not, and the issues themselves are an unsuitable place for this.)
+ Is gitlab's CI build system up to the task for Inkscape? What provisions will we need to make (e.g. supplying our own build hosts)
- It seems it's possible to upload one's own docker container images, but not tested.
+ What concerns or issues remain, that should be watched during our initial migration? + We'll ask everyone involved in inkscape_web for a thumb's up or down. If there are thumb's down, we'll halt and re-evaluate.
- Thumbs up from me. No issues with inkscape-web or inkscape-web-i18n on gitlab.
Maren
Migrate inkscape to gitlab.
- All bzr committers are eligible for gitlab commit access, but will need to place a request for access
- tweenk has a script to fix up discrepant author names and e-mails. Can't be shared publically since has personal info (but could be passed to a board member via pgp encrypt).
- At least one dry run should be done, to ensure that revision history, branches, tags, etc. are successfully converted.
- Functionality that uses 'bzr revno' (like the about screen) will need modified to use git.
- Formatting for about screen should be something resembling: "Inkscape 0.92+devel (2017-01-18 f0e47570)"
- git describe --tags --dirty will tell the last tag, whether there are changes to the checkout (the --dirty), the short hash of the last commit and also the number of commits since the tag. It's not too hard to clean up the tag name (remove "release-") and add the commit date.
- Use the commit date rather than the author date
- Issues encountered with gitlab will be recorded in our bug tracker with the 'gitlab-migration' tag.
- Transition of wiki pages can start as desired (see separate plan proposal).
- Bugs stay on LP for now
Outreach effort to bring in contributors
- Assemble an outreach/advocacy team
- Leverage our release marketing procedures and contacts
- Coordinate with GSoC, releases, hackfests
- Ensure we have reviewers/mentors on hand
Following the 0.93.0 release is a second checkpoint.
- Review the recorded issues encountered. Collect further feedback.
- How has use of gitlab affected contribution levels to the Inkscape codebase? If contribution levels have not grown then we need to reassess.
- All active users of the service are asked to give thumbs up/down on their experience using gitlab. If most everyone gives thumb's up, we will proceed and stick with gitlab at least until 1.0.0. Otherwise, we need to re-evaluate our plans.
- Plan follow-on work to investigate/address top issues.
Following the 1.0.0 release, we have another reassessment of all project technologies and services. cmake, git, gitlab, C++11, gtk3, and so on. We should then plan transitions from those to whatever is next, over the course of several 1.x releases.
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
2017-03-02 3:12 GMT+01:00 maren <marenhachmann@...36...>:
Am 01.03.2017 um 22:19 schrieb Bryce Harrington:
On Tue, Feb 28, 2017 at 07:12:20PM -0800, Bryce Harrington wrote:
Thanks everyone who provided feedback on the plan to migrate to gitlab. I've updated the plan to incorporate all the feedback (see attached
diff
for what changed).
...cut...
Is the user experience acceptable?
- For me, it's fine - after Martin added a webhook that sends an email
with a diff on push events. I felt blind without that (but it seems to be the norm, it's the same on github).
...cut...
Maren
What do you mean with "push events"? Do you get an email with a diff for each commit to master?
Best regards -- Christoffer Holmstedt
On Thu, 2017-03-02 at 19:44 +0100, Christoffer Holmstedt wrote:
What do you mean with "push events"? Do you get an email with a diff for each commit to master?
Each push hits a http address with a json file. I have offered to provide this in the website so it'll email all people in a given special group every time there's an event from gitlab.
It's a way to get emails from GitLab for commits.
Best Regards, Martin Owens
To reduce confusion:
Martin and I are talking about different options. We're currently using the one I described (gitlab integration, sorry, used the wrong term), which doesn't allow for people subscribing themselves, but is ready-made.
The option Martin describes (webhook) would need to be set up on the inkscape.org server, but would allow people to subscribe and unsubscribe any time.
Maren
Am 02.03.2017 um 20:12 schrieb Martin Owens:
On Thu, 2017-03-02 at 19:44 +0100, Christoffer Holmstedt wrote:
What do you mean with "push events"? Do you get an email with a diff for each commit to master?
Each push hits a http address with a json file. I have offered to provide this in the website so it'll email all people in a given special group every time there's an event from gitlab.
It's a way to get emails from GitLab for commits.
Best Regards, Martin Owens
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
Am 02.03.2017 um 19:44 schrieb Christoffer Holmstedt:
2017-03-02 3:12 GMT+01:00 maren <marenhachmann@...36... mailto:marenhachmann@...36...>:
Am 01.03.2017 um 22:19 schrieb Bryce Harrington:
On Tue, Feb 28, 2017 at 07:12:20PM -0800, Bryce Harrington wrote:
Thanks everyone who provided feedback on the plan to migrate to gitlab. I've updated the plan to incorporate all the feedback (see attached
diff
for what changed).
...cut...
Is the user experience acceptable?
- For me, it's fine - after Martin added a webhook that sends an email
with a diff on push events. I felt blind without that (but it seems to be the norm, it's the same on github).
...cut...
Maren
What do you mean with "push events"? Do you get an email with a diff for each commit to master?
- It's an email with a diff for the commits to any branch inside the repo per 'git push'.
I don't know if commits that have been pushed together get a diff over all commits (but I think so - only I don't have any that contain more than one commit in my mail trash currently).
Email addresses for subscribers (currently) need to be added manually by someone who has access to the settings.
Screenshot of one of the mails attached (no custom code needed to create them, it's pre-made, just need to activate the option in the settings at gitlab).
Regards, Maren
Best regards
Christoffer Holmstedt
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
Am Donnerstag, 2. März 2017, 20:23:22 CET schrieb Maren Hachmann:
Am 02.03.2017 um 19:44 schrieb Christoffer Holmstedt:
2017-03-02 3:12 GMT+01:00 maren <marenhachmann@...36...
mailto:marenhachmann@...36...>:
Am 01.03.2017 um 22:19 schrieb Bryce Harrington:
On Tue, Feb 28, 2017 at 07:12:20PM -0800, Bryce Harrington wrote:
Thanks everyone who provided feedback on the plan to migrate to gitlab. I've updated the plan to incorporate all the feedback (see attached
diff
for what changed).
...cut...
Is the user experience acceptable?
- For me, it's fine - after Martin added a webhook that sends an email
with a diff on push events. I felt blind without that (but it seems to be the norm, it's the same on github).
...cut...
Maren
What do you mean with "push events"? Do you get an email with a diff for each commit to master?
- It's an email with a diff for the commits to any branch inside the
repo per 'git push'.
I don't know if commits that have been pushed together get a diff over all commits (but I think so - only I don't have any that contain more than one commit in my mail trash currently).
Email addresses for subscribers (currently) need to be added manually by someone who has access to the settings.
Wouldn't it make sense to set up a mailing list where only the gitlab server may send to, have gitlab send its push notifications there and allow people to just subscribe? That would use the already existing mailing list infrastructure and not require too much extra work.
Screenshot of one of the mails attached (no custom code needed to create them, it's pre-made, just need to activate the option in the settings at gitlab).
Regards, Maren
Tobias
Best regards
Christoffer Holmstedt
---- 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
Am 03.03.2017 um 12:07 schrieb Tobias Ellinghaus:
<snip>
Wouldn't it make sense to set up a mailing list where only the gitlab server may send to, have gitlab send its push notifications there and allow people to just subscribe? That would use the already existing mailing list infrastructure and not require too much extra work.
- Sounds like a very good idea to me, Tobias.
Martin, would that be easier to do for you than the webhook thing?
We wouldn't need to worry about any parsing of json, text or styling or whatever, if we just use the mails that gitlab can already create. Only need to make sure to allow html mails ;-)
Maren
Screenshot of one of the mails attached (no custom code needed to create them, it's pre-made, just need to activate the option in the settings at gitlab).
Regards, Maren
Tobias
Best regards
Christoffer Holmstedt
---- 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
On Fri, 2017-03-03 at 17:05 +0100, Maren Hachmann wrote:
- Sounds like a very good idea to me, Tobias.
Martin, would that be easier to do for you than the webhook thing?
We wouldn't need to worry about any parsing of json, text or styling or whatever, if we just use the mails that gitlab can already create. Only need to make sure to allow html mails ;-)
Oye! mailing lists. Now there's a sore spot. Did you know that we're still on sourceforge mailman2 because there's not an organisation in the entire world that knows anything about mailing lists enough to help us.
Our mailing lists in general need fixing, it's a good idea to have this code detail mailing list, but we'll need to add it to the queue of things we can do once we have found that mythical mailman supporting organisation.
Best Regards, Martin Owens
On Fri, Mar 03, 2017 at 11:52:07AM -0500, Martin Owens wrote:
On Fri, 2017-03-03 at 17:05 +0100, Maren Hachmann wrote:
- Sounds like a very good idea to me, Tobias.
Martin, would that be easier to do for you than the webhook thing?
We wouldn't need to worry about any parsing of json, text or styling or whatever, if we just use the mails that gitlab can already create. Only need to make sure to allow html mails ;-)
Oye! mailing lists. Now there's a sore spot. Did you know that we're still on sourceforge mailman2 because there's not an organisation in the entire world that knows anything about mailing lists enough to help us.
Our mailing lists in general need fixing, it's a good idea to have this code detail mailing list, but we'll need to add it to the queue of things we can do once we have found that mythical mailman supporting organisation.
Meanwhile, really no reason we couldn't set up another one at sourceforge, if it helps with the git migration.
Mailman migration's on the todo list too but as you say, it's going to take some concerted effort to sort out.
Bryce
Am 03.03.2017 um 17:52 schrieb Martin Owens:
On Fri, 2017-03-03 at 17:05 +0100, Maren Hachmann wrote:
- Sounds like a very good idea to me, Tobias.
Martin, would that be easier to do for you than the webhook thing?
We wouldn't need to worry about any parsing of json, text or styling or whatever, if we just use the mails that gitlab can already create. Only need to make sure to allow html mails ;-)
Oye! mailing lists. Now there's a sore spot. Did you know that we're still on sourceforge mailman2 because there's not an organisation in the entire world that knows anything about mailing lists enough to help us.
- JFTR (it's not mailman3, so maybe too far from what you'd like): Framasoft (French open source community) has a free service for Open Source Projects: https://framalistes.org/
They're using sympa, a mail server software I had never heard of before: https://www.sympa.org/overview/features , https://en.wikipedia.org/wiki/Sympa
but which seems to be used by large organizations.
Maren
Our mailing lists in general need fixing, it's a good idea to have this code detail mailing list, but we'll need to add it to the queue of things we can do once we have found that mythical mailman supporting organisation.
Best Regards, Martin Owens
On Thu, Mar 02, 2017 at 03:12:42AM +0100, maren wrote:
+ What concerns or issues remain, that should be watched during our initial migration? + We'll ask everyone involved in inkscape_web for a thumb's up or down. If there are thumb's down, we'll halt and re-evaluate.
- Thumbs up from me. No issues with inkscape-web or inkscape-web-i18n on
gitlab.
Thanks Maren and Martin. We discussed the migration at today's board meeting, and will be proceeding with the next phase. Expect further details to be announced in the coming days with timing.
Migrate inkscape to gitlab.
- All bzr committers are eligible for gitlab commit access, but will need to place a request for access
- tweenk has a script to fix up discrepant author names and e-mails. Can't be shared publically since has personal info (but could be passed to a board member via pgp encrypt).
- At least one dry run should be done, to ensure that revision history, branches, tags, etc. are successfully converted.
- Functionality that uses 'bzr revno' (like the about screen) will need modified to use git.
- Formatting for about screen should be something resembling: "Inkscape 0.92+devel (2017-01-18 f0e47570)"
- git describe --tags --dirty will tell the last tag, whether there are changes to the checkout (the --dirty), the short hash of the last commit and also the number of commits since the tag. It's not too hard to clean up the tag name (remove "release-") and add the commit date.
- Use the commit date rather than the author date
- Issues encountered with gitlab will be recorded in our bug tracker with the 'gitlab-migration' tag.
- Transition of wiki pages can start as desired (see separate plan proposal).
- Bugs stay on LP for now
Bryce
Outreach effort to bring in contributors
- Assemble an outreach/advocacy team
- Leverage our release marketing procedures and contacts
- Coordinate with GSoC, releases, hackfests
- Ensure we have reviewers/mentors on hand
Following the 0.93.0 release is a second checkpoint.
- Review the recorded issues encountered. Collect further feedback.
- How has use of gitlab affected contribution levels to the Inkscape codebase? If contribution levels have not grown then we need to reassess.
- All active users of the service are asked to give thumbs up/down on their experience using gitlab. If most everyone gives thumb's up, we will proceed and stick with gitlab at least until 1.0.0. Otherwise, we need to re-evaluate our plans.
- Plan follow-on work to investigate/address top issues.
Following the 1.0.0 release, we have another reassessment of all project technologies and services. cmake, git, gitlab, C++11, gtk3, and so on. We should then plan transitions from those to whatever is next, over the course of several 1.x releases.
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
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, 2017-02-28 at 19:12 -0800, Bryce Harrington wrote:
So, Martin, Maren, jazzynico, and others who have been maintaining inkscape-related products on gitlab, would you mind sharing your experiences with gitlab, and whether you recommend for or against migrating inkscape itself at this time?
So far very happy with GitLab.
The issues tracker is working well for us with custom labels and Maren has even used the CI builder to test the i18n repository for correctness.
I've put all my scripting work up here for people to have a look at lpout (getting things out of launchpad):
https://github.com/doctormo/lpout
It may be something we use to get milestones out, or we might consider moving the issues tracker at some future point. I think this took (when tested and finished) will provide the needed functionality for it.
Best Regards, Martin Owens
participants (6)
-
Bryce Harrington -
Christoffer Holmstedt -
maren -
Maren Hachmann -
Martin Owens -
Tobias Ellinghaus