Confirmed users
241
edits
Bugzilla:Meetings: Difference between revisions
→Wednesday, 27 August 2014
| Line 31: | Line 31: | ||
#* i'd prefer for this to be implemented upstream, but will make a bmo extension if the upstream policy is to remain | #* i'd prefer for this to be implemented upstream, but will make a bmo extension if the upstream policy is to remain | ||
#* [sgreen] Although I hate adding more params, I think there should be a param for this, so that site admins can determine whether they want this feature or not. An even better option is to have a param that takes a group as its input, and you need to be in that group to see this option. My concern is that newbies would use this option when making an important comment, and the developers (bug watchers) wouldn't be notified. Just like a can do on MoWiki. | #* [sgreen] Although I hate adding more params, I think there should be a param for this, so that site admins can determine whether they want this feature or not. An even better option is to have a param that takes a group as its input, and you need to be in that group to see this option. My concern is that newbies would use this option when making an important comment, and the developers (bug watchers) wouldn't be notified. Just like a can do on MoWiki. | ||
# [dkl] Ideas on how to do upgrade automated testing using Travis CI. Hosting landfill dumps for Travis CI workers to download and import turned out be a bad idea and is no longer possible and so we need a new method. | |||
#* Maybe generate the test data systematically using a script for each version of the database being upgraded? | |||
#* Just use the blank database created by checksetup.pl, upgrade to new version and run checksetup.pl and just test schema updates and not worry about data migration? | |||
# Add other items here. | # Add other items here. | ||