Hello Benjamin. I am the other volunteer for this project. Are we both new to this procedure or is it just me?
I have not used a bakery or a forge from the project-admin end of things. How complicated does versioning need to be? By what I gather we just need them to be able to click "add version", type in the new version number, then upload whatever contents they want in it. Is this right? If I understand this correctly we can discuss the database design on it Benjamin. As far as uploads go, where are the uploaded files being stored? If it is on the filesystem I do not see the benefit of a virtual filesystem structure. Rating system looks good. It is early to be talking about performance and caching features, but as a future thought we could avoid pulling every user rating to calculate the average if we just put a couple extra fields in the projects table. Licensing is hardly my category so I will let you work that one out with Wombert ;) - Eric On Tue, Apr 14, 2009 at 4:26 PM, Benjamin Börngen-Schmidt < [email protected]> wrote: > Hey there, > > I'm benjamin, also known on IRC as benschi. I started working on the > Redracer project about 1,5 weeks ago, but since then I haven't done that > much. Currently I already did the basic DB layout (see attached graphic), > made a very, very, very basic design and added login and logout > functionallity. > For Coding I use Agavi, Doctrine and ADT which should do it for the > beginning. What I'm still looking for is a good markup for descriptions and > some good library for code highlighting. Any ideas on that are welcome! > > Hi guys, >> >> it's time to RedRacer now that both benschi and erisco have offered to >> work on it. My role in this project will mostly be a managerial one, >> although I will look over the code regularly to make sure it meets our best >> practices. >> >> I'd like all dev related discussions to happen here on this list. >> >> Trac and SVN are set up at http://www.redracer.org/ >> >> I have added two milestones, and will add the major feature tickets once >> we have discussed them. >> >> Right now, the focus is *not* on multitenancy, that'll be reserved for >> 2.0. Version 1.0 should only have basic features. >> >> Benjamin and I have discussed those already, but I'll put them up for >> discussion here again: >> >> - Users (registration, simple profile) >> > As you will see in the UML Diagram of the DB the user features for the > first version are very basic, like username, email, password. But I think > this should be enough for the first version, since we can easily extend > this! > > - Projects >> > There is one thing about the projects which bugs me. Versioning. Right now, > if a project will evolve to its next stage this cannot be reflected in DB > projects table, since there is only one description field. Maybe bringing up > a new table called project_versions could handle this. Then the descriptions > should be saved in a new table as well with FK projectid, versionid. > Also Projects can be of a different type, like a module, a model, some > external libaray integration or what ever. Just wanted to point it out, so > noone can say "Hey you never said that" :) > > - Downloads/Releases >> > I thought about this quite a while and I came to the conclusion that this > could be reflected in the DB as a nested set. So we have all the meta data > in the DB and do not need to read from the filesystem each time on a > request. Basicly rebuilding the physical folder structure in the DB. Also > there shouldn't be high performance issues, since these structures will only > be read most of the time and each project will have its one tree. > >> - Comments >> - Ratings, although we might consider using a "stack" like Ohloh's >> exclusively, and no ratings at all (I've read a blog post about that >> somewhere recently, but can't remember where or how) >> > I would go for rating! We can implement Stacks in lets say version 1.1. But > sometimes you use a project once for a special purpose but never again, why > would I stack it then? I would just stack things I use really often eg. ADT > >> - "Tip of the hat" and "Wag of the finger" (where Agavi core devs can say >> "this is awesome, we recommend it" or "this is not good because it breaks x >> or is insecure or defeats purpose bleh") - separate from ratings >> > As observant readers might have noticed (when they have looked at the UML) > I called it project_approvals the status and reason fields should tell their > story > > >> For future releases, there'd be stuff like: >> - Tags >> - Dependencies >> - Remote package installs (that mostly requires an infrastructure in >> Agavi, not in the forge, and is specific to forge.agavi.org) >> - Multitenancy support (so that RedRacer is a real software, with a bunch >> of user-editable config files to control templates, settings etc) >> - Magic >> >> Two non-technical questions: >> - I think we should have Contributor License Agreements; anyone has >> objections? It would be the standard Apache CLA. >> > Well that is one thing i have no thought about yet. But shouldn't it be up > to the Contributer to descide which license he wants to use for his > contribution? > > - What license do we use? >> > What speaks against some GPL license eg. GPLv3? We had a very short > discussion about it on IRC and back then we agreed on GPLv3 for Redracer. > > >> Cheers, >> >> - David_______________________________________________ >> Agavi Dev Mailing List >> [email protected] >> http://lists.agavi.org/mailman/listinfo/dev >> > --- > Benjamin Börngen-Schmidt > [email protected] > > > > > _______________________________________________ > Agavi Dev Mailing List > [email protected] > http://lists.agavi.org/mailman/listinfo/dev > >
_______________________________________________ Agavi Dev Mailing List [email protected] http://lists.agavi.org/mailman/listinfo/dev
