Re: [Mypaint-discuss] Possible migration to github
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 Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Possible migration to github
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
[Mypaint-discuss] Possible migration to github
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. - Gitorious has had fairly frequent outtages where pull/push is unreponsive. A nice thing in Github is the tighter integration between commits, pull requests and issues. When someone refers to something from a commit, issue or pull request, comments will be automatically posted on the thing referred to - establishing two-way links. Currently we've been trying to do that manually. Other useful projects are also integrating with Github and its APIs. An example here is Travis CI, a free hosted continuous integration service for open source projects. But mostly benefits of may come from non-technical aspects: Github is popular. Many more people have, or are willing to create and use github accounts, compared to gitorious and gna. This _may_ lead to an increase in contributions, both on bug-reporting and code. 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. == 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 For platform we already used [Windows] and similar tags in bug titles, possibly more so than the platform field. Labels: windows, osx, linux 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 == How to migrate == Moving the git repository over is of course no issue. That would just require updating URLs in documentation and configurations. Migrating the bugreports would be a bit more work, but is not at all that difficult. GNA offers an XML export for the database*, and GitHub offers an HTTP API for Issues. Based on this I've hacked up a prototype script for automatic migration. Currently it can extract most of the relevant info, and format this as github API requests (though not actually send them yet). Branch gna2github on my personal repo: http://gitorious.org/~jonnor/mypaint/jonnors-clone/commits/gna2github 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. I would suggest that we only migrate open bugs, and do this after we have cleaned up the tracker and closed as much as possible. This should leave us with around 100 bugs (just closing fixed and similar would bring us to 130). After a successful migration we would close the bugs on gna.org with a link to the migrated bug on github.com. * Currently it has some invalid UTF8 characters, but the data is still usable with some massaging. Reported here: http://gna.org/support/?2982 -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
