Custom Query (1173 matches)
Results (109 - 111 of 1173)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#127 | FIXED | move mailing list to new server | ||
Description |
We currently have a development-focused mailing list on the social server. We want to move this over to our own server. OpenHatch has a `devel@openhatch.org <mailto:devel@openhatch.org>`_ mailing list. I was thinking we'd do the same and create `devel@mediagoblin.org <mailto:devel@mediagoblin.org>`_ . I have mailman already set up, so the things that need to be done are: 1. test the mailman installation 2. create the list 3. tell the people on the old list, "yo, we've moved the list--subscribe to the new one" 4. figure out what to do with archives (gmane?) |
|||
#128 | fixed | move bug tracker | ||
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. |
|||
#50 | FIXED | mongodb not scaling down: workaround and documentation | ||
Description |
mongodb needs 0.5 GB for a fresh install. Half of this goes to kombu. kombu could use redis or some other transport (see `#322 </issues/322>`_), so fixing `#322 </issues/322>`_ will help this issue too. mongodb database files contain a lot of NUL bytes. So one can easily use sparse files to save space on disk: :: # service mongodb stop # cd /var/lib/ # cp -a --sparse=always mongodb mongodb.new # mv mongodb mongodb.old # mv mongodb.new mongodb # service mongodb start # # TEST mongodb # rm -rf mongodb.old Maybe later versions of mongodb do this already internally. The above was needed on mongodb from debian/stable. Documenting the "make sparse" possibility will also help this issue. |
Note:
See TracQuery
for help on using queries.