On Sun, Mar 16, 2014 at 6:31 PM, Antonia Horincar < [email protected]> wrote:
> In this case, what should be the scope of the project then? Should I stick > on having remote attachments on Amazon S3 and Google Drive (or etc), or > should I look further into making deployment easier? > I have doubts about the suitability of the remote attachments project reflected in the ongoing discussion about whether this can be accomplished without code changes, as well whether remote attachment storage is widely useful itself. We can certainly come up with projects that are useful in a limited scope, but I have doubts as to whether this is of high priority for Bloodhound. Making deployment easier is certainly a very high priority for the Bloodhound project. If you are able to define a project around that yourself, then I would say to go for it. However, I can't really give you much guidance as to what are good approaches without doing some research myself, and I don't think I will have time to offer much feedback or guidance within the time frame of the submission. I would like to think that deployment to Google App Engine is possible, but I don't know anything about the platform, so you'll really be on your own to research that. Certainly feel free though to send us the ideas you have, along with any good documentation references and maybe we can offer some guidance. So depending on how you are feeling about the projects at this state, that potentially leaves you with not much to build on, and we certainly want you to have a good project to run with since we've already seen that you are very capable and follow-through on the project. It's getting a bit late to switch directions unfortunately, but we have a pretty good list of projects in the i.a.o issue tracker (1). If one of those is a good fit with your interests, we can work with you to narrow the scope and define the project over the next several days. What Gary mentioned earlier about "remote access to subversion repositories" is probably a good project. There is the long standing ticket #493 (2) in Trac, and the issue of not supporting remote Subversion repositories comes up fairly regularly on the trac-users mailing list (3). There is also the pubsub integration (4). I can't tell you off-hand which approach to take, but the scope is narrow enough that I could see finding time in the next few days to offer guidance. Anyway, I wanted to make sure you knew that even though we are short on time, there is no shortage of projects! Btw, you had asked about config.py. The code in there is not easy to understand, which is a fact that I'm well aware of after trying to fix some config.py defects in Trac over the past week. Essentially though, config.py is a wrapper for ConfigParser (5). The classes in config.py need to be documented better! (1) https://issues.apache.org/bloodhound/query?status=!closed&keywords=~gsoc (2) http://trac.edgewall.org/ticket/493 (3) https://groups.google.com/d/msg/trac-users/X-d7dZkv-QI/OmfH6ad5R14J (4) https://issues.apache.org/bloodhound/ticket/478 (5) http://docs.python.org/2.7/library/configparser.html
