Hi all!
Last weekend, I attended the GSoC mentor summit which had a great variety of very interesting people and sessions, I'm just going to summarize my thoughts about some of the most interesting sessions and discussions. Some are mostly board-related, but most can be of interest to the whole contributors community.
ToC: * Diversity * Fuzzing * Version numbers * Gitlab : self-hosting & independence * Bug management * GCI * Funding
I started writing all this in a single email, but for clarity, I'm just going to answer this email with an email for every individual topic, allowing to thread it nicely on email clients and keep all threads on mostly one topic.
The vast majority of our contributors (especially our code contributors since we have a bit more diversity in the helping/doc/website part) are, to put it mildly, not very representative of the diversity of the world's population. In one of the sessions, Karen Sandler presented Outreachyhttps://www.outreachy.org/, a sister project within the SFC, whose goal is to provide internships very similar to GSoC, but for groups underrepresented in tech (with the notable differences that mentees can be non-students and can work on non-code projects). The main requirement to /enter/ this program (apart from the requirements we already match, be an opensource program, etc) is that to show dedication to the idea of increasing diversity, we have to provide ourselves the funding for the first student, which is $6500 (5500 for the student, 500 for travel, 500 for outreachy, iirc). From this first student on, we'll be "in" and outreachy's sponsors help outreachy make it work more like gsoc (paying the students working on projects)
I propose that we try to enter that program starting next year to try to build up a more diverse dev community.
Hi Marc Jeanmougin,
I haven't been involved in Inkscape development for a long time, so feel free to ignore my answer at will. I'm here merely as a curious external figure.
2017-10-20 19:52 GMT-03:00 Marc Jeanmougin <marc@...3062...>:
The main requirement to /enter/ this program (apart from the requirements we already match, be an opensource program, etc) is that to show dedication to the idea of increasing diversity
So, I'm specially concerned about this part.
What does it mean to embrace diversity? In my dictionary, it is to give (i.e. to empower it) the individual — this post-larval insectoid species of ours — the (often forgotten) liberty to let them create their own worlds, their own realities (freed from the dominant culture that governed them until Hir adolescent age). I find hard to imagine anyone who would challenge this notion, as the opposite is logically unreachable (power all from above dictating what their insectoid properties must be and do... and still... do it differently from EachOther... refusing to take the orders just received... thinking for Thy Selfs and questioning darefullingly authority) and anti-CommonSense.
I grew up passionate with this idea of free software since I knew it. It was very natural for me to keep an eye on several communities gathered around these centers. And you see, Inkscape is one of the most embracing communities I've stumbled upon. Always very help-ful and dedicating generous time (that is theirs to do what they want, not ours) to baby-step any foreign New-Comer to find a place in our community where this temporary New-Comer could become a (semi-)permanent Citizen free to get Hirself entangled in endless spaghetti lines of source code, translating the most alien concepts into Hir native language or find Hir own other ways to engage in this diverse project of ours (but always with good company and chat on Hir side).
So, you see... I feel uneasy about your need to /emphasize/ our commitment To The Cause (never to the so-forgotten Individual). Why do you need to be so emphatic? Are you already predicting further demands from the power all above To The Cause at a later time? I feel particularly uneasy because, like I said, Inkscape is one of the more inviting communities I've stumbled upon, and then you come here to offer some seductive money (*)
(*) given we show some appreciation To The Cause, of course
To think of it — I beg your pardon — but it is so funnily incoherent that I cannot help Myself but laugh. You suggest that our demographics are on par with bigotry and racism, /especially on code/, but then offer some money to allocate people to work on projects that can be code-unrelated? You offer us nothing — it is what you're saying. The project is just the same with or without you.
Now, with the incoherence put aside...
How can we be sure that you're not (not-knowingly) involved in money-laundry from governmental institutions? I mean, by now it's pretty clear that the people who will receive the payment will not be creating relevant commits to our notable Inkscape. Also clear is that /all/ involved with this scheme are /very/ committed To The Cause. This seems like a good way to laundry money mucking the name that the Inkscape community dedicated so many years to make. I just can't take such proposal seriously (it's so funny).
In summary, you came here all-authoritative with the following commandments:
1. Hey guys, you all are too racist, /to put it mildly/ 2. But don't worry folks, because I brought The Solution. 3. After you accept me in your boat, the racism will go away, vanish, done. Capisce? 4. Also, I ask for a vow of loyalty and obedience. You must be faithful To The Cause (never to the Individual). We — I don't mean you, of course — may ask for a few little favours in the future, after all (but don't worry, it's very unlikely, just a formality). 5. Also, nothing I offered will actually do any changes to the problems I just attacked in this very first approach. So I expect to dominate you at long-term by exploiting your guilty (you don't dare to be Anti-Diversity, do you?).
Did I get it right? Would you put an end to my curiosity (as an external figure)? It's just... funny!
Dear Vinícius,
On Fri, 2017-10-20 at 22:44 -0300, Vinícius dos Santos Oliveira wrote:
Did I get it right?
No.
Would you put an end to my curiosity (as an external figure)?
Your assumption is that the meeting Marc attended was talking about our own institutional behaviour, but it's not. We could be perfect in how we handle contributors and still end up with a lack of diversity. Because most of the issue after you've got a strong code of conduct is inherited.
The Inkscape community inherits from the wider world some of the inherent biases in our contributor mix. We can't change the feed-in mix very much because they have all sorts of reasons from national policies to social stratification to global technological reach.
But one thing that can be done is extend extra help to people who /could/ be contributors by being proactive. But that will need deep thought into what exactly we'd be looking for as a community and how exactly to go about a pro-active invitation scheme.
I have no answers for that.
Best Regards, Martin Owens
I'd like to suggest that we start by banning Vinicius dos Santos Oliveira < vini.ipsmaker@...400...> from this mailing list. He clearly is a troll willing to put all necessary effort to make a true hell of any effort at improving diversity.
2017-10-20 23:44 GMT-02:00 Vinícius dos Santos Oliveira < vini.ipsmaker@...400...>:
Hi Marc Jeanmougin,
I haven't been involved in Inkscape development for a long time, so feel free to ignore my answer at will. I'm here merely as a curious external figure.
2017-10-20 19:52 GMT-03:00 Marc Jeanmougin <marc@...3062...>:
The main requirement to /enter/ this program (apart from the requirements we already match, be an opensource program, etc) is that to show dedication to the idea of increasing diversity
So, I'm specially concerned about this part.
What does it mean to embrace diversity? In my dictionary, it is to give (i.e. to empower it) the individual — this post-larval insectoid species of ours — the (often forgotten) liberty to let them create their own worlds, their own realities (freed from the dominant culture that governed them until Hir adolescent age). I find hard to imagine anyone who would challenge this notion, as the opposite is logically unreachable (power all from above dictating what their insectoid properties must be and do... and still... do it differently from EachOther... refusing to take the orders just received... thinking for Thy Selfs and questioning darefullingly authority) and anti-CommonSense.
I grew up passionate with this idea of free software since I knew it. It was very natural for me to keep an eye on several communities gathered around these centers. And you see, Inkscape is one of the most embracing communities I've stumbled upon. Always very help-ful and dedicating generous time (that is theirs to do what they want, not ours) to baby-step any foreign New-Comer to find a place in our community where this temporary New-Comer could become a (semi-)permanent Citizen free to get Hirself entangled in endless spaghetti lines of source code, translating the most alien concepts into Hir native language or find Hir own other ways to engage in this diverse project of ours (but always with good company and chat on Hir side).
So, you see... I feel uneasy about your need to /emphasize/ our commitment To The Cause (never to the so-forgotten Individual). Why do you need to be so emphatic? Are you already predicting further demands from the power all above To The Cause at a later time? I feel particularly uneasy because, like I said, Inkscape is one of the more inviting communities I've stumbled upon, and then you come here to offer some seductive money (*)
(*) given we show some appreciation To The Cause, of course
To think of it — I beg your pardon — but it is so funnily incoherent that I cannot help Myself but laugh. You suggest that our demographics are on par with bigotry and racism, /especially on code/, but then offer some money to allocate people to work on projects that can be code-unrelated? You offer us nothing — it is what you're saying. The project is just the same with or without you.
Now, with the incoherence put aside...
How can we be sure that you're not (not-knowingly) involved in money-laundry from governmental institutions? I mean, by now it's pretty clear that the people who will receive the payment will not be creating relevant commits to our notable Inkscape. Also clear is that /all/ involved with this scheme are /very/ committed To The Cause. This seems like a good way to laundry money mucking the name that the Inkscape community dedicated so many years to make. I just can't take such proposal seriously (it's so funny).
In summary, you came here all-authoritative with the following commandments:
- Hey guys, you all are too racist, /to put it mildly/
- But don't worry folks, because I brought The Solution.
- After you accept me in your boat, the racism will go away, vanish,
done. Capisce? 4. Also, I ask for a vow of loyalty and obedience. You must be faithful To The Cause (never to the Individual). We — I don't mean you, of course — may ask for a few little favours in the future, after all (but don't worry, it's very unlikely, just a formality). 5. Also, nothing I offered will actually do any changes to the problems I just attacked in this very first approach. So I expect to dominate you at long-term by exploiting your guilty (you don't dare to be Anti-Diversity, do you?).
Did I get it right? Would you put an end to my curiosity (as an external figure)? It's just... funny!
-- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/
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
Hey Inkscape developers, and those otherwho are on the mailing list,
Ok, I am utterly lost here. What does diversity have anything to do with Inkscape development? And second of all, ain't skills is what is relevant at Inkscape development? Orientation, skin color, and so on does not matter at all to the development of Inkscape. And third of all, is there any proof that someone here care so much about irrelevant aspect of a individual? And last of all, can we not bring politics here?
On 10/21/2017 8:56 AM, Felipe Sanches wrote: I'd like to suggest that we start by banning Vinicius dos Santos Oliveira <vini.ipsmaker@...400...mailto:vini.ipsmaker@...400...> from this mailing list. He clearly is a troll willing to put all necessary effort to make a true hell of any effort at improving diversity.
2017-10-20 23:44 GMT-02:00 Vinícius dos Santos Oliveira <vini.ipsmaker@...400...mailto:vini.ipsmaker@...400...>: Hi Marc Jeanmougin,
I haven't been involved in Inkscape development for a long time, so feel free to ignore my answer at will. I'm here merely as a curious external figure.
2017-10-20 19:52 GMT-03:00 Marc Jeanmougin <marc@...3062...mailto:marc@...3062...>: The main requirement to /enter/ this program (apart from the requirements we already match, be an opensource program, etc) is that to show dedication to the idea of increasing diversity
So, I'm specially concerned about this part.
What does it mean to embrace diversity? In my dictionary, it is to give (i.e. to empower it) the individual — this post-larval insectoid species of ours — the (often forgotten) liberty to let them create their own worlds, their own realities (freed from the dominant culture that governed them until Hir adolescent age). I find hard to imagine anyone who would challenge this notion, as the opposite is logically unreachable (power all from above dictating what their insectoid properties must be and do... and still... do it differently from EachOther... refusing to take the orders just received... thinking for Thy Selfs and questioning darefullingly authority) and anti-CommonSense.
I grew up passionate with this idea of free software since I knew it. It was very natural for me to keep an eye on several communities gathered around these centers. And you see, Inkscape is one of the most embracing communities I've stumbled upon. Always very help-ful and dedicating generous time (that is theirs to do what they want, not ours) to baby-step any foreign New-Comer to find a place in our community where this temporary New-Comer could become a (semi-)permanent Citizen free to get Hirself entangled in endless spaghetti lines of source code, translating the most alien concepts into Hir native language or find Hir own other ways to engage in this diverse project of ours (but always with good company and chat on Hir side).
So, you see... I feel uneasy about your need to /emphasize/ our commitment To The Cause (never to the so-forgotten Individual). Why do you need to be so emphatic? Are you already predicting further demands from the power all above To The Cause at a later time? I feel particularly uneasy because, like I said, Inkscape is one of the more inviting communities I've stumbled upon, and then you come here to offer some seductive money (*)
(*) given we show some appreciation To The Cause, of course
To think of it — I beg your pardon — but it is so funnily incoherent that I cannot help Myself but laugh. You suggest that our demographics are on par with bigotry and racism, /especially on code/, but then offer some money to allocate people to work on projects that can be code-unrelated? You offer us nothing — it is what you're saying. The project is just the same with or without you.
Now, with the incoherence put aside...
How can we be sure that you're not (not-knowingly) involved in money-laundry from governmental institutions? I mean, by now it's pretty clear that the people who will receive the payment will not be creating relevant commits to our notable Inkscape. Also clear is that /all/ involved with this scheme are /very/ committed To The Cause. This seems like a good way to laundry money mucking the name that the Inkscape community dedicated so many years to make. I just can't take such proposal seriously (it's so funny).
In summary, you came here all-authoritative with the following commandments:
1. Hey guys, you all are too racist, /to put it mildly/ 2. But don't worry folks, because I brought The Solution. 3. After you accept me in your boat, the racism will go away, vanish, done. Capisce? 4. Also, I ask for a vow of loyalty and obedience. You must be faithful To The Cause (never to the Individual). We — I don't mean you, of course — may ask for a few little favours in the future, after all (but don't worry, it's very unlikely, just a formality). 5. Also, nothing I offered will actually do any changes to the problems I just attacked in this very first approach. So I expect to dominate you at long-term by exploiting your guilty (you don't dare to be Anti-Diversity, do you?).
Did I get it right? Would you put an end to my curiosity (as an external figure)? It's just... funny!
-- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/
------------------------------------------------------------------------------ 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.netmailto: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.netmailto:Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi,
This subject has been discussed at the two hackfests of 2016 and 2017. The fact that we want to strive for a more inclusive and diverse community is not up for debate.
This is not just about code, but about development: we need to keep an open and welcoming environment to attract new contributors, and diversity helps a lot to build a healthy community.
This discussion is not about *whether* but *how* to build a more diverse/inclusive community. I mention this program for comments because it was mentioned at the summit, but if you know of similar initiatives, please share them.
If there is a problem with diversity here and it seem so as Vinicius seem to take a issue with us, then maybe we could make it more obvious that we do accept people of all kinds, and as a matter of fact, you can add me as a example. I'm a post-heterosexual asexual person, and I been asexual since I was about 16 years old, and I'm going to be 24 this year. How do we make it obvious though? I do prefer it if we weren't involved in politics, and the last thing Inkscape needs is to be political, but it's inevitable I guess.
On 10/21/2017 11:41 AM, Marc Jeanmougin wrote:
Hi,
This subject has been discussed at the two hackfests of 2016 and 2017. The fact that we want to strive for a more inclusive and diverse community is not up for debate.
This is not just about code, but about development: we need to keep an open and welcoming environment to attract new contributors, and diversity helps a lot to build a healthy community.
This discussion is not about *whether* but *how* to build a more diverse/inclusive community. I mention this program for comments because it was mentioned at the summit, but if you know of similar initiatives, please share them.
------------------------------------------------------------------------------ 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.netmailto:Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Let's remember first and foremost to keep discussions civil.
Just as we have diversity in nationalities, genders, and cultures we have diversity in viewpoints and beliefs. Diversity in and of itself is apolitical; politics only enters in if we bring it. If we find areas of disagreement, we should first view those as opportunities to learn and educate.
Mc's right that fostering diversity has been a long standing goal in Inkscape, and has come up repeatedly at hackfests. It's one of the reasons why we've given strong attention to internationalization, why we've embraced programs like GSoC that attract students from diverse places in the world, why we put strong importance on establishing the Code of Conduct, and why we strive to recognize the importance of a wide breadth of contribution types beyond just coding. We are far, far stronger as an organization the more diverse we are, and putting attention on improving diversity today will make us stronger tomorrow.
I'd like to also emphasize Marc's position that we need to strive to keep our community open and friendly, and a place that people feel safe and welcome. I think we've done well at this to date, but such an environment needs continual attention to keep it well maintained and avoid losing it. I'm certain there's far more we could do.
I love the work Karen has been doing in this area, and while I don't yet know if this particular program makes sense for Inkscape or not, I strongly encourage us to look into it and other similar projects that might help us. Others in this thread have, I believe, striven to make the point that ultimately inclusiveness must come from the fabric of our community, and is not something that really can or should be imposed from outside. So we must merely look at external programs as tools rather than solutions, and judge if they are the right tool for the job we need done.
I'm very glad to see the discussion around this topic, let's be sure to keep the discussions respectful and constructive.
Bryce
On Sat, Oct 21, 2017 at 05:41:58PM +0200, Marc Jeanmougin wrote:
Hi,
This subject has been discussed at the two hackfests of 2016 and 2017. The fact that we want to strive for a more inclusive and diverse community is not up for debate.
This is not just about code, but about development: we need to keep an open and welcoming environment to attract new contributors, and diversity helps a lot to build a healthy community.
This discussion is not about *whether* but *how* to build a more diverse/inclusive community. I mention this program for comments because it was mentioned at the summit, but if you know of similar initiatives, please share them.
-- Mc
On 10/21/2017 04:26 PM, Miguel Lopez wrote:
Hey Inkscape developers, and those otherwho are on the mailing list,
Ok, I am utterly lost here. What does diversity have anything to do with Inkscape development? And second of all, ain't skills is what is relevant at Inkscape development? Orientation, skin color, and so on does not matter at all to the development of Inkscape. And third of all, is there any proof that someone here care so much about irrelevant aspect of a individual? And last of all, can we not bring politics here?
-----BEGIN PGP SIGNATURE-----
iF0EARECAB0WIQR06NoTmAVagSCydutfyyBO+IKwegUCWetq0QAKCRBfyyBO+IKw eiYUAJwPqAND+l9jCYr5IshGVFC7LwjeXACfXqjLjjI72OoFh99tNoE5y5Wy0B4= =hWuf -----END PGP SIGNATURE-----
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
Some suggestions:
Recommend the facebook page and group to get people more active.
Let them know that the Vectors can always use help.
Identify other successful non profit organizations and ask them how they increased diversity.
Measure the diversity now, and every 3 month hereafter.
Thanks,
Robert Sterbal robert@...3541... 412-977-3526 call/text
On 10/21/2017 11:41 AM, Marc Jeanmougin wrote:
Hi,
This subject has been discussed at the two hackfests of 2016 and 2017. The fact that we want to strive for a more inclusive and diverse community is not up for debate.
This is not just about code, but about development: we need to keep an open and welcoming environment to attract new contributors, and diversity helps a lot to build a healthy community.
This discussion is not about *whether* but *how* to build a more diverse/inclusive community. I mention this program for comments because it was mentioned at the summit, but if you know of similar initiatives, please share them.
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
This email has been checked for viruses by AVG. http://www.avg.com
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Remember that diversity is also extremely important on a purely practical level - it's not just a hippy moralistic crusade.
We want to make a product that is as attractive and welcoming to its diverse user base as possible. As such, it's important to have a comparably diverse developers team to help avoid the accidental biases that can creep in... i.e., stuff that is fun, or utterly irrelevant to a straight, white male, but might make a user from a different demographic feel unwelcome.
Some examples of easy, inclusive things we can do, that hopefully won't cause too much rage to Bro-flakes:
* Have a "community month" on our Social media - ask for people to share their artwork celebrating human diversity, and prominently advertise our pages on how to contribute to the project.
* Use the best quality submissions to make the gallery on our project website more representative.
* Have the next About Page competition along the same theme - prompt people to share the competition brief among Social Media community groups representing wider diversity.
* Be proactive about accessibility issues: put out a call to users to report their main issues with the UI. There are probably hundreds of tiny, easily-fixable issues that we haven't noticed, that make Inkscape harder for users with visual/mobility/learning difficulties to use.
* Similarly - have a translations drive. There are many very committed translators, but we can still do better.
In principle, I'm happy with the Outreachy idea - obviously, it would need some careful assessment of our budget.
AV
On 21 October 2017 at 20:25, Robert Sterbal <rsterbal@...714...> wrote:
Some suggestions:
Recommend the facebook page and group to get people more active.
Let them know that the Vectors can always use help.
Identify other successful non profit organizations and ask them how they increased diversity.
Measure the diversity now, and every 3 month hereafter.
Thanks,
Robert Sterbal robert@...3541... 412-977-3526 call/text
On 10/21/2017 11:41 AM, Marc Jeanmougin wrote:
Hi,
This subject has been discussed at the two hackfests of 2016 and 2017. The fact that we want to strive for a more inclusive and diverse community is not up for debate.
This is not just about code, but about development: we need to keep an open and welcoming environment to attract new contributors, and diversity helps a lot to build a healthy community.
This discussion is not about *whether* but *how* to build a more diverse/inclusive community. I mention this program for comments because it was mentioned at the summit, but if you know of similar initiatives, please share them.
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
This email has been checked for viruses by AVG.http://www.avg.com
Inkscape-devel mailing listInkscape-devel@...1901...://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
Google presented a fuzzing tool named "oss-fuzz"https://github.com/google/oss-fuzz that they already tested on high-profile OSS like crypto libraries or libxml2, and are now opening to all serious open source projects. It builds up on continuous integration and tries to craft testing files to test as many code paths as possible. We could use it to detect when files makes Inkscape crash on start, for instance (or for other purpose like testing how robust our css or .gpl "parsers" are, I'll let it to devs/testers creativity)
NB: Above "for instance" is actually a good example: just today, someone came to IRC with a file that made Inkscape crash, and I simplified it to https://paste.fulltxt.net/I9,7M1hCFkPmSBV which is the sort of bug a fuzzer is *designed* to detect (I suspected such bugs were possible when they presented it, but today's IRC conversation made it a really perfect example).
In the non-UNIX world, versions 0.something is usually associated with "beta". If we manage to have a really stable 0.93 (say, as stable as 0.48.5 and as fast as it), with few regressions, an easily css-customizable UI on windows that also would look right on 4k screens, and ideally also works nicely on macs, it might be worth it to call our 0.93.1 … "1.0" (Yeah, I listed all the main challenges I can think of)
On Sat, Oct 21, 2017 at 12:52:46AM +0200, Marc Jeanmougin wrote:
In the non-UNIX world, versions 0.something is usually associated with "beta". If we manage to have a really stable 0.93 (say, as stable as 0.48.5 and as fast as it), with few regressions, an easily css-customizable UI on windows that also would look right on 4k screens, and ideally also works nicely on macs, it might be worth it to call our 0.93.1 … "1.0" (Yeah, I listed all the main challenges I can think of)
Certainly, and in fact that's the plan -- that's why we jumped numbers from 0.48 up to 0.9x. Intent has been to get to 1.00 "soonish".
The question is what precisely needs to be achieved, and when we first discussed it, the list was pretty daunting. However the good news is we've checked off a bunch of the items... gtest, cmake, git/gitlab, gtk3, and so on.
There's still work to get the gtk3 changes looking and working properly, and I'm hoping Tav can build us a good todo list for what should be focused on for 0.93 (and maybe 0.94?)
You mention stability and elimination of regressions, which likely is going to be a big expectation to deliver for a 1.00 release, and so should be given lots of attention. I wish I had a better handle on the size and scope of this work; I worry it could be overwhelmingly huge. Maybe worth making a prioritized list. I suppose it depends a lot on how much devel power we have available for working on the bugs (and how we can augment it).
At some point we'll want to taper down on feature development work, to avoid introducing new regressions. That'll be hard because new features are always exciting and the pressure to include them is very strong. Refactoring and architectural adjustment work can also be potential sources of regressions.
Bryce
Bryce,
We could road map this to create an expected structure.
Get 0.93 out the door with Gtk3 and all the problems that are likely caused by it
Immediately state the next release will be 1.0, no 0.94 hedging release.
Then we operate 0.93 to 1.0 like a super long freeze with bug fixes and regression testing and maybe a few non-feature improvements.
But this kind of thing is a matter for leadership and that may fall on yourself or who ever wants to be commander in the batter for the 1.0 release.
Best Regards, Martin Owens
On Fri, 2017-10-20 at 23:08 -0700, Bryce Harrington wrote:
On Sat, Oct 21, 2017 at 12:52:46AM +0200, Marc Jeanmougin wrote:
In the non-UNIX world, versions 0.something is usually associated with "beta". If we manage to have a really stable 0.93 (say, as stable as 0.48.5 and as fast as it), with few regressions, an easily css-customizable UI on windows that also would look right on 4k screens, and ideally also works nicely on macs, it might be worth it to call our 0.93.1 … "1.0" (Yeah, I listed all the main challenges I can think of)
Certainly, and in fact that's the plan -- that's why we jumped numbers from 0.48 up to 0.9x. Intent has been to get to 1.00 "soonish".
The question is what precisely needs to be achieved, and when we first discussed it, the list was pretty daunting. However the good news is we've checked off a bunch of the items... gtest, cmake, git/gitlab, gtk3, and so on.
There's still work to get the gtk3 changes looking and working properly, and I'm hoping Tav can build us a good todo list for what should be focused on for 0.93 (and maybe 0.94?)
You mention stability and elimination of regressions, which likely is going to be a big expectation to deliver for a 1.00 release, and so should be given lots of attention. I wish I had a better handle on the size and scope of this work; I worry it could be overwhelmingly huge. Maybe worth making a prioritized list. I suppose it depends a lot on how much devel power we have available for working on the bugs (and how we can augment it).
At some point we'll want to taper down on feature development work, to avoid introducing new regressions. That'll be hard because new features are always exciting and the pressure to include them is very strong. Refactoring and architectural adjustment work can also be potential sources of regressions.
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
One of the problems raised in a session was that of dependency on big platforms: the open source ecosystem in general is fond of decentralizing and hacking in general, yet relies heavily, for reasons like visibility/resume/portfolio/comfort/ease, on github[1]. Yet, self-hosting instances has a non-negligible cost (if only in terms of maintenance and administration) so it's mostly up to each project to decide if he "can" self-host (for instance, gnome probably has enough resources, and hosts its gitlab). I think staying on gitlab.com is sort of a good compromise for us: on one hand we can benefit from not having to maintain infrastructure, and we can use the ee version, and we have the shared runners available, and we are not on a platform as closed as github, on the other hand sourceforge-like problems (while "locked on a platform") are quite unlikely: as long as hosting our own gitlab is *possible*, and as long as the option to export the whole project, along with its bugtracker data, wiki, etc, is there (in other terms: as long as not only the git repo is safe, because that is already distributed, but also the development ecosystem is not locked); we are "free" (in my opinion, feel free to disagree).
/** [1]BTW, for visibility purpose, I think it would be good to actually automatically mirror the repository on github (like gnome : https://github.com/GNOME). That way, e.g. a recruiter looking at the github profile would see the Inkscape contributions listed. (Cons: Doing it for these reasons would mostly mean acknowledging the dominant position of github for open-source code, which is kind of sad) **/
== Launchpad == It is not very practical to keep our bugs to lp, for several reasons :
* The integration in both directions is non-existent : while we could, on lp, use stuff like "bzr commit --fixes lp:123456", and commit/bugs would link one to the other, and while gitlab MR and bugs can also be linked (https://docs.gitlab.com/ce/user/project/issues/closing_issues.html#via-merge...) ; using separate platforms prevents us to use either of those and forces to link manually bugs urls in MR and commit URLs in bug comments.
* It is unintuitive to new contributors. They have to subscribe on two different -- non-integrated -- platforms, with different logins (AND lp logins is more confusing since it uses "ubuntu one login")
IMO It would be very good to migrate bugs to gitlab (see below).
== Bugs management in general == During a session about "managing lots of bugs", I learned a few tricks that could be of use:
Bug management was also discussed a lot in that session and the advice that comes most is basically "when in doubt, respectfully close the issue. A user with a closed issue because of lack of details can always reopen it simply with those details, but an issue lacking information left open will drown in an ocean of issues". Migration may help us with sorting issues that have been taken care of, unreproducible ones, wishlist items, and such (see below).
A guy from Gitmate (https://gitmate.io) also talked about it and it looked interesting(also, free for OSS) : basically, automated duplicate bug detection and ability to automatically contact devs with interest in the issue (e.g. contacting one dev for issue about text, or another for crashes or problems in Selection…)
== Wishlist bugs == - Opensuse uses a different system for managing feature requests (https://features.opensuse.org/) and actual bugs. It helps them keep the discussions on a different platform, and clearly manage them with votes, discussions, different teams, tags, etc. Overall, considering the different needs for those two different uses of a bugtracker, I was rather fond of the idea. For Inkscape, since we have the option to make "templates" to fill bugs, I would be in favor of making a new inkscape sub-project in gitlab, just for feature requests. That way, we would have the possibility to have devs subscribed to the "bugs" to get the notifications about bugs well separated from feat requests, and have community members interested about features requests able to only get the discussions about them. Also, the set of tags or the default template to fill in would be very different and they would not appear on the same "list" of issues.
== Migration ==
How I would propose to go about the migration would be to basically post on every one of the 4500 open bugs on lp a closing message with an invitation to try to reproduce the bug with the devel version (maybe with a link to a page explaining how to try it [e.g. Ubuntu with apt, other linux compiling, windows with downloading the latest built 7z]) and if it can be reliably reproduced, to submit it on gitlab and close the issue on lp (or, if wishlist, submit it to the wishlist project). Distributing the task on the bug reporters may help a lot with the initial triaging, and (I'm an optimist) make for a smooth transition.
I don't have much to say on the topic in general as I'm afraid whatever we'll do with bugs will result in a big mess anyway (I'm obviously *not* an optimist but I think of myself as being realistic ;-) ).
I wanted to comment on one specific argument, though, which might not be an advantage as "obvious" as it appears on first glance:
Am 21.10.2017 um 00:53 schrieb Marc Jeanmougin:
- The integration in both directions is non-existent : while we could,
on lp, use stuff like "bzr commit --fixes lp:123456", and commit/bugs would link one to the other, and while gitlab MR and bugs can also be linked (https://docs.gitlab.com/ce/user/project/issues/closing_issues.html#via-merge...) ; using separate platforms prevents us to use either of those and forces to link manually bugs urls in MR and commit URLs in bug comments.
While such integrations are nice in principle, they are actually the source of a lot of problems:
* For example you cited Bazaar's --fixes switch. It was great while we were on bzr, but when we moved to GitLab we almost lost this information! Only by hacking the export routine we were able to save this data and migrate it. * Even with that information secured there are still a lot of commit messages simply stating "fixes bug 123456" which leaves one searching for the actual launchpad bug manually. * Luckily for launchpad a manual search is actually possible as bug numbers are global and do not depend on the project. For GitLab issues are counted per-project (and we already have several) so it might quickly become a mess if we rely on automatic linking. (Just imagine what happens if your local git client tells you issue #123 was fixed - it will be fun to find out which project this refers to and derive a bug link from that) * An this is just now! Imagine the chaos that will result if we switch our VCS again at some point (hopefully far into) the future.
With this in mind the apparent advantage from automatic linking integrations is diminished significantly (if not even negated) and for these reasons I actually want to *encourage* everybody to actively use full URLs where reasonable (especially in commit messages).
While it might be a tiny bit more work initially (most of the time the full link is available for copy/pasting though, so it really doesn't matter), it actually saves a lot of time when trying to work with that information afterwards, especially if *not* working on GitLab. This way we actually become independent from such platforms GitLab and produce helpful commit data, not only for us but also for the generations after us!
On Sat, Oct 21, 2017 at 07:58:41PM +0200, Eduard Braun wrote:
I don't have much to say on the topic in general as I'm afraid whatever we'll do with bugs will result in a big mess anyway (I'm obviously *not* an optimist but I think of myself as being realistic ;-) ).
I wanted to comment on one specific argument, though, which might not be an advantage as "obvious" as it appears on first glance:
Am 21.10.2017 um 00:53 schrieb Marc Jeanmougin:
- The integration in both directions is non-existent : while we could,
on lp, use stuff like "bzr commit --fixes lp:123456", and commit/bugs would link one to the other, and while gitlab MR and bugs can also be linked (https://docs.gitlab.com/ce/user/project/issues/closing_issues.html#via-merge...) ; using separate platforms prevents us to use either of those and forces to link manually bugs urls in MR and commit URLs in bug comments.
While such integrations are nice in principle, they are actually the source of a lot of problems:
- For example you cited Bazaar's --fixes switch. It was great while we were on bzr, but when we moved to GitLab we almost lost this information! Only by hacking the export routine we were able to save this data and migrate it.
- Even with that information secured there are still a lot of commit messages simply stating "fixes bug 123456" which leaves one searching for the actual launchpad bug manually.
- Luckily for launchpad a manual search is actually possible as bug numbers are global and do not depend on the project. For GitLab issues are counted per-project (and we already have several) so it might quickly become a mess if we rely on automatic linking. (Just imagine what happens if your local git client tells you issue #123 was fixed - it will be fun to find out which project this refers to and derive a bug link from that)
- An this is just now! Imagine the chaos that will result if we switch our VCS again at some point (hopefully far into) the future.
With this in mind the apparent advantage from automatic linking integrations is diminished significantly (if not even negated) and for these reasons I actually want to *encourage* everybody to actively use full URLs where reasonable (especially in commit messages).
Well said, and a very good point. For Cairo and other projects I work on there are no automatic linking provisions, so I paste in the full url; typically I have the bug report open in a browser on the side so the work is negligible.
From a release maintainer point of view, having the full URLs is quite
useful in generating the release announcement. I'm generally going through dozens of bug reports in a go, so the more consistent the bug report links are the quicker this work goes.
The Linux kernel uses a convention for tagging in git commit messages, to enable various automated processing things that they do. A typical commit might look like:
From: Bryce Harrington <bryce@...961...> Subject: [PATCH v3 2/5] baz: Foo the bar
Blah blah foo blah blah bar blah blah in baz.
Signed-off-by: Bryce Harrington <bryce@...961...> Reviewed-by: Honored Reviewer <you@...3620...> Fixes: http://gitlab.com/inkscape/inkscape/issues/123
This style has some other conventional tags, like Reported-by, Tested-by, Suggested-by, Implements, which have obvious documentational utility and should be fairly widely recognized in the tool ecosystem, though they're straightforward enough to do manually. They're also ameniable to setting up your own hotkeys/shortcuts/compose sequences, etc. - helpful if you deal with large numbers of patches.
While it might be a tiny bit more work initially (most of the time the full link is available for copy/pasting though, so it really doesn't matter), it actually saves a lot of time when trying to work with that information afterwards, especially if *not* working on GitLab. This way we actually become independent from such platforms GitLab and produce helpful commit data, not only for us but also for the generations after us!
Exactly, well said and completely agreed.
Bryce
There were several talks about "google code-in" (https://codein.withgoogle.com/), which is a program aimed at high-school students to get them involved in open source programs. Basically, programs setup "tasks" (which can range from "compile the project" or "write some documentation about X" to "solve a bug" or "refactor X", or probably even "improve test coverage", "make a tutorial video about an underrated feature", etc) and students earn "points" by completing them, over a six-weeks timeframe. Tasks are manually checked and validated by the project members (in <24h), so it requires dedication from several contributors to achieve this (apparently, there are quite a lot of students participating, so it also has the immediate side-effect of stress-testing the quality and efficiency of available project documentation and help channels).
I don't think we have the resources (in terms of people available, tasks, or doc) to participate in this year's edition (deadline is in 3 days), but I found the idea very interesting, and participating orgs reported that a lot of former participants stayed as long term contributors and even helped the next year's contestants.
I discussed funding models with various people from different projects, so here is what I gathered:
* Both VLC and Blender have a lot of sponsorship from hardware companies who are interested in these softs keeping running smoothly with their newest hardware on the highest resolution monitors existing. Blender also has support from the steam workshop, a 3d asset store, their store (training, books, wear)… * VLC has a dual structure with a non-profit along with a small startup in multimedia consulting, paying a dozen devs (They also say that they have a single ad (adsense) on their download page which alone pays for a dev) * MuseScore (software for music sheets) has a website to upload/share them which has a paying subscription model to upload more than some amount
Overall, no "magical" way to amass vast riches, just a thought that if we could support GPU SVG rendering we might be able to ask GPU vendors if they'd be interested in sponsoring us (or conversely if they'd be interested in sponsoring us so that we could try to implement/use GPUs in cairo rendering)
On Sat, 2017-10-21 at 00:53 +0200, Marc Jeanmougin wrote:
I discussed funding models with various people from different projects, so here is what I gathered:
- Both VLC and Blender have a lot of sponsorship from hardware
companies who are interested in these softs keeping running smoothly with their newest hardware on the highest resolution monitors existing. Blender also has support from the steam workshop, a 3d asset store, their store (training, books, wear)…
- VLC has a dual structure with a non-profit along with a small
startup in multimedia consulting, paying a dozen devs (They also say that they have a single ad (adsense) on their download page which alone pays for a dev)
- MuseScore (software for music sheets) has a website to upload/share
them which has a paying subscription model to upload more than some amount
Overall, no "magical" way to amass vast riches, just a thought that if we could support GPU SVG rendering we might be able to ask GPU vendors if they'd be interested in sponsoring us (or conversely if they'd be interested in sponsoring us so that we could try to implement/use GPUs in cairo rendering)
Nvidia approached me a few years ago about adding a GPU backend using their OpenGL 2d rendering extensions to Inkscape. We (Inkscape) talked about it briefly but didn't want to start using proprietary things (Nvidia was trying to get the extensions into the OpenGL standard but none of the other GPU manufacturers were interested). We had also just recently moved to Cairo and adding another rendering backend seemed a bit much. I suggested that they look into an OpenGL backend for Cairo.
The examples they showed of rendering SVG did look great as they could get rid of a lot of rendering artifacts by rendering at a higer DPI then scaling down.
Tav
participants (10)
-
Alex Valavanis -
Bryce Harrington -
Eduard Braun -
Felipe Sanches -
Marc Jeanmougin -
Martin Owens -
Miguel Lopez -
Robert Sterbal -
Tavmjong Bah -
Vinícius dos Santos Oliveira