Heyho, i just created DC11 entry in our production pentabarf, with a set of days for it. No rooms or anything else, no logo. But any pentabarf admin can now easily modify that conference entry (dont press "Delete" :) ). You most probably want to put a logo there, change names of days, add rooms, modify css. I then looked at the first changes I see in git for pentabarf. Few comments: - I disagree with plainly removing fields from the pentabarf rxml files. If you don't want them in one conference, do set an "if" around them and check for conference_id. If you plainly delete them you break the display of prior conferences. Moving them would be fine, but plain delete is bad. (What happens is that, when someone visits a prior debconf entry and hits save, the data for that field would be lost. And we do allow people to see their last year entry. And admins anyways.) - The submission_controller save_person has a hack that enables to block certain changes. Which is what we want after the apply deadline. But right now this needs to be deactivated. Comment it out. You will see what i mean when you check for a if/elsif chain involving lots of numbers right at the beginning of def save_person Its a set of multiple blocked things, you may want to allow them all for now. down until POPE.user.person_id. - Ensure that any new database field, if any, is only in our debconf tables and dont ever add to the "upstream" pentabarf. Also, any change to database, please save them. in skinner there is /srv/penta/www/dc-penta for this with lotsa small .sql files. - I just made gwolf member of "pentabarf" group, which, besides the pentatest he already has, allows host access to skinner.debconf.org and appropriate sudo commands to do the fs-level works on pentabarf (git pull and stuff) And let me paste something I sent to Jimmy last year. Mostly still accurate: - It is located in /org/penta/www. The real app is in rails/ there. dc-penta contains *all* changes ever done to pentabarf. It *might* contain a file or two also that had just been quick notes on what to do when getting something special, but all the modifying things are for sure in there. And this is how it has to stay. Doing any changes? NOT, EVER, without placing the full SQL into a file, give it a meaningful name and place it in there. - In /org/penta/static we have the page visible on https://penta.debconf.org/. Feel free to update it for dc10. Its not much more than an unimportant placeholder, but maybe a little debconf-data svn commit is nice. - The code in /o/p/www is an *anonymous* checkout from git. And should always stay so, changes are not done here, only pull them from git! Of course best tested on cletus first. :) - I renamed the pentabarf group we had until now, to pentatest. It contains all the user with access to cletus. - I added a pentabarf group, this contains all the ones with access to skinner. Naturally pentatest can have about anyone working on pentabarf/DebConf. We do not care (much). Pentabarf will always be strictly limited. I think one person from the running/upcoming conference is enough, as there are *rarely* changes to be done on the system itself. At maximum I think we should have 2 of them, remember there are always the admins too to help out. (Database access for the few that need it is done via hostssl entries without host access!) - As on cletus, the pentabarf group can restart the mongrels cluster, in case there is really a code change it needs to know about. - The webinterface can have more people able to look in, but that should be similarly restricted. Dont give out more rights than absolutely needed (a reviewer doesnt need committee nor admin or somesuch for example), and be sure people know about the personal data stored in there and that they should keep it secret. -- bye, Joerg <Maulkin> db.oftc.net? * Maulkin thinks Ganneff is doing evil ldap stuff again <Maulkin> It's called the Ganneff fingerprint <Maulkin> If somethign has 'db.foo.blah' it's had Ganneff involved
Attachment:
pgptbdaRv_1aj.pgp
Description: PGP signature