Add Google's ipaddr.py to the stdlib

@gvanrossum

BPO	3959
Nosy	@gvanrossum, @loewis, @gpshead, @abalkin, @pitrou, @giampaolo, @benjaminp, @ezio-melotti, @bitdancer
Files	unnamed

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/gpshead'
closed_at = <Date 2009-05-03.07:04:47.318>
created_at = <Date 2008-09-24.23:14:09.742>
labels = []
title = "Add Google's ipaddr.py to the stdlib"
updated_at = <Date 2009-06-02.17:00:27.598>
user = 'https://github.com/gvanrossum'

bugs.python.org fields:

activity = <Date 2009-06-02.17:00:27.598>
actor = 'belopolsky'
assignee = 'gregory.p.smith'
closed = True
closed_date = <Date 2009-05-03.07:04:47.318>
closer = 'gregory.p.smith'
components = []
creation = <Date 2008-09-24.23:14:09.742>
creator = 'gvanrossum'
dependencies = []
files = ['13834']
hgrepos = []
issue_num = 3959
keywords = []
message_count = 81.0
messages = ['73761', '73762', '73763', '73764', '73768', '73770', '73793', '74092', '74093', '74094', '78216', '78218', '78666', '78673', '78675', '78677', '78680', '78683', '78700', '78826', '78836', '78908', '78984', '78985', '78988', '78989', '79069', '79098', '79099', '79187', '81006', '81007', '81009', '81010', '81011', '81050', '81141', '81144', '81146', '81147', '81150', '81151', '81167', '82684', '82688', '82695', '84445', '86898', '86902', '86903', '86925', '86926', '86928', '87033', '88653', '88654', '88655', '88672', '88673', '88675', '88676', '88678', '88686', '88688', '88692', '88700', '88703', '88705', '88706', '88707', '88709', '88710', '88711', '88712', '88713', '88717', '88718', '88719', '88720', '88742', '88752']
nosy_count = 16.0
nosy_names = ['gvanrossum', 'loewis', 'gregory.p.smith', 'belopolsky', 'Rhamphoryncus', 'pitrou', 'giampaolo.rodola', 'benjamin.peterson', 'ezio.melotti', 'mattsmart', 'shields', 'pmoody', 'pnasrat', 'r.david.murray', 'oubiwann', 'claymation']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue3959'
versions = ['Python 3.1']

Google just released ipaddr.py, a module that knows how to manipulate IP
addresses (both IPv4 and IPv6).

I have nothing to do with this module, but I suggest considering it for
inclusion in the standard library.

It fills a gap for address manipulations that will become more important
to fill as IPv6 becomes more widespread.

Where can we find this?

It would help if I added a link to the Google release:

http://code.google.com/p/ipaddr-py/

Description:

"

An IPv4/IPv6 manipulation library in Python.

This library is used to create/poke/manipulate IPv4 and IPv6 addresses
and prefixes.

"

Almost time machine. :)

I see a list of owners in the code (although it's difficult to infer
real names or email addresses from that list). I think we should not
include the code without their explicit approval.

The question will then always be: what is the official master copy of
the code? The one in Python, or the one on Google code? Whose
responsibility would it be to keep those synchronized, and incorporate
changes from one copy into the other?

I would prefer if the copy in Python (say, 2.7) becomes the master copy,
and the copy on Google code eventually disappears (when interest in
older Python versions has died).

I would object to a mere fork of the code (i.e. where one of the regular
Python committers incorporates, from time to time, the changes that
Google made)

as one of the owners listed in the code.google.com project (same name),
and the original author, you certainly have my approval for inclusion in
python.

On Wed, Sep 24, 2008 at 9:07 PM, Martin v. Löwis <[email protected]> wrote:

Martin v. Löwis <[email protected]> added the comment:
I see a list of owners in the code (although it's difficult to infer
real names or email addresses from that list). I think we should not
include the code without their explicit approval.

I know they *want* this to happen, no worries on this front.

The question will then always be: what is the official master copy of
the code? The one in Python, or the one on Google code? Whose
responsibility would it be to keep those synchronized, and incorporate
changes from one copy into the other?

I would prefer if the copy in Python (say, 2.7) becomes the master copy,
and the copy on Google code eventually disappears (when interest in
older Python versions has died).

I'm in favor of this, and I believe the authors at Google are too --
it was written out of necessity, and once integrated, the need for a
separate Google copy will go away.

I would object to a mere fork of the code (i.e. where one of the regular
Python committers incorporates, from time to time, the changes that
Google made)

Agreed.

I'm the maintainer of IPy library. Another library for IPv4/IPv6
manipulation. The code is old (was written for Python 2.2?), but
released under BSD license. Main issue of this library: it's unable to
manipulation "invalid ranges": 10.20.4.0/30 is valid but
10.20.4.1-10.20.4.5 is invalid since it's not possible to create a
bitmask matching the range. I don't care if you choose Google library,
maybe better. But you might check IPy to reuse some idea ;-)

Ooops, the website: http://software.inl.fr/trac/wiki/IPy

Another Python library: http://erlug.linux.it/~da/soft/iplib/

Now that 2.6 and 3.0 are out of the way, how should we move forward?
Will a PEP be required?

Now that 2.6 and 3.0 are out of the way, how should we move forward?

I think some committer needs to take charge and work with the authors
on merging the code. If pmoody wants commit access, that should be set
up, and he should add it himself in a commit-after-review manner (with
an actual patch, including documentation and tests).

If he doesn't want to do the integration, some committer needs to
volunteer - I personally won't (lack of time).

In any case, we would need a copyright form signed, unless Guido can
confirm that the code is covered by some agreement between Google and
the PSF.

Will a PEP be required?

I doubt that; a quick announcement to python-dev might be sufficient
(in general, a PEP should only be done if dissent is likely). It
seems that Victor didn't actually disagree to integrating this
package; we should somehow encourage IPy users to review the code
and comment on the (possibly lack of) functionality.

I think this might be worth a look before any hard and fast decisions
are made :-

http://code.google.com/p/netaddr/

I'm biased ;) but I don't see what netaddr provides over ipaddr. it
also seems to be in the neighborhood of 50% slower (at least on my mac
mini).

pmoody@mini - 04:52 PM - ~/Downloads/ipaddr-1.0.1
-> python -m timeit 'import ipaddr;\
ipaddr.IP("1.1.1.1")'
10000 loops, best of 3: 46.2 usec per loop

pmoody@mini - 04:52 PM - ~/Downloads/netaddr-0.5.2
-> python -m timeit 'import netaddr;\
netaddr.IP("1.1.1.1")'
10000 loops, best of 3: 71.9 usec per loop

dealing with netmasks, the difference is even greater.
pmoody@mini - 04:52 PM - ~/Downloads/ipaddr-1.0.1
-> python -m timeit 'import ipaddr;\
ipaddr.IP("1.1.1.1/255.255.255.0")'
10000 loops, best of 3: 78.4 usec per loop

pmoody@mini - 04:49 PM - ~/Downloads/netaddr-0.5.2
-> python -m timeit 'import netaddr;\

netaddr.IP("1.1.1.1/255.255.255.0")'
1000 loops, best of 3: 247 usec per loop

(and it doesn't seem to deal with hostsmasked addresses).

it also seems to be layed out in an unintuitive way, treating address
ranges a something very different than network addresses. hopefully
someone who isn't intimately familiar with both libraries can comment,
but ipaddr feels a lot cleaner to me.

Performance shouldn't be a major concern here. Utility is more
important and the implementation can be optimized later.

My initial impression of netaddr is pretty good. One thing it has going
for it is documentation. The netaddr google page gives a really great
overview of the functionality provided. In comparison, the ipaddr-py
page is extremely sparse; the documentation in the repository is no
better (as there isn't really any).

There are a lot of minor things about ipaddr-py which are off-putting.
It uses a naming convention that's not like any real Python software I'm
familiar with. In particular, CamelCase method names really draw the
eye (in a bad way) and distract from the actual functionality being
provided. I assume that if ipaddr-py is selected for inclusion, the API
will be adapted to fit PEP-8. In comparison, netaddr appears to largely
comply with PEP-8 already.

Regarding the treatment of addresses versus address ranges, I prefer
netaddr's solution. An address is not the same as an address range. It
seems odd to try to represent them both with the same type as ipaddr-py
does. This feels somewhat APLesque (where everything is a vector),
which isn't bad in itself, but generally if I want to manipulate an IP
address, I'm not thinking about it as a list of one address. If I
wanted to do that, then I'd make a list and put the address in it. By
comparison, the separate CIDR type in netaddr makes a lot of sense. It
preserves a memory-efficient representation of the address range, but
does it with a different type than the fundamental address type.

This is far from a complete review of either library, obviously. I've
done little more than glance over the documentation of each and do a
small amount of interactive playing around. A lot more effort seems to
have gone into making netaddr accessible and appealing, and I think it
has succeeded. Perhaps if some documentation for ipaddr-py is written
it will be easier to see where that library excels. Of course, I assume
this is a prerequisite for inclusion in the standard library as well.

On Mon, Jun 1, 2009 at 4:51 PM, pmoody <[email protected]> wrote:

>>>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
> True
>
> ipaddr makes no distinction between two fundamentally different
> concepts -- to my mind, that is a serious flaw.

I don't see these a fundamentally different, I guess. can you
demonstrate how this equivalency makes ipaddr unusable?

Fortunately, it's not up for debate: RFC-791 defines an IP address as
a 32-bit number, with no provision for a mask. Networks are defined by
their address and their mask. To correctly model them in an
object-oriented system, we would say that a Network has-a Address,
certainly not that a Network is-a Address.

I haven't seen any new issues on code.google.com (and I haven't heard
of any being reported on the python bugtracker), so since you're using
this thread to report issues, can you elaborate?

I will go ahead and open issues on code.google.com.

have used it to develop software and will continue to use it to
develop software.

I'd like to hear from application developers outside of Google. The
two that have commented on this issue seem not to prefer ipaddr's API.

Clay

On Mon, Jun 1, 2009 at 7:51 PM, pmoody <[email protected]> wrote:

> For an example of why 192.168.1.1 != 192.168.1.1/32, look no further
> than ifconfig:
>
> # ifconfig en0 192.168.1.1/32
> # ifconfig en0
> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> inet 192.168.1.1 netmask 0xffffffff broadcast 192.168.1.1
> ...
>
> # ifconfig en0 192.168.1.1
> # ifconfig en0
> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> ...

what this shows is that your copy of darwin defaults to a /24
prefixlen; ipaddr assumes a /32 prefixlen. I don't see anything
particularly *more* intuitive with darwin, but in any event, it seems
to provide support for assuming a prefixlen when none is supplied.

The example demonstrates one case where the strings '192.168.1.1' and
'192.168.1.1/32' are not equivalent -- it wouldn't be hard to find
other examples -- yet you seem to think that (a) this is
Darwin-specific behavior, and that (b) this discrepancy is acceptable
and does not constitute a design flaw.

You're wrong on both fronts, since in fact all IP implementations
understand classful addressing (as per RFC-791), not just Darwin, and
your insistence on the equality of '192.168.1.1' and '192.168.1.1/32'
means that your library is unusable in applications that pass
ipaddr.IPv4 objects to ifconfig.

Clay

On Mon, Jun 1, 2009 at 8:05 PM, R. David Murray <[email protected]> wrote:

In pre-CIDR days, assuming a prefixlen of 24 for a 192.168.x.x address
made sense. Nowadays it is better not to make that assumption. So I
find ipaddr's default of 32 to be "safer" than using a class based default.

Sorry, but why should you determine what is better for my application?

The larger point, however, is that there _is_ a mask associated with the
address in ifconfig. There _must_ be one. So that is not an example
that shows that a separate address class is useful.

Again, you're wrong. The mask that you see in ifconfig is associated
with the network to which the interface is attached, not the interface
address. You also see a broadcast address in the ifconfig output, but
certainly you don't believe that the broadcast address is a property
of the interface address? No, of course not; it's a property of the
network to which the interface is attached -- just like the mask.

That's why we call it a "netmask".

As for an example of when the equivalence is useful, it is useful every
time I set up an access rule or route that applies to a single host.

Host routes are routes like all others -- they have a destination
address and a mask. That a host route has a prefix length of 32 does
not imply that the host route is equivalent to the host address.
You're confusing the two concepts.

Most networking
software that I've dealt with requires explicit netmasks (often with a
shorthand to specify an ip/hostmask pair).

By "ip/hostmask" pair, you actually mean "ip/netmask" pair, and yes,
this is a convenient notation for expressing two distinct but related
concepts: an address, and a mask. Addresses do not have masks;
networks do. I am not sure how to be any more clear about that point,
yet you still seem not to understand.

It is true that when a
netmask isn't required it generally defaults to the classful netmask,
but having such a default is becoming more rare with time, in my
experience (because of CIDR).

I'm not advocating classful routing, I'm merely stating (emphatically
and without ambiguity) that addresses and networks are different:
networks have masks; addresses do not. The ipaddr library forces a
mask on me every time I specify an address. In my view, that is a
design flaw.

Clay

On Mon, Jun 1, 2009 at 9:03 PM, pmoody <[email protected]> wrote:

> ifconfig: 255.255.255.0/32: bad value
>
> That's because ipaddr wrongly appends a prefix length to all
> ipaddr.IPv4 objects, even those representing addresses, which do not
> have prefix lengths.

I'm not sure what you're trying to do here, can you elaborate?

Let's say I have a UI that prompts users for two pieces of
information: interface address, and network mask. I then take those
two strings and make ipaddr.IPv4 objects out of them. This lets me
validate their correctness, and lets me perform convenient
calculations and tests (things the ipaddr library has done well).
Next, I take the IPv4 objects, coerce them to strings, and pass them
to ifconfig to configure an interface.

Assuming the user has supplied this information:

Interface address = '192.168.1.1'
Network mask = '255.255.255.0'

the following would get passed to ifconfig:

ifconfig en0 192.168.1.1/32 netmask 255.255.255.0/32

Clearly this is not what we expect, nor even legal. The principle of
least surprise is violated here, if nothing else.

We could work around this, of course, but why should we have to work
around our libraries when simply fixing them isn't that hard?

> if isinstance(address, ipaddr.IPv4):
> if address.prefixlen != 32:
> raise TypeError("Expecting IP address, not network")
> elif isinstance(address, ipaddr.IPv6):
> if address.prefixlen != 128:
> raise TypeError("Expecting IP address, not network")

i'm not sure what's onerous about this code. you're missing a
try/except around ipaddr.IP(), but otherwise it seems fine.

Your definition of onerous apparently differs from mine :)

In my own applications, when I'm expecting a network, I use an
IPNetwork class, and when I'm expecting an address, I use an IPAddress
class. This means I can simply rely on the class constructors to do
the type checking for me. With ipaddr, I have to do the validation
myself. Simple isinstance() testing and duck typing don't work because
networks and addresses are represented (wrongly) by the same class.

it's actually already been included, but that's beside the point. I'm
now asking you a second time to submit bug reports if there are issues
which you see; perhaps these 'myriad of quirks' can be fixed, perhaps
not. yelling here doesn't actually do anything productive.

Rest assured, I've opened one issue and will open one or two more
before the night is out.

I'm sorry that you think "yelling" is unproductive. I happen to think
that healthy debate breeds better code.

Cheers,

Clay

On Mon, Jun 1, 2009 at 7:38 PM, Clay McClure <[email protected]> wrote:
>
> Clay McClure <[email protected]> added the comment:
>
> On Mon, Jun 1, 2009 at 9:03 PM, pmoody <[email protected]> wrote:
>
>>> ifconfig: 255.255.255.0/32: bad value
>>>
>>> That's because ipaddr wrongly appends a prefix length to all
>>> ipaddr.IPv4 objects, even those representing addresses, which do not
>>> have prefix lengths.
>>
>> I'm not sure what you're trying to do here, can you elaborate?
>
> Let's say I have a UI that prompts users for two pieces of
> information: interface address, and network mask. I then take those
> two strings and make ipaddr.IPv4 objects out of them. This lets me
> validate their correctness, and lets me perform convenient
> calculations and tests (things the ipaddr library has done well).
> Next, I take the IPv4 objects, coerce them to strings, and pass them
> to ifconfig to configure an interface.
>
> Assuming the user has supplied this information:
>
> Interface address = '192.168.1.1'
> Network mask = '255.255.255.0'
>
> the following would get passed to ifconfig:
>
> ifconfig en0 192.168.1.1/32 netmask 255.255.255.0/32

I suppose that might be the case if you didn't know how to use ipaddr.
knowing that ipaddr accepts an ipaddress/netmask, I'd pass it

my_ip = ipaddr.IP('%s/%s' % (ipaddress, netmask))

and then check for any exceptions. I'd then ifconfig en0 str(my_ip)

Clearly this is not what we expect, nor even legal. The principle of
least surprise is violated here, if nothing else.

We could work around this, of course, but why should we have to work
around our libraries when simply fixing them isn't that hard?

>> if isinstance(address, ipaddr.IPv4):
>> if address.prefixlen != 32:
>> raise TypeError("Expecting IP address, not network")
>> elif isinstance(address, ipaddr.IPv6):
>> if address.prefixlen != 128:
>> raise TypeError("Expecting IP address, not network")
>
> i'm not sure what's onerous about this code. you're missing a
> try/except around ipaddr.IP(), but otherwise it seems fine.

Your definition of onerous apparently differs from mine :)

In my own applications, when I'm expecting a network, I use an
IPNetwork class, and when I'm expecting an address, I use an IPAddress
class. This means I can simply rely on the class constructors to do
the type checking for me. With ipaddr, I have to do the validation
myself. Simple isinstance() testing and duck typing don't work because
networks and addresses are represented (wrongly) by the same class.

so ipaddr doing this validation for the user actually could make some
sense, but this could be fixed by something as easy

  ipaddr.IP(ip, network=False)
or
  ipaddr.IP(net, network=True)

anyway (more below)...

> it's actually already been included, but that's beside the point. I'm
> now asking you a second time to submit bug reports if there are issues
> which you see; perhaps these 'myriad of quirks' can be fixed, perhaps
> not. yelling here doesn't actually do anything productive.

Rest assured, I've opened one issue and will open one or two more
before the night is out.

cool, I see that you did that. as an aside, this probably isn't the
best place for continued discussion on ipaddr. ipaddr has already been
shipped with python, so i'm not sure that debate on it's inclusion is
able to influence that decision. All of the folks who've worked on
ipaddr + the python committer are on [email protected]
(looks like you are too), so might I suggest we continue this
discussion there?

I'm sorry that you think "yelling" is unproductive. I happen to think
that healthy debate breeds better code.

I think debate is healthy, too. but I measure my success at a debate
by my ability to convince other people of my side. I find I have
better success when I listen other people and respond with respect.
yelling promotes neither of those.

Cheers,
/peter

Cheers,

Clay

----------

Python tracker <[email protected]>
<http://bugs.python.org/issue3959\>

Consider applications that need to validate addresses (or networks,
but not both) supplied as user input:

address = ipaddr.IP(input)

If that is a frequent need, it would be reasonable to add an API

address = ipaddr.IP(input, allow_mask=False)

which would raise an exception if a mask was specified (as an
old-style bit mask, or in CIDR form).

if isinstance(address, ipaddr.IPv4):
if address.prefixlen != 32:
raise TypeError("Expecting IP address, not network")
elif isinstance(address, ipaddr.IPv6):
if address.prefixlen != 128:
raise TypeError("Expecting IP address, not network")

With the current API, you don't need to write it in such a quirky
way. Instead

if address.numhosts != 1:
   raise TypeError("Expecting IP address, not network")

would do as well.

Given its myriad quirks

Well, you deliberately make it appear more quirky than it actually is.

I will go ahead and open issues on code.google.com.

If you want to see them fixed in Python, please report them to this
tracker.

On Tue, Jun 2, 2009 at 1:21 AM, Martin v. Löwis <[email protected]> wrote:

> I will go ahead and open issues on code.google.com.

If you want to see them fixed in Python, please report them to this
tracker.

I'd like to see the issues fixed upstream, and the library removed
from Python until it is satisfactory to the developers who will
actually use it. To my knowledge, every developer (outside of Google)
who has commented on the issue has indicated a preference for a
different API.

Thanks,

Clay

Consider applications that need to validate addresses (or networks,
but not both) supplied as user input:

address = ipaddr.IP(input)

if isinstance(address, ipaddr.IPv4):
if address.prefixlen != 32:
raise TypeError("Expecting IP address, not network")
elif isinstance(address, ipaddr.IPv6):
if address.prefixlen != 128:
raise TypeError("Expecting IP address, not network")

Support for this can be added (its too late for Python 3.1). User
input validation is a good use case. For now I suggest the simpler
code:

if '/' in input:
    raise TypeError("Expecting IP address")
address = ipaddr.IP(input)

Or for a more pedantic test prior to calling ipaddr.IP.

if re.match('^[0-9a-fA-F:.]+$', input):
    raise TypeError("Invalid characters in IP address")

Please file a feature request on bugs.python.org for this one if you
haven't already. We could add optional parameter(s) to ipaddr.IP to
enable only accepting host addresses or network addresses in the
future.

I'd like to see the issues fixed upstream, and the library removed
from Python until it is satisfactory to the developers who will
actually use it. To my knowledge, every developer (outside of Google)
who has commented on the issue has indicated a preference for a
different API.

That's not true - I'm outside of Google, and have not indicated such
a preference.

On Tue, Jun 2, 2009 at 2:18 AM, Martin v. Löwis <[email protected]> wrote:

> I'd like to see the issues fixed upstream, and the library removed
> from Python until it is satisfactory to the developers who will
> actually use it. To my knowledge, every developer (outside of Google)
> who has commented on the issue has indicated a preference for a
> different API.

That's not true - I'm outside of Google, and have not indicated such
a preference.

You've indicated no preference either way, and have said:

"I personally have no plans for using this library, or any other IP
address library"

I should think you would seek the opinion of those developers who
actually do have plans to use an IP address library. As far as I can
tell, every developer in that category, outside of Google, that has
commented on this issue here or in python-dev has advocated a
different API.

Clay

I should think you would seek the opinion of those developers who
actually do have plans to use an IP address library.

That's what this has been doing for the last 8 1/2 months.

As far as I can
tell, every developer in that category, outside of Google, that has
commented on this issue here or in python-dev has advocated a
different API.

Is there some sort of conspiracy theory-ish reason that a google
software engineer might be somehow unfairly influenced?

Cheers,
/peter

On Tue, Jun 2, 2009 at 2:52 AM, pmoody <[email protected]> wrote:

> As far as I can
> tell, every developer in that category, outside of Google, that has
> commented on this issue here or in python-dev has advocated a
> different API.

Is there some sort of conspiracy theory-ish reason that a google
software engineer might be somehow unfairly influenced?

From reading your comments and the code, it is clear that concepts
that aren't relevant at Google have been neglected. For that reason,
developers at Google who are already familiar with ipaddr might
consider its API quite natural because of their institutionalized
thinking. But since this library is now intended for general purpose
use outside Google, I should think it is important to consult
developers outside Google who have been exposed to a broader range of
IP addressing issues. I don't believe that "good enough for Google"
ought to be our acid test.

The fact that developers outside Google seem to prefer a different API
is not new -- comments in this issue dating back several months
reflect that fact. What I don't see is a comment that explains why
their concerns were not considered.

Clay

This issue is closed.

Please take discussion up on a mailing list.

Navigation Menu

Repository navigation

Add Google's ipaddr.py to the stdlib #48209

56 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Add Google's ipaddr.py to the stdlib #48209

Description

Activity

gvanrossum commented on Sep 24, 2008

benjaminp commented on Sep 24, 2008

gvanrossum commented on Sep 24, 2008

benjaminp commented on Sep 24, 2008

loewis commented on Sep 25, 2008

pmoody commented on Sep 25, 2008

gvanrossum commented on Sep 25, 2008

vstinner commented on Sep 30, 2008

vstinner commented on Sep 30, 2008

vstinner commented on Sep 30, 2008

benjaminp commented on Dec 22, 2008

loewis commented on Dec 22, 2008

drkjam commented on Dec 31, 2008

pmoody commented on Jan 1, 2009

exarkun commented on Jan 1, 2009

56 remaining items

claymation commented on Jun 2, 2009

claymation commented on Jun 2, 2009

claymation commented on Jun 2, 2009

claymation commented on Jun 2, 2009

pmoody commented on Jun 2, 2009

loewis commented on Jun 2, 2009

loewis commented on Jun 2, 2009

claymation commented on Jun 2, 2009

gpshead commented on Jun 2, 2009

loewis commented on Jun 2, 2009

claymation commented on Jun 2, 2009

pmoody commented on Jun 2, 2009

claymation commented on Jun 2, 2009

gpshead commented on Jun 2, 2009

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions