On 21 November 2012 12:05, Andrew Chadwick <a.t.chadw...@gmail.com> 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
_______________________________________________ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
