Hi guys, As you know, I have taken up the task of adequating Frab to serve us as a Pentabarf replacement. However, I have not been able to devote as much resources as I'd like, and I really don't want to end up failing late and hard. Read: Staying with Pentabarf is untenable, we *really* want to move away from it.
Frab is a very readable, clean system. Its main shortcoming for our collective point of view is that it is built completely in The Rails Way, which means, it needs to live in its own Ruby Gems ecosystem (which means, it lives in a parallel universe to that of Debian packages, and it is full of some practices we regard as pernicious). Now, I'm asking for your help because... If I have to take the task by myself (as I have done), I know I will end up failing. I am quite short on time preparing the course I will soon start teaching, and I know that (at least for the first semester) it will take me even more time once classes start, late this month. The (very) little I have done so far is just to check how easy/hard to install is Frab (answer: It is not trivial, but the instructions work... Sometimes - That is, depending on the status of each of the branches. I have been told by the Frab devs that "master" is now in a proper state). Setting up a VM with the needed environment is quite easy. The needed task is now to bribe Ganneff into setting up an official instance - But there is not *too* much hurry for that as the installation would first require having Frab usable for us. Then comes programming. Out of the currently active controllers, most of the Pentabarf functionality we use is there, we only need to implement four controllers: In order of perceived complexity, - Assassins - Travel sponsorship - Volunteer - Video The Frab developers request we implement those as plugins, and not on the main tree, which makes sense and adds just a little complexity hurdle. As for the personal information, I am less confident our changes are doable as plugins. They are quite trivial to add in the base MVC - The fields we use (and which are mostly references to other tables, most per-conference-instance catalogs) are: - accomodation_preferences - arrived - debcamp_option - debcamp_work_plan - disabilities - food_preferences - nickname - reconfirmed - role_in_debian - role_in_deconf - room_preference Adjusting Frab to gather that basic information, if not done in a plugin fashion, is probably a simple work that should not take more than one evening (tops). Looking at our history, I think the natural way for us is to fork off master and start our own branch, trying to follow and sync along. Things will get messier along the years, as conference-specific fields and logic will accumulate. For example, we have used fields which have shown to be inoperant (i.e. photo_or_film_ok) and I'm not including here anymore, but in some instances we will want to keep for historical values. Some others follow a wrong model, but historical data depends on them (i.e. dc_conference_person was split after DC11 into role_in_debian and role_in_debconf). Anyway - The task is not *so* big, but I know I need help. Also, I need to no longer be the only guy who understands (or fakes understanding of) the Beast. Please step up and help! _______________________________________________ Debconf-discuss mailing list [email protected] http://lists.debconf.org/mailman/listinfo/debconf-discuss
