[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Debconf-team] Registration: Are we sticking with Pentabarf, or leaving it behind?



Hi,

Following Felix's post in another thread:

> After the global team meeting today we want to revive the discussion on
> the dates for opening register, and deadlines for (travel, sleep and
> food) sponsorship application and talk submission.

It's time for us to consider a basic point for those dates and
deadlines.

Since 2007, DebConf has run based on the Pentabarf conference
management system. Compared with the systems we had before it, Penta
allowed us for a great flexibility that impacted even our work
organization. However, it might be time to move away. Penta is:

‣ Dead upstream (or so it seems)
‣ Very hard to set up (so those of us who have hacked on it have not
  done so with local installations: There is a master, live copy, and
  a staging/testing server, and that's that)
‣ The user interface has long confused many (if not all) of us. And
  it's not that we are a bunch of computer-illiterate guys.
‣ The user interface is not friendly towards smaller-screen devices

However, finding a replacement is much easier said than done. The
latest runner-up for this is a beast called "Frab"¹. Its main
attraction is that it has a helper for migrating from Penta (we don't
want to lose information/history!) However, it's advertised as:

    Frab is under heavy development. There is no stable release
    yet. You may want to try to use frab regardless, but be warned,
    that it may be a rocky ride.

    That being  said, frab is being  used to organize  FrOSCon 2011, a
    conference with more than 60  talks (and as many speakers) in more
    than 5 parallel tracks over 2 days.

So, I fear it will bring more than Goddess Meditations our way. There
are many issues. I have not yet taken a good look at it, but this is
what I remember, in no particular way:

• DebConf handles a lot of specific data, and –in order to deviate
  from upstream as little as possible– we have implemented it with a
  tablespace of our own, keeping the upstream DB structure
  untouched. I am not really sure on how we will manage to merge with
  it. Not impossible, certainly, but not trivial.
• Frab is not I18N-friendly (English strings are specified literally
  and with no L10N functionality, straight in the views)
• There is a *lot* of functionality we'd have to re-develop during the
  next couple of months. For sure, the travel sponsorship subsystem
  and the video workflow, and quite probably other bits. We would
  probably switch some of our procedures to match the system in other
  areas.
• On the bright side, Frab is closer to "traditional" Rails. This
  means, no longer bending around Momomoto's strange idiosincracy.
• Frab's coding style looks quite straightforward to follow.

What is my opinion here? I think moving over to Frab would be a net
win. However, I don't think we can commit to doing it during the
next ~two months (at least, I most probably won't). This is a task
that should be done with enough time and testing to catch many corner
cases. Specially if we want to import all of the history since 2007
and not lose even one Assassins kill.

So, if you have anything to say in this regard, please do so. Now. I
committed to determining a week from now whether we are sticking to
the Pentabarf Goddess or we go Frab ourselves instead. Or we could go
another route, if you suggest an alternate implementation.

Also, are you interested in helping with this process? Whatever the
result, now is the time to do so!

¹ https://github.com/oneiros/frab

Attachment: signature.asc
Description: Digital signature


Reply to: