change trac 'component' names

[warner]

The 'code' component needs to be broken up into smaller pieces. Let's enumerate those pieces here for a few weeks and then I'll go into trac and add the new names.

• introducer / peer connection establishment
• peer selection (upload)
• peer selection (download)
• file encoding / decoding
• vdrive maintenance (including filetree work)
• local web ui
• other ui approaches (FUSE, 'allmydata-tahoe cp' commands, etc)
• storageserver service/remoteinterface

others?

[zooko]

We're not sure that we actually want more "component" names. Maybe we want less component names.

In cases like this, I like to think "imperatively" rather than "declaratively". Rather than asking: "What should be?", I like to ask "How should we act?".

With regard to component names I currently don't use them for anything. I tried using them to narrow down the field in order to find specific tickets I was looking for, but I frequently guessed wrong about what "component" the ticket would be filed under, which slowed down my search rather than speeding it up. Nowadays, I just look at the entire list and scan with my eyes, or else use the search field to search all tickets. I don't use the "component" field for anything.

[warner]

I'm looking at the 35 'code' tickets that we have, and I find that I want to classify them by functional area, possibly so I can visually find them more easily, possibly so I can get a sense of how much work we need to do on various parts of our roadmap.txt .

The categories I'm seeing are:

• performance (memory consumption, network efficiency, speed): #29, #54
• storage: #90
• peer selection: #96
• frontend interfaces: #53, #36, #48, #95, #32, #33, #39, #52, #73, #74, #78, #89, #92, #94
• node admin: #71, #72, #83
• encoding: #86, #5, #87

[warner]

I'm going to create the following code- components now:

• performance
• storage
• peer selection
• frontend
• frontend-web
• node-admin
• encoding
• network (upnp, stun, relay, introduction)

[warner]

done