I sugest we migrate to GitHub, since it's very mainstream...
On Wed, Nov 21, 2012 at 10:53 AM, <[email protected]> wrote: > Send Mypaint-discuss mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.gna.org/listinfo/mypaint-discuss > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Mypaint-discuss digest..." > > > Today's Topics: > > 1. Re: Possible migration to github (Andrew Chadwick) > 2. Re: string freeze, release status (David Revoy) > 3. Re: Possible migration to github (Jon Nordby) > 4. Fwd: Surface optimizations proposed for merging (Jon Nordby) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 21 Nov 2012 11:05:20 +0000 > From: Andrew Chadwick <[email protected]> > To: [email protected] > Subject: Re: [Mypaint-discuss] Possible migration to github > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > On 21/11/12 02:59, Jon Nordby wrote: > > A question whether to migrate to github has come up a couple of times on > > irc now. > > > > == Should we migrate == > > I only have two issues with the current infrastructure we use: > > - GNA uses certificates which are not considered trusted by many web > > browsers. This scares off some people wanting to file bugs. > > That's a good reason to move away from Gna! to something friendlier. > Major issue this. It's probably scaring off people trying to search for > bugs too. > > > - Gitorious has had fairly frequent outtages where pull/push is > unreponsive. > > Annoying when it happens, but not by itself reason enough to change. > > > What do you think about using github? > > > > Note that whatever the decision would be, we won't change anything > > before MyPaint 1.1 is out. > > Basically positive. If Martin's OK with it, and the faff is minimal, I'd > have no objections. > > > == Managing missing fields in github issues == > > Github Issues does not have as many fields for a bug/issue as GNA. > > Instead it offers string-based labels/tags. > > The fields that we were somewhat using in gna that are missing are: > > Status, Severity, and Platform. > > > > We used status to implement a two-step fixed->closed workflow. Fixed > > when the fix is in git master, closed when released. In addition it is > > useful to mark triaged bugs with the outcome of the triage, either > > confirmed or need-info. > > Labels: fixed, need-info, confirmed > > How much of this can be achieved with milestones referring to past and > future versions? we never really used the Gna! ones, but Github > milestones seem flexible, can be annotated and renamed, have pretty > completeness bars, and you can filter for issues which don't have one > assigned yet. > > I've never much liked "fixed+open" as a concept. IMO a bug is either > open or closed; it seems more expressive and documentary to assign open > or closed bugs to a milestone reflective of current and past work focus. > The meaning "closed+<future-version>" seems self-evident, particularly > if "<future-version>" carries an obvious label. > > You never know. We might even be able to drive short release cycles from > weight of open bugs :) > > > For platform we already used "[Windows]" and similar tags in bug titles, > > possibly more so than the platform field. > > Labels: windows, osx, linux > > Seems good to me. Absence indicates any OS (as far as we know)? > > > We have not used severity that much, except for separating out wishes > > from bugreports and indicate very serious issues. This is still useful I > > think. > > Labels: wish, crash, dataloss > > +annoyance, exception, "feature"... > > It's nice to be able to treat these things as freeform tags in a way, > provided they can be used for prioritising things for upcoming releases. > > > == How to migrate == > > In such a migration all comments would be created with the username of > > the one running the import script. To work around this a comment could > > be posted on each comment/report about who originally created it, and > > link to the original content on gna. > > Would this be possible with a very clearly distinct github account? > > -- > Andrew Chadwick > > > > ------------------------------ > > Message: 2 > Date: Wed, 21 Nov 2012 12:38:48 +0100 > From: David Revoy <[email protected]> > To: Andrew Chadwick <[email protected]> > Cc: [email protected] > Subject: Re: [Mypaint-discuss] string freeze, release status > Message-ID: > <CAPX1LSC4Mzoi33C2eihQBtQ6m3jpD1nPW= > [email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > > > > Yes - icons shouldn't need translating :) > > > I think I understand only now what 'freeze string' means > ( shame on me -_-' , I thought at first it was a sort of 'freeze all the > code' for a next release ) > > > > > I'll continue the recent icon work on master this week, if I have time. > > New templates and tweaked export script, FYI - I've automated slightly > > more of the workflow. > > > Oh, good news and thanks about new templates + new export script if you > have time. It will be super useful for sure ! > > > Something else ; but certainly useful before a "string freeze" : > Is it possible to add a text label to the buttons in the "Brush Setting > Editor" here : > http://wstaw.org/m/2012/11/21/2012-11-21_screenshot_001.jpeg > Depending the theme and desktop environment the icons are sometime similar > , and it's confusing. > ( the text would be the same as the actual tool tip text ; > Save Settings / Add as new / Edit brush icon / Rename / Remove > Maybe they are already translated ? > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > </public/mypaint-discuss/attachments/20121121/35e2f7f4/attachment.html> > > ------------------------------ > > Message: 3 > Date: Wed, 21 Nov 2012 13:33:23 +0100 > From: Jon Nordby <[email protected]> > To: mypaint-discuss <[email protected]> > Subject: Re: [Mypaint-discuss] Possible migration to github > Message-ID: > < > cajeabuvtitfwip-3c24dmyc6dcnku9hoy4v1w5tw5e5jvnd...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On 21 November 2012 12:05, Andrew Chadwick <[email protected]> wrote: > > > On 21/11/12 02:59, Jon Nordby wrote: > > > A question whether to migrate to github has come up a couple of times > on > > > irc now. > > > > > > == Should we migrate == > > > I only have two issues with the current infrastructure we use: > > > - GNA uses certificates which are not considered trusted by many web > > > browsers. This scares off some people wanting to file bugs. > > > > That's a good reason to move away from Gna! to something friendlier. > > Major issue this. It's probably scaring off people trying to search for > > bugs too. > > > > > - Gitorious has had fairly frequent outtages where pull/push is > > unreponsive. > > > > Annoying when it happens, but not by itself reason enough to change. > > > > > What do you think about using github? > > > > > > Note that whatever the decision would be, we won't change anything > > > before MyPaint 1.1 is out. > > > > Basically positive. If Martin's OK with it, and the faff is minimal, I'd > > have no objections. > > > Ok, sounds good. > > > > > == Managing missing fields in github issues == > > > Github Issues does not have as many fields for a bug/issue as GNA. > > > Instead it offers string-based labels/tags. > > > The fields that we were somewhat using in gna that are missing are: > > > Status, Severity, and Platform. > > > > > > We used status to implement a two-step fixed->closed workflow. Fixed > > > when the fix is in git master, closed when released. In addition it is > > > useful to mark triaged bugs with the outcome of the triage, either > > > confirmed or need-info. > > > Labels: fixed, need-info, confirmed > > > > How much of this can be achieved with milestones referring to past and > > future versions? we never really used the Gna! ones, but Github > > milestones seem flexible, can be annotated and renamed, have pretty > > completeness bars, and you can filter for issues which don't have one > > assigned yet. > > > > I've never much liked "fixed+open" as a concept. IMO a bug is either > > open or closed; it seems more expressive and documentary to assign open > > or closed bugs to a milestone reflective of current and past work focus. > > The meaning "closed+<future-version>" seems self-evident, particularly > > if "<future-version>" carries an obvious label. > > > > Fair point, milestones is perhaps a better way to deal with this on github. > A github milestone is completed when all issues for that milestone is > complete. So to prevent this from happening prematurely, we would create a > "Release MyPaint 1.2" bug which we would close when the release, and thus > the milestone, is done. Could be a good place to discuss (and for people to > follow) release-level things as well. > > > > You never know. We might even be able to drive short release cycles from > > weight of open bugs :) > > > I would like shorter release cycles. Though I am not sure I know any other > way to achieve them than for someone to continuously push for it. Which is > always hard in a volunteer driven project as making releases is not the > most fun thing there is. > How can we make releases more fun? One thing would perhaps be to automate > it more, so there is less manual hassle and it can be done quicker. > > > > > For platform we already used "[Windows]" and similar tags in bug > titles, > > > possibly more so than the platform field. > > > Labels: windows, osx, linux > > > > Seems good to me. Absence indicates any OS (as far as we know)? > > > Yep. > > > > > We have not used severity that much, except for separating out wishes > > > from bugreports and indicate very serious issues. This is still useful > I > > > think. > > > Labels: wish, crash, dataloss > > > > +annoyance, exception, "feature"... > > > > It's nice to be able to treat these things as freeform tags in a way, > > provided they can be used for prioritising things for upcoming releases. > > > New labels can be added by anyone who is a "collaborator". As far as I know > that is the same as those that have commit access. Currently we have more > people with bug edit status than people with git access, but we can > probably give everyone who now has bug edit status commit access without > any issues. > > > > > == How to migrate == > > > In such a migration all comments would be created with the username of > > > the one running the import script. To work around this a comment could > > > be posted on each comment/report about who originally created it, and > > > link to the original content on gna. > > > > Would this be possible with a very clearly distinct github account? > > > Yes, I'd create some user for just this purpose. "mypaint-gna" or somesuch. > > > -- > Jon Nordby - www.jonnor.com > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > </public/mypaint-discuss/attachments/20121121/34fd3695/attachment.html> > > ------------------------------ > > Message: 4 > Date: Wed, 21 Nov 2012 16:53:09 +0100 > From: Jon Nordby <[email protected]> > To: mypaint-discuss <[email protected]> > Subject: [Mypaint-discuss] Fwd: Surface optimizations proposed for > merging > Message-ID: > < > cajeabuupq1cptr5ntbohkhw0ear9dyabkpsiab_eq3ymjsf...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Forwarding to list > > ---------- Forwarded message ---------- > From: Popolon <[email protected]> > Date: 21 November 2012 01:55 > Subject: Re: [Mypaint-discuss] Surface optimizations proposed for merging > To: Jon Nordby <[email protected]> > > > I made some test with the last git version versus surface optimization > version and here are the results in mycase (core i7 4core + hyperthreading > ~8core)@3.7Ghz, no opencl support (no intel openCL driver on linux). > > I tested mosly the deevad brush : deevad/basic_digital_knife_**smudging). > this seem to be the slower brush. In all case i growed at max the size of > the brush by pressing several time [f] key. > > All brush are fluid in surface.optimizations version but the > deevad/basic_digital_knife_**smudging. > > In most case this brush is very slow in standard version (perhaps 0.20 to > 0.5 s lag). In surface optimization version, it seems to fluidly drawn, > when the whole stroke is included in the portion of the canvas seen at > screen, but suffer of big slow down every time the brush stroke go out of > this area, perhaps simply because the whole surface stroked is bigger ? > > I made a video record with this brush, but it seems that's the record is > not really in real time, probably a little bit accelerated ??? I used > gtk-record-mydestkop for this screencast, if someone know a better option, > I could make a newone. > > http://popolon.org/mypaint/**out_seems_accelerated.ogv< > http://popolon.org/mypaint/out_seems_accelerated.ogv> > > I have some slowdown with deevad/watercolor_glazing, deevad/thin_watercolor > and deevad/large_watercolor_fringe brushs too. > > > Popolon > > > Le 19/11/2012 13:11, Jon Nordby a ?crit : > > > > > On 18 November 2012 03:12, Jon Nordby <[email protected] > > <mailto:[email protected]>> wrote: > > > > I have some more ideas for further improve performance, and am > working > > to document these now. > > > > Now documented in the surface-optimizations branch, file > > brushlib/PERFORMANCE: > > http://gitorious.org/mypaint/**mypaint/blobs/surface-** > > optimizations/brushlib/**PERFORMANCE< > http://gitorious.org/mypaint/mypaint/blobs/surface-optimizations/brushlib/PERFORMANCE > > > > > > Here are the main points: > > === TODO: Improve vectorization === > > === TODO: More efficient serial code === > > === TODO: Try different tile sizes === > > === IDEA: Dab masks cache === > > === IDEA: Make use of GPU processing: OpenCL and OpenGL === > > > > -- > > Jon Nordby - www.jonnor.com <http://www.jonnor.com> > > > > > > ______________________________**_________________ > > Mypaint-discuss mailing list > > [email protected] > > https://mail.gna.org/listinfo/**mypaint-discuss< > https://mail.gna.org/listinfo/mypaint-discuss> > > > > > > > > -- > Jon Nordby - www.jonnor.com > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > </public/mypaint-discuss/attachments/20121121/a7633fb6/attachment.html> > > ------------------------------ > > _______________________________________________ > Mypaint-discuss mailing list > [email protected] > https://mail.gna.org/listinfo/mypaint-discuss > > > End of Mypaint-discuss Digest, Vol 52, Issue 6 > ********************************************** >
_______________________________________________ Mypaint-discuss mailing list [email protected] https://mail.gna.org/listinfo/mypaint-discuss
