Getting off Google Code
Owen Winkler
don't like our patchwork of licenses, there are issues with the bug
tracker, specifically that only people with commit access can change
issue properties. Beyond that, I think that the milestone/tagging
stuff is kind of flaky.
In any case, I believe that we should begin our migration sooner
rather than later, since the task only gets harder as more issues need
to be moved to whatever the new system is.
And that's really the next big question: What system should we use?
I can't give you a concrete reason why, but I just don't like Trac. I
suppose it's effective and already installed on habariproject.org, so
it has that advantage. It would be nice if all of its wiki features
could be removed, especially the text formatting that gets processed
even on commit messages. (It turns any mention of "__isset()" calls
into underlined text, for example.)
I've been looking at issue trackers online, and I'm tired of searching
for something good. All of the good stuff is hosted. It would almost
be worthwhile to tweak Habari slightly so that you could create an
issue using a custom post type.
What would be very nice is if we could retain our svn history in the move.
Let's have a discussion about this, and close out this thread with a
plan of action.
Owen
Scott Merrill
> We've got to get off of Google Code.
> In any case, I believe that we should begin our migration sooner
> rather than later, since the task only gets harder as more issues need
> to be moved to whatever the new system is.
>
> And that's really the next big question: What system should we use?
We talked about this many moons ago. Whatever hosted solution the ASF
uses was mentioned as one possibility.
> Let's have a discussion about this, and close out this thread with a
> plan of action.
What features do you need? You've already identified two:
* no formatting applied to commit messages
* allow "regular" users to adjust ticket statuses
What are other features do you consider mandatory?
It _would_ be clever to use Habari as an issue tracker. Tags could be
applied much like they are on GCode. Tags could be used to signify open
/ closed status. We'd need to concoct a way for non-authors to change
tags on a ticket without changing the contents of that ticket.
The nice thing about Trac is how integrated commits and tickets are.
Referencing a ticket # in a commit message automatically generates a
link to that ticket. That's functionality we're unlikely to retain if
we switch to disparate systems for commit history and ticketing.
--
GPG 9CFA4B35 | ski...@skippy.net | http://skippy.net/
Owen Winkler
>
> It _would_ be clever to use Habari as an issue tracker. Tags could be
> applied much like they are on GCode. Tags could be used to signify open
> / closed status. We'd need to concoct a way for non-authors to change
> tags on a ticket without changing the contents of that ticket.
This is probably not as hard as one might think.
> The nice thing about Trac is how integrated commits and tickets are.
> Referencing a ticket # in a commit message automatically generates a
> link to that ticket. That's functionality we're unlikely to retain if
> we switch to disparate systems for commit history and ticketing.
I have already extended our Mediawiki installation to do this.
See: http://wiki.habariproject.org/en/User:ringmaster/sandbox
The point being that it might not be as hard to do this as one might
think, either.
Owen
Owen Winkler
> * no formatting applied to commit messages
> * allow "regular" users to adjust ticket statuses
>
> What are other features do you consider mandatory?
>
I like the idea of adding "features" for milestones so that we can see
progress toward them, and perhaps even having child features/bugs
under other features so that things can be grouped logically. Tagging
is interesting, but inconsistent due to the many vectors issues are
added from.
Simple reports are good. There is something overwhelming about seeing
all of the issues at once. One thing I could never figure out about
Trac is how to get a list of issues that were open that I wanted to
work on. Like, "mark these issues for me to do".
The use of the "assigned"-like fields never made sense to me. Do we
assign a new issue to ourselves so we can track progress? Do we
assign it to a dev? Do we leave it open for someone to assign to
themselves? What happens to issues that are left unassigned? Too
much ambiguity.
Marking things as duplicates will be important for a system that is
open to anyone to add things.
The diffing that Trac does between versions is very useful. Both the
per-changeset diff and the per-file/rev diff. I would like to keep
that functionality.
Integrating the system with our habariproject.org logins will be a nice feature.
Really, I want "simple". Some of these products have way too many
settings and options.
Owen
Scott Merrill
> On 8/18/07, Scott Merrill <ski...@skippy.net> wrote:
>> It _would_ be clever to use Habari as an issue tracker. Tags could be
>> applied much like they are on GCode. Tags could be used to signify open
>> / closed status. We'd need to concoct a way for non-authors to change
>> tags on a ticket without changing the contents of that ticket.
>
> This is probably not as hard as one might think.
I'm sure it's not terribly difficult. Would statuses be plain ol' tags,
or would they be more like post statuses, atomic indicators such that
the author (or someone with sufficient permission) changes the post status?
>> The nice thing about Trac is how integrated commits and tickets are.
>> Referencing a ticket # in a commit message automatically generates a
>> link to that ticket. That's functionality we're unlikely to retain if
>> we switch to disparate systems for commit history and ticketing.
>
> I have already extended our Mediawiki installation to do this.
> See: http://wiki.habariproject.org/en/User:ringmaster/sandbox
>
> The point being that it might not be as hard to do this as one might
> think, either.
After sending my message, I started to envision all sorts of cool ways
to tie Habari into an SVN repository. Either through post-commit hooks,
or by having Habari consume an RSS feed of commit messages, Habari could
easily represent the commit messages as posts. With some clever
regexes, references to tickets in the commit log could be linked to the
ticket's permalink.
As cool as that might be, though, I wonder how useful that will be in
the long run? We run the risk of being accused of falling prey to the
"not invented here" paradigm; and we might end up spending inordinate
amounts of time on fringe issues, detracting from core Habari development.
Moreover, how would you propose to address your desire for "simple
reports", and hierarchical milestones / bugs?
If we can do it, and have it sufficiently functional without taking away
from core Habari development, I'm willing to explore the opportunity. I
just don't want us to reinvent the wheel: the reason there are so many
ticketing / bug tracking solutions is because they've all decided they
can solve the problem better than any of their predecessors. Do we
think we have some specific insight that they lack?
Andrew da Silva
Owen Winkler
>
> Owen Winkler wrote:
> > On 8/18/07, Scott Merrill <ski...@skippy.net> wrote:
> >> It _would_ be clever to use Habari as an issue tracker. Tags could be
> >> applied much like they are on GCode. Tags could be used to signify open
> >> / closed status. We'd need to concoct a way for non-authors to change
> >> tags on a ticket without changing the contents of that ticket.
> >
> > This is probably not as hard as one might think.
>
> I'm sure it's not terribly difficult. Would statuses be plain ol' tags,
> or would they be more like post statuses, atomic indicators such that
> the author (or someone with sufficient permission) changes the post status?
I think we could do one of two things:
Option #1: We could use info fields on posts to have indicators of
statuses. The interface can be made to allow access to change these
only by users who have permission. Status change history can be
stored in comment info with comments.
Option #2: We extend the Habari API altogether: Add a couple of
fields to the posttype table to indicate the table and keyfield of
where that posttype is stored. Then we can either use a separate
table to store issues with its own specific fields, or specify the
same table, but take advantage of the different posttype as an
indicator of what editing interface/output to display for that post.
> After sending my message, I started to envision all sorts of cool ways
> to tie Habari into an SVN repository. Either through post-commit hooks,
> or by having Habari consume an RSS feed of commit messages, Habari could
> easily represent the commit messages as posts. With some clever
> regexes, references to tickets in the commit log could be linked to the
> ticket's permalink.
PHP svn bindings are available if you can install them. Using a
post-commit hook or a cron, we can very easily obtain that
information. Adding new posts to a "svn" tag would be a neat way to
have a rolling log of commits and separate them from the rest of the
site's posts.
> As cool as that might be, though, I wonder how useful that will be in
> the long run? We run the risk of being accused of falling prey to the
> "not invented here" paradigm; and we might end up spending inordinate
> amounts of time on fringe issues, detracting from core Habari development.
I think that we need a use-case for having additional post types that
we can use to prove that the post type assembly is extensible enough
to use Habari as a platform for generic site development. While an
issue-tracking system is an ambitious project for such a use, it will
surely test the system's capabilities more than a simpler "podcast"
post type or similar.
It would also necessarily be something external to the core, meaning
that it would be tested as an *extension* rather than a hack of the
core code. This would ensure that we've got all of the necessary
hooks in the core that any extension would need to implement any
similar project. Obviously, we could release the issue tracker plugin
as a separate project under ASL too.
Really, I don't care which we do - extend Habari or roll some other
software - as long as the result is suitable. I think extending
Habari would be sweet, and prove that it's not just blog software but
a viable site development platform.
I expect Matt Read to have implemented this whole issue tracking
system two days within reading this post, anyway. ;)
> Moreover, how would you propose to address your desire for "simple
> reports", and hierarchical milestones / bugs?
The simple reports are easy, since we can just concoct a
"ticket.multiple" template that does it. Hierarchical issues could be
implemented with the info field also, although that will make
displaying them hierarchically more interesting.
I'm not sure how we'd manage milestones, though. Maybe an additional post type?
> If we can do it, and have it sufficiently functional without taking away
> from core Habari development, I'm willing to explore the opportunity. I
> just don't want us to reinvent the wheel: the reason there are so many
> ticketing / bug tracking solutions is because they've all decided they
> can solve the problem better than any of their predecessors. Do we
> think we have some specific insight that they lack?
One specific thing that other issue tracking systems lack is that they
don't run in PHP. PHP issue trackers that exist are oddly not simple.
I think we should solve the problem of bug tracking "worse" (as
opposed to "better") than all of the other systems, by not having so
many darn options.
This is not meant to imply that we need a reason to implement an issue
tracker beyond seeing Habari do it, which I think is reason enough to
give it a shot.
Owen
Scott Merrill
> Option #1: We could use info fields on posts to have indicators of
> statuses. The interface can be made to allow access to change these
> only by users who have permission. Status change history can be
> stored in comment info with comments.
>
> Option #2: We extend the Habari API altogether: Add a couple of
> fields to the posttype table to indicate the table and keyfield of
> where that posttype is stored. Then we can either use a separate
> table to store issues with its own specific fields, or specify the
> same table, but take advantage of the different posttype as an
> indicator of what editing interface/output to display for that post.
Option #3: extend the poststatus table to permit a list of posttypes to
which those statuses can be applied. In this way, we could have a
"status" poststatus that is only applicable to items of posttype
"ticket". This seems the most extensible option for custom post types
and statuses, and better leverages our existing API and data structures.
> I think that we need a use-case for having additional post types that
> we can use to prove that the post type assembly is extensible enough
> to use Habari as a platform for generic site development. While an
> issue-tracking system is an ambitious project for such a use, it will
> surely test the system's capabilities more than a simpler "podcast"
> post type or similar.
Agreed.
> It would also necessarily be something external to the core, meaning
> that it would be tested as an *extension* rather than a hack of the
> core code. This would ensure that we've got all of the necessary
> hooks in the core that any extension would need to implement any
> similar project. Obviously, we could release the issue tracker plugin
> as a separate project under ASL too.
That would be fun. Using one's Habari installation as an issue tracker
for the development of that installation ... the mind boggles.
> I'm not sure how we'd manage milestones, though. Maybe an additional post type?
In Trac, a milestone represents "all of these tickets are closed". I
guess a post type that integrated existing tickets by a specific tag
might reproduce that. I'm not entirely keen on milestones in that
fashion, though, so I'm not overly enthusiastic about that idea.
> One specific thing that other issue tracking systems lack is that they
> don't run in PHP. PHP issue trackers that exist are oddly not simple.
> I think we should solve the problem of bug tracking "worse" (as
> opposed to "better") than all of the other systems, by not having so
> many darn options.
So we'd be providing absolute basic functionality: tickets, tags for
tickets, basic ticket statuses, and comments on tickets. Are you sure
there's nothing else we'd need to provide?
Root
Tony Stevenson
Call me simple, but, what is the requirement to have the wiki, and bug
tracking all in one boat?
Surely keeping the wiki separate from bug tracking will ensure
formatting does not affect entries, but also none comitters, or even
helpers can use the bug tracking then, much like the Apache HTTPD
project does.
People can then add proposed pacthes, or fixes.
Just a thought. Keeping it simple, is often the best way to approach a
problem.
Tony
Christian Mohn
or what you should use), perhaps this would be a good time to have a look at
something like Review Board (http://review-board.org/). As the project grows
bigger, getting code reviews done before commits probably makes some good
sense (as usual my reference is Gallery and the Gallery 2 developers
extensively uses peer code reviews before major commits - they don't use
Review Board though, as that didn't come along until after they selected a
review package).
Christian
Owen Winkler
>
> While not directly related (I have no real comment on alternatives to GCode,
> or what you should use), perhaps this would be a good time to have a look at
> something like Review Board (http://review-board.org/).
Wow, Review Board is really cool. It would be great if an issue
report could have one or more patches attached to it that appear in
Review Board, integrating the two systems.
Owen
Owen Winkler
>
> Call me simple, but, what is the requirement to have the wiki, and bug
> tracking all in one boat?
There is no requirement to have the wiki as a part of the bug tracking
solution. I don't see any practical purpose for having links from the
wiki to issue tickets or revision histories, even though connecting
those systems is trivial.
On the other hand, having svn and a commit reporting system integrated
with the issue tracking system is a very good idea because it will
help easily explain what issue a specific commit was meant to address,
and provide the developers an easier way to do it.
For example, when reporting an issue as fixed, I have to commit the
code with a full comment, then visit the issue tracker to mark it as
fixed for QA, while noticing and remembering the rev number so I can
add that to the ticket in the tracker. It would be nice to simply add
"fixes issue #123" to the commit message, have the system parse that
out, and apply the commit message to the ticket with a link to the
changes in the visual svn log.
> Surely keeping the wiki separate from bug tracking will ensure
> formatting does not affect entries, but also none comitters, or even
> helpers can use the bug tracking then, much like the Apache HTTPD
> project does.
>
> People can then add proposed pacthes, or fixes.
I didn't quite follow you there, but it is our intent to allow people
to submit issues and/or patches without having been granted explicit
permission to do so. That's the problem with Google Code now - it
doesn't let people modify tickets after they're submitted unless they
also have access to commit source code to the repository.
Owen
Andrew da Silva
Scott Merrill
> In any case, I believe that we should begin our migration sooner
> rather than later, since the task only gets harder as more issues need
> to be moved to whatever the new system is.
>
> And that's really the next big question: What system should we use?
Lest this initiative suffer neglect, I'd like to suggest that we
investigate Launchpad, the collaboration suite being developed by Canonical:
https://launchpad.net/
Launchpad is another hosted service, like Google Code; so we might
simply be trading one set of restrictions for another.
The most obvious concern is that Launchpad is heavily geared toward the
Bazaar revision control system, rather than SVN.
https://code.launchpad.net/+about
Chris J. Davis
launchpad, then I am -1.
Chris
Rich Bowen
Root
Nathaniel McCallum
Michael Bishop
something like that for updating. I didn't see a native Mac download
for bazaar, and doubt it could be configured to be used on the server
installation I also run off of trunk.
~miklb
On Aug 23, 6:32 pm, "Nathaniel McCallum" <npmccal...@gmail.com> wrote:
> Is it that hard?http://bazaar-vcs.org/BzrForSVNUsers;)
>
> OK, ignore the bzr lover now... :)
>
Owen Winkler
>
> Lest this initiative suffer neglect, I'd like to suggest that we
> investigate Launchpad, the collaboration suite being developed by Canonical:
> https://launchpad.net/
Launchpad is really slick. Weren't we going to use that for translations?
Here is a different proposal...
moeffju had set up our Trac's SVN
(http://trac.habariproject.org/habari) to sync with our GCode
repository all along. So our revision history is maintained there.
We also already have Trac, and I'm told that issue tracking is just an
ini setting.
The downside of moving away from Google-hosted svn and tracking is
that we lose the power of Google to monitor any issues we have with
it, do backups, and the like.
To mitigate this, I've offered backup space on a different server
where the Trac and svn data can be regularly synced. At least this
way, we'll have backups.
Trac is not perfect but I think it may suit our needs.
What do you all think?
Owen
Andrew da Silva
On 8/23/07, Scott Merrill < ski...@skippy.net> wrote:
>
> Lest this initiative suffer neglect, I'd like to suggest that we
> investigate Launchpad, the collaboration suite being developed by Canonical:
> https://launchpad.net/
Launchpad is really slick. Weren't we going to use that for translations?
Here is a different proposal...
moeffju had set up our Trac's SVN
( http://trac.habariproject.org/habari) to sync with our GCode
Owen Winkler
> +1, although, would we be able to rollback to GCode at any time? (with the
> syncing and all)
No, although moving away from Google Code at all makes going back
difficult, since I don't think they can import our SVN history.
Owen
Chris J. Davis
Matthias Bauer
> +1, although, would we be able to rollback to GCode at any time? (with
> the syncing and all)
No, once we have history of our own, we can't "just" resync or reimport.
Google offer to manually import SVN dumps for you, but that is not
automated (read: takes time, is a one-time thing).
-M
Christian Mohn
Scott Merrill
> This might be a stupid question, but is there a reason why sf.net hasn't
> been mentioned?
SourceForge was originally rejected because they have a long history of
poor performance. Google's offering was snappy, and not laden down with
advertising; both attributes that were very positive to us.
I wouldn't want to host on sf.net, if other options exist.
> -----Original Message-----
> From: habar...@googlegroups.com [mailto:habar...@googlegroups.com] On
> Behalf Of Matthias Bauer
> Sent: 24. august 2007 14:47
> To: habar...@googlegroups.com
> Subject: [habari-dev] Re: Getting off Google Code
>
>
> On 24.08.2007 04:31 Andrew da Silva wrote:
>
>> +1, although, would we be able to rollback to GCode at any time? (with
>> the syncing and all)
>
> No, once we have history of our own, we can't "just" resync or reimport.
> Google offer to manually import SVN dumps for you, but that is not
> automated (read: takes time, is a one-time thing).
|
--
Christian Mohn
I've not experienced much slowness, but that's just me :) ). Now I got an
answer. :-)
Christian
Nathaniel McCallum
and most servers with python >= 2.4.