March 2019 - Inkscape Devel - Inkscape Mailman

GSoC application review
by Valentin Ionita 24 Mar '19

24 Mar '19

Hello again, developers! I am Valentin, or @vanntile as you may know me on Rocket. As Bryce had recommended me a couple of days ago, I have created a repo where I've put the necessary resources for my application to Inkscape. This is a long-planned step and I hope I can get some overall feedback on the draft and some specific feedback from Tav. I am planning on working on the CSS support and JS polyfills projects, both of which you're a mentor on. You can find my draft here https://gitlab.com/vanntile/inkscape-gsoc-application I hope you have a wonderful week coming up! Valentin

1 0

Critical bugs and the Beta release plan
by Bryce Harrington 24 Mar '19

24 Mar '19

Hi all, Beta was roughly planned for March, but it looks like more work is needed on bugs. Below is a review of where we're at and proposal for how to decide when we're ready for releasing beta (and after that, when we can enter Freeze). There are two high importance bugs labeled "Blocker", #153 "Language selector doesn't work" and #45 "Text rendering offset". Fortunately, both are getting some attention, and Tav has potentially fixed the latter. I've assigned #45 to Tav, but we need someone to own #153. Marc, could you take it? Blockers: * https://gitlab.com/inkscape/inkscape/issues/45 [Tav] * https://gitlab.com/inkscape/inkscape/issues/153 [Mc?] There are several critical importance bugs. In gitlab is #35 "Crash on exit following menu rewrite" which several people are confirming; there is a backtrace but it needs some analysis work done to figure out what is happening. Can someone take assignment on that? In launchpad there is #1806878 "Master not working without GUI" and #1809676 "Crash on Undo, Cut Path, Divide path, etc." Tav has done some work on the first and has taken the assignment on it. The second has a good backtrace but needs someone to investigate. Who'd like to take a stab at it? Criticals: * https://gitlab.com/inkscape/inkscape/issues/35 * https://bugs.launchpad.net/inkscape/+bug/1806878 [Tav] * https://bugs.launchpad.net/inkscape/+bug/1809676 In addition to those, there are about a dozen more bugs targeted to 1.0. A couple of note are: #125 "Toolbar empty after startup", and #96 "Text object changes size". The first sounds like it needs Tav or Alex to give advice on, the other has a MR by Joseph Da Silva that sounds like it will fix it. Milestone 1.0: * https://gitlab.com/inkscape/inkscape/issues?milestone_title=1.0 For Beta, I propose we set as pre-requisites that all Blocker bugs must be closed, and all Critical bugs must be Assigned and listed as Known Issues in the release notes, before we initiate Chill and start work on the beta release process. For Freeze, I propose we set as pre-requisites that all Blocker bugs are closed, that all Critical bugs targeted to 1.0 are closed, and that all other 1.0 Milestone bugs must be Assigned and listed as Known issues in the release notes. After Freeze has started, if any new Blocker bugs crop up, then Freeze will be halted, any established release schedule is canceled, and the release put on indefinite hold until the Blocker has been cleared. How do these rules sound? Bryce

1 0

R.I.P. mrdocs (1963--2019)
by "Christoph Schäfer" 23 Mar '19

23 Mar '19

The Scribus Team is deeply saddened to announce the loss of our friend and colleague Peter Linnell who in the end lost his long battle against cancer. It is no understatement to say that without Peter Scribus wouldn't be what it is today. It was Peter who spotted the potential of Franz Schmid's initially humble Python program and, as a pre-press consultant at the time, contacted Franz to make him aware of the necessities of PostScript and PDF support, among other things. Peter also wrote the first version of the Scribus online documentation, which resulted in his nickname "mrdocs" in IRC and elsewhere. Until recently, and despite his detoriating health, Peter continued to be involved in building and releasing new Scribus versions. Scribus was the project he helped to set on track and which marked the beginning of his journey into the world of Free Software development. While it remained at the heart of his commitments to Open Source in general and Libre Graphics software in particular, Peter contributed to Free Software in many other ways as well. For example via contributions to projects related to freedesktop.org, as a package builder of many Free programs for several Linux distributions on the openSUSE Build Service, and later as an openSUSE board member. Peter was also crucial in bringing the Libre Graphics community together by way of sharing his expertise with other graphics-oriented projects and his assistance in organzing the first Libre Graphics Meetings. In the sometimes ego-driven and often emotional world of Open Source development, Peter managed to get along very well with almost everybody and never lost his sense of humour. We will remember Peter "mrdocs" Linnell for what he was: an optimist, an incredible team player, an honest man and, above all, a friend. Our thoughts are with his family. March 2019, The Scribus Team

4 3

Potential GSOC student: Contributing into InkScape
by Shavez Malick 21 Mar '19

21 Mar '19

Hi Inkscape! I am Shavez, a sophomore @IIT Indore. I really liked InkScape when I first used it. I am seeking participation in GSOC 2019. I have chosen InkScape as my org to contribute. I had my mid-term exams over the month of March, :( They went well, though :). I have cloned your repo and will be pushing couple of patches soon. I have fairly good exposure to programming, I participated in many coding-related events till now. I will really appreciate any suggestions related to this.

1 0

Re: [Inkscape-devel] LGM/Saarbrücken Hackfest
by Maren Hachmann 20 Mar '19

20 Mar '19

Okay, thanks you for your replies, Jabier, Marc, Mihaela, Thomas and Tav! (and for updating the Wiki page already :) ) I'll confirm the dates, and will include Thomas in the email, so he and Aude can contact each other for the signing/key arrangements. --------------------- Everyone: Next, it would be good if everyone interested in joining could put their name into the list of 'unconfirmed but likely attendees' on the Wiki: http://wiki.inkscape.org/wiki/index.php/Hackfest2019_Saarbr%C3%BCcken_Atten… This is so the board can arrange a vote for funding, as SFC requires us to give them the attendees' names in advance. If you want to join, but do not need or want project funding, please indicate this in the Wiki. If you already have decided *when* you want to be there, please include that info. It is helpful in determining how many people will be there at k8's office. Thanks! Maren Am 19.03.19 um 23:30 schrieb Marker: > Great Maren thanks for the call and for the write up. > > I think Q1 is perfect dates, realy not sure when I attend jet... > > > On Tue, 2019-03-19 at 23:15 +0100, Maren Hachmann wrote: >> Hi Inkscapers, >> >> today, I phoned Aude Poilroux, project manager working at k8, who had >> offered to help us with getting a space for the planned Hackfest >> before LGM. >> >> k8.design (Institut für strategische Ästhetik) >> ---------------------------------------------- >> >> A non-profit company (gGmbH) owned by the Saarbrücken arts >> university. >> They do work on organizing events, art cooperations, digital >> transformation, supporting and executing projects that originated in >> the >> university, and many other things that the university itself isn't >> allowed to do, because it's an educational institution, and not a >> business. Their offices are at Keplerstr. 3-5 in Saarbrücken. >> >> Meeting space >> ------------- >> >> Aude is offering us a part of k8's open-plan office for May 27th, >> 28th >> and 29th. The part is usually used as sitting area, but they want to >> put >> some additional chairs and tables in. She says the place can hold up >> to >> 20 persons (but then it will be a bit cramped). There is another >> adjacent office, that can hold about 10 persons, but it may not be >> available all the time. We could use it for discussing stuff, while >> working can be done in the larger room. I forgot to ask about >> whiteboard/blackboard/projector/flip chart or similar. There are lots >> of >> electricity outlets, but we might need to bring some German multiple >> socket outlets. They have WiFi. I'm not sure about wired LAN, but she >> says the internet connection is broad band and very fast. >> >> We could use the space from ~ 9:00 in the morning, and if we can name >> one responsible person, she is considering to give us a key, so we >> can >> stay as long as we need. >> >> There is no canteen, and no organized meals. However, the venue is >> located in a pedestrian zone with multiple places where one can buy >> food >> close by. One of them is a wholefood shop, which offers meals at >> reasonable prices. There are also a couple of bakeries, and then >> there's >> a microwave in the office. >> >> She is asking us to let her know the rough number of attendees by mid >> May. We would then also need to name a responsible person, who would >> need to sign for the group, and would guarantee for us not wreaking >> havoc in their offices. >> >> On the 29th, there will be an additional event called "From Code to >> Community", starting around midday, where local (as in ~ 100km >> radius) >> businesses and open source projects are meant to meet. The program >> isn't >> ready to be published yet, but it is planned that there will be >> keynotes >> by politicians and people from FSFE, talks about open source business >> applications, talks about open culture, a workshop on collaboration >> culture, booths from various open source projects (educational, LUGs, >> mapping, MSF, framasoft). The event is meant to attract students and >> businesses. It's going to take place in the same building where, at >> 18:00, the opening of LGM will take place. >> >> Aude is asking us if we would be able to staff a booth there, to >> present >> Inkscape to students and small businesses. The event is mostly in >> German, but people from Luxembourg and France are invited to attend >> too, >> so it might be useful to also have one of our French-speaking >> community >> members there. >> >> During LGM, they seem to have more rooms available than there will be >> conference tracks, so she says it should be possible to have a >> collaboration space for Inkscape. However, we probably won't be able >> to >> have the same place continuously, and we would have to ask when we >> need >> it. There is also plenty of sitting space available on the venue that >> is >> not in a separate room. >> >> >> So Q1: >> Shall I confirm the dates as written above? >> >> Q2: >> Would someone be interested in presenting Inkscape to local people >> before LGM on Wednesday? (I would be) >> >> And Q3: >> Is there anyone volunteering to be the one who holds the key (if we >> get >> one) and to sign the agreement? I will probably not stay late, so I'd >> like that to be someone else. >> >> It's probably not a problem to translate things to English, but >> someone >> from Germany would be preferred for this. >> >> Thanks! >> >> Please let me know what you think about Q1-Q3 quickly :) >> >> Maren >> >> >> _______________________________________________ >> Inkscape-devel mailing list >> Inkscape-devel(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/inkscape-devel > >

1 0

rules and guidelines for new forum - first draft
by brynn 19 Mar '19

19 Mar '19

Hi Friends, As it turned out, only me and a couple of other people were interested in drafting the rules and guidelines for the new forum. So we can get more eyes on it, and possibly more professional opinions about it, I'd like to ask the community to have a look at it. I have no background in writing such documents, so it's purely a layperson's whack at it. I feel quite confident about the contents, based on my years of experience in Inkscape forums. But the format of the document, and possibly some of the language might need some technical advice. So any an all comments and suggestions about the format or language are very welcome. https://gitlab.com/inkscape/vectors/content/blob/master/articles/Forum%20Ru… (I've left it locked to editing, so everyone sees the same doc, for this first review. Then I'll unlock it afterwards.) Thank you very much, brynn PS - I'm also posting about this in the forums.

3 8

Re: [Inkscape-devel] [Inkscape-user] Fundrasing for FOSS Projects - meetup this saturday
by unknown＠example.com 19 Mar '19

19 Mar '19

On Sun, 2019-03-17 at 13:47 -0700, Andrew Kurn wrote: > Why does Inkscape need money? The low budget requirements are for things like hackfest travel, hotels, stickers, posters, hardware, DNS, trademark registration, legal defense, (and then accountancy because of said needs for money). Depending on the source of money, there can be lots of things Inkscape could do with a good budget. We've been using money for a long time now. > Can you give some idea of how much we spend each year and how > much we take in? Doesn't need to be a full income statement, > but hit the high points. Bryce publishes an account each year. I think he'll be happy to post it again here. Best Regards, Martin Owens

2 1

Watch Parties - starting Mar 16th
by Bryce Harrington 16 Mar '19

16 Mar '19

Topic: Fundraising for FOSS Projects When: Sat, Mar 16th 19:00 UTC to 21:00 UTC Where: chat.inkscape.org in channel #collaboration_space This Saturday, Michèle and I will be watching and discussing a series of videos on fundraising for open source projects. Afterwards, we can bounce ideas around for how to improve Inkscape's funding. Please join us, we'd love the company. :-) For links to the videos, and some tentative plans for future topics for Watch Parties, please see: http://wiki.inkscape.org/wiki/index.php/Inkscape_Classes Bryce

1 1

Bug management for inkscape/inkscape
by Patrick Storz 14 Mar '19

14 Mar '19

Hi all, it seems the message of our move of issue tracking to GitLab is slowly spreading and we're seeing a steady flow of new reports in our inkscape/inkscape issue tracker on Gitlab (https://gitlab.com/inkscape/inkscape/issues). As most of us had the opportunity to get some first-hand experience with the new issue tracking by now and with the amount of bugs still being manageable, it seems to be a good time to discuss and decide on some guidelines for this tracker, so we can make most efficient use of it. Having worked with the tracker fo some time here's my list of items (in no particular order) that I feel need attention. Please add to it as needed and most importantly discuss, so we can find solutions that work well for all of us. (We can obviously break individual topics out into GitLab issues eventually, once we have set a rough direction). * *Milestones:* On Launchpad (LP) we used Milestones for targeting bugs (only occasionally, though) but more importantly for tracking in which release a fix landed. The latter seems of particular importance, as release notes rely on it heavily. I suggest to continue this practice and expand it to merge requests. However this requires us all to make sure to actually set milestones properly. Currently we often just close bugs without giving it further thought (GitLab even does that automatically for us if a suitable commit message is used), which would make it almost impossible to keep track of the issues fixed in a particular release. Even more so for MRs... * *Importance:* I feel that we need some mechanism to prioritize bugs. What is your take on creating a set of prioritized labels of the form "Importance: High" to replace LPs importance field? I propose to use "Critical -> High -> Medium -> Low". Even above critical I'd put the already existing label "Blocker". At the end of the list I'd rank "Feature request". Does this sound reasonable? Or is it too fine grained? Is handling "Blocker" and "Feature request" as additional importance labels fine or should they be separate? * *Labels: * o A general question is what labels we want to apply and how many there should be. I'm a bit torn here, as a short list makes it easier to keep track of the existing labels and avoids similar issues being tagged differently, especially if there are multiple similar choices or one tag is a sub/superset of another. A longer list would help us categorize issues better though. (For example: Do we want a tag for every packaging option we have, e.g. AppImage, Flatpak, msi, exe, Windows Store, ...? Do we want a tag for every Linux distribution or just a single "Linux" tag?). o Another question is if we want to categorize them (e.g. "OS/Linux", "OS/Windows", "OS/Mac") or if we strip the category? The former ensures similar tags are sorted together (otherwise they're sorted alphabetically) and *if* one remembers the category name it makes it easy to get all relevant tags by simply typing "OS", but then again tagging with just "Windows" seems more natural and the category might add noise. Also it obviously requires some thought in order to create useful categories (in contrast to just applying "random" tags that fit and creating new ones on-the-fly). As I'm somebody who likes order I tend to prefer categorization, but this is something I'd like your opinion on. (Important note: The search is clever enough to give you "OS/Windows" if you search for "win"). * *Status *On LP we had a detailed status field (new, confirmed, triaged, in progress, fix commited, fix released - also: incomplete, opinion, invalid, won't fix). Which of those do we want to replicate in GitLab (and how?). We could obviously create a label for each of them, but I have a feeling without a dedicated field it'd not be used consistently. One idea: o "new/confirmed" should be covered by "inkscape/inkscape" vs "inkscape/inbox". Only confirmed issues should ever end up in "inkscape/inkscape" (everything else should be confirmed or moved to the inbox for triaging). o "triaged" would be replaced by the presence (or absence) of an "Importance:" label should we choose to use them. o "in progress": We already have a corresponding label and could use it. Alternatively we could define that all assigned bugs are "in progress" (i.e. only assign bugs if the assignee is going to work on them eventually; un-assign otherwise) o "fix commited/fix released": I don't know how to replicate this reasonably. Is it even required? o "incomplete": We have "Need info" but such bugs should usually not be kept in "inkscape/inkscape" for extended periods of time (if the info is not given, close or move back to "inbox") o "opinion": should never exist in "inkscape/inkscape" o "invalid": Do we need a label? Or shall we just close in this case and forget about it? o "won't fix": should usually not make it into "inkscape/inkscape" - do we want a label or shall we just close (i.e. same question as as for invalid?) * *Assignee* As suggested above we could use the assignee field to put devs who are going to work on an issue eventually (i.e. indicate "this issue is being looked into / will be looked into shortly"). Alternatively we could use it to indicate devs who are likely to be able to fix the issue and are most suited for detailed triaging and further investigation (i.e. indicate "we know somebody who might be able to help, please wait until they find the time to check"). This could be used to distribute and direct the workload a bit. However we can likely do that with simple @mentioning? Sorry for the long text (I hope you all read up to this ;-)), it certainly got longer than intended... I'm looking forward to your opinions, though! Cheers Patrick

6 20

Wiki account request
by Ryan Jarvis 13 Mar '19

13 Mar '19

Hello, I've been helping on the inkscape extension front and would like access to the wiki to edit some of the related pages. Thanks!

2 2