Custom Query (1166 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (16 - 18 of 1166)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Ticket Resolution Summary Owner Reporter
#122 fixed set us up on openhatch Will Kahn-Greene
Description
I haven't checked out the state of things, so I don't know where
they're at.

MediaGoblin should have a solid presence on OpenHatch
(`http://openhatch.org/ <http://openhatch.org/>`_). This includes:


-  asking and answering the big questions on the project page
-  setting openhatch up to track our bitesized bugs (see issue
   `#382 </issues/382>`_)
-  getting a workflow set up so that when someone is interested in
   helping out, someone is notified and someone reaches out



#128 fixed move bug tracker Will Kahn-Greene Will Kahn-Greene
Description
This bug covers moving the bug tracker from bugs.foocorp.net to our
own server.

I asked on the mailing list whether people wanted to switch bug
trackers and there were no strong opinions.

My current problems with redmine are:


1. can't tag bugs -- useful for marking bugs as bitesized (bug
   `#382 </issues/382>`_)
2. mediocre search
3. I'm concerned it won't scale to hundreds of contributors

It's possible I can solve issue 1 if we had our own redmine
instance using a plugin or something. We can push off issue 3. No
one else seems to have problems with issue 2, so we can push that
off, too.

Given that, this bug covers:


1. researching redmine to learn how to set it up and run it
2. figuring out what to do about tags
3. getting a dump of the data from foocorp
4. importing the data into the new bug tracker
5. changing all the urls in the docs and web-site to point to the
   new instance
6. creating some kind of automated something that watches the old
   bug tracker for activity and tells people to use the new one

I'm going to try to get this done for 0.0.4.



#142 fixed Make sure we're using 100% efficient queries / indexes Christopher Allan Webber Christopher Allan Webber
Description
Every query we use should be able to efficiently use an index, yet
at the same time, we shouldn't create superflous indexes.

Related:


-  `http://kylebanker.com/blog/2010/09/21/the-joy-of-mongodb-indexes/ <http://kylebanker.com/blog/2010/09/21/the-joy-of-mongodb-indexes/>`_
-  `http://www.mongodb.org/display/DOCS/Indexing+Advice+and+FAQ <http://www.mongodb.org/display/DOCS/Indexing+Advice+and+FAQ>`_
-  `http://www.mongodb.org/display/DOCS/Indexes <http://www.mongodb.org/display/DOCS/Indexes>`_

Especially, we should play with using explain:

`http://www.mongodb.org/display/DOCS/Indexing+Advice+and+FAQ#IndexingAdviceandFAQ-Use{{explain <http://www.mongodb.org/display/DOCS/Indexing+Advice+and+FAQ#IndexingAdviceandFAQ-Use%7B%7Bexplain>`_}}.

Assigning to myself, but feel free to claim this if you're excited
about investigating.



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Note: See TracQuery for help on using queries.