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 _______________________________________________ Mypaint-discuss mailing list [email protected] https://mail.gna.org/listinfo/mypaint-discuss
