- Inkscape Devel - Inkscape Mailman

[RFC] gitlab migration plan
by Bryce Harrington 02 Feb '17

02 Feb '17

Thank you everyone for considering the options and rasing good points and concerns, including: * Gaining contributors is a motivation here * Performance might be problematic with gitlab * FOSS options fit Inkscape values, and we should prefer to support FOSS projects, but not if it inhibits us too badly * Other choices do exist besides just github vs. gitlab A lot of people are voicing preference for gitlab, perhaps a majority, but we're certainly not at a full consensus. I sense that we need some actual experience under our belts, and we should plan to reassess our decision as we get into it. Performance is, at least, something we can test. If gitlab has severe performance issues, then that should be obvious and likely measurable if we just try it. Github certainly would give us more visibility, however there's no guarantee this would translate into more contributors. Will Entriken made a good point that being on github would enable more drive-by contributions based on general experience in various small/medium projects, however Mc makes a strong counter-argument that what we are really after are dedicated contributors, and with Inkscape already having a fairly widespread profile those folks will find us just fine regardless of the popularity of the hosting platform. Perhaps a separate outreach effort to recruit contributors after the git migration has been done would be more likely to generate good results? So given the above, I'd like to propose a migration to githab but with several checkpoints, according to the following plan: 1. 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? + 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 + At least one dry run should be done, to ensure that revision history, branches, tags, etc. are successfully converted. + Issues encountered with gitlab will be recorded, either in a dedicated bug tracker or just a simple 'complaints' web page. + 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 + 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. If you've read this far - thanks! Feedback is most appreciated. Bryce

5 9

Any progress on CMYK?
by John Culleton 02 Feb '17

02 Feb '17

My copy of the 4th edition of the Bah book says it is "under way." The absence is a pity because with the built-in perfect book layout facility Inkscape would be most useful in creating book covers. The ability to distort type faces makes for some interesting possibilities I recognize the size of the task of course. -- John Culleton Wexfordpress Book design and indexing.

2 1

Seeking Review: Inkscape Development for Users
by Martin Owens 01 Feb '17

01 Feb '17

Hi Everyone, Golden Ribbon (GR) has made this slick info graphic to explain and prompt more users to help with Inkscape development. http://grtuts.com/inkscape-development-builds/ He's asked me for advice on the details and I figure I'd throw it open to everyone. You can comment directly in the blog post if you like. Or here, since I know GR is subscribed here too. Also I think we might like to think about brining the planet back to life with some new blood. I wouldn't mind having non-coders on the planet, professionals perhaps. Or more than one if a planet is put into the website for example (they're fairly easy to write) Thoughts? Best Regards, Martin Owens

5 5

[RFC] Wiki replacement plan
by Bryce Harrington 31 Jan '17

31 Jan '17

I'd like to offer a proposal for a path forward here, merging ideas and concerns everyone's put in, particularly Maren's feedback on my initial proposal in the previous wiki thread. Apologies ahead of time for the length, as usual brevity escapes me. Wiki Replacement Plan ---------------------- #0 - No change to the current wiki until Inkscape's codebase is migrated to git. So, probably no change until March or so. Thus, people considering using the wiki for things right now, should proceed with doing those things. #1 - Application documentation and reference source files are moved to Inkscape's share directory in VCS. Extension references, output format details, tutorials, usage advice, and so on. This will be shipped with the application, and probably worth rendering in some web-viewable format as well. Nearly all of this will be worth translating. #2 - Strictly user-facing pages in the wiki are moved to the main website. High level project info, roadmaps, user-oriented FAQs, community resources, and so on. If a page requires advanced styling or layout functionality in our current mediawiki, that would be a strong indication it should be moved to our Django. This will obviously take time and effort but can be tackled bit by bit. Most of this is worth translating. Finalized release notes will become part of the releases app; this will support html and translations. #3 - Static coder-facing documentation should be moved to Inkscape's doc/ directory. This includes anything that documents implemented designs, protocols, and other assorted functionality. It also includes coder tutorials and guidelines. Generally materials that can be considered "finished" and worth keeping for reference value. This doesn't include unimplemented ideas/proposals, nor anything that is obsolete or that we're keeping simply for historical purposes. Little of this will be worth translating. #4 - Dynamic development pages are moved to the git*b wiki. This includes design mockups, development plans, todo lists, architectural brainstorming, infrastructure refactoring proposals and the like. A lot of the stuff currently registered as blueprints, that are adequately well fleshed out and that may be worth including in our official roadmap, should also move here. None of this should be translated. The release notes under development for the trunk codebase are drafted here in this wiki. Perhaps eventually we'll move editing to the releases app. This also includes organizational documentation for the Inkscape board, pages relating to fundraising, hackfest planning, and so on. #5 - Obsolete pages are left in the current wiki, but "mothballed" for historical reference. #6 - A "Community Wiki" will be established with open access for members of the wider Inkscape community, to use as a freeform collaborative editing space. There would not be rules about what can and can't go in here, but this is where folks would go to do collaborative brainstorming, flesh out raw ideas, and share random wishes and bits of information not ready or suitable for inclusion in any of the above. It should be easy to register for and easy to edit, but also robust against spam. All other pages not covered by 2-5 above, will end up here. As a general rule of thumb, if a page in the Community Wiki is important enough to be worth translating, or if we find ourselves linking to the page frequently, then that is a sign the page ought to be promoted and moved elsewhere. This could be an updated MediaWiki like we currently have, however I'd like to see thought given to alternative solutions, such as a Django wiki plugin that allows tighter integration with the website, or even using an externally maintained wiki service. It could also be a special Git*b project with really lax rules for committing. Whatever we pick, the important things are that it's widely available to all, easy to use, and very light on rules or imposed structure. #7 - Feature requests and wishlist changes, eventually will move into a future project management system on the website (I envision something that couples bug tracker style commenting with wiki like editing within a Blueprints-type tracking system). This is probably a few years out though so we'll need to keep using #4 devel wiki in the meantime. Let me know what you think, and please poke holes. If there are no red flags raised, we can proceed with this plan subsequent to our move to git. Thanks, Bryce

5 9

problems having only macports to install Inkscape on Mac
by brynn 31 Jan '17

31 Jan '17

Hi Friends, We have this message which has gone unsolved, in the User mailing list. https://sourceforge.net/p/inkscape/mailman/message/35630257/ I've seen this same problem posted 3 or 4 other times. They follow the instructions for installing using Macports. Everything seems to have worked without producing errors or other problems. But afterwards they can't find Inkscape. In one of them, I'm trying to help a newbie who posted on Inkscape Community. She has sought support from Macport support, and apparently they are either unable or unwilling to simplify the solution for a newbie. I'd like to know the solution for this, since it seems so common. Then I (or we) can help Mac users who have this problem. In my opinion, it reflects poorly on the project not to have a solution which newbies can use. Hopefully Kirk Slowe will be successful packaging a DMG version for 0.92 or 0.92.1. But meanwhile, can anyone tell me the solution for this? Thank you very much, brynn

1 0

Inkscape 0.92 via homebew on macOS
by Tim Sheridan 31 Jan '17

31 Jan '17

If you use homebrew on macOS, then you can get Inkscape 0.92 by running: brew install caskformula/caskformula/inkscape (For non homebrew people, here's a glossary: formula => package built from source, tap => repository, cask => package redistributing an upstream binary) This formula originates from the inkscape formula in the homebrew-gui tap. However, recently the homebrew-gui tap has been deprecated. In the case of Inkscape, the cask is considered the successor package. But since the inkscape cask is limited to official releases (or third party releases nominated by the Inkscape project), the cask will stay at 0.91. So for the time being, I'll be maintaining the inkscape formula in this tap. Any contributions/improvements are welcome: https://github.com/caskformula/homebrew-caskformula Cheers, Tim

5 8

Inkscape 0.92.x stable daily PPA
by Bryce Harrington 30 Jan '17

30 Jan '17

For testers on Ubuntu, I've created a new automated PPA that builds snapshots of the current stable branch, 0.92.x: https://code.launchpad.net/~inkscape.dev/+archive/ubuntu/stable-daily Note that while these snapshots are of the stable tree, the packages aren't official releases, so there is some chance of bugs, and things can change. This PPA is intended to make it more convenient for folks to test our stable tree and help us ensure the point releases are high quality. I've only tested the Trusty package, so ymmv on other ubuntu releases but I expect they should all work as well as the official point releases. Bryce

1 0

Git Rebasing
by Martin Owens 29 Jan '17

29 Jan '17

Hi Developers, Just a heads up. I rebased the inkscape-web git repository on GitLab to sort out problems with it's cherry picks. This took 2 hours of picking through the rebasing as some of it could be automated. So I had to manually merge about two hundred of the 1600 commits to get it working. Not sure if this will bite the inkscape git repository some time in the future. But being aware of the non-linear repository created by a migration from bzr. Best Regards, Martin Owens

5 13

Fw: Lack of mac installer
by brynn 29 Jan '17

29 Jan '17

I received the original message (at the bottom) through the Contact form on Inkscape Community. Forwarding along to the list. You can see I suggested to subscribe to the list. But as of now, he isn't a subscribed. I didn't know exactly what to say about the change to depending on Macports, so hopefully you all can be more helpful. brynn -----Original Message----- From: admin@...3472... Sent: Sunday, January 29, 2017 6:42 AM To: kirk@...3473... Subject: Re: Lack of mac installer Hi Kirk, Wow, that's a fantastic offer! You've actually reached a forum which is only temporarily the official Inkscape forum, while we are working on getting the new official forum working. And for some reason which I find odd, Inkscape developers don't use bb style forums. Since I'm not a Mac user, I haven't paid very close attention to why they switched to Macports. But judging by all the complaints we've had about people trying to use Macports, maybe it would be good to have the DMG version. You'll want to subscribe to the developer's mailing list (https://inkscape.org/en/community/mailing-lists/), which is where this kind of issue is discussed and handled. I could go ahead and forward this to the list, so the people who need to know will see it. You won't be able to post to the list, until you subscribe. But you'll get any replies. And you can follow any discussion which might happen after I forward this, in the archives. The link to the archives is right beside the link to subscribe, on the page above. Actually, developers are about to release 0.92.1, so this could be good timing! Thanks for your generous offer, and I'll send this right along to the people who can answer your questions. All best, brynn -----Original Message----- From: kirk@...3473... Sent: Saturday, January 28, 2017 5:40 AM To: admin@...3472... Subject: Lack of mac installer Contact Page Form for Inkscape Community Name: Kirk Email: kirk@...3473... IP: 209.131.239.35 Message: Do you lack someone to create a dmg installer of v .92? Is that why macports is being used? I'm a mac guy and so understand why so many people have issues with macports. I'm not an expert but would like to volunteer my services to get this version created into a .dmg installer.

2 1

0.92.1 plan
by Bryce Harrington 29 Jan '17

29 Jan '17

The 0.92.x stable branch is reopened for changes. Consider it as under feature freeze but not string freeze. Bugfixes are welcome to be added. Please continue to check with me before landing things, but for the next few weeks I expect to be in rubber stamp mode and approve most anything that looks sensible. We do need to be cautious about not introducing regressions at this point. Write good changelog messages explaining the fixes in good detail please. Translation updates (and entirely new translations) are fine to land directly, no need to check with me. There are already a handful on the branch already that unfortunately came in just after I had cut the tarball. Extension updates and new extensions are probably low enough regression risk that I'll try to be liberal in approving them. The ones we have to be cautious about are the highly used extensions, since we risk breaking people's workflow. A few specifics I'm aware of, that sound worth including: + Tutorials and other .svg files we ship have the dpi scaling issue, and need updated for 0.92.1 + suv mentioned an extension to provide users a workaround to some line spacing issues, iirc. + A mechanism to backup / reset prefs settings + Fixes to some strings that were found post-string freeze + A gpl3 widget needs removed (or relicensed) I'd like to avoid maintaining a bugs-needing-fixed list, but rather focus time more on patch review and testing. I figure the important thing is to get 0.92.1 out in a timely manner, and if there's still bugs needing attention we can always do a 0.92.2 some time later on. Proposed Timing: Mon Jan 2 Feature Freeze 0.92.1pre0 Mon Jan 23 Hard Freeze 0.92.1pre1 Mon Jan 30 String Freeze 0.92.1pre2 Mon Feb 6 Release Candidate 0.92.1 Fri Feb 10 Cut Release Mon Feb 13 Announcement I know we've not got a strong history of staying to schedule, but I'm going to try hard to hit these dates at least within a day or so. That means we'll have to be strict about string changes after String Freeze, and strict about any changes after the Release Candidate. This schedule allows the weekend of Feb 11-12 for prepping website changes, finalizing packages, and so on. Anything you can think of missing from this plan? Bryce

4 6