Package List for getting Limesurvey in the Fedora repos
| Package | Bug | Status | Review Ticket | Assigned to |
|---|---|---|---|---|
| Limesurvey | Waiting for dependencies to be packaged | 508817 | Sparks | |
| adodb | Packaged as php-adodb | |||
| datetimeconverter | have license, needs packaging | |||
| pchart | Awaiting Review | 549590 | Sparks | |
| php-gettext | Done | 544821 | ||
| php-mailer | Done | 505356 | ||
| domxml-php4-php5 | Done | 590777 | ||
| progressbar | ||||
| sha256 | This requires a patch to limesurvey to not use this - no packaging needed. | |||
| php-pear-Spreadsheet-Excel-Writer | Done | 542028 | ||
| php-pear-OLE | Done | 542500 | ||
| php-pear | Packaged as 1:php-pear | |||
| phpCAS | DONE | 573345 | ||
| phpzip | License issues | |||
| tcpdf | in phpMyAdmin (bug 548260). This is VERY painful to package - for the present, rrix has a patch to remove printable survey functionality so as to eliminate the need to package this immediately. | |||
| inputfilter | this has been modified - we need to see to what extent |
Limesurvey Next Steps
For next steps - we need (a) owners, and (b) generous estimates of durations for the tasks.
- Needs eyeballs: The steps below that Robyn has listed. What did I miss?
- IRC Roundup meeting: Let's set a date to discuss the steps below. It shouldn't be a separate weekly meeting - if we can nail down the following task / next steps, we can continue driving the actual schedule during a few minutes in each weekly marketing meeting.
Packaging
- We have a lot of packages listed above - some with issues, some with no bz listed (or at least bz's linked into the table). Are the packages without bz's already in fedora? If not, does every package need a bz, and if so (or if not, but there are outstanding pieces that do) - can someone take ownership of getting those bz's entered with appropriate information?
- We have a bunch of packages that need "fixing" because they are forked from the original package. What is the process we want to take for those packages, which packages are they, and how long will that take?
Limesurvey Infrastructure Deployment
- NEEDS OWNER: Need to complete How_to_set_up_a_limesurvey_sandbox. I (User:rbergero)) assume that a prerequisite here is having all the packages packaged properly. Once packaging is complete, what is a realistic time frame for completing the document?
- Testing (needs more detail - how long is the process, what info do we need to provide infrastructure with for testing, etc.) Do we need an official owner for this process?
- Actual Deployment: Do we need to do anything here once testing is done or do we just assume it will get deployed?
- Requesting surveys.fp.o as a name - do we want to do this? If so - process?
- Tying FAS into Limesurvey. Do we think this is valuable? I think it could be - we could have setups like ambassadors being able to deploy a survey to survey their own group, etc. Or in general, making sure that only people who have signed the CLA can participate in specific surveys, and only participate once. I assume this is a longer-term project than packaging / deployment will take - is this something we want to put on the longer-term roadmap (F16ish)?
- Setting up an SOP on how to create a survey - Robyn Bergeron will take ownership of this task, to be done around the same time that testing is completed.
Overall Timeline
Need dates for task completion, ownership / commitment to getting it done. I want to give us plenty of time here - we're not under pressure of having it done by $certaindate - but I'd like to see this piece of infrastructure come to fruition so that marketing can use it. We should just be realistic and consider all the other projects we're working on when committing to dates. Once we have durations for tasks, Robyn will work on an actual master schedule of sorts, taking into consideration working around all the other stuff we're committed to.
Marketing TRAC Items
Robyn will make tickets in the Marketing Trac list for all related task items and link in a customized report for those here. This will be more of the testing / deployment / SOP items, not the BZ's for packages - no need to be making redundant tickets for those items.