Port pift_server to Drupal 6
Gábor Hojtsy - January 21, 2009 - 17:17
| Project: | Project issue file testing |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
| Issue tags: | drupal.org upgrade |
Jump to:
Description
Creating issue for the drupal.org upgrade process to keep track of testing the 6.x branch server.

#1
I think you want PIFT queue?
#2
Ugh, yup. Looks like the platform was separated from the file tester. Sorry, I am not involved closely enough in this. Since the server is not on 6.x at all, retitling for the port.
#3
PIFT is the code that runs on d.o.
PIFR is the code that runs on testing clients (computers that run tests), and t.d.o to manage testing and aggregate results back to d.o
#4
all code is ported to 6.x except the failed test mailing functionality (which we're not using on d.o yet anyways). i do need to test things a bit, but we're close.
#5
oo...and ahead of schedule!
#6
ok, ran into some snags. the file API changed the database structure for both upload module and comment_upload module. this means that the file-related queries in the module will need to be updated/rewritten, along with any other core/comment_upload changes in form structure, etc.
on the good side, i fixed and tested the 5.x -> 6.x database upgrade for the module. there are some schema changes necessary, but mostly just to bring the 5.x db structure into place with the 6.x approach of doing inserts, and making sure the fields have consistent attributes -- no new or changed columns.
also, i fixed and tested the file import script that i originally used to import patch files. this script supports entering a range of file ID's, so it can be used to import missing files in the case where PIFT has been disabled on a site, to catch the file uploads that were submitted while it was off. all this means that even if i don't have the module itself working by the time d.o is upgraded, we can just leave it disabled and use the script to catch up when the module is fully ported.
#7
this is now complete and committed.
#8
Should the mail stuff just be removed? If anything I think it makes more sense for subscription to issue type notification.
#9
Automatically closed -- issue fixed for 2 weeks with no activity.