From 90311ca13679c6d9cde770e4c659f8ee9dbe65b6 Mon Sep 17 00:00:00 2001 From: Matthew Gaughan Date: Tue, 21 Oct 2025 15:19:13 -0700 Subject: [PATCH] updating with new human labels --- 102125_human_info_sample.csv | 1949 + analysis_data/102025_human_labels.csv | 61006 ++++++++++++++++++++++++ analysis_data/sampling_strat_check.R | 49 + dsl/human_sampling.R | 52 +- mgaughan-rstudio-server_30181212.out | 17 - 5 files changed, 63041 insertions(+), 32 deletions(-) create mode 100644 102125_human_info_sample.csv create mode 100644 analysis_data/102025_human_labels.csv create mode 100644 analysis_data/sampling_strat_check.R delete mode 100644 mgaughan-rstudio-server_30181212.out diff --git a/102125_human_info_sample.csv b/102125_human_info_sample.csv new file mode 100644 index 0000000..d49c140 --- /dev/null +++ b/102125_human_info_sample.csv @@ -0,0 +1,1949 @@ +"id","task_title","comment_text","date_created","AuthorPHID","TaskPHID","comment_type","text_for_analysis","cleaned_messages","priority","priority_score","date_closed","CloserPHID","status","time_flag","source","phase","author_closer","same_author","week_index","http_flag","olmo_cleaned_sentences","resolution_outcome","comment_index","isAuthorWMF","cleaned_sentences" +10828,"Newly-uploaded image doesn't immediately appear in image search results in VisualEditor","The good news: CirrusSearch is updated a few seconds after a page is added, changed, or deleted. +The bad news: it isn't ready yet!",1377001750,"PHID-USER-2rnfxoezl66afpa7w7in","PHID-TASK-zckv7xwfgl4cxjix23f5","task_subcomment","The good news: CirrusSearch is updated a few seconds after a page is added, changed, or deleted. +The bad news: it isn't ready yet!","The good news: CirrusSearch is updated a few seconds after a page is added, changed, or deleted. +The bad news: it isn't ready yet!",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,7,NA,"['The good news: CirrusSearch is updated a few seconds after a page is added, changed, or deleted.', ""The bad news: it isn't ready yet!""]",NA,3,TRUE,"The good news: CirrusSearch is updated a few seconds after a page is added, changed, or deleted." +10828,"Newly-uploaded image doesn't immediately appear in image search results in VisualEditor","The good news: CirrusSearch is updated a few seconds after a page is added, changed, or deleted. +The bad news: it isn't ready yet!",1377001750,"PHID-USER-2rnfxoezl66afpa7w7in","PHID-TASK-zckv7xwfgl4cxjix23f5","task_subcomment","The good news: CirrusSearch is updated a few seconds after a page is added, changed, or deleted. +The bad news: it isn't ready yet!","The good news: CirrusSearch is updated a few seconds after a page is added, changed, or deleted. +The bad news: it isn't ready yet!",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,7,NA,"['The good news: CirrusSearch is updated a few seconds after a page is added, changed, or deleted.', ""The bad news: it isn't ready yet!""]",NA,3,TRUE,"The bad news: it isn't ready yet!" +837,"VisualEditor: Dimensions of small images are lost in rendering","Re-checked on https://www.mediawiki.org/wiki/VisualEditor/Team - seems to be fixed.",1415912062,"PHID-USER-4alekd35in5tg53zpsl4","PHID-TASK-bd72y7iiei67kbxti76b","task_subcomment","Re-checked on https://www.mediawiki.org/wiki/VisualEditor/Team - seems to be fixed.","Re-checked on URL - seems to be fixed.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,71,NA,"['Re-checked on URL - seems to be fixed.']",NA,5,FALSE,"Re-checked on URL - seems to be fixed." +1278,"Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs","Both MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule). + +This is a proof of concept for doing this more broadly. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=54160",1374573300,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-w26cnf2uzn6whhzpd4p5","task_description","Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs./n/nBoth MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule). + +This is a proof of concept for doing this more broadly. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=54160","Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs./n/nBoth MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule). + +This is a proof of concept for doing this more broadly. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +URL","Needs Triage",90,1408666032,NA,"declined","True","c1",3,"True","False",3,NA,"['Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs.', 'Both MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired.', 'Vagrant currently has this, but Labs does not.', 'We should find a way to factor it out so the two environments can share it (possibly with a git submodule).', 'This is a proof of concept for doing this more broadly.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,89,TRUE,"Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs." +1278,"Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs","Both MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule). + +This is a proof of concept for doing this more broadly. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=54160",1374573300,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-w26cnf2uzn6whhzpd4p5","task_description","Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs./n/nBoth MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule). + +This is a proof of concept for doing this more broadly. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=54160","Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs./n/nBoth MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule). + +This is a proof of concept for doing this more broadly. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +URL","Needs Triage",90,1408666032,NA,"declined","True","c1",3,"True","False",3,NA,"['Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs.', 'Both MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired.', 'Vagrant currently has this, but Labs does not.', 'We should find a way to factor it out so the two environments can share it (possibly with a git submodule).', 'This is a proof of concept for doing this more broadly.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,89,TRUE,"Both MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired." +1278,"Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs","Both MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule). + +This is a proof of concept for doing this more broadly. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=54160",1374573300,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-w26cnf2uzn6whhzpd4p5","task_description","Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs./n/nBoth MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule). + +This is a proof of concept for doing this more broadly. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=54160","Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs./n/nBoth MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule). + +This is a proof of concept for doing this more broadly. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +URL","Needs Triage",90,1408666032,NA,"declined","True","c1",3,"True","False",3,NA,"['Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs.', 'Both MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired.', 'Vagrant currently has this, but Labs does not.', 'We should find a way to factor it out so the two environments can share it (possibly with a git submodule).', 'This is a proof of concept for doing this more broadly.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,89,TRUE,"Vagrant currently has this, but Labs does not." +1278,"Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs","Both MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule). + +This is a proof of concept for doing this more broadly. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=54160",1374573300,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-w26cnf2uzn6whhzpd4p5","task_description","Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs./n/nBoth MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule). + +This is a proof of concept for doing this more broadly. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=54160","Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs./n/nBoth MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule). + +This is a proof of concept for doing this more broadly. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +URL","Needs Triage",90,1408666032,NA,"declined","True","c1",3,"True","False",3,NA,"['Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs.', 'Both MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired.', 'Vagrant currently has this, but Labs does not.', 'We should find a way to factor it out so the two environments can share it (possibly with a git submodule).', 'This is a proof of concept for doing this more broadly.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,89,TRUE,"We should find a way to factor it out so the two environments can share it (possibly with a git submodule)." +1278,"Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs","Both MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule). + +This is a proof of concept for doing this more broadly. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=54160",1374573300,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-w26cnf2uzn6whhzpd4p5","task_description","Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs./n/nBoth MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule). + +This is a proof of concept for doing this more broadly. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=54160","Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs./n/nBoth MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule). + +This is a proof of concept for doing this more broadly. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +URL","Needs Triage",90,1408666032,NA,"declined","True","c1",3,"True","False",3,NA,"['Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs.', 'Both MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired.', 'Vagrant currently has this, but Labs does not.', 'We should find a way to factor it out so the two environments can share it (possibly with a git submodule).', 'This is a proof of concept for doing this more broadly.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,89,TRUE,"This is a proof of concept for doing this more broadly." +1278,"Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs","Both MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule). + +This is a proof of concept for doing this more broadly. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=54160",1374573300,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-w26cnf2uzn6whhzpd4p5","task_description","Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs./n/nBoth MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule). + +This is a proof of concept for doing this more broadly. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=54160","Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs./n/nBoth MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired. Vagrant currently has this, but Labs does not. We should find a way to factor it out so the two environments can share it (possibly with a git submodule). + +This is a proof of concept for doing this more broadly. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +URL","Needs Triage",90,1408666032,NA,"declined","True","c1",3,"True","False",3,NA,"['Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs.', 'Both MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired.', 'Vagrant currently has this, but Labs does not.', 'We should find a way to factor it out so the two environments can share it (possibly with a git submodule).', 'This is a proof of concept for doing this more broadly.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,89,TRUE,"--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL" +1279,"Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs","Yeah. It's not integrated with the normal Wikitech interface, but my understanding is it gets the job done (I haven't really used Labs-Vagrant, but I have a general understanding how it works).",1408666032,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-w26cnf2uzn6whhzpd4p5","task_subcomment","Yeah. It's not integrated with the normal Wikitech interface, but my understanding is it gets the job done (I haven't really used Labs-Vagrant, but I have a general understanding how it works).","Yeah. It's not integrated with the normal Wikitech interface, but my understanding is it gets the job done (I haven't really used Labs-Vagrant, but I have a general understanding how it works).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,59,NA,"['Yeah.', ""It's not integrated with the normal Wikitech interface, but my understanding is it gets the job done (I haven't really used Labs-Vagrant, but I have a general understanding how it works).""]",NA,140,TRUE,"Yeah." +1279,"Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs","Yeah. It's not integrated with the normal Wikitech interface, but my understanding is it gets the job done (I haven't really used Labs-Vagrant, but I have a general understanding how it works).",1408666032,"PHID-USER-dw53c5cb2qfhyemej57o","PHID-TASK-w26cnf2uzn6whhzpd4p5","task_subcomment","Yeah. It's not integrated with the normal Wikitech interface, but my understanding is it gets the job done (I haven't really used Labs-Vagrant, but I have a general understanding how it works).","Yeah. It's not integrated with the normal Wikitech interface, but my understanding is it gets the job done (I haven't really used Labs-Vagrant, but I have a general understanding how it works).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,59,NA,"['Yeah.', ""It's not integrated with the normal Wikitech interface, but my understanding is it gets the job done (I haven't really used Labs-Vagrant, but I have a general understanding how it works).""]",NA,140,TRUE,"It's not integrated with the normal Wikitech interface, but my understanding is it gets the job done (I haven't really used Labs-Vagrant, but I have a general understanding how it works)." +960,"Move VisualEditor Selenium test to VisualEditor repository","Requested by James Forrester at QA mailing list: + +http://lists.wikimedia.org/pipermail/qa/2013-August/000339.html + +-------------------------- +**Version**: unspecified +**Severity**: normal",1377688440,"PHID-USER-fz7hkyvt4jypl76ieyol","PHID-TASK-5xzxzrfm4dqssl7w5dix","task_description","Move VisualEditor Selenium test to VisualEditor repository./n/nRequested by James Forrester at QA mailing list: + +http://lists.wikimedia.org/pipermail/qa/2013-August/000339.html + +-------------------------- +**Version**: unspecified +**Severity**: normal","Move VisualEditor Selenium test to VisualEditor repository./n/nRequested by James Forrester at QA mailing list: + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1377696492,NA,"resolved","True","c1",3,"True","False",8,NA,"['Move VisualEditor Selenium test to VisualEditor repository.', 'Requested by James Forrester at QA mailing list:\n\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,4,TRUE,"Move VisualEditor Selenium test to VisualEditor repository." +960,"Move VisualEditor Selenium test to VisualEditor repository","Requested by James Forrester at QA mailing list: + +http://lists.wikimedia.org/pipermail/qa/2013-August/000339.html + +-------------------------- +**Version**: unspecified +**Severity**: normal",1377688440,"PHID-USER-fz7hkyvt4jypl76ieyol","PHID-TASK-5xzxzrfm4dqssl7w5dix","task_description","Move VisualEditor Selenium test to VisualEditor repository./n/nRequested by James Forrester at QA mailing list: + +http://lists.wikimedia.org/pipermail/qa/2013-August/000339.html + +-------------------------- +**Version**: unspecified +**Severity**: normal","Move VisualEditor Selenium test to VisualEditor repository./n/nRequested by James Forrester at QA mailing list: + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1377696492,NA,"resolved","True","c1",3,"True","False",8,NA,"['Move VisualEditor Selenium test to VisualEditor repository.', 'Requested by James Forrester at QA mailing list:\n\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,4,TRUE,"Requested by James Forrester at QA mailing list:\n\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal" +964,"Move VisualEditor Selenium test to VisualEditor repository","Resolved in https://gerrit.wikimedia.org/r/#/c/81486/",1377695195,"PHID-USER-fz7hkyvt4jypl76ieyol","PHID-TASK-5xzxzrfm4dqssl7w5dix","task_subcomment","Resolved in https://gerrit.wikimedia.org/r/#/c/81486/","Resolved in URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,8,NA,"['Resolved in URL']",NA,5,TRUE,"Resolved in URL" +8334,"VisualEditor: round-trip adjacent and nested annotations","VisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations. Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, http://en.wikipedia.org/w/index.php?title=Bose%E2%80%93Einstein_condensate&diff=prev&oldid=562481552). + +Both will lead to a DOM diff and thus likely to a dirty wikitext diff. + +Note that this only applies to existing content- merging identical annotations in new content is fine. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1372734720,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-kazpxbs6hxscszn2mj4j","task_description","VisualEditor: round-trip adjacent and nested annotations./n/nVisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations. Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, http://en.wikipedia.org/w/index.php?title=Bose%E2%80%93Einstein_condensate&diff=prev&oldid=562481552). + +Both will lead to a DOM diff and thus likely to a dirty wikitext diff. + +Note that this only applies to existing content- merging identical annotations in new content is fine. + +-------------------------- +**Version**: unspecified +**Severity**: normal","VisualEditor: round-trip adjacent and nested annotations./n/nVisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations. Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, URL + +Both will lead to a DOM diff and thus likely to a dirty wikitext diff. + +Note that this only applies to existing content- merging identical annotations in new content is fine. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Medium",50,1380845963,NA,"resolved","True","c1",3,"True","False",0,NA,"['VisualEditor: round-trip adjacent and nested annotations.', 'VisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations.', 'Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, URL\n\nBoth will lead to a DOM diff and thus likely to a dirty wikitext diff.', 'Note that this only applies to existing content- merging identical annotations in new content is fine.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,113,TRUE,"VisualEditor: round-trip adjacent and nested annotations." +8334,"VisualEditor: round-trip adjacent and nested annotations","VisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations. Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, http://en.wikipedia.org/w/index.php?title=Bose%E2%80%93Einstein_condensate&diff=prev&oldid=562481552). + +Both will lead to a DOM diff and thus likely to a dirty wikitext diff. + +Note that this only applies to existing content- merging identical annotations in new content is fine. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1372734720,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-kazpxbs6hxscszn2mj4j","task_description","VisualEditor: round-trip adjacent and nested annotations./n/nVisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations. Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, http://en.wikipedia.org/w/index.php?title=Bose%E2%80%93Einstein_condensate&diff=prev&oldid=562481552). + +Both will lead to a DOM diff and thus likely to a dirty wikitext diff. + +Note that this only applies to existing content- merging identical annotations in new content is fine. + +-------------------------- +**Version**: unspecified +**Severity**: normal","VisualEditor: round-trip adjacent and nested annotations./n/nVisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations. Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, URL + +Both will lead to a DOM diff and thus likely to a dirty wikitext diff. + +Note that this only applies to existing content- merging identical annotations in new content is fine. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Medium",50,1380845963,NA,"resolved","True","c1",3,"True","False",0,NA,"['VisualEditor: round-trip adjacent and nested annotations.', 'VisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations.', 'Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, URL\n\nBoth will lead to a DOM diff and thus likely to a dirty wikitext diff.', 'Note that this only applies to existing content- merging identical annotations in new content is fine.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,113,TRUE,"VisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations." +8334,"VisualEditor: round-trip adjacent and nested annotations","VisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations. Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, http://en.wikipedia.org/w/index.php?title=Bose%E2%80%93Einstein_condensate&diff=prev&oldid=562481552). + +Both will lead to a DOM diff and thus likely to a dirty wikitext diff. + +Note that this only applies to existing content- merging identical annotations in new content is fine. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1372734720,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-kazpxbs6hxscszn2mj4j","task_description","VisualEditor: round-trip adjacent and nested annotations./n/nVisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations. Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, http://en.wikipedia.org/w/index.php?title=Bose%E2%80%93Einstein_condensate&diff=prev&oldid=562481552). + +Both will lead to a DOM diff and thus likely to a dirty wikitext diff. + +Note that this only applies to existing content- merging identical annotations in new content is fine. + +-------------------------- +**Version**: unspecified +**Severity**: normal","VisualEditor: round-trip adjacent and nested annotations./n/nVisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations. Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, URL + +Both will lead to a DOM diff and thus likely to a dirty wikitext diff. + +Note that this only applies to existing content- merging identical annotations in new content is fine. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Medium",50,1380845963,NA,"resolved","True","c1",3,"True","False",0,NA,"['VisualEditor: round-trip adjacent and nested annotations.', 'VisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations.', 'Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, URL\n\nBoth will lead to a DOM diff and thus likely to a dirty wikitext diff.', 'Note that this only applies to existing content- merging identical annotations in new content is fine.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,113,TRUE,"Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, URL\n\nBoth will lead to a DOM diff and thus likely to a dirty wikitext diff." +8334,"VisualEditor: round-trip adjacent and nested annotations","VisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations. Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, http://en.wikipedia.org/w/index.php?title=Bose%E2%80%93Einstein_condensate&diff=prev&oldid=562481552). + +Both will lead to a DOM diff and thus likely to a dirty wikitext diff. + +Note that this only applies to existing content- merging identical annotations in new content is fine. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1372734720,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-kazpxbs6hxscszn2mj4j","task_description","VisualEditor: round-trip adjacent and nested annotations./n/nVisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations. Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, http://en.wikipedia.org/w/index.php?title=Bose%E2%80%93Einstein_condensate&diff=prev&oldid=562481552). + +Both will lead to a DOM diff and thus likely to a dirty wikitext diff. + +Note that this only applies to existing content- merging identical annotations in new content is fine. + +-------------------------- +**Version**: unspecified +**Severity**: normal","VisualEditor: round-trip adjacent and nested annotations./n/nVisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations. Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, URL + +Both will lead to a DOM diff and thus likely to a dirty wikitext diff. + +Note that this only applies to existing content- merging identical annotations in new content is fine. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Medium",50,1380845963,NA,"resolved","True","c1",3,"True","False",0,NA,"['VisualEditor: round-trip adjacent and nested annotations.', 'VisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations.', 'Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, URL\n\nBoth will lead to a DOM diff and thus likely to a dirty wikitext diff.', 'Note that this only applies to existing content- merging identical annotations in new content is fine.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,113,TRUE,"Note that this only applies to existing content- merging identical annotations in new content is fine." +8334,"VisualEditor: round-trip adjacent and nested annotations","VisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations. Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, http://en.wikipedia.org/w/index.php?title=Bose%E2%80%93Einstein_condensate&diff=prev&oldid=562481552). + +Both will lead to a DOM diff and thus likely to a dirty wikitext diff. + +Note that this only applies to existing content- merging identical annotations in new content is fine. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1372734720,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-kazpxbs6hxscszn2mj4j","task_description","VisualEditor: round-trip adjacent and nested annotations./n/nVisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations. Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, http://en.wikipedia.org/w/index.php?title=Bose%E2%80%93Einstein_condensate&diff=prev&oldid=562481552). + +Both will lead to a DOM diff and thus likely to a dirty wikitext diff. + +Note that this only applies to existing content- merging identical annotations in new content is fine. + +-------------------------- +**Version**: unspecified +**Severity**: normal","VisualEditor: round-trip adjacent and nested annotations./n/nVisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations. Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, URL + +Both will lead to a DOM diff and thus likely to a dirty wikitext diff. + +Note that this only applies to existing content- merging identical annotations in new content is fine. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Medium",50,1380845963,NA,"resolved","True","c1",3,"True","False",0,NA,"['VisualEditor: round-trip adjacent and nested annotations.', 'VisualEditor needs to preserve adjacent (even if identical) and additive elements that it internally treats as annotations.', 'Right now it often removes nested annotations (bug 49755) or merges adjacent annotations (bug 49873, URL\n\nBoth will lead to a DOM diff and thus likely to a dirty wikitext diff.', 'Note that this only applies to existing content- merging identical annotations in new content is fine.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,113,TRUE,"--------------------------\n**Version**: unspecified\n**Severity**: normal" +8336,"VisualEditor: round-trip adjacent and nested annotations","Also, don't cut annotations. This is what I suspect happened here: +http://en.wikipedia.org/w/index.php?title=List_of_Mystery_Science_Theater_3000_episodes&diff=prev&oldid=562488147",1372742791,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-kazpxbs6hxscszn2mj4j","task_subcomment","Also, don't cut annotations. This is what I suspect happened here: +http://en.wikipedia.org/w/index.php?title=List_of_Mystery_Science_Theater_3000_episodes&diff=prev&oldid=562488147","Also, don't cut annotations. This is what I suspect happened here: +URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,0,NA,"[""Also, don't cut annotations."", 'This is what I suspect happened here:\nURL']",NA,118,TRUE,"This is what I suspect happened here:\nURL" +8336,"VisualEditor: round-trip adjacent and nested annotations","Also, don't cut annotations. This is what I suspect happened here: +http://en.wikipedia.org/w/index.php?title=List_of_Mystery_Science_Theater_3000_episodes&diff=prev&oldid=562488147",1372742791,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-kazpxbs6hxscszn2mj4j","task_subcomment","Also, don't cut annotations. This is what I suspect happened here: +http://en.wikipedia.org/w/index.php?title=List_of_Mystery_Science_Theater_3000_episodes&diff=prev&oldid=562488147","Also, don't cut annotations. This is what I suspect happened here: +URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,0,NA,"[""Also, don't cut annotations."", 'This is what I suspect happened here:\nURL']",NA,118,TRUE,"Also, don't cut annotations." +1281,"Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs","[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.]",1378939553,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-w26cnf2uzn6whhzpd4p5","task_subcomment","[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.]","[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.]",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['[mass-moving from Tools>MediaWiki-Vagrant to separate product.', 'See bug 54041.', 'Filter bugmail on this comment.]']",NA,140,TRUE,"[mass-moving from Tools>MediaWiki-Vagrant to separate product." +1281,"Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs","[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.]",1378939553,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-w26cnf2uzn6whhzpd4p5","task_subcomment","[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.]","[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.]",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['[mass-moving from Tools>MediaWiki-Vagrant to separate product.', 'See bug 54041.', 'Filter bugmail on this comment.]']",NA,140,TRUE,"See bug 54041." +1281,"Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs","[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.]",1378939553,"PHID-USER-hgn5uw2jafgjgfvxibhh","PHID-TASK-w26cnf2uzn6whhzpd4p5","task_subcomment","[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.]","[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.]",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['[mass-moving from Tools>MediaWiki-Vagrant to separate product.', 'See bug 54041.', 'Filter bugmail on this comment.]']",NA,140,TRUE,"Filter bugmail on this comment.]" +3211,"VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown","Change 75785 had a related patch set uploaded by Catrope: +Fix the save button disappearing on certain pages in Firefox + +https://gerrit.wikimedia.org/r/75785",1374699991,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-nlgy7km52ntxkqvlqnu2","task_subcomment","Change 75785 had a related patch set uploaded by Catrope: +Fix the save button disappearing on certain pages in Firefox + +https://gerrit.wikimedia.org/r/75785","Change 75785 had a related patch set uploaded by Catrope: +Fix the save button disappearing on certain pages in Firefox + +GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"['Change 75785 had a related patch set uploaded by Catrope:\nFix the save button disappearing on certain pages in Firefox\n\nGERRIT_URL']",NA,526,FALSE,"Change 75785 had a related patch set uploaded by Catrope:\nFix the save button disappearing on certain pages in Firefox\n\nGERRIT_URL" +3210,"VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown","Change 75785 merged by jenkins-bot: +Fix the save button disappearing on certain pages in Firefox + +https://gerrit.wikimedia.org/r/75785",1374700767,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-nlgy7km52ntxkqvlqnu2","task_subcomment","Change 75785 merged by jenkins-bot: +Fix the save button disappearing on certain pages in Firefox + +https://gerrit.wikimedia.org/r/75785","Change 75785 merged by jenkins-bot: +Fix the save button disappearing on certain pages in Firefox + +GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"['Change 75785 merged by jenkins-bot:\nFix the save button disappearing on certain pages in Firefox\n\nGERRIT_URL']",NA,527,FALSE,"Change 75785 merged by jenkins-bot:\nFix the save button disappearing on certain pages in Firefox\n\nGERRIT_URL" +965,"Move VisualEditor Selenium test to VisualEditor repository","Change 81486 had a related patch set uploaded by Zfilipin: +Moved VisualEditor Selenium tests from browsertests repository + +https://gerrit.wikimedia.org/r/81486",1377694989,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-5xzxzrfm4dqssl7w5dix","task_subcomment","Change 81486 had a related patch set uploaded by Zfilipin: +Moved VisualEditor Selenium tests from browsertests repository + +https://gerrit.wikimedia.org/r/81486","Change 81486 had a related patch set uploaded by Zfilipin: +Moved VisualEditor Selenium tests from browsertests repository + +GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,8,NA,"['Change 81486 had a related patch set uploaded by Zfilipin:\nMoved VisualEditor Selenium tests from browsertests repository\n\nGERRIT_URL']",NA,716,FALSE,"Change 81486 had a related patch set uploaded by Zfilipin:\nMoved VisualEditor Selenium tests from browsertests repository\n\nGERRIT_URL" +963,"Move VisualEditor Selenium test to VisualEditor repository","Change 81490 had a related patch set uploaded by Zfilipin: +Added support for running VisualEditor to Jenkins job template + +https://gerrit.wikimedia.org/r/81490",1377696235,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-5xzxzrfm4dqssl7w5dix","task_subcomment","Change 81490 had a related patch set uploaded by Zfilipin: +Added support for running VisualEditor to Jenkins job template + +https://gerrit.wikimedia.org/r/81490","Change 81490 had a related patch set uploaded by Zfilipin: +Added support for running VisualEditor to Jenkins job template + +GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,8,NA,"['Change 81490 had a related patch set uploaded by Zfilipin:\nAdded support for running VisualEditor to Jenkins job template\n\nGERRIT_URL']",NA,717,FALSE,"Change 81490 had a related patch set uploaded by Zfilipin:\nAdded support for running VisualEditor to Jenkins job template\n\nGERRIT_URL" +962,"Move VisualEditor Selenium test to VisualEditor repository","Change 81490 merged by Cmcmahon: +Added support for running VisualEditor tests to Jenkins job template + +https://gerrit.wikimedia.org/r/81490",1377720850,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-5xzxzrfm4dqssl7w5dix","task_subcomment","Change 81490 merged by Cmcmahon: +Added support for running VisualEditor tests to Jenkins job template + +https://gerrit.wikimedia.org/r/81490","Change 81490 merged by Cmcmahon: +Added support for running VisualEditor tests to Jenkins job template + +GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,8,NA,"['Change 81490 merged by Cmcmahon:\nAdded support for running VisualEditor tests to Jenkins job template\n\nGERRIT_URL']",NA,718,FALSE,"Change 81490 merged by Cmcmahon:\nAdded support for running VisualEditor tests to Jenkins job template\n\nGERRIT_URL" +961,"Move VisualEditor Selenium test to VisualEditor repository","Change 81486 merged by jenkins-bot: +Moved VisualEditor Selenium tests from browsertests repository + +https://gerrit.wikimedia.org/r/81486",1377721181,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-5xzxzrfm4dqssl7w5dix","task_subcomment","Change 81486 merged by jenkins-bot: +Moved VisualEditor Selenium tests from browsertests repository + +https://gerrit.wikimedia.org/r/81486","Change 81486 merged by jenkins-bot: +Moved VisualEditor Selenium tests from browsertests repository + +GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,8,NA,"['Change 81486 merged by jenkins-bot:\nMoved VisualEditor Selenium tests from browsertests repository\n\nGERRIT_URL']",NA,719,FALSE,"Change 81486 merged by jenkins-bot:\nMoved VisualEditor Selenium tests from browsertests repository\n\nGERRIT_URL" +6268,"Jenkins: Use node-jscs as checkstyle for javascript coding style","Change 99596 had a related patch set uploaded by Krinkle: +Set up node-jscs, pass it, and configure in local Gruntfile + +https://gerrit.wikimedia.org/r/99596",1386297732,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","Change 99596 had a related patch set uploaded by Krinkle: +Set up node-jscs, pass it, and configure in local Gruntfile + +https://gerrit.wikimedia.org/r/99596","Change 99596 had a related patch set uploaded by Krinkle: +Set up node-jscs, pass it, and configure in local Gruntfile + +GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,22,NA,"['Change 99596 had a related patch set uploaded by Krinkle:\nSet up node-jscs, pass it, and configure in local Gruntfile\n\nGERRIT_URL']",NA,994,FALSE,"Change 99596 had a related patch set uploaded by Krinkle:\nSet up node-jscs, pass it, and configure in local Gruntfile\n\nGERRIT_URL" +6267,"Jenkins: Use node-jscs as checkstyle for javascript coding style","Change 99596 merged by jenkins-bot: +Set up node-jscs, pass it, and configure in local Gruntfile + +https://gerrit.wikimedia.org/r/99596",1386355303,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","Change 99596 merged by jenkins-bot: +Set up node-jscs, pass it, and configure in local Gruntfile + +https://gerrit.wikimedia.org/r/99596","Change 99596 merged by jenkins-bot: +Set up node-jscs, pass it, and configure in local Gruntfile + +GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,22,NA,"['Change 99596 merged by jenkins-bot:\nSet up node-jscs, pass it, and configure in local Gruntfile\n\nGERRIT_URL']",NA,996,FALSE,"Change 99596 merged by jenkins-bot:\nSet up node-jscs, pass it, and configure in local Gruntfile\n\nGERRIT_URL" +6265,"Jenkins: Use node-jscs as checkstyle for javascript coding style","Change 100732 had a related patch set uploaded by Krinkle: +Set up node-jscs, pass it, and configure in local Gruntfile + +https://gerrit.wikimedia.org/r/100732",1386727450,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","Change 100732 had a related patch set uploaded by Krinkle: +Set up node-jscs, pass it, and configure in local Gruntfile + +https://gerrit.wikimedia.org/r/100732","Change 100732 had a related patch set uploaded by Krinkle: +Set up node-jscs, pass it, and configure in local Gruntfile + +GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,23,NA,"['Change 100732 had a related patch set uploaded by Krinkle:\nSet up node-jscs, pass it, and configure in local Gruntfile\n\nGERRIT_URL']",NA,1000,FALSE,"Change 100732 had a related patch set uploaded by Krinkle:\nSet up node-jscs, pass it, and configure in local Gruntfile\n\nGERRIT_URL" +6264,"Jenkins: Use node-jscs as checkstyle for javascript coding style","Change 100732 merged by jenkins-bot: +Set up node-jscs, pass it, and configure in local Gruntfile + +https://gerrit.wikimedia.org/r/100732",1387317987,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","Change 100732 merged by jenkins-bot: +Set up node-jscs, pass it, and configure in local Gruntfile + +https://gerrit.wikimedia.org/r/100732","Change 100732 merged by jenkins-bot: +Set up node-jscs, pass it, and configure in local Gruntfile + +GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,24,NA,"['Change 100732 merged by jenkins-bot:\nSet up node-jscs, pass it, and configure in local Gruntfile\n\nGERRIT_URL']",NA,1017,FALSE,"Change 100732 merged by jenkins-bot:\nSet up node-jscs, pass it, and configure in local Gruntfile\n\nGERRIT_URL" +6263,"Jenkins: Use node-jscs as checkstyle for javascript coding style","Change 111963 had a related patch set uploaded by Krinkle: +[WIP] Set up node-jscs via Grunt (and pass it) + +https://gerrit.wikimedia.org/r/111963",1391746605,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","Change 111963 had a related patch set uploaded by Krinkle: +[WIP] Set up node-jscs via Grunt (and pass it) + +https://gerrit.wikimedia.org/r/111963","Change 111963 had a related patch set uploaded by Krinkle: +[WIP] Set up node-jscs via Grunt (and pass it) + +GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,31,NA,"['Change 111963 had a related patch set uploaded by Krinkle:\n[WIP] Set up node-jscs via Grunt (and pass it)\n\nGERRIT_URL']",NA,1093,FALSE,"Change 111963 had a related patch set uploaded by Krinkle:\n[WIP] Set up node-jscs via Grunt (and pass it)\n\nGERRIT_URL" +6262,"Jenkins: Use node-jscs as checkstyle for javascript coding style","Change 111963 merged by jenkins-bot: +Set up node-jscs via Grunt (and pass it) + +https://gerrit.wikimedia.org/r/111963",1395730881,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","Change 111963 merged by jenkins-bot: +Set up node-jscs via Grunt (and pass it) + +https://gerrit.wikimedia.org/r/111963","Change 111963 merged by jenkins-bot: +Set up node-jscs via Grunt (and pass it) + +GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,38,NA,"['Change 111963 merged by jenkins-bot:\nSet up node-jscs via Grunt (and pass it)\n\nGERRIT_URL']",NA,1168,FALSE,"Change 111963 merged by jenkins-bot:\nSet up node-jscs via Grunt (and pass it)\n\nGERRIT_URL" +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE,"""Leave Feedback"" link rendering as two lines in some fonts." +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE,"Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \" +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE,"User guide\" +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE," and \" +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE,"Leave\" +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE," and another one between \" +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE,"Leave\" +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE," and \" +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE,"feedback\" +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE,"." +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE,"My very first thought was that \" +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE,"Leave\" +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE," would be the switch for signing out of the beta test (note that I didn\" +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE,"s default font: DejaVu Sans." +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE,"Arial, so it causes a linebreak in the link." +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE,"Maybe one could make that space non-breaking and have the flyout widen instead?""" +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE,"URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal" +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE,"\n\nThe culprit, evidently is " +1354,"""Leave Feedback"" link rendering as two lines in some fonts","Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal",1374162000,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-pbxss6r2sg7qfrxykect","task_description","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up + +-------------------------- +**Version**: unspecified +**Severity**: normal","""Leave Feedback"" link rendering as two lines in some fonts./n/nUsing Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"" + +The culprit, evidently is ""Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"" + +URL + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1374162111,NA,"resolved","True","c1",3,"False","False",2,NA,"['""Leave Feedback"" link rendering as two lines in some fonts.', 'Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that ""I see an empty line between \'\'User guide\'\' and \'\'Leave\'\' and another one between \'\'Leave\'\' and \'\'feedback\'\'.', 'My very first thought was that \'\'Leave\'\' would be the switch for signing out of the beta test (note that I didn\'t click it ;-)""\n\nThe culprit, evidently is ""Ubuntu\'s default font: DejaVu Sans.', ""That's a bit wider than e.g."", 'Arial, so it causes a linebreak in the link.', 'Maybe one could make that space non-breaking and have the flyout widen instead?""', 'URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,79,TRUE,"That's a bit wider than e.g." +1280,"Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs","Does ::role::labs::vagrant satisfy this request? Applying it via the wikitech interface provisions the labs host with a copy of MediaWiki-Vagrant and then the `labs-vagrant` command can be used to manipulate roles and run puppet.",1408597771,"PHID-USER-ll6tmaogat2b5q7tnqas","PHID-TASK-w26cnf2uzn6whhzpd4p5","task_subcomment","Does ::role::labs::vagrant satisfy this request? Applying it via the wikitech interface provisions the labs host with a copy of MediaWiki-Vagrant and then the `labs-vagrant` command can be used to manipulate roles and run puppet.","Does ::role::labs::vagrant satisfy this request? Applying it via the wikitech interface provisions the labs host with a copy of MediaWiki-Vagrant and then the CODE command can be used to manipulate roles and run puppet.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,59,NA,"['Does ::role::labs::vagrant satisfy this request?', 'Applying it via the wikitech interface provisions the labs host with a copy of MediaWiki-Vagrant and then the CODE command can be used to manipulate roles and run puppet.']",NA,16,TRUE,"Does ::role::labs::vagrant satisfy this request?" +1280,"Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs","Does ::role::labs::vagrant satisfy this request? Applying it via the wikitech interface provisions the labs host with a copy of MediaWiki-Vagrant and then the `labs-vagrant` command can be used to manipulate roles and run puppet.",1408597771,"PHID-USER-ll6tmaogat2b5q7tnqas","PHID-TASK-w26cnf2uzn6whhzpd4p5","task_subcomment","Does ::role::labs::vagrant satisfy this request? Applying it via the wikitech interface provisions the labs host with a copy of MediaWiki-Vagrant and then the `labs-vagrant` command can be used to manipulate roles and run puppet.","Does ::role::labs::vagrant satisfy this request? Applying it via the wikitech interface provisions the labs host with a copy of MediaWiki-Vagrant and then the CODE command can be used to manipulate roles and run puppet.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,59,NA,"['Does ::role::labs::vagrant satisfy this request?', 'Applying it via the wikitech interface provisions the labs host with a copy of MediaWiki-Vagrant and then the CODE command can be used to manipulate roles and run puppet.']",NA,16,TRUE,"Applying it via the wikitech interface provisions the labs host with a copy of MediaWiki-Vagrant and then the CODE command can be used to manipulate roles and run puppet." +6258,"Jenkins: Use node-jscs as checkstyle for javascript coding style","Is there work being done to get this run on ci? I'd like to push this for Wikibase as well :)",1421137099,"PHID-USER-m2zne2efu3rgmre73nl7","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","Is there work being done to get this run on ci? I'd like to push this for Wikibase as well :)","Is there work being done to get this run on ci? I'd like to push this for Wikibase as well :)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,80,NA,"['Is there work being done to get this run on ci?', ""I'd like to push this for Wikibase as well :)""]",NA,1,FALSE,"Is there work being done to get this run on ci?" +6258,"Jenkins: Use node-jscs as checkstyle for javascript coding style","Is there work being done to get this run on ci? I'd like to push this for Wikibase as well :)",1421137099,"PHID-USER-m2zne2efu3rgmre73nl7","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","Is there work being done to get this run on ci? I'd like to push this for Wikibase as well :)","Is there work being done to get this run on ci? I'd like to push this for Wikibase as well :)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,80,NA,"['Is there work being done to get this run on ci?', ""I'd like to push this for Wikibase as well :)""]",NA,1,FALSE,"I'd like to push this for Wikibase as well :)" +6256,"Jenkins: Use node-jscs as checkstyle for javascript coding style","Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: + +* Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +* integration/config: https://gerrit.wikimedia.org/r/#/c/184592/",1421144139,"PHID-USER-m2zne2efu3rgmre73nl7","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: + +* Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +* integration/config: https://gerrit.wikimedia.org/r/#/c/184592/","Cool, thanks. I added CODE, although I didn't go through grunt since we are not running any other grunt jobs, yet: + +* Wikibase: URL +* integration/config: URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,80,NA,"['Cool, thanks.', ""I added CODE, although I didn't go through grunt since we are not running any other grunt jobs, yet:\n\n* Wikibase: URL\n* integration/config: URL""]",NA,2,FALSE,"Cool, thanks." +6256,"Jenkins: Use node-jscs as checkstyle for javascript coding style","Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: + +* Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +* integration/config: https://gerrit.wikimedia.org/r/#/c/184592/",1421144139,"PHID-USER-m2zne2efu3rgmre73nl7","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: + +* Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +* integration/config: https://gerrit.wikimedia.org/r/#/c/184592/","Cool, thanks. I added CODE, although I didn't go through grunt since we are not running any other grunt jobs, yet: + +* Wikibase: URL +* integration/config: URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,80,NA,"['Cool, thanks.', ""I added CODE, although I didn't go through grunt since we are not running any other grunt jobs, yet:\n\n* Wikibase: URL\n* integration/config: URL""]",NA,2,FALSE,"I added CODE, although I didn't go through grunt since we are not running any other grunt jobs, yet:\n\n* Wikibase: URL\n* integration/config: URL" +10827,"Newly-uploaded image doesn't immediately appear in image search results in VisualEditor","*** Bug 54777 has been marked as a duplicate of this bug. ***",1382572188,"PHID-USER-oetk6bbl6omm354ejz3b","PHID-TASK-zckv7xwfgl4cxjix23f5","task_subcomment","*** Bug 54777 has been marked as a duplicate of this bug. ***","*** Bug 54777 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,16,NA,"['*** Bug 54777 has been marked as a duplicate of this bug.', '***']",NA,37,FALSE,"*** Bug 54777 has been marked as a duplicate of this bug." +10827,"Newly-uploaded image doesn't immediately appear in image search results in VisualEditor","*** Bug 54777 has been marked as a duplicate of this bug. ***",1382572188,"PHID-USER-oetk6bbl6omm354ejz3b","PHID-TASK-zckv7xwfgl4cxjix23f5","task_subcomment","*** Bug 54777 has been marked as a duplicate of this bug. ***","*** Bug 54777 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,16,NA,"['*** Bug 54777 has been marked as a duplicate of this bug.', '***']",NA,37,FALSE,"***" +10826,"Newly-uploaded image doesn't immediately appear in image search results in VisualEditor","Marking WONTFIX as this is inherently fixed by CirrusSearch and lsearchd has been end of life'd and won't be improved further.",1383013054,"PHID-USER-oetk6bbl6omm354ejz3b","PHID-TASK-zckv7xwfgl4cxjix23f5","task_subcomment","Marking WONTFIX as this is inherently fixed by CirrusSearch and lsearchd has been end of life'd and won't be improved further.","Marking WONTFIX as this is inherently fixed by CirrusSearch and lsearchd has been end of life'd and won't be improved further.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,17,NA,"[""Marking WONTFIX as this is inherently fixed by CirrusSearch and lsearchd has been end of life'd and won't be improved further.""]",NA,38,FALSE,"Marking WONTFIX as this is inherently fixed by CirrusSearch and lsearchd has been end of life'd and won't be improved further." +6271,"Jenkins: Use node-jscs as checkstyle for javascript coding style","Is that a replacement for JSHint or unrelated?",1379433243,"PHID-USER-orzyp3dswemhdgdznro5","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","Is that a replacement for JSHint or unrelated?","Is that a replacement for JSHint or unrelated?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,11,NA,"['Is that a replacement for JSHint or unrelated?']",NA,95,TRUE,"Is that a replacement for JSHint or unrelated?" +6259,"Jenkins: Use node-jscs as checkstyle for javascript coding style","Sounds good to me Timo. That nicely scale up CI to developers :-)",1409164241,"PHID-USER-orzyp3dswemhdgdznro5","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","Sounds good to me Timo. That nicely scale up CI to developers :-)","Sounds good to me Timo. That nicely scale up CI to developers :-)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,60,NA,"['Sounds good to me Timo.', 'That nicely scale up CI to developers :-)']",NA,150,TRUE,"Sounds good to me Timo." +6259,"Jenkins: Use node-jscs as checkstyle for javascript coding style","Sounds good to me Timo. That nicely scale up CI to developers :-)",1409164241,"PHID-USER-orzyp3dswemhdgdznro5","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","Sounds good to me Timo. That nicely scale up CI to developers :-)","Sounds good to me Timo. That nicely scale up CI to developers :-)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,60,NA,"['Sounds good to me Timo.', 'That nicely scale up CI to developers :-)']",NA,150,TRUE,"That nicely scale up CI to developers :-)" +6257,"Jenkins: Use node-jscs as checkstyle for javascript coding style",">>! In T56218#972923, @adrianheine wrote: +> Is there work being done to get this run on ci? I'd like to push this for Wikibase as well :) + +You will need a package.json and a npm 'test' entry point with a devDependencies for grunt-jscs. From there we can add a Jenkins job that invokes 'npm test' and that should run jscs. + +Example: + +https://gerrit.wikimedia.org/r/#/c/100732/ + +More details at https://www.mediawiki.org/wiki/Continuous_integration/Test_entry_points#JavaScript :-)",1421140918,"PHID-USER-orzyp3dswemhdgdznro5","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment",">>! In T56218#972923, @adrianheine wrote: +> Is there work being done to get this run on ci? I'd like to push this for Wikibase as well :) + +You will need a package.json and a npm 'test' entry point with a devDependencies for grunt-jscs. From there we can add a Jenkins job that invokes 'npm test' and that should run jscs. + +Example: + +https://gerrit.wikimedia.org/r/#/c/100732/ + +More details at https://www.mediawiki.org/wiki/Continuous_integration/Test_entry_points#JavaScript :-)","QUOTE +QUOTE + +You will need a package.json and a npm 'test' entry point with a devDependencies for grunt-jscs. From there we can add a Jenkins job that invokes 'npm test' and that should run jscs. + +Example: + +URL + +More details at URL :-)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,80,NA,"[""QUOTE\nQUOTE\n\nYou will need a package.json and a npm 'test' entry point with a devDependencies for grunt-jscs."", ""From there we can add a Jenkins job that invokes 'npm test' and that should run jscs."", 'Example:\n\nURL\n\nMore details at URL :-)']",NA,152,TRUE,"Example:\n\nURL\n\nMore details at URL :-)" +6257,"Jenkins: Use node-jscs as checkstyle for javascript coding style",">>! In T56218#972923, @adrianheine wrote: +> Is there work being done to get this run on ci? I'd like to push this for Wikibase as well :) + +You will need a package.json and a npm 'test' entry point with a devDependencies for grunt-jscs. From there we can add a Jenkins job that invokes 'npm test' and that should run jscs. + +Example: + +https://gerrit.wikimedia.org/r/#/c/100732/ + +More details at https://www.mediawiki.org/wiki/Continuous_integration/Test_entry_points#JavaScript :-)",1421140918,"PHID-USER-orzyp3dswemhdgdznro5","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment",">>! In T56218#972923, @adrianheine wrote: +> Is there work being done to get this run on ci? I'd like to push this for Wikibase as well :) + +You will need a package.json and a npm 'test' entry point with a devDependencies for grunt-jscs. From there we can add a Jenkins job that invokes 'npm test' and that should run jscs. + +Example: + +https://gerrit.wikimedia.org/r/#/c/100732/ + +More details at https://www.mediawiki.org/wiki/Continuous_integration/Test_entry_points#JavaScript :-)","QUOTE +QUOTE + +You will need a package.json and a npm 'test' entry point with a devDependencies for grunt-jscs. From there we can add a Jenkins job that invokes 'npm test' and that should run jscs. + +Example: + +URL + +More details at URL :-)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,80,NA,"[""QUOTE\nQUOTE\n\nYou will need a package.json and a npm 'test' entry point with a devDependencies for grunt-jscs."", ""From there we can add a Jenkins job that invokes 'npm test' and that should run jscs."", 'Example:\n\nURL\n\nMore details at URL :-)']",NA,152,TRUE,"QUOTE\nQUOTE\n\nYou will need a package.json and a npm 'test' entry point with a devDependencies for grunt-jscs." +6257,"Jenkins: Use node-jscs as checkstyle for javascript coding style",">>! In T56218#972923, @adrianheine wrote: +> Is there work being done to get this run on ci? I'd like to push this for Wikibase as well :) + +You will need a package.json and a npm 'test' entry point with a devDependencies for grunt-jscs. From there we can add a Jenkins job that invokes 'npm test' and that should run jscs. + +Example: + +https://gerrit.wikimedia.org/r/#/c/100732/ + +More details at https://www.mediawiki.org/wiki/Continuous_integration/Test_entry_points#JavaScript :-)",1421140918,"PHID-USER-orzyp3dswemhdgdznro5","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment",">>! In T56218#972923, @adrianheine wrote: +> Is there work being done to get this run on ci? I'd like to push this for Wikibase as well :) + +You will need a package.json and a npm 'test' entry point with a devDependencies for grunt-jscs. From there we can add a Jenkins job that invokes 'npm test' and that should run jscs. + +Example: + +https://gerrit.wikimedia.org/r/#/c/100732/ + +More details at https://www.mediawiki.org/wiki/Continuous_integration/Test_entry_points#JavaScript :-)","QUOTE +QUOTE + +You will need a package.json and a npm 'test' entry point with a devDependencies for grunt-jscs. From there we can add a Jenkins job that invokes 'npm test' and that should run jscs. + +Example: + +URL + +More details at URL :-)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,80,NA,"[""QUOTE\nQUOTE\n\nYou will need a package.json and a npm 'test' entry point with a devDependencies for grunt-jscs."", ""From there we can add a Jenkins job that invokes 'npm test' and that should run jscs."", 'Example:\n\nURL\n\nMore details at URL :-)']",NA,152,TRUE,"From there we can add a Jenkins job that invokes 'npm test' and that should run jscs." +836,"VisualEditor: Dimensions of small images are lost in rendering","Images that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original. + +MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost. + + +For example, on https://www.mediawiki.org/wiki/VisualEditor/Team there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1379390340,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-bd72y7iiei67kbxti76b","task_description","VisualEditor: Dimensions of small images are lost in rendering./n/nImages that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original. + +MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost. + + +For example, on https://www.mediawiki.org/wiki/VisualEditor/Team there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150. + +-------------------------- +**Version**: unspecified +**Severity**: normal","VisualEditor: Dimensions of small images are lost in rendering./n/nImages that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original. + +MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost. + + +For example, on URL there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1415881118,NA,"resolved","True","c1",3,"True","False",11,NA,"['VisualEditor: Dimensions of small images are lost in rendering.', 'Images that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original.', 'MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost.', 'For example, on URL there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px).', 'The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,284,TRUE,"VisualEditor: Dimensions of small images are lost in rendering." +836,"VisualEditor: Dimensions of small images are lost in rendering","Images that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original. + +MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost. + + +For example, on https://www.mediawiki.org/wiki/VisualEditor/Team there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1379390340,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-bd72y7iiei67kbxti76b","task_description","VisualEditor: Dimensions of small images are lost in rendering./n/nImages that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original. + +MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost. + + +For example, on https://www.mediawiki.org/wiki/VisualEditor/Team there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150. + +-------------------------- +**Version**: unspecified +**Severity**: normal","VisualEditor: Dimensions of small images are lost in rendering./n/nImages that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original. + +MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost. + + +For example, on URL there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1415881118,NA,"resolved","True","c1",3,"True","False",11,NA,"['VisualEditor: Dimensions of small images are lost in rendering.', 'Images that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original.', 'MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost.', 'For example, on URL there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px).', 'The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,284,TRUE,"Images that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original." +836,"VisualEditor: Dimensions of small images are lost in rendering","Images that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original. + +MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost. + + +For example, on https://www.mediawiki.org/wiki/VisualEditor/Team there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1379390340,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-bd72y7iiei67kbxti76b","task_description","VisualEditor: Dimensions of small images are lost in rendering./n/nImages that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original. + +MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost. + + +For example, on https://www.mediawiki.org/wiki/VisualEditor/Team there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150. + +-------------------------- +**Version**: unspecified +**Severity**: normal","VisualEditor: Dimensions of small images are lost in rendering./n/nImages that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original. + +MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost. + + +For example, on URL there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1415881118,NA,"resolved","True","c1",3,"True","False",11,NA,"['VisualEditor: Dimensions of small images are lost in rendering.', 'Images that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original.', 'MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost.', 'For example, on URL there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px).', 'The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,284,TRUE,"MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost." +836,"VisualEditor: Dimensions of small images are lost in rendering","Images that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original. + +MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost. + + +For example, on https://www.mediawiki.org/wiki/VisualEditor/Team there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1379390340,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-bd72y7iiei67kbxti76b","task_description","VisualEditor: Dimensions of small images are lost in rendering./n/nImages that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original. + +MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost. + + +For example, on https://www.mediawiki.org/wiki/VisualEditor/Team there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150. + +-------------------------- +**Version**: unspecified +**Severity**: normal","VisualEditor: Dimensions of small images are lost in rendering./n/nImages that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original. + +MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost. + + +For example, on URL there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1415881118,NA,"resolved","True","c1",3,"True","False",11,NA,"['VisualEditor: Dimensions of small images are lost in rendering.', 'Images that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original.', 'MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost.', 'For example, on URL there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px).', 'The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,284,TRUE,"For example, on URL there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px)." +836,"VisualEditor: Dimensions of small images are lost in rendering","Images that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original. + +MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost. + + +For example, on https://www.mediawiki.org/wiki/VisualEditor/Team there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1379390340,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-bd72y7iiei67kbxti76b","task_description","VisualEditor: Dimensions of small images are lost in rendering./n/nImages that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original. + +MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost. + + +For example, on https://www.mediawiki.org/wiki/VisualEditor/Team there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150. + +-------------------------- +**Version**: unspecified +**Severity**: normal","VisualEditor: Dimensions of small images are lost in rendering./n/nImages that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original. + +MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost. + + +For example, on URL there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1415881118,NA,"resolved","True","c1",3,"True","False",11,NA,"['VisualEditor: Dimensions of small images are lost in rendering.', 'Images that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original.', 'MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost.', 'For example, on URL there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px).', 'The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,284,TRUE,"The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150." +836,"VisualEditor: Dimensions of small images are lost in rendering","Images that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original. + +MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost. + + +For example, on https://www.mediawiki.org/wiki/VisualEditor/Team there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1379390340,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-bd72y7iiei67kbxti76b","task_description","VisualEditor: Dimensions of small images are lost in rendering./n/nImages that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original. + +MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost. + + +For example, on https://www.mediawiki.org/wiki/VisualEditor/Team there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150. + +-------------------------- +**Version**: unspecified +**Severity**: normal","VisualEditor: Dimensions of small images are lost in rendering./n/nImages that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original. + +MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost. + + +For example, on URL there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Needs Triage",90,1415881118,NA,"resolved","True","c1",3,"True","False",11,NA,"['VisualEditor: Dimensions of small images are lost in rendering.', 'Images that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original.', 'MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost.', 'For example, on URL there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px).', 'The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,284,TRUE,"--------------------------\n**Version**: unspecified\n**Severity**: normal" +6254,"Jenkins: Use node-jscs as checkstyle for javascript coding style","See https://github.com/mdevils/node-jscs + +This is the first tool I've seen in the category of asserting coding style for javascript that actually looks like it is worth looking into further. + +I intend to experiment with it in the near future for 1 or 2 projects, first in non-voting mode and perhaps later to become a standard enabled job for many projects. + +-------------------------- +**Version**: wmf-deployment +**Severity**: enhancement",1379415660,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_description","Jenkins: Use node-jscs as checkstyle for javascript coding style./n/nSee https://github.com/mdevils/node-jscs + +This is the first tool I've seen in the category of asserting coding style for javascript that actually looks like it is worth looking into further. + +I intend to experiment with it in the near future for 1 or 2 projects, first in non-voting mode and perhaps later to become a standard enabled job for many projects. + +-------------------------- +**Version**: wmf-deployment +**Severity**: enhancement","Jenkins: Use node-jscs as checkstyle for javascript coding style./n/nSee URL + +This is the first tool I've seen in the category of asserting coding style for javascript that actually looks like it is worth looking into further. + +I intend to experiment with it in the near future for 1 or 2 projects, first in non-voting mode and perhaps later to become a standard enabled job for many projects. + +-------------------------- +**Version**: wmf-deployment +**Severity**: enhancement","Medium",50,1409154874,NA,"resolved","True","c1",3,"True","False",11,NA,"['Jenkins: Use node-jscs as checkstyle for javascript coding style.', ""See URL\n\nThis is the first tool I've seen in the category of asserting coding style for javascript that actually looks like it is worth looking into further."", 'I intend to experiment with it in the near future for 1 or 2 projects, first in non-voting mode and perhaps later to become a standard enabled job for many projects.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: enhancement']",FALSE,286,TRUE,"Jenkins: Use node-jscs as checkstyle for javascript coding style." +6254,"Jenkins: Use node-jscs as checkstyle for javascript coding style","See https://github.com/mdevils/node-jscs + +This is the first tool I've seen in the category of asserting coding style for javascript that actually looks like it is worth looking into further. + +I intend to experiment with it in the near future for 1 or 2 projects, first in non-voting mode and perhaps later to become a standard enabled job for many projects. + +-------------------------- +**Version**: wmf-deployment +**Severity**: enhancement",1379415660,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_description","Jenkins: Use node-jscs as checkstyle for javascript coding style./n/nSee https://github.com/mdevils/node-jscs + +This is the first tool I've seen in the category of asserting coding style for javascript that actually looks like it is worth looking into further. + +I intend to experiment with it in the near future for 1 or 2 projects, first in non-voting mode and perhaps later to become a standard enabled job for many projects. + +-------------------------- +**Version**: wmf-deployment +**Severity**: enhancement","Jenkins: Use node-jscs as checkstyle for javascript coding style./n/nSee URL + +This is the first tool I've seen in the category of asserting coding style for javascript that actually looks like it is worth looking into further. + +I intend to experiment with it in the near future for 1 or 2 projects, first in non-voting mode and perhaps later to become a standard enabled job for many projects. + +-------------------------- +**Version**: wmf-deployment +**Severity**: enhancement","Medium",50,1409154874,NA,"resolved","True","c1",3,"True","False",11,NA,"['Jenkins: Use node-jscs as checkstyle for javascript coding style.', ""See URL\n\nThis is the first tool I've seen in the category of asserting coding style for javascript that actually looks like it is worth looking into further."", 'I intend to experiment with it in the near future for 1 or 2 projects, first in non-voting mode and perhaps later to become a standard enabled job for many projects.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: enhancement']",FALSE,286,TRUE,"I intend to experiment with it in the near future for 1 or 2 projects, first in non-voting mode and perhaps later to become a standard enabled job for many projects." +6254,"Jenkins: Use node-jscs as checkstyle for javascript coding style","See https://github.com/mdevils/node-jscs + +This is the first tool I've seen in the category of asserting coding style for javascript that actually looks like it is worth looking into further. + +I intend to experiment with it in the near future for 1 or 2 projects, first in non-voting mode and perhaps later to become a standard enabled job for many projects. + +-------------------------- +**Version**: wmf-deployment +**Severity**: enhancement",1379415660,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_description","Jenkins: Use node-jscs as checkstyle for javascript coding style./n/nSee https://github.com/mdevils/node-jscs + +This is the first tool I've seen in the category of asserting coding style for javascript that actually looks like it is worth looking into further. + +I intend to experiment with it in the near future for 1 or 2 projects, first in non-voting mode and perhaps later to become a standard enabled job for many projects. + +-------------------------- +**Version**: wmf-deployment +**Severity**: enhancement","Jenkins: Use node-jscs as checkstyle for javascript coding style./n/nSee URL + +This is the first tool I've seen in the category of asserting coding style for javascript that actually looks like it is worth looking into further. + +I intend to experiment with it in the near future for 1 or 2 projects, first in non-voting mode and perhaps later to become a standard enabled job for many projects. + +-------------------------- +**Version**: wmf-deployment +**Severity**: enhancement","Medium",50,1409154874,NA,"resolved","True","c1",3,"True","False",11,NA,"['Jenkins: Use node-jscs as checkstyle for javascript coding style.', ""See URL\n\nThis is the first tool I've seen in the category of asserting coding style for javascript that actually looks like it is worth looking into further."", 'I intend to experiment with it in the near future for 1 or 2 projects, first in non-voting mode and perhaps later to become a standard enabled job for many projects.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: enhancement']",FALSE,286,TRUE,"--------------------------\n**Version**: wmf-deployment\n**Severity**: enhancement" +6254,"Jenkins: Use node-jscs as checkstyle for javascript coding style","See https://github.com/mdevils/node-jscs + +This is the first tool I've seen in the category of asserting coding style for javascript that actually looks like it is worth looking into further. + +I intend to experiment with it in the near future for 1 or 2 projects, first in non-voting mode and perhaps later to become a standard enabled job for many projects. + +-------------------------- +**Version**: wmf-deployment +**Severity**: enhancement",1379415660,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_description","Jenkins: Use node-jscs as checkstyle for javascript coding style./n/nSee https://github.com/mdevils/node-jscs + +This is the first tool I've seen in the category of asserting coding style for javascript that actually looks like it is worth looking into further. + +I intend to experiment with it in the near future for 1 or 2 projects, first in non-voting mode and perhaps later to become a standard enabled job for many projects. + +-------------------------- +**Version**: wmf-deployment +**Severity**: enhancement","Jenkins: Use node-jscs as checkstyle for javascript coding style./n/nSee URL + +This is the first tool I've seen in the category of asserting coding style for javascript that actually looks like it is worth looking into further. + +I intend to experiment with it in the near future for 1 or 2 projects, first in non-voting mode and perhaps later to become a standard enabled job for many projects. + +-------------------------- +**Version**: wmf-deployment +**Severity**: enhancement","Medium",50,1409154874,NA,"resolved","True","c1",3,"True","False",11,NA,"['Jenkins: Use node-jscs as checkstyle for javascript coding style.', ""See URL\n\nThis is the first tool I've seen in the category of asserting coding style for javascript that actually looks like it is worth looking into further."", 'I intend to experiment with it in the near future for 1 or 2 projects, first in non-voting mode and perhaps later to become a standard enabled job for many projects.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: enhancement']",FALSE,286,TRUE,"See URL\n\nThis is the first tool I've seen in the category of asserting coding style for javascript that actually looks like it is worth looking into further." +6270,"Jenkins: Use node-jscs as checkstyle for javascript coding style","Unrelated.",1379460821,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","Unrelated.","Unrelated.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,11,NA,"['Unrelated.']",NA,287,TRUE,"Unrelated." +6269,"Jenkins: Use node-jscs as checkstyle for javascript coding style","node-jscs would be purely for coding style, not code quality (which is what jshint is primarily for). + +Although there are a few minor things that jshint does in the realm of coding style, those are arguably code quality as well (like using of braces in if/else blocks). + +This would allow us to validate the complete coding style (especially with regards to whitespace), which right now is mostly enforced by leaving comments in code review and fixup commits pointing to [[mw:CC/JS]].",1379461361,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","node-jscs would be purely for coding style, not code quality (which is what jshint is primarily for). + +Although there are a few minor things that jshint does in the realm of coding style, those are arguably code quality as well (like using of braces in if/else blocks). + +This would allow us to validate the complete coding style (especially with regards to whitespace), which right now is mostly enforced by leaving comments in code review and fixup commits pointing to [[mw:CC/JS]].","node-jscs would be purely for coding style, not code quality (which is what jshint is primarily for). + +Although there are a few minor things that jshint does in the realm of coding style, those are arguably code quality as well (like using of braces in if/else blocks). + +This would allow us to validate the complete coding style (especially with regards to whitespace), which right now is mostly enforced by leaving comments in code review and fixup commits pointing to [[mw:CC/JS]].",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,11,NA,"['node-jscs would be purely for coding style, not code quality (which is what jshint is primarily for).', 'Although there are a few minor things that jshint does in the realm of coding style, those are arguably code quality as well (like using of braces in if/else blocks).', 'This would allow us to validate the complete coding style (especially with regards to whitespace), which right now is mostly enforced by leaving comments in code review and fixup commits pointing to [[mw:CC/JS]].']",NA,288,TRUE,"node-jscs would be purely for coding style, not code quality (which is what jshint is primarily for)." +6269,"Jenkins: Use node-jscs as checkstyle for javascript coding style","node-jscs would be purely for coding style, not code quality (which is what jshint is primarily for). + +Although there are a few minor things that jshint does in the realm of coding style, those are arguably code quality as well (like using of braces in if/else blocks). + +This would allow us to validate the complete coding style (especially with regards to whitespace), which right now is mostly enforced by leaving comments in code review and fixup commits pointing to [[mw:CC/JS]].",1379461361,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","node-jscs would be purely for coding style, not code quality (which is what jshint is primarily for). + +Although there are a few minor things that jshint does in the realm of coding style, those are arguably code quality as well (like using of braces in if/else blocks). + +This would allow us to validate the complete coding style (especially with regards to whitespace), which right now is mostly enforced by leaving comments in code review and fixup commits pointing to [[mw:CC/JS]].","node-jscs would be purely for coding style, not code quality (which is what jshint is primarily for). + +Although there are a few minor things that jshint does in the realm of coding style, those are arguably code quality as well (like using of braces in if/else blocks). + +This would allow us to validate the complete coding style (especially with regards to whitespace), which right now is mostly enforced by leaving comments in code review and fixup commits pointing to [[mw:CC/JS]].",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,11,NA,"['node-jscs would be purely for coding style, not code quality (which is what jshint is primarily for).', 'Although there are a few minor things that jshint does in the realm of coding style, those are arguably code quality as well (like using of braces in if/else blocks).', 'This would allow us to validate the complete coding style (especially with regards to whitespace), which right now is mostly enforced by leaving comments in code review and fixup commits pointing to [[mw:CC/JS]].']",NA,288,TRUE,"Although there are a few minor things that jshint does in the realm of coding style, those are arguably code quality as well (like using of braces in if/else blocks)." +6269,"Jenkins: Use node-jscs as checkstyle for javascript coding style","node-jscs would be purely for coding style, not code quality (which is what jshint is primarily for). + +Although there are a few minor things that jshint does in the realm of coding style, those are arguably code quality as well (like using of braces in if/else blocks). + +This would allow us to validate the complete coding style (especially with regards to whitespace), which right now is mostly enforced by leaving comments in code review and fixup commits pointing to [[mw:CC/JS]].",1379461361,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","node-jscs would be purely for coding style, not code quality (which is what jshint is primarily for). + +Although there are a few minor things that jshint does in the realm of coding style, those are arguably code quality as well (like using of braces in if/else blocks). + +This would allow us to validate the complete coding style (especially with regards to whitespace), which right now is mostly enforced by leaving comments in code review and fixup commits pointing to [[mw:CC/JS]].","node-jscs would be purely for coding style, not code quality (which is what jshint is primarily for). + +Although there are a few minor things that jshint does in the realm of coding style, those are arguably code quality as well (like using of braces in if/else blocks). + +This would allow us to validate the complete coding style (especially with regards to whitespace), which right now is mostly enforced by leaving comments in code review and fixup commits pointing to [[mw:CC/JS]].",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,11,NA,"['node-jscs would be purely for coding style, not code quality (which is what jshint is primarily for).', 'Although there are a few minor things that jshint does in the realm of coding style, those are arguably code quality as well (like using of braces in if/else blocks).', 'This would allow us to validate the complete coding style (especially with regards to whitespace), which right now is mostly enforced by leaving comments in code review and fixup commits pointing to [[mw:CC/JS]].']",NA,288,TRUE,"This would allow us to validate the complete coding style (especially with regards to whitespace), which right now is mostly enforced by leaving comments in code review and fixup commits pointing to [[mw:CC/JS]]." +6260,"Jenkins: Use node-jscs as checkstyle for javascript coding style","The bug is to figure out how to properly do it. Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable. + +I think we've reached that point. Any further repos that want it, can enable it the same way other pipelines are introduced. By patching their Gruntfile or adding a new npm-test pipeline.",1409154874,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","The bug is to figure out how to properly do it. Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable. + +I think we've reached that point. Any further repos that want it, can enable it the same way other pipelines are introduced. By patching their Gruntfile or adding a new npm-test pipeline.","The bug is to figure out how to properly do it. Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable. + +I think we've reached that point. Any further repos that want it, can enable it the same way other pipelines are introduced. By patching their Gruntfile or adding a new npm-test pipeline.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,60,NA,"['The bug is to figure out how to properly do it.', 'Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable.', ""I think we've reached that point."", 'Any further repos that want it, can enable it the same way other pipelines are introduced.', 'By patching their Gruntfile or adding a new npm-test pipeline.']",NA,354,TRUE,"The bug is to figure out how to properly do it." +6260,"Jenkins: Use node-jscs as checkstyle for javascript coding style","The bug is to figure out how to properly do it. Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable. + +I think we've reached that point. Any further repos that want it, can enable it the same way other pipelines are introduced. By patching their Gruntfile or adding a new npm-test pipeline.",1409154874,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","The bug is to figure out how to properly do it. Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable. + +I think we've reached that point. Any further repos that want it, can enable it the same way other pipelines are introduced. By patching their Gruntfile or adding a new npm-test pipeline.","The bug is to figure out how to properly do it. Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable. + +I think we've reached that point. Any further repos that want it, can enable it the same way other pipelines are introduced. By patching their Gruntfile or adding a new npm-test pipeline.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,60,NA,"['The bug is to figure out how to properly do it.', 'Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable.', ""I think we've reached that point."", 'Any further repos that want it, can enable it the same way other pipelines are introduced.', 'By patching their Gruntfile or adding a new npm-test pipeline.']",NA,354,TRUE,"Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable." +6260,"Jenkins: Use node-jscs as checkstyle for javascript coding style","The bug is to figure out how to properly do it. Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable. + +I think we've reached that point. Any further repos that want it, can enable it the same way other pipelines are introduced. By patching their Gruntfile or adding a new npm-test pipeline.",1409154874,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","The bug is to figure out how to properly do it. Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable. + +I think we've reached that point. Any further repos that want it, can enable it the same way other pipelines are introduced. By patching their Gruntfile or adding a new npm-test pipeline.","The bug is to figure out how to properly do it. Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable. + +I think we've reached that point. Any further repos that want it, can enable it the same way other pipelines are introduced. By patching their Gruntfile or adding a new npm-test pipeline.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,60,NA,"['The bug is to figure out how to properly do it.', 'Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable.', ""I think we've reached that point."", 'Any further repos that want it, can enable it the same way other pipelines are introduced.', 'By patching their Gruntfile or adding a new npm-test pipeline.']",NA,354,TRUE,"Any further repos that want it, can enable it the same way other pipelines are introduced." +6260,"Jenkins: Use node-jscs as checkstyle for javascript coding style","The bug is to figure out how to properly do it. Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable. + +I think we've reached that point. Any further repos that want it, can enable it the same way other pipelines are introduced. By patching their Gruntfile or adding a new npm-test pipeline.",1409154874,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","The bug is to figure out how to properly do it. Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable. + +I think we've reached that point. Any further repos that want it, can enable it the same way other pipelines are introduced. By patching their Gruntfile or adding a new npm-test pipeline.","The bug is to figure out how to properly do it. Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable. + +I think we've reached that point. Any further repos that want it, can enable it the same way other pipelines are introduced. By patching their Gruntfile or adding a new npm-test pipeline.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,60,NA,"['The bug is to figure out how to properly do it.', 'Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable.', ""I think we've reached that point."", 'Any further repos that want it, can enable it the same way other pipelines are introduced.', 'By patching their Gruntfile or adding a new npm-test pipeline.']",NA,354,TRUE,"By patching their Gruntfile or adding a new npm-test pipeline." +6260,"Jenkins: Use node-jscs as checkstyle for javascript coding style","The bug is to figure out how to properly do it. Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable. + +I think we've reached that point. Any further repos that want it, can enable it the same way other pipelines are introduced. By patching their Gruntfile or adding a new npm-test pipeline.",1409154874,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","The bug is to figure out how to properly do it. Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable. + +I think we've reached that point. Any further repos that want it, can enable it the same way other pipelines are introduced. By patching their Gruntfile or adding a new npm-test pipeline.","The bug is to figure out how to properly do it. Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable. + +I think we've reached that point. Any further repos that want it, can enable it the same way other pipelines are introduced. By patching their Gruntfile or adding a new npm-test pipeline.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,60,NA,"['The bug is to figure out how to properly do it.', 'Which I define by hacking it together for one repo, and as you repeat it for more repos you refine it until it seems sensible/maintainable.', ""I think we've reached that point."", 'Any further repos that want it, can enable it the same way other pipelines are introduced.', 'By patching their Gruntfile or adding a new npm-test pipeline.']",NA,354,TRUE,"I think we've reached that point." +6255,"Jenkins: Use node-jscs as checkstyle for javascript coding style",">>! In T56218#973118, @adrianheine wrote: +> Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: +> +> * Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +> * integration/config: https://gerrit.wikimedia.org/r/#/c/184592/ + +That's quite alright. If you don't need do run bash commands like `mv`, `cp`, `rm`, `ln` etc. which might not work cross-platform if put inside `scripts.test` (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ +http://ponyfoo.com/articles/choose-grunt-gulp-or-npm",1426088335,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment",">>! In T56218#973118, @adrianheine wrote: +> Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: +> +> * Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +> * integration/config: https://gerrit.wikimedia.org/r/#/c/184592/ + +That's quite alright. If you don't need do run bash commands like `mv`, `cp`, `rm`, `ln` etc. which might not work cross-platform if put inside `scripts.test` (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ +http://ponyfoo.com/articles/choose-grunt-gulp-or-npm","QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +That's quite alright. If you don't need do run bash commands like CODE, CODE, CODE, CODE etc. which might not work cross-platform if put inside CODE (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +URL +URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,88,NA,"[""QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat's quite alright."", ""If you don't need do run bash commands like CODE, CODE, CODE, CODE etc."", ""which might not work cross-platform if put inside CODE (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common."", ""I've recently started to use this more often as well."", ""Only use Grunt when there's a need for it."", 'This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g.', ""jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way."", 'URL\nURL']",NA,372,TRUE,"This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g." +6255,"Jenkins: Use node-jscs as checkstyle for javascript coding style",">>! In T56218#973118, @adrianheine wrote: +> Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: +> +> * Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +> * integration/config: https://gerrit.wikimedia.org/r/#/c/184592/ + +That's quite alright. If you don't need do run bash commands like `mv`, `cp`, `rm`, `ln` etc. which might not work cross-platform if put inside `scripts.test` (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ +http://ponyfoo.com/articles/choose-grunt-gulp-or-npm",1426088335,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment",">>! In T56218#973118, @adrianheine wrote: +> Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: +> +> * Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +> * integration/config: https://gerrit.wikimedia.org/r/#/c/184592/ + +That's quite alright. If you don't need do run bash commands like `mv`, `cp`, `rm`, `ln` etc. which might not work cross-platform if put inside `scripts.test` (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ +http://ponyfoo.com/articles/choose-grunt-gulp-or-npm","QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +That's quite alright. If you don't need do run bash commands like CODE, CODE, CODE, CODE etc. which might not work cross-platform if put inside CODE (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +URL +URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,88,NA,"[""QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat's quite alright."", ""If you don't need do run bash commands like CODE, CODE, CODE, CODE etc."", ""which might not work cross-platform if put inside CODE (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common."", ""I've recently started to use this more often as well."", ""Only use Grunt when there's a need for it."", 'This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g.', ""jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way."", 'URL\nURL']",NA,372,TRUE,"URL\nURL" +6255,"Jenkins: Use node-jscs as checkstyle for javascript coding style",">>! In T56218#973118, @adrianheine wrote: +> Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: +> +> * Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +> * integration/config: https://gerrit.wikimedia.org/r/#/c/184592/ + +That's quite alright. If you don't need do run bash commands like `mv`, `cp`, `rm`, `ln` etc. which might not work cross-platform if put inside `scripts.test` (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ +http://ponyfoo.com/articles/choose-grunt-gulp-or-npm",1426088335,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment",">>! In T56218#973118, @adrianheine wrote: +> Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: +> +> * Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +> * integration/config: https://gerrit.wikimedia.org/r/#/c/184592/ + +That's quite alright. If you don't need do run bash commands like `mv`, `cp`, `rm`, `ln` etc. which might not work cross-platform if put inside `scripts.test` (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ +http://ponyfoo.com/articles/choose-grunt-gulp-or-npm","QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +That's quite alright. If you don't need do run bash commands like CODE, CODE, CODE, CODE etc. which might not work cross-platform if put inside CODE (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +URL +URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,88,NA,"[""QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat's quite alright."", ""If you don't need do run bash commands like CODE, CODE, CODE, CODE etc."", ""which might not work cross-platform if put inside CODE (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common."", ""I've recently started to use this more often as well."", ""Only use Grunt when there's a need for it."", 'This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g.', ""jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way."", 'URL\nURL']",NA,372,TRUE,"QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat's quite alright." +6255,"Jenkins: Use node-jscs as checkstyle for javascript coding style",">>! In T56218#973118, @adrianheine wrote: +> Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: +> +> * Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +> * integration/config: https://gerrit.wikimedia.org/r/#/c/184592/ + +That's quite alright. If you don't need do run bash commands like `mv`, `cp`, `rm`, `ln` etc. which might not work cross-platform if put inside `scripts.test` (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ +http://ponyfoo.com/articles/choose-grunt-gulp-or-npm",1426088335,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment",">>! In T56218#973118, @adrianheine wrote: +> Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: +> +> * Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +> * integration/config: https://gerrit.wikimedia.org/r/#/c/184592/ + +That's quite alright. If you don't need do run bash commands like `mv`, `cp`, `rm`, `ln` etc. which might not work cross-platform if put inside `scripts.test` (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ +http://ponyfoo.com/articles/choose-grunt-gulp-or-npm","QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +That's quite alright. If you don't need do run bash commands like CODE, CODE, CODE, CODE etc. which might not work cross-platform if put inside CODE (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +URL +URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,88,NA,"[""QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat's quite alright."", ""If you don't need do run bash commands like CODE, CODE, CODE, CODE etc."", ""which might not work cross-platform if put inside CODE (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common."", ""I've recently started to use this more often as well."", ""Only use Grunt when there's a need for it."", 'This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g.', ""jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way."", 'URL\nURL']",NA,372,TRUE,"If you don't need do run bash commands like CODE, CODE, CODE, CODE etc." +6255,"Jenkins: Use node-jscs as checkstyle for javascript coding style",">>! In T56218#973118, @adrianheine wrote: +> Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: +> +> * Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +> * integration/config: https://gerrit.wikimedia.org/r/#/c/184592/ + +That's quite alright. If you don't need do run bash commands like `mv`, `cp`, `rm`, `ln` etc. which might not work cross-platform if put inside `scripts.test` (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ +http://ponyfoo.com/articles/choose-grunt-gulp-or-npm",1426088335,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment",">>! In T56218#973118, @adrianheine wrote: +> Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: +> +> * Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +> * integration/config: https://gerrit.wikimedia.org/r/#/c/184592/ + +That's quite alright. If you don't need do run bash commands like `mv`, `cp`, `rm`, `ln` etc. which might not work cross-platform if put inside `scripts.test` (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ +http://ponyfoo.com/articles/choose-grunt-gulp-or-npm","QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +That's quite alright. If you don't need do run bash commands like CODE, CODE, CODE, CODE etc. which might not work cross-platform if put inside CODE (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +URL +URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,88,NA,"[""QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat's quite alright."", ""If you don't need do run bash commands like CODE, CODE, CODE, CODE etc."", ""which might not work cross-platform if put inside CODE (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common."", ""I've recently started to use this more often as well."", ""Only use Grunt when there's a need for it."", 'This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g.', ""jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way."", 'URL\nURL']",NA,372,TRUE,"which might not work cross-platform if put inside CODE (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common." +6255,"Jenkins: Use node-jscs as checkstyle for javascript coding style",">>! In T56218#973118, @adrianheine wrote: +> Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: +> +> * Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +> * integration/config: https://gerrit.wikimedia.org/r/#/c/184592/ + +That's quite alright. If you don't need do run bash commands like `mv`, `cp`, `rm`, `ln` etc. which might not work cross-platform if put inside `scripts.test` (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ +http://ponyfoo.com/articles/choose-grunt-gulp-or-npm",1426088335,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment",">>! In T56218#973118, @adrianheine wrote: +> Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: +> +> * Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +> * integration/config: https://gerrit.wikimedia.org/r/#/c/184592/ + +That's quite alright. If you don't need do run bash commands like `mv`, `cp`, `rm`, `ln` etc. which might not work cross-platform if put inside `scripts.test` (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ +http://ponyfoo.com/articles/choose-grunt-gulp-or-npm","QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +That's quite alright. If you don't need do run bash commands like CODE, CODE, CODE, CODE etc. which might not work cross-platform if put inside CODE (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +URL +URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,88,NA,"[""QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat's quite alright."", ""If you don't need do run bash commands like CODE, CODE, CODE, CODE etc."", ""which might not work cross-platform if put inside CODE (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common."", ""I've recently started to use this more often as well."", ""Only use Grunt when there's a need for it."", 'This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g.', ""jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way."", 'URL\nURL']",NA,372,TRUE,"I've recently started to use this more often as well." +6255,"Jenkins: Use node-jscs as checkstyle for javascript coding style",">>! In T56218#973118, @adrianheine wrote: +> Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: +> +> * Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +> * integration/config: https://gerrit.wikimedia.org/r/#/c/184592/ + +That's quite alright. If you don't need do run bash commands like `mv`, `cp`, `rm`, `ln` etc. which might not work cross-platform if put inside `scripts.test` (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ +http://ponyfoo.com/articles/choose-grunt-gulp-or-npm",1426088335,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment",">>! In T56218#973118, @adrianheine wrote: +> Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: +> +> * Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +> * integration/config: https://gerrit.wikimedia.org/r/#/c/184592/ + +That's quite alright. If you don't need do run bash commands like `mv`, `cp`, `rm`, `ln` etc. which might not work cross-platform if put inside `scripts.test` (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ +http://ponyfoo.com/articles/choose-grunt-gulp-or-npm","QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +That's quite alright. If you don't need do run bash commands like CODE, CODE, CODE, CODE etc. which might not work cross-platform if put inside CODE (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +URL +URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,88,NA,"[""QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat's quite alright."", ""If you don't need do run bash commands like CODE, CODE, CODE, CODE etc."", ""which might not work cross-platform if put inside CODE (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common."", ""I've recently started to use this more often as well."", ""Only use Grunt when there's a need for it."", 'This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g.', ""jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way."", 'URL\nURL']",NA,372,TRUE,"Only use Grunt when there's a need for it." +6255,"Jenkins: Use node-jscs as checkstyle for javascript coding style",">>! In T56218#973118, @adrianheine wrote: +> Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: +> +> * Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +> * integration/config: https://gerrit.wikimedia.org/r/#/c/184592/ + +That's quite alright. If you don't need do run bash commands like `mv`, `cp`, `rm`, `ln` etc. which might not work cross-platform if put inside `scripts.test` (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ +http://ponyfoo.com/articles/choose-grunt-gulp-or-npm",1426088335,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment",">>! In T56218#973118, @adrianheine wrote: +> Cool, thanks. I added `npm test`, although I didn't go through grunt since we are not running any other grunt jobs, yet: +> +> * Wikibase: https://gerrit.wikimedia.org/r/#/c/184591/ +> * integration/config: https://gerrit.wikimedia.org/r/#/c/184592/ + +That's quite alright. If you don't need do run bash commands like `mv`, `cp`, `rm`, `ln` etc. which might not work cross-platform if put inside `scripts.test` (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ +http://ponyfoo.com/articles/choose-grunt-gulp-or-npm","QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +That's quite alright. If you don't need do run bash commands like CODE, CODE, CODE, CODE etc. which might not work cross-platform if put inside CODE (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common. I've recently started to use this more often as well. Only use Grunt when there's a need for it. This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g. jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way. + +URL +URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,88,NA,"[""QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat's quite alright."", ""If you don't need do run bash commands like CODE, CODE, CODE, CODE etc."", ""which might not work cross-platform if put inside CODE (so you'll want to use a nodejs script or Grunt task for that); Running programs like jscs and jshint directly is perfectly fine and actually quite common."", ""I've recently started to use this more often as well."", ""Only use Grunt when there's a need for it."", 'This avoids added complexity, needless abstraction, and indirect dependencies on the underlying framework (e.g.', ""jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way."", 'URL\nURL']",NA,372,TRUE,"jscs/jshint) which can be quite annoying since it doesn't like being pinned to a direct version that way." +10942,"VisualEditor: Disallow (discourage?) placing references inside section headers","<> + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",1375436160,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-beeof7d2r6t7gnezbj7a","task_description","VisualEditor: Disallow (discourage?) placing references inside section headers./n/n<> + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","VisualEditor: Disallow (discourage?) placing references inside section headers./n/n<> + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","Low",25,NA,NA,"open","True","c1",3,"False","False",4,NA,"['VisualEditor: Disallow (discourage?)', 'placing references inside section headers.', '<>\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,55,TRUE,"VisualEditor: Disallow (discourage?)" +10942,"VisualEditor: Disallow (discourage?) placing references inside section headers","<> + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",1375436160,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-beeof7d2r6t7gnezbj7a","task_description","VisualEditor: Disallow (discourage?) placing references inside section headers./n/n<> + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","VisualEditor: Disallow (discourage?) placing references inside section headers./n/n<> + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","Low",25,NA,NA,"open","True","c1",3,"False","False",4,NA,"['VisualEditor: Disallow (discourage?)', 'placing references inside section headers.', '<>\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,55,TRUE,"placing references inside section headers." +10942,"VisualEditor: Disallow (discourage?) placing references inside section headers","<> + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",1375436160,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-beeof7d2r6t7gnezbj7a","task_description","VisualEditor: Disallow (discourage?) placing references inside section headers./n/n<> + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","VisualEditor: Disallow (discourage?) placing references inside section headers./n/n<> + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","Low",25,NA,NA,"open","True","c1",3,"False","False",4,NA,"['VisualEditor: Disallow (discourage?)', 'placing references inside section headers.', '<>\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,55,TRUE,"<> + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",1375436160,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-beeof7d2r6t7gnezbj7a","task_description","VisualEditor: Disallow (discourage?) placing references inside section headers./n/n<> + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","VisualEditor: Disallow (discourage?) placing references inside section headers./n/n<> + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","Low",25,NA,NA,"open","True","c1",3,"False","False",4,NA,"['VisualEditor: Disallow (discourage?)', 'placing references inside section headers.', '<>\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,55,TRUE,"This is never needed or wanted (it is ugly, and the thing that needs to be referenced should be in the text of the section, not only in the title anyway)." +10942,"VisualEditor: Disallow (discourage?) placing references inside section headers","<> + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",1375436160,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-beeof7d2r6t7gnezbj7a","task_description","VisualEditor: Disallow (discourage?) placing references inside section headers./n/n<> + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","VisualEditor: Disallow (discourage?) placing references inside section headers./n/n<> + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","Low",25,NA,NA,"open","True","c1",3,"False","False",4,NA,"['VisualEditor: Disallow (discourage?)', 'placing references inside section headers.', '<>\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,55,TRUE,"Example (spam, but the principle applies): URL ." +10942,"VisualEditor: Disallow (discourage?) placing references inside section headers","<> + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",1375436160,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-beeof7d2r6t7gnezbj7a","task_description","VisualEditor: Disallow (discourage?) placing references inside section headers./n/n<> + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","VisualEditor: Disallow (discourage?) placing references inside section headers./n/n<> + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","Low",25,NA,NA,"open","True","c1",3,"False","False",4,NA,"['VisualEditor: Disallow (discourage?)', 'placing references inside section headers.', '<>\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,55,TRUE,"Fram (talk) 07:31, 2 August 2013 (UTC) >>\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement" +10824,"Newly-uploaded image doesn't immediately appear in image search results in VisualEditor","<< http://en.wikipedia.org/wiki/File:GreatNurse.jpeg is a headshot of Virginia Henderson that was uploaded to Commons yesterday. VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist. WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >> + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=37578",1376382300,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-zckv7xwfgl4cxjix23f5","task_description","Newly-uploaded image doesn't immediately appear in image search results in VisualEditor./n/n<< http://en.wikipedia.org/wiki/File:GreatNurse.jpeg is a headshot of Virginia Henderson that was uploaded to Commons yesterday. VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist. WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >> + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=37578","Newly-uploaded image doesn't immediately appear in image search results in VisualEditor./n/n<< URL is a headshot of Virginia Henderson that was uploaded to Commons yesterday. VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist. WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >> + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +URL","Low",25,1383013054,NA,"declined","True","c1",3,"False","False",6,NA,"[""Newly-uploaded image doesn't immediately appear in image search results in VisualEditor."", '<< URL is a headshot of Virginia Henderson that was uploaded to Commons yesterday.', ""VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist."", 'WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >>\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,78,TRUE,"<< URL is a headshot of Virginia Henderson that was uploaded to Commons yesterday." +10824,"Newly-uploaded image doesn't immediately appear in image search results in VisualEditor","<< http://en.wikipedia.org/wiki/File:GreatNurse.jpeg is a headshot of Virginia Henderson that was uploaded to Commons yesterday. VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist. WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >> + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=37578",1376382300,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-zckv7xwfgl4cxjix23f5","task_description","Newly-uploaded image doesn't immediately appear in image search results in VisualEditor./n/n<< http://en.wikipedia.org/wiki/File:GreatNurse.jpeg is a headshot of Virginia Henderson that was uploaded to Commons yesterday. VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist. WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >> + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=37578","Newly-uploaded image doesn't immediately appear in image search results in VisualEditor./n/n<< URL is a headshot of Virginia Henderson that was uploaded to Commons yesterday. VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist. WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >> + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +URL","Low",25,1383013054,NA,"declined","True","c1",3,"False","False",6,NA,"[""Newly-uploaded image doesn't immediately appear in image search results in VisualEditor."", '<< URL is a headshot of Virginia Henderson that was uploaded to Commons yesterday.', ""VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist."", 'WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >>\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,78,TRUE,"WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >>\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL" +10824,"Newly-uploaded image doesn't immediately appear in image search results in VisualEditor","<< http://en.wikipedia.org/wiki/File:GreatNurse.jpeg is a headshot of Virginia Henderson that was uploaded to Commons yesterday. VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist. WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >> + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=37578",1376382300,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-zckv7xwfgl4cxjix23f5","task_description","Newly-uploaded image doesn't immediately appear in image search results in VisualEditor./n/n<< http://en.wikipedia.org/wiki/File:GreatNurse.jpeg is a headshot of Virginia Henderson that was uploaded to Commons yesterday. VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist. WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >> + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=37578","Newly-uploaded image doesn't immediately appear in image search results in VisualEditor./n/n<< URL is a headshot of Virginia Henderson that was uploaded to Commons yesterday. VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist. WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >> + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +URL","Low",25,1383013054,NA,"declined","True","c1",3,"False","False",6,NA,"[""Newly-uploaded image doesn't immediately appear in image search results in VisualEditor."", '<< URL is a headshot of Virginia Henderson that was uploaded to Commons yesterday.', ""VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist."", 'WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >>\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,78,TRUE,"Newly-uploaded image doesn't immediately appear in image search results in VisualEditor." +10824,"Newly-uploaded image doesn't immediately appear in image search results in VisualEditor","<< http://en.wikipedia.org/wiki/File:GreatNurse.jpeg is a headshot of Virginia Henderson that was uploaded to Commons yesterday. VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist. WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >> + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=37578",1376382300,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-zckv7xwfgl4cxjix23f5","task_description","Newly-uploaded image doesn't immediately appear in image search results in VisualEditor./n/n<< http://en.wikipedia.org/wiki/File:GreatNurse.jpeg is a headshot of Virginia Henderson that was uploaded to Commons yesterday. VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist. WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >> + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=37578","Newly-uploaded image doesn't immediately appear in image search results in VisualEditor./n/n<< URL is a headshot of Virginia Henderson that was uploaded to Commons yesterday. VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist. WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >> + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +URL","Low",25,1383013054,NA,"declined","True","c1",3,"False","False",6,NA,"[""Newly-uploaded image doesn't immediately appear in image search results in VisualEditor."", '<< URL is a headshot of Virginia Henderson that was uploaded to Commons yesterday.', ""VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist."", 'WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >>\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,78,TRUE,"VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist." +871,"Request for edit summary preview","A De.WP user suggested to include a preview for the edit summary. Report: + +https://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=122207411#Vorschau_f.C3.BCr_Zusammenfassung_und_Quellen + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",1378253700,"PHID-USER-wswkm7jrcwes3tc7o34k","PHID-TASK-uro44a5vqso2sy7u2arn","task_description","Request for edit summary preview./n/nA De.WP user suggested to include a preview for the edit summary. Report: + +https://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=122207411#Vorschau_f.C3.BCr_Zusammenfassung_und_Quellen + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","Request for edit summary preview./n/nA De.WP user suggested to include a preview for the edit summary. Report: + +URL + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","Needs Triage",90,1380545659,NA,"resolved","True","c1",3,"False","False",9,NA,"['Request for edit summary preview.', 'A De.WP user suggested to include a preview for the edit summary.', 'Report:\n\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,12,TRUE,"Request for edit summary preview." +871,"Request for edit summary preview","A De.WP user suggested to include a preview for the edit summary. Report: + +https://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=122207411#Vorschau_f.C3.BCr_Zusammenfassung_und_Quellen + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",1378253700,"PHID-USER-wswkm7jrcwes3tc7o34k","PHID-TASK-uro44a5vqso2sy7u2arn","task_description","Request for edit summary preview./n/nA De.WP user suggested to include a preview for the edit summary. Report: + +https://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=122207411#Vorschau_f.C3.BCr_Zusammenfassung_und_Quellen + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","Request for edit summary preview./n/nA De.WP user suggested to include a preview for the edit summary. Report: + +URL + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","Needs Triage",90,1380545659,NA,"resolved","True","c1",3,"False","False",9,NA,"['Request for edit summary preview.', 'A De.WP user suggested to include a preview for the edit summary.', 'Report:\n\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,12,TRUE,"A De.WP user suggested to include a preview for the edit summary." +871,"Request for edit summary preview","A De.WP user suggested to include a preview for the edit summary. Report: + +https://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=122207411#Vorschau_f.C3.BCr_Zusammenfassung_und_Quellen + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",1378253700,"PHID-USER-wswkm7jrcwes3tc7o34k","PHID-TASK-uro44a5vqso2sy7u2arn","task_description","Request for edit summary preview./n/nA De.WP user suggested to include a preview for the edit summary. Report: + +https://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=122207411#Vorschau_f.C3.BCr_Zusammenfassung_und_Quellen + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","Request for edit summary preview./n/nA De.WP user suggested to include a preview for the edit summary. Report: + +URL + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","Needs Triage",90,1380545659,NA,"resolved","True","c1",3,"False","False",9,NA,"['Request for edit summary preview.', 'A De.WP user suggested to include a preview for the edit summary.', 'Report:\n\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,12,TRUE,"Report:\n\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement" +3208,"VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown","The particular article in the URL field of this bug report doesn't not display the Save button in Firefox. + +The Save button is displayed in Chrome, and it is displayed in other articles in Firefox. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%93_%28%D7%9E%D7%99%D7%AA%D7%95%D7%9C%D7%95%D7%92%D7%99%D7%94%29?veaction=edit",1374694260,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-nlgy7km52ntxkqvlqnu2","task_description","VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown./n/nThe particular article in the URL field of this bug report doesn't not display the Save button in Firefox. + +The Save button is displayed in Chrome, and it is displayed in other articles in Firefox. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%93_%28%D7%9E%D7%99%D7%AA%D7%95%D7%9C%D7%95%D7%92%D7%99%D7%94%29?veaction=edit","VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown./n/nThe particular article in the URL field of this bug report doesn't not display the Save button in Firefox. + +The Save button is displayed in Chrome, and it is displayed in other articles in Firefox. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**URL**: URL","High",80,1374700983,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Action buttons of the toolbar (including ""Save"") don\'t appear on some articles in Firefox because error is thrown.', ""The particular article in the URL field of this bug report doesn't not display the Save button in Firefox."", 'The Save button is displayed in Chrome, and it is displayed in other articles in Firefox.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,58,TRUE,"VisualEditor: Action buttons of the toolbar (including ""Save"") don\" +3208,"VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown","The particular article in the URL field of this bug report doesn't not display the Save button in Firefox. + +The Save button is displayed in Chrome, and it is displayed in other articles in Firefox. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%93_%28%D7%9E%D7%99%D7%AA%D7%95%D7%9C%D7%95%D7%92%D7%99%D7%94%29?veaction=edit",1374694260,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-nlgy7km52ntxkqvlqnu2","task_description","VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown./n/nThe particular article in the URL field of this bug report doesn't not display the Save button in Firefox. + +The Save button is displayed in Chrome, and it is displayed in other articles in Firefox. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%93_%28%D7%9E%D7%99%D7%AA%D7%95%D7%9C%D7%95%D7%92%D7%99%D7%94%29?veaction=edit","VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown./n/nThe particular article in the URL field of this bug report doesn't not display the Save button in Firefox. + +The Save button is displayed in Chrome, and it is displayed in other articles in Firefox. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**URL**: URL","High",80,1374700983,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Action buttons of the toolbar (including ""Save"") don\'t appear on some articles in Firefox because error is thrown.', ""The particular article in the URL field of this bug report doesn't not display the Save button in Firefox."", 'The Save button is displayed in Chrome, and it is displayed in other articles in Firefox.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,58,TRUE,", ""The particular article in the URL field of this bug report doesn" +3208,"VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown","The particular article in the URL field of this bug report doesn't not display the Save button in Firefox. + +The Save button is displayed in Chrome, and it is displayed in other articles in Firefox. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%93_%28%D7%9E%D7%99%D7%AA%D7%95%D7%9C%D7%95%D7%92%D7%99%D7%94%29?veaction=edit",1374694260,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-nlgy7km52ntxkqvlqnu2","task_description","VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown./n/nThe particular article in the URL field of this bug report doesn't not display the Save button in Firefox. + +The Save button is displayed in Chrome, and it is displayed in other articles in Firefox. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%93_%28%D7%9E%D7%99%D7%AA%D7%95%D7%9C%D7%95%D7%92%D7%99%D7%94%29?veaction=edit","VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown./n/nThe particular article in the URL field of this bug report doesn't not display the Save button in Firefox. + +The Save button is displayed in Chrome, and it is displayed in other articles in Firefox. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**URL**: URL","High",80,1374700983,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Action buttons of the toolbar (including ""Save"") don\'t appear on some articles in Firefox because error is thrown.', ""The particular article in the URL field of this bug report doesn't not display the Save button in Firefox."", 'The Save button is displayed in Chrome, and it is displayed in other articles in Firefox.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,58,TRUE,"The Save button is displayed in Chrome, and it is displayed in other articles in Firefox." +3208,"VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown","The particular article in the URL field of this bug report doesn't not display the Save button in Firefox. + +The Save button is displayed in Chrome, and it is displayed in other articles in Firefox. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%93_%28%D7%9E%D7%99%D7%AA%D7%95%D7%9C%D7%95%D7%92%D7%99%D7%94%29?veaction=edit",1374694260,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-nlgy7km52ntxkqvlqnu2","task_description","VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown./n/nThe particular article in the URL field of this bug report doesn't not display the Save button in Firefox. + +The Save button is displayed in Chrome, and it is displayed in other articles in Firefox. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%93_%28%D7%9E%D7%99%D7%AA%D7%95%D7%9C%D7%95%D7%92%D7%99%D7%94%29?veaction=edit","VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown./n/nThe particular article in the URL field of this bug report doesn't not display the Save button in Firefox. + +The Save button is displayed in Chrome, and it is displayed in other articles in Firefox. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**URL**: URL","High",80,1374700983,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Action buttons of the toolbar (including ""Save"") don\'t appear on some articles in Firefox because error is thrown.', ""The particular article in the URL field of this bug report doesn't not display the Save button in Firefox."", 'The Save button is displayed in Chrome, and it is displayed in other articles in Firefox.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,58,TRUE,"--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL" +3212,"VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown","Another article where this happens: + +https://he.wikipedia.org/wiki/%D7%A4%D7%9C%D7%99%D7%98%D7%99_%D7%9E%D7%9C%D7%97%D7%9E%D7%AA_%D7%94%D7%90%D7%96%D7%A8%D7%97%D7%99%D7%9D_%D7%91%D7%A1%D7%95%D7%A8%D7%99%D7%94?veaction=edit",1374694774,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-nlgy7km52ntxkqvlqnu2","task_subcomment","Another article where this happens: + +https://he.wikipedia.org/wiki/%D7%A4%D7%9C%D7%99%D7%98%D7%99_%D7%9E%D7%9C%D7%97%D7%9E%D7%AA_%D7%94%D7%90%D7%96%D7%A8%D7%97%D7%99%D7%9D_%D7%91%D7%A1%D7%95%D7%A8%D7%99%D7%94?veaction=edit","Another article where this happens: + +URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"['Another article where this happens:\n\nURL']",NA,59,TRUE,"Another article where this happens:\n\nURL" +1355,"""Leave Feedback"" link rendering as two lines in some fonts","This was already reported as bug 51335 (sorry!). + +*** This bug has been marked as a duplicate of bug 51335 ***",1374162111,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-pbxss6r2sg7qfrxykect","task_subcomment","This was already reported as bug 51335 (sorry!). + +*** This bug has been marked as a duplicate of bug 51335 ***","This was already reported as bug 51335 (sorry!). + +*** This bug has been marked as a duplicate of bug 51335 ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,2,NA,"['This was already reported as bug 51335 (sorry!).', '*** This bug has been marked as a duplicate of bug 51335 ***']",NA,1316,TRUE,"This was already reported as bug 51335 (sorry!)." +1355,"""Leave Feedback"" link rendering as two lines in some fonts","This was already reported as bug 51335 (sorry!). + +*** This bug has been marked as a duplicate of bug 51335 ***",1374162111,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-pbxss6r2sg7qfrxykect","task_subcomment","This was already reported as bug 51335 (sorry!). + +*** This bug has been marked as a duplicate of bug 51335 ***","This was already reported as bug 51335 (sorry!). + +*** This bug has been marked as a duplicate of bug 51335 ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,2,NA,"['This was already reported as bug 51335 (sorry!).', '*** This bug has been marked as a duplicate of bug 51335 ***']",NA,1316,TRUE,"*** This bug has been marked as a duplicate of bug 51335 ***" +3209,"VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown","This is now fixed in master; we will make sure it is deployed tomorrow.",1374700983,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-nlgy7km52ntxkqvlqnu2","task_subcomment","This is now fixed in master; we will make sure it is deployed tomorrow.","This is now fixed in master; we will make sure it is deployed tomorrow.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,3,NA,"['This is now fixed in master; we will make sure it is deployed tomorrow.']",NA,1399,TRUE,"This is now fixed in master; we will make sure it is deployed tomorrow." +10829,"Newly-uploaded image doesn't immediately appear in image search results in VisualEditor","The image now comes up in the search result - this is probably a delay in the speed with which the search index is updated.",1376952277,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-zckv7xwfgl4cxjix23f5","task_subcomment","The image now comes up in the search result - this is probably a delay in the speed with which the search index is updated.","The image now comes up in the search result - this is probably a delay in the speed with which the search index is updated.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,7,NA,"['The image now comes up in the search result - this is probably a delay in the speed with which the search index is updated.']",NA,1568,TRUE,"The image now comes up in the search result - this is probably a delay in the speed with which the search index is updated." +8335,"VisualEditor: round-trip adjacent and nested annotations","This has been fixed for some time in the DM. Marking as such.",1380845963,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-kazpxbs6hxscszn2mj4j","task_subcomment","This has been fixed for some time in the DM. Marking as such.","This has been fixed for some time in the DM. Marking as such.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['This has been fixed for some time in the DM.', 'Marking as such.']",NA,1793,TRUE,"This has been fixed for some time in the DM." +8335,"VisualEditor: round-trip adjacent and nested annotations","This has been fixed for some time in the DM. Marking as such.",1380845963,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-kazpxbs6hxscszn2mj4j","task_subcomment","This has been fixed for some time in the DM. Marking as such.","This has been fixed for some time in the DM. Marking as such.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['This has been fixed for some time in the DM.', 'Marking as such.']",NA,1793,TRUE,"Marking as such." +10825,"Newly-uploaded image doesn't immediately appear in image search results in VisualEditor","*** Bug 52218 has been marked as a duplicate of this bug. ***",1383282089,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-zckv7xwfgl4cxjix23f5","task_subcomment","*** Bug 52218 has been marked as a duplicate of this bug. ***","*** Bug 52218 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,17,NA,"['*** Bug 52218 has been marked as a duplicate of this bug.', '***']",NA,1861,TRUE,"*** Bug 52218 has been marked as a duplicate of this bug." +10825,"Newly-uploaded image doesn't immediately appear in image search results in VisualEditor","*** Bug 52218 has been marked as a duplicate of this bug. ***",1383282089,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-zckv7xwfgl4cxjix23f5","task_subcomment","*** Bug 52218 has been marked as a duplicate of this bug. ***","*** Bug 52218 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,17,NA,"['*** Bug 52218 has been marked as a duplicate of this bug.', '***']",NA,1861,TRUE,"***" +6266,"Jenkins: Use node-jscs as checkstyle for javascript coding style","Now merged locally in the repo for VisualEditor, and appears to be adding value; moving back to NEW for consideration to be added to jenkins for automated running.",1386355646,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","Now merged locally in the repo for VisualEditor, and appears to be adding value; moving back to NEW for consideration to be added to jenkins for automated running.","Now merged locally in the repo for VisualEditor, and appears to be adding value; moving back to NEW for consideration to be added to jenkins for automated running.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,22,NA,"['Now merged locally in the repo for VisualEditor, and appears to be adding value; moving back to NEW for consideration to be added to jenkins for automated running.']",NA,1973,TRUE,"Now merged locally in the repo for VisualEditor, and appears to be adding value; moving back to NEW for consideration to be added to jenkins for automated running." +6261,"Jenkins: Use node-jscs as checkstyle for javascript coding style","Is this intended to be a tracking bug for every repo, a bug for it to be done automatically for all repos and then repos that now break need to fix themselves, or can it be marked as FIXED?",1395766504,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-2mkgo6douokimv6febmw","task_subcomment","Is this intended to be a tracking bug for every repo, a bug for it to be done automatically for all repos and then repos that now break need to fix themselves, or can it be marked as FIXED?","Is this intended to be a tracking bug for every repo, a bug for it to be done automatically for all repos and then repos that now break need to fix themselves, or can it be marked as FIXED?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,38,NA,"['Is this intended to be a tracking bug for every repo, a bug for it to be done automatically for all repos and then repos that now break need to fix themselves, or can it be marked as FIXED?']",NA,2127,TRUE,"Is this intended to be a tracking bug for every repo, a bug for it to be done automatically for all repos and then repos that now break need to fix themselves, or can it be marked as FIXED?" +838,"VisualEditor: Dimensions of small images are lost in rendering","Fixed in 2013.",1415881118,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-bd72y7iiei67kbxti76b","task_subcomment","Fixed in 2013.","Fixed in 2013.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,71,NA,"['Fixed in 2013.']",NA,2334,TRUE,"Fixed in 2013." +872,"Request for edit summary preview"," + +*** This bug has been marked as a duplicate of bug 42139 ***",1380545659,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-uro44a5vqso2sy7u2arn","task_subcomment"," + +*** This bug has been marked as a duplicate of bug 42139 ***"," + +*** This bug has been marked as a duplicate of bug 42139 ***",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['\n\n*** This bug has been marked as a duplicate of bug 42139 ***']",NA,407,FALSE,"\n\n*** This bug has been marked as a duplicate of bug 42139 ***" diff --git a/analysis_data/102025_human_labels.csv b/analysis_data/102025_human_labels.csv new file mode 100644 index 0000000..0695ce6 --- /dev/null +++ b/analysis_data/102025_human_labels.csv @@ -0,0 +1,61006 @@ +id,task_title,comment_text,date_created,AuthorPHID,TaskPHID,comment_type,text_for_analysis,cleaned_messages,priority,priority_score,date_closed,CloserPHID,status,time_flag,source,phase,author_closer,same_author,week_index,http_flag,olmo_cleaned_sentences,resolution_outcome,verification_sample,cleaned_sentences,human_label,isEdgeCase,ECRationale +1964,"VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting","See (ferinstance) https://en.wikipedia.org/w/index.php?title=User:JohnCD/draft&diff=560430675&oldid=560430611 + +-------------------------- +**Version**: unspecified +**Severity**: normal",1371574560,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-kybodyavmyonstmof6sr,task_description,"VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting./n/nSee (ferinstance) https://en.wikipedia.org/w/index.php?title=User:JohnCD/draft&diff=560430675&oldid=560430611 + +-------------------------- +**Version**: unspecified +**Severity**: normal","VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting./n/nSee (ferinstance) URL + +-------------------------- +**Version**: unspecified +**Severity**: normal",Needs Triage,90,1371574643,NA,resolved,TRUE,c1,2,FALSE,FALSE,-2,NA,"['VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting.', 'See (ferinstance) URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,See (ferinstance) URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal,BUG REPRODUCTION,x,"provides link to example error where bug is reproduced, could also be INVESTIGATION AND EXPLORATION" +6364,VisualEditor: Pasting text into VE from external text processor removes newlines,"System environment: +Win7 X64 +Google Chrome 29.0.1547.62 m + +Steps to reproduce: +Open a page +Edit it in VE +Copy-paste the following text: +a +b +c +d +e + +Expected output: +a +b +c +d +e + +Actual output: +abcde + +The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. + +The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",1378418160,PHID-USER-4bjsher5mqcoikeqnnec,PHID-TASK-3yhieue5lg5ipuzhildn,task_description,"VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: +Win7 X64 +Google Chrome 29.0.1547.62 m + +Steps to reproduce: +Open a page +Edit it in VE +Copy-paste the following text: +a +b +c +d +e + +Expected output: +a +b +c +d +e + +Actual output: +abcde + +The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. + +The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=52096","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: +Win7 X64 +Google Chrome 29.0.1547.62 m + +Steps to reproduce: +Open a page +Edit it in VE +Copy-paste the following text: +a +b +c +d +e + +Expected output: +a +b +c +d +e + +Actual output: +abcde + +The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. + +The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +URL",Medium,50,1385505615,NA,resolved,TRUE,c1,3,FALSE,FALSE,9,NA,"['VisualEditor: Pasting text into VE from external text processor removes newlines.', 'System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).', 'Newline is not copied in any of the cases.', 'The problem has also been tested by trying to copy-paste html text from chrome itself.', 'Newline is not copied.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,1,--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL,OBSERVED BUG BEHAVIOR,x,Describes observed bug behavior as severe +6365,VisualEditor: Pasting text into VE from external text processor removes newlines,"Change 86664 merged by jenkins-bot: +Rich paste + +https://gerrit.wikimedia.org/r/86664",1385500082,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-3yhieue5lg5ipuzhildn,task_subcomment,"Change 86664 merged by jenkins-bot: +Rich paste + +https://gerrit.wikimedia.org/r/86664","Change 86664 merged by jenkins-bot: +Rich paste + +GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,21,NA,['Change 86664 merged by jenkins-bot:\nRich paste\n\nGERRIT_URL'],NA,1,Change 86664 merged by jenkins-bot:\nRich paste\n\nGERRIT_URL,TASK PROGRESS,x,Not quite action on issue but it is an update of how the work is going +6392,"VisualEditor:
not always preventing editing in VE","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div. + +The editing templates within the div does sound like a bug though. + +If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.",1378320819,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div. + +The editing templates within the div does sound like a bug though. + +If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div. + +The editing templates within the div does sound like a bug though. + +If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.', 'The editing templates within the div does sound like a bug though.', ""If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.""]",NA,1,"According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.",INVESTIGATION AND EXPLORATION,x,"I'm not sure if this falls into SOLUTION DISCUSSION though, primarily concerned with figuring out the behavior of the bug " +6394,"VisualEditor:
not always preventing editing in VE","The original person to report this noted that they were using Chrome 29 on Windows 7. + +I have been unable to reproduce this in Firefox 23 on Linux. + +Neither kww or the ip who can reproduce this have noted their system.",1378318792,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"The original person to report this noted that they were using Chrome 29 on Windows 7. + +I have been unable to reproduce this in Firefox 23 on Linux. + +Neither kww or the ip who can reproduce this have noted their system.","The original person to report this noted that they were using Chrome 29 on Windows 7. + +I have been unable to reproduce this in Firefox 23 on Linux. + +Neither kww or the ip who can reproduce this have noted their system.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['The original person to report this noted that they were using Chrome 29 on Windows 7.', 'I have been unable to reproduce this in Firefox 23 on Linux.', 'Neither kww or the ip who can reproduce this have noted their system.']",NA,1,Neither kww or the ip who can reproduce this have noted their system.,BUG REPRODUCTION,x,Could also be Social; though it's a social comment focused on bug reproduction +7036,VisualEditor: Backspace should not delete list and line in same action,"**Author:** `mcdevitd` + +**Description:** +Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",1375729680,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_description,"VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** `mcdevitd` + +**Description:** +Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.","VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** CODE + +**Description:** +Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",Medium,50,NA,NA,open,TRUE,c1,3,FALSE,FALSE,5,NA,"['VisualEditor: Backspace should not delete list and line in same action.', '**Author:** CODE\n\n**Description:**\nTypically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more.', 'VisualEditor will completely delete the line itself and move the text to the end of the previous line.', 'This is not how OpenOffice or Word works.']",FALSE,1,This is not how OpenOffice or Word works.,EXPECTED BEHAVIOR,x,I think this makes sense because it's describing motivating examples of expected behavior +7037,VisualEditor: Backspace should not delete list and line in same action,"Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext). Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden �����no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",1650765676,PHID-USER-unpoeiyj52rmcfqi5rbw,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_subcomment,"Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext). Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden �����no equivalence in VE; second Backspace press: the paragraph is merged with previous element).","Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext). Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden �����no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,459,NA,"['Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext).', 'Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden ���\xa0no equivalence in VE; second Backspace press: the paragraph is merged with previous element).']",NA,1,"Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext).",EXPECTED BEHAVIOR,x,I think that this is clearly describing a motivating example of expected functionality -- could also be motivational or social. +7037,VisualEditor: Backspace should not delete list and line in same action,"Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext). Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden �����no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",1650765676,PHID-USER-unpoeiyj52rmcfqi5rbw,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_subcomment,"Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext). Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden �����no equivalence in VE; second Backspace press: the paragraph is merged with previous element).","Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext). Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden �����no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,459,NA,"['Currently (for years), pressing backspace in LibreOffice makes the paragraph exit the list **only if it is empty** (note we may split an ordered list in OpenDocuments, whereas we cannot in wikitext).', 'Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden ���\xa0no equivalence in VE; second Backspace press: the paragraph is merged with previous element).']",NA,1,"Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden ���\xa0no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",EXPECTED BEHAVIOR,x,I think that this is clearly describing a motivating example of expected functionality -- could also be motivational or social. +7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +QUOTE +QUOTE +QUOTE + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +QUOTE +QUOTE + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow).",SOLUTION DISCUSSION,x,"I think that this is a pretty direct discussion of a possible solution, something that hasn't happened yet but is also not explicitly planned" +7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"The re-ordered tabs and section edit links, so that the VE tab is second?",SOLUTION DISCUSSION,x,"I think these are all solution discussions because though they are framed as questions, they are specifically asking about facets of a given solution" +9571,mw.hook listeners for GuidedTour for shouldSkip,"Investigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. + +If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). + +-------------------------- +**Version**: master +**Severity**: enhancement",1368612900,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-xj7stom4ugsmlhxmz6az,task_description,"mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. + +If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). + +-------------------------- +**Version**: master +**Severity**: enhancement","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. + +If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). + +-------------------------- +**Version**: master +**Severity**: enhancement",Medium,50,1402344878,NA,resolved,TRUE,c1,1,TRUE,FALSE,-7,NA,"['mw.hook listeners for GuidedTour for shouldSkip.', 'Investigate how mw.hook could be useful for GuidedTour.', 'One idea is subscribing to state changes for shouldSkip.', 'For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.', 'If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",FALSE,1,"For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.",EXPECTED BEHAVIOR,x,"Once again, describing extant software behavior as the expected behavior of a given feature " +12556,VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars,"Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. + +The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. + +And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",1359158880,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-fbrnpd67ntdl7dxrvivk,task_description,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. + +The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. + +And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. + +The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. + +And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",Low,25,NA,NA,open,TRUE,c1,1,TRUE,FALSE,-23,NA,"['VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.', 'Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.', ""The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."", ""And we're currently duplicating this internal logic at the cost of decentralisation."", 'So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,"The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.",MOTIVATION,x,"In this case, kind of an anti-motivation" +12556,VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars,"Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. + +The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. + +And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",1359158880,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-fbrnpd67ntdl7dxrvivk,task_description,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. + +The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. + +And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. + +The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. + +And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",Low,25,NA,NA,open,TRUE,c1,1,TRUE,FALSE,-23,NA,"['VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.', 'Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.', ""The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."", ""And we're currently duplicating this internal logic at the cost of decentralisation."", 'So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,And we're currently duplicating this internal logic at the cost of decentralisation.,INVESTIGATION AND EXPLORATION,x, +14316,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.,1384972951,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.,I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. URL redirects to URL which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''URL making the request SSL/TLS protected for all users.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,12,TRUE,"['I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin.', 'URL redirects to URL which causes the XHR request to hang/fail.', ""This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?'"", ""to ''URL making the request SSL/TLS protected for all users.""]",NA,1,to ''URL making the request SSL/TLS protected for all users.,SOCIAL CONVERSATION,x,Seems like small talk when decontextualized +14319,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),"(In reply to comment #1) +> A related improvement would be to use the secure API endpoint when the user +> is using https on the mediawiki site. + +Only if it works. ;-)",1379997214,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,"(In reply to comment #1) +> A related improvement would be to use the secure API endpoint when the user +> is using https on the mediawiki site. + +Only if it works. ;-)","(In reply to comment #1) +QUOTE +QUOTE + +Only if it works. ;-)",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,3,TRUE,"['(In reply to comment #1)\nQUOTE\nQUOTE\n\nOnly if it works.', ';-)']",NA,1,;-),SOCIAL CONVERSATION,, +15546,Wikidata.org is using the SSL certificate for *.wikimedia.org,"RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. +Closing too, thanks for the ping.",1354281045,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. +Closing too, thanks for the ping.","RT #3803 resolved, URL merged. +Closing too, thanks for the ping.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-39,TRUE,"['RT #3803 resolved, URL merged.', 'Closing too, thanks for the ping.']",NA,1,"RT #3803 resolved, URL merged.",TASK PROGRESS,x,Update on relevant work to the comment +15551,Wikidata.org is using the SSL certificate for *.wikimedia.org," Ah so wikidata SSL is working now +<^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. +<^demon> Krenair: Apache config is correct. It needs further DNS work. + +And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",1351534738,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment," Ah so wikidata SSL is working now +<^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. +<^demon> Krenair: Apache config is correct. It needs further DNS work. + +And Wikidata SUL autologin has been re-enabled with Gerrit change 30623."," Ah so wikidata SSL is working now +<^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. +<^demon> Krenair: Apache config is correct. It needs further DNS work. + +And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"[' Ah so wikidata SSL is working now\n<^demon> Krenair: For wikidata.org & www.wikidata.org.', 'Lang subdomains need a little further tweaking.', '<^demon> Krenair: Apache config is correct.', 'It needs further DNS work.', 'And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.']",NA,1, Ah so wikidata SSL is working now\n<^demon> Krenair: For wikidata.org & www.wikidata.org.,SOLUTION DISCUSSION,x,"Thought about this being investigation and exploration but it's explicitly about the solution working on the pages - so I think it's discussion,. " +15556,Wikidata.org is using the SSL certificate for *.wikimedia.org,Doesn't seem to have fixed it... Or just hasn't been deployed.,1351377062,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,Doesn't seem to have fixed it... Or just hasn't been deployed.,Doesn't seem to have fixed it... Or just hasn't been deployed.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"[""Doesn't seem to have fixed it... Or just hasn't been deployed.""]",NA,1,Doesn't seem to have fixed it... Or just hasn't been deployed.,OBSERVED BUG BEHAVIOR,x,I think this is still describing the persistence of buggy behavior but could also be something else +16733,MWHttpRequest may have to require_once() GlobalFunctions.php,You'll want to create a $wgAuth instance I think (or should even that not run until wgExtensionFunctions time? quite possibly) but you definitely should NOT be actively attempting to use framework features as nothing may be set up yet.,1321644785,PHID-USER-yek7ymogrv4qc67oilhf,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,You'll want to create a $wgAuth instance I think (or should even that not run until wgExtensionFunctions time? quite possibly) but you definitely should NOT be actively attempting to use framework features as nothing may be set up yet.,You'll want to create a $wgAuth instance I think (or should even that not run until wgExtensionFunctions time? quite possibly) but you definitely should NOT be actively attempting to use framework features as nothing may be set up yet.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-93,TRUE,"[""You'll want to create a $wgAuth instance I think (or should even that not run until wgExtensionFunctions time?"", 'quite possibly) but you definitely should NOT be actively attempting to use framework features as nothing may be set up yet.']",NA,1,quite possibly) but you definitely should NOT be actively attempting to use framework features as nothing may be set up yet.,INVESTIGATION AND EXPLORATION,X,"ITS HARD BECAUSE IT SEEMS LIKE A DIRECTIVE, BUT I THINK ULTIMATELY THIS IS STILL A QUESTION TRYING TO FIGURE OUT THE USE PATTERN THAT GENERATES THE BUG " +16857,NewUserMessage extensions breaks login,"I installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker",1326123000,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_description,"NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker","NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker",High,80,1350964208,NA,declined,TRUE,c2,1,FALSE,FALSE,-86,TRUE,"['NewUserMessage extensions breaks login.', 'I installed this extension and it works fine for a new user signing up, but it breaks login for existing users.', 'Logging in as an existing user generates the error:\n\nLogin error\nYou have not specified a valid username.', 'Disabling the extension resolved the issue for me.', 'This is using MediaWiki 1.18.0.', 'Nothing showed up in the error log.', '--------------------------\n**Version**: unspecified\n**Severity**: blocker']",TRUE,1,This is using MediaWiki 1.18.0.,BUG REPRODUCTION,X,"I THINK THE INFORMATION PROVIDED IS CLEARLY FOR REPRODUCTION PURPOSES, BUT ALSO COULD BE INVESTIGATION " +16859,NewUserMessage extensions breaks login,"Unfortunately closing this report as no further information has been provided. + +Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see http://www.mediawiki.org/wiki/Version_lifecycle ). Thanks!",1350964208,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"Unfortunately closing this report as no further information has been provided. + +Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see http://www.mediawiki.org/wiki/Version_lifecycle ). Thanks!","Unfortunately closing this report as no further information has been provided. + +Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see URL ). Thanks!",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-45,TRUE,"['Unfortunately closing this report as no further information has been provided.', 'Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see URL ).', 'Thanks!']",NA,1,Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see URL ).,ACTION ON ISSUE,X,"GIVEN THAT THE COMMENT PRIMARILY FOCUSES ON THE ISSUE OPEN/CLOSE STATUS, I THINK THAT IT IS MORE ACTION ON ISSUE THAN IT IS FUTURE WORK OR ANYTHING " +16860,NewUserMessage extensions breaks login,"**AzianAlex** wrote: + +Works fine for me too. Have you tried clearing your cache?",1337632645,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"**AzianAlex** wrote: + +Works fine for me too. Have you tried clearing your cache?","**AzianAlex** wrote: + +Works fine for me too. Have you tried clearing your cache?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-67,TRUE,"['**AzianAlex** wrote:\n\nWorks fine for me too.', 'Have you tried clearing your cache?']",NA,1,**AzianAlex** wrote:\n\nWorks fine for me too.,SOLUTION USAGE,X,"ANTI-REPRODUCTION, TESTING AND USAGE OF SOLUTION" +16861,NewUserMessage extensions breaks login,"**vivekee047** wrote: + +This works fine for me. Can you check it once again please. +Thanks",1335110687,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"**vivekee047** wrote: + +This works fine for me. Can you check it once again please. +Thanks","**vivekee047** wrote: + +This works fine for me. Can you check it once again please. +Thanks",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"['**vivekee047** wrote:\n\nThis works fine for me.', 'Can you check it once again please.', 'Thanks']",NA,1,**vivekee047** wrote:\n\nThis works fine for me.,SOLUTION USAGE,X, +17237,"Notification emails should link to https, not http","Just got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 +for all changes since your last visit. See +http://en.wikipedia.org/wiki/User_talk:Multichill for the current +revision. + +To contact the editor, visit +http://en.wikipedia.org/wiki/User:Magicpiano + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you +would like to switch off your notifications, visit +http://en.wikipedia.org/wiki/Special:Preferences + +Feedback and further assistance: +http://en.wikipedia.org/wiki/Help:Contents + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1322836380,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_description,"Notification emails should link to https, not http./n/nJust got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 +for all changes since your last visit. See +http://en.wikipedia.org/wiki/User_talk:Multichill for the current +revision. + +To contact the editor, visit +http://en.wikipedia.org/wiki/User:Magicpiano + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you +would like to switch off your notifications, visit +http://en.wikipedia.org/wiki/Special:Preferences + +Feedback and further assistance: +http://en.wikipedia.org/wiki/Help:Contents + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Notification emails should link to https, not http./n/nJust got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +URL +for all changes since your last visit. See +URL for the current +revision. + +To contact the editor, visit +URL + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see URL If you +would like to switch off your notifications, visit +URL + +Feedback and further assistance: +URL + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal",Medium,50,1404092595,NA,resolved,TRUE,c2,1,FALSE,FALSE,-91,TRUE,"['Notification emails should link to https, not http.', 'Just got a new message notification:\n\nDear Multichill,\n\n\nThe Wikipedia page ""User talk:Multichill"" has been changed on\n2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking\non National Register of Historic Places in Lowell, Massachusetts */ link\nfix \n\nSee\nURL\nfor all changes since your last visit.', 'See\nURL for the current\nrevision.', 'To contact the editor, visit\nURL\n\nNote that additional changes to the page ""User talk:Multichill"" will not\nresult in any further notifications, until you have logged in and\nvisited the page.', 'Your friendly Wikipedia notification system\n\n--\n\nThis email notification feature was enabled on English Wikipedia in May\n2011 - see URL If you\nwould like to switch off your notifications, visit\nURL\n\nFeedback and further assistance:\nURL\n\n(end)\n\nAll links should be https now we properly implemented ssl.', 'If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"Your friendly Wikipedia notification system\n\n--\n\nThis email notification feature was enabled on English Wikipedia in May\n2011 - see URL If you\nwould like to switch off your notifications, visit\nURL\n\nFeedback and further assistance:\nURL\n\n(end)\n\nAll links should be https now we properly implemented ssl.",TASK PROGRESS,X,CONTAINS BOTH BUG BEHAVIOR AND SOLUTION DISCUSSION BUT I THINK THAT THE SOLUTION DISCUSSION IS A BIT MORE SALIENT +17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,And this bug sitting here isn't going to change that schedule.,ISSUE CONTENT MANAGEMENT,X,REFERENCE TO THE ISSUE +17241,"Notification emails should link to https, not http","Marking works for me, it is a duplicate of several other bugs: + +* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) +* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. + +Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",1342801588,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"Marking works for me, it is a duplicate of several other bugs: + +* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) +* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. + +Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).","Marking works for me, it is a duplicate of several other bugs: + +* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) +* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. + +Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-58,TRUE,"['Marking works for me, it is a duplicate of several other bugs:\n\n* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11)\n* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages.', 'Note that to enable https by default, all we need to do is set wgCanonicalServer to https.', ""That's just a configuration change, no software change."", 'The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone.', 'There is a bug open about that already.', 'See also the tracking bug about secure access (bug 27946).']",NA,1,See also the tracking bug about secure access (bug 27946).,ISSUE CONTENT MANAGEMENT,X,SEEMS TO BE REDIRECTING DISCUSSION TO EXTERNAL SPACE- NOT NECESSARILY DISCUSSING ISSUE ACTION THOUGH +17532,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +> http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ +> Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg +> +> Some sort of Guru meditation. + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +> I determined that I'd hit bug 17645, saved the file as a baseline optimized +> JPEG rather than progressive and now the thumbnails work. Sorry for the +> noise. +> +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",1400351520,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +> http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ +> Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg +> +> Some sort of Guru meditation. + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +> I determined that I'd hit bug 17645, saved the file as a baseline optimized +> JPEG rather than progressive and now the thumbnails work. Sorry for the +> noise. +> +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.","Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +QUOTE +QUOTE +QUOTE +QUOTE + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,37,TRUE,"['Error code 137 = out of memory.', ""(In reply to Jasper Deng from comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's the use case for generating a 6000px wide thumbnail?"", '(In reply to earthsound from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that would do it.', 'Progressive images are much more memory intensive to scale.', '----\nNote: the Carbon river file is a baseline jpeg.', ""Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail."", 'I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.']",NA,1,(In reply to Jasper Deng from comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's the use case for generating a 6000px wide thumbnail?,SOLUTION USAGE,X,COULD ALSO BE INVESTIGATION +17539,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**sumanah** wrote: + +Still reproducible at + +http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg + +When I change the width: + +https://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/72px-Carbon_River_pano_01A.jpg + +then it's fine. + +This may be related to bug 13493 (""Can't create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?"").",1351149257,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**sumanah** wrote: + +Still reproducible at + +http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg + +When I change the width: + +https://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/72px-Carbon_River_pano_01A.jpg + +then it's fine. + +This may be related to bug 13493 (""Can't create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?"").","**sumanah** wrote: + +Still reproducible at + +URL + +When I change the width: + +URL + +then it's fine. + +This may be related to bug 13493 (""Can't create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?"").",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-44,TRUE,"[""**sumanah** wrote:\n\nStill reproducible at\n\nURL\n\nWhen I change the width:\n\nURL\n\nthen it's fine."", 'This may be related to bug 13493 (""Can\'t create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?', '"").']",NA,1,"This may be related to bug 13493 (""Can\",INVESTIGATION AND EXPLORATION,X,ISSUE-CONTENT-Y BUT ULTIMATELY IS CONJECTURE ABOUT MECHANISM +22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL + + - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,"Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.",POTENTIAL NEW ISSUES AND REQUESTS,X,ALSO A LITTLE BIT OF DISCUSSION AROUND THE MANAGEMENT OF THE SOLUTION ETC. +1964,"VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting","See (ferinstance) https://en.wikipedia.org/w/index.php?title=User:JohnCD/draft&diff=560430675&oldid=560430611 + +-------------------------- +**Version**: unspecified +**Severity**: normal",1371574560,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-kybodyavmyonstmof6sr,task_description,"VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting./n/nSee (ferinstance) https://en.wikipedia.org/w/index.php?title=User:JohnCD/draft&diff=560430675&oldid=560430611 + +-------------------------- +**Version**: unspecified +**Severity**: normal","VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting./n/nSee (ferinstance) URL + +-------------------------- +**Version**: unspecified +**Severity**: normal",Needs Triage,90,1371574643,NA,resolved,TRUE,c1,2,FALSE,FALSE,-2,NA,"['VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting.', 'See (ferinstance) URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,"VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting.",OBSERVED BUG BEHAVIOR,, +1965,"VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting"," + +%%%*** This bug has been marked as a duplicate of bug 49755 ***%%%",1371574643,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-kybodyavmyonstmof6sr,task_subcomment," + +%%%*** This bug has been marked as a duplicate of bug 49755 ***%%%"," + +%%%*** This bug has been marked as a duplicate of bug 49755 ***%%%",NA,NA,NA,NA,NA,TRUE,c1,2,FALSE,NA,-2,NA,['\n\n%%%*** This bug has been marked as a duplicate of bug 49755 ***%%%'],NA,1,\n\n%%%*** This bug has been marked as a duplicate of bug 49755 ***%%%,ACTION ON ISSUE,, +6364,VisualEditor: Pasting text into VE from external text processor removes newlines,"System environment: +Win7 X64 +Google Chrome 29.0.1547.62 m + +Steps to reproduce: +Open a page +Edit it in VE +Copy-paste the following text: +a +b +c +d +e + +Expected output: +a +b +c +d +e + +Actual output: +abcde + +The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. + +The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",1378418160,PHID-USER-4bjsher5mqcoikeqnnec,PHID-TASK-3yhieue5lg5ipuzhildn,task_description,"VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: +Win7 X64 +Google Chrome 29.0.1547.62 m + +Steps to reproduce: +Open a page +Edit it in VE +Copy-paste the following text: +a +b +c +d +e + +Expected output: +a +b +c +d +e + +Actual output: +abcde + +The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. + +The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=52096","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: +Win7 X64 +Google Chrome 29.0.1547.62 m + +Steps to reproduce: +Open a page +Edit it in VE +Copy-paste the following text: +a +b +c +d +e + +Expected output: +a +b +c +d +e + +Actual output: +abcde + +The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. + +The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +URL",Medium,50,1385505615,NA,resolved,TRUE,c1,3,FALSE,FALSE,9,NA,"['VisualEditor: Pasting text into VE from external text processor removes newlines.', 'System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).', 'Newline is not copied in any of the cases.', 'The problem has also been tested by trying to copy-paste html text from chrome itself.', 'Newline is not copied.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,1,VisualEditor: Pasting text into VE from external text processor removes newlines.,OBSERVED BUG BEHAVIOR,, +6364,VisualEditor: Pasting text into VE from external text processor removes newlines,"System environment: +Win7 X64 +Google Chrome 29.0.1547.62 m + +Steps to reproduce: +Open a page +Edit it in VE +Copy-paste the following text: +a +b +c +d +e + +Expected output: +a +b +c +d +e + +Actual output: +abcde + +The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. + +The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",1378418160,PHID-USER-4bjsher5mqcoikeqnnec,PHID-TASK-3yhieue5lg5ipuzhildn,task_description,"VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: +Win7 X64 +Google Chrome 29.0.1547.62 m + +Steps to reproduce: +Open a page +Edit it in VE +Copy-paste the following text: +a +b +c +d +e + +Expected output: +a +b +c +d +e + +Actual output: +abcde + +The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. + +The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=52096","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: +Win7 X64 +Google Chrome 29.0.1547.62 m + +Steps to reproduce: +Open a page +Edit it in VE +Copy-paste the following text: +a +b +c +d +e + +Expected output: +a +b +c +d +e + +Actual output: +abcde + +The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. + +The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +URL",Medium,50,1385505615,NA,resolved,TRUE,c1,3,FALSE,FALSE,9,NA,"['VisualEditor: Pasting text into VE from external text processor removes newlines.', 'System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).', 'Newline is not copied in any of the cases.', 'The problem has also been tested by trying to copy-paste html text from chrome itself.', 'Newline is not copied.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,1,"System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).",BUG REPRODUCTION,, +6364,VisualEditor: Pasting text into VE from external text processor removes newlines,"System environment: +Win7 X64 +Google Chrome 29.0.1547.62 m + +Steps to reproduce: +Open a page +Edit it in VE +Copy-paste the following text: +a +b +c +d +e + +Expected output: +a +b +c +d +e + +Actual output: +abcde + +The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. + +The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",1378418160,PHID-USER-4bjsher5mqcoikeqnnec,PHID-TASK-3yhieue5lg5ipuzhildn,task_description,"VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: +Win7 X64 +Google Chrome 29.0.1547.62 m + +Steps to reproduce: +Open a page +Edit it in VE +Copy-paste the following text: +a +b +c +d +e + +Expected output: +a +b +c +d +e + +Actual output: +abcde + +The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. + +The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=52096","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: +Win7 X64 +Google Chrome 29.0.1547.62 m + +Steps to reproduce: +Open a page +Edit it in VE +Copy-paste the following text: +a +b +c +d +e + +Expected output: +a +b +c +d +e + +Actual output: +abcde + +The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. + +The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +URL",Medium,50,1385505615,NA,resolved,TRUE,c1,3,FALSE,FALSE,9,NA,"['VisualEditor: Pasting text into VE from external text processor removes newlines.', 'System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).', 'Newline is not copied in any of the cases.', 'The problem has also been tested by trying to copy-paste html text from chrome itself.', 'Newline is not copied.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,1,Newline is not copied in any of the cases.,OBSERVED BUG BEHAVIOR,, +6364,VisualEditor: Pasting text into VE from external text processor removes newlines,"System environment: +Win7 X64 +Google Chrome 29.0.1547.62 m + +Steps to reproduce: +Open a page +Edit it in VE +Copy-paste the following text: +a +b +c +d +e + +Expected output: +a +b +c +d +e + +Actual output: +abcde + +The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. + +The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",1378418160,PHID-USER-4bjsher5mqcoikeqnnec,PHID-TASK-3yhieue5lg5ipuzhildn,task_description,"VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: +Win7 X64 +Google Chrome 29.0.1547.62 m + +Steps to reproduce: +Open a page +Edit it in VE +Copy-paste the following text: +a +b +c +d +e + +Expected output: +a +b +c +d +e + +Actual output: +abcde + +The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. + +The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=52096","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: +Win7 X64 +Google Chrome 29.0.1547.62 m + +Steps to reproduce: +Open a page +Edit it in VE +Copy-paste the following text: +a +b +c +d +e + +Expected output: +a +b +c +d +e + +Actual output: +abcde + +The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. + +The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +URL",Medium,50,1385505615,NA,resolved,TRUE,c1,3,FALSE,FALSE,9,NA,"['VisualEditor: Pasting text into VE from external text processor removes newlines.', 'System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).', 'Newline is not copied in any of the cases.', 'The problem has also been tested by trying to copy-paste html text from chrome itself.', 'Newline is not copied.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,1,The problem has also been tested by trying to copy-paste html text from chrome itself.,BUG REPRODUCTION,, +6364,VisualEditor: Pasting text into VE from external text processor removes newlines,"System environment: +Win7 X64 +Google Chrome 29.0.1547.62 m + +Steps to reproduce: +Open a page +Edit it in VE +Copy-paste the following text: +a +b +c +d +e + +Expected output: +a +b +c +d +e + +Actual output: +abcde + +The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. + +The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=52096",1378418160,PHID-USER-4bjsher5mqcoikeqnnec,PHID-TASK-3yhieue5lg5ipuzhildn,task_description,"VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: +Win7 X64 +Google Chrome 29.0.1547.62 m + +Steps to reproduce: +Open a page +Edit it in VE +Copy-paste the following text: +a +b +c +d +e + +Expected output: +a +b +c +d +e + +Actual output: +abcde + +The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. + +The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=52096","VisualEditor: Pasting text into VE from external text processor removes newlines./n/nSystem environment: +Win7 X64 +Google Chrome 29.0.1547.62 m + +Steps to reproduce: +Open a page +Edit it in VE +Copy-paste the following text: +a +b +c +d +e + +Expected output: +a +b +c +d +e + +Actual output: +abcde + +The problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR). Newline is not copied in any of the cases. + +The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied. + +-------------------------- +**Version**: unspecified +**Severity**: normal +**See Also**: +URL",Medium,50,1385505615,NA,resolved,TRUE,c1,3,FALSE,FALSE,9,NA,"['VisualEditor: Pasting text into VE from external text processor removes newlines.', 'System environment:\nWin7 X64\nGoogle Chrome 29.0.1547.62 m\n\nSteps to reproduce:\nOpen a page\nEdit it in VE\nCopy-paste the following text:\na\nb\nc\nd\ne\n\nExpected output:\na\nb\nc\nd\ne\n\nActual output:\nabcde\n\nThe problem has been tested with notepad++ as the external editor, with line endings in windows format (CRLF), UNIX format (LF) and MAC format (CR).', 'Newline is not copied in any of the cases.', 'The problem has also been tested by trying to copy-paste html text from chrome itself.', 'Newline is not copied.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,1,Newline is not copied.,OBSERVED BUG BEHAVIOR,, +6366,VisualEditor: Pasting text into VE from external text processor removes newlines,Works with gedit & chrome with the rich paste patch.,1381157678,PHID-USER-it53o2f2kyryqyj33uzt,PHID-TASK-3yhieue5lg5ipuzhildn,task_subcomment,Works with gedit & chrome with the rich paste patch.,Works with gedit & chrome with the rich paste patch.,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,14,NA,['Works with gedit & chrome with the rich paste patch.'],NA,1,Works with gedit & chrome with the rich paste patch.,EXPECTED BEHAVIOR,, +6367,VisualEditor: Pasting text into VE from external text processor removes newlines,"Change 86664 had a related patch set uploaded by Esanders: +Rich paste + +https://gerrit.wikimedia.org/r/86664",1381157509,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-3yhieue5lg5ipuzhildn,task_subcomment,"Change 86664 had a related patch set uploaded by Esanders: +Rich paste + +https://gerrit.wikimedia.org/r/86664","Change 86664 had a related patch set uploaded by Esanders: +Rich paste + +GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,14,NA,['Change 86664 had a related patch set uploaded by Esanders:\nRich paste\n\nGERRIT_URL'],NA,1,Change 86664 had a related patch set uploaded by Esanders:\nRich paste\n\nGERRIT_URL,TASK PROGRESS,, +6368,VisualEditor: Pasting text into VE from external text processor removes newlines,"Confirmed in Firefox 23 / Xubuntu Linux / Monobook + +Using kwrite: +Tested with \n \r and \r\n end of lines and it makes no difference. +Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. + +Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: + +a + +b + +c + +d + +e + +None of it makes the slightest bit of difference. + +https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0",1378420228,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-3yhieue5lg5ipuzhildn,task_subcomment,"Confirmed in Firefox 23 / Xubuntu Linux / Monobook + +Using kwrite: +Tested with \n \r and \r\n end of lines and it makes no difference. +Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. + +Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: + +a + +b + +c + +d + +e + +None of it makes the slightest bit of difference. + +https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0","Confirmed in Firefox 23 / Xubuntu Linux / Monobook + +Using kwrite: +Tested with \n \r and \r\n end of lines and it makes no difference. +Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. + +Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: + +a + +b + +c + +d + +e + +None of it makes the slightest bit of difference. + +URL is the copy from comment 0",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['Confirmed in Firefox 23 / Xubuntu Linux / Monobook\n\nUsing kwrite:\nTested with \\n \\r and \\r\\n end of lines and it makes no difference.', 'Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.', 'Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:\n\na\n\nb\n\nc\n\nd\n\ne\n\nNone of it makes the slightest bit of difference.', 'URL is the copy from comment 0']",NA,1,Confirmed in Firefox 23 / Xubuntu Linux / Monobook\n\nUsing kwrite:\nTested with \\n \\r and \\r\\n end of lines and it makes no difference.,TESTING,, +6368,VisualEditor: Pasting text into VE from external text processor removes newlines,"Confirmed in Firefox 23 / Xubuntu Linux / Monobook + +Using kwrite: +Tested with \n \r and \r\n end of lines and it makes no difference. +Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. + +Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: + +a + +b + +c + +d + +e + +None of it makes the slightest bit of difference. + +https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0",1378420228,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-3yhieue5lg5ipuzhildn,task_subcomment,"Confirmed in Firefox 23 / Xubuntu Linux / Monobook + +Using kwrite: +Tested with \n \r and \r\n end of lines and it makes no difference. +Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. + +Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: + +a + +b + +c + +d + +e + +None of it makes the slightest bit of difference. + +https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0","Confirmed in Firefox 23 / Xubuntu Linux / Monobook + +Using kwrite: +Tested with \n \r and \r\n end of lines and it makes no difference. +Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. + +Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: + +a + +b + +c + +d + +e + +None of it makes the slightest bit of difference. + +URL is the copy from comment 0",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['Confirmed in Firefox 23 / Xubuntu Linux / Monobook\n\nUsing kwrite:\nTested with \\n \\r and \\r\\n end of lines and it makes no difference.', 'Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.', 'Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:\n\na\n\nb\n\nc\n\nd\n\ne\n\nNone of it makes the slightest bit of difference.', 'URL is the copy from comment 0']",NA,1,"Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.",TESTING,, +6368,VisualEditor: Pasting text into VE from external text processor removes newlines,"Confirmed in Firefox 23 / Xubuntu Linux / Monobook + +Using kwrite: +Tested with \n \r and \r\n end of lines and it makes no difference. +Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. + +Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: + +a + +b + +c + +d + +e + +None of it makes the slightest bit of difference. + +https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0",1378420228,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-3yhieue5lg5ipuzhildn,task_subcomment,"Confirmed in Firefox 23 / Xubuntu Linux / Monobook + +Using kwrite: +Tested with \n \r and \r\n end of lines and it makes no difference. +Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. + +Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: + +a + +b + +c + +d + +e + +None of it makes the slightest bit of difference. + +https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0","Confirmed in Firefox 23 / Xubuntu Linux / Monobook + +Using kwrite: +Tested with \n \r and \r\n end of lines and it makes no difference. +Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. + +Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: + +a + +b + +c + +d + +e + +None of it makes the slightest bit of difference. + +URL is the copy from comment 0",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['Confirmed in Firefox 23 / Xubuntu Linux / Monobook\n\nUsing kwrite:\nTested with \\n \\r and \\r\\n end of lines and it makes no difference.', 'Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.', 'Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:\n\na\n\nb\n\nc\n\nd\n\ne\n\nNone of it makes the slightest bit of difference.', 'URL is the copy from comment 0']",NA,1,"Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:\n\na\n\nb\n\nc\n\nd\n\ne\n\nNone of it makes the slightest bit of difference.",TESTING,, +6368,VisualEditor: Pasting text into VE from external text processor removes newlines,"Confirmed in Firefox 23 / Xubuntu Linux / Monobook + +Using kwrite: +Tested with \n \r and \r\n end of lines and it makes no difference. +Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. + +Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: + +a + +b + +c + +d + +e + +None of it makes the slightest bit of difference. + +https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0",1378420228,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-3yhieue5lg5ipuzhildn,task_subcomment,"Confirmed in Firefox 23 / Xubuntu Linux / Monobook + +Using kwrite: +Tested with \n \r and \r\n end of lines and it makes no difference. +Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. + +Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: + +a + +b + +c + +d + +e + +None of it makes the slightest bit of difference. + +https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=571705481&oldid=571089410 is the copy from comment 0","Confirmed in Firefox 23 / Xubuntu Linux / Monobook + +Using kwrite: +Tested with \n \r and \r\n end of lines and it makes no difference. +Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings. + +Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following: + +a + +b + +c + +d + +e + +None of it makes the slightest bit of difference. + +URL is the copy from comment 0",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['Confirmed in Firefox 23 / Xubuntu Linux / Monobook\n\nUsing kwrite:\nTested with \\n \\r and \\r\\n end of lines and it makes no difference.', 'Tested also using UTF-8, UTF-16, ISO-8859-1, ISO-8859-2 and Windows-1258 encodings.', 'Also tested copying from this page viewed in Firefox, Konqueror and Linuks, from a PDF, a text file in a terminal, and again from kwrite using the following:\n\na\n\nb\n\nc\n\nd\n\ne\n\nNone of it makes the slightest bit of difference.', 'URL is the copy from comment 0']",NA,1,URL is the copy from comment 0,INVESTIGATION AND EXPLORATION,, +6380,"VisualEditor:
not always preventing editing in VE","**Author:** `kwwilliams` + +**Description:** +When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with
and
. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted. + +VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=52141",1378317960,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_description,"VisualEditor:
not always preventing editing in VE./n/n**Author:** `kwwilliams` + +**Description:** +When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with
and
. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted. + +VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=52141","VisualEditor:
not always preventing editing in VE./n/n**Author:** CODE + +**Description:** +When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with
and
. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted. + +VE is now allowing edits to templates inside the article (see URL for an example), so we now have no way to protect articles that we know VE cannot handle. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +URL",Medium,50,1403741232,NA,declined,TRUE,c1,3,FALSE,FALSE,9,NA,"['VisualEditor:
not always preventing editing in VE.', '**Author:** CODE\n\n**Description:**\nWhen articles contain items that lead VE to corrupt the article, we\'ve been protecting them by wrapping the article with
and
.', 'This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.', 'VE is now allowing edits to templates inside the article (see URL for an example), so we now have no way to protect articles that we know VE cannot handle.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,1,"VisualEditor:
not always preventing editing in VE.",OBSERVED BUG BEHAVIOR,, +6380,"VisualEditor:
not always preventing editing in VE","**Author:** `kwwilliams` + +**Description:** +When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with
and
. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted. + +VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=52141",1378317960,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_description,"VisualEditor:
not always preventing editing in VE./n/n**Author:** `kwwilliams` + +**Description:** +When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with
and
. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted. + +VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=52141","VisualEditor:
not always preventing editing in VE./n/n**Author:** CODE + +**Description:** +When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with
and
. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted. + +VE is now allowing edits to templates inside the article (see URL for an example), so we now have no way to protect articles that we know VE cannot handle. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +URL",Medium,50,1403741232,NA,declined,TRUE,c1,3,FALSE,FALSE,9,NA,"['VisualEditor:
not always preventing editing in VE.', '**Author:** CODE\n\n**Description:**\nWhen articles contain items that lead VE to corrupt the article, we\'ve been protecting them by wrapping the article with
and
.', 'This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.', 'VE is now allowing edits to templates inside the article (see URL for an example), so we now have no way to protect articles that we know VE cannot handle.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,1,"**Author:** CODE\n\n**Description:**\nWhen articles contain items that lead VE to corrupt the article, we\",MOTIVATION,, +6380,"VisualEditor:
not always preventing editing in VE","**Author:** `kwwilliams` + +**Description:** +When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with
and
. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted. + +VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=52141",1378317960,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_description,"VisualEditor:
not always preventing editing in VE./n/n**Author:** `kwwilliams` + +**Description:** +When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with
and
. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted. + +VE is now allowing edits to templates inside the article (see https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&veaction=edit for an example), so we now have no way to protect articles that we know VE cannot handle. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +https://bugzilla.wikimedia.org/show_bug.cgi?id=52141","VisualEditor:
not always preventing editing in VE./n/n**Author:** CODE + +**Description:** +When articles contain items that lead VE to corrupt the article, we've been protecting them by wrapping the article with
and
. This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted. + +VE is now allowing edits to templates inside the article (see URL for an example), so we now have no way to protect articles that we know VE cannot handle. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement +**See Also**: +URL",Medium,50,1403741232,NA,declined,TRUE,c1,3,FALSE,FALSE,9,NA,"['VisualEditor:
not always preventing editing in VE.', '**Author:** CODE\n\n**Description:**\nWhen articles contain items that lead VE to corrupt the article, we\'ve been protecting them by wrapping the article with
and
.', 'This used to keep VE from being able to select any material within the article, which allowed us to keep the article from being corrupted.', 'VE is now allowing edits to templates inside the article (see URL for an example), so we now have no way to protect articles that we know VE cannot handle.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,1,ve-ce-protectedNode,NA,, +6381,"VisualEditor:
not always preventing editing in VE","(In reply to This, that and the other from comment #13) +> As it stands, this is a dupe of bug 52141. I've put back the original bug +> summary; it seems to me that WONTFIX is the appropriate resolution for this +> bug. + +Agreed.",1403741232,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"(In reply to This, that and the other from comment #13) +> As it stands, this is a dupe of bug 52141. I've put back the original bug +> summary; it seems to me that WONTFIX is the appropriate resolution for this +> bug. + +Agreed.","(In reply to This, that and the other from comment #13) +QUOTE +QUOTE +QUOTE + +Agreed.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,51,NA,"['(In reply to This, that and the other from comment #13)\nQUOTE\nQUOTE\nQUOTE\n\nAgreed.']",NA,1,"(In reply to This, that and the other from comment #13)\nQUOTE\nQUOTE\nQUOTE\n\nAgreed.",SOCIAL CONVERSATION,, +6382,"VisualEditor:
not always preventing editing in VE","As it stands, this is a dupe of bug 52141. I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.",1403416223,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"As it stands, this is a dupe of bug 52141. I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.","As it stands, this is a dupe of bug 52141. I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,50,NA,"['As it stands, this is a dupe of bug 52141.', ""I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.""]",NA,1,"As it stands, this is a dupe of bug 52141.",ISSUE CONTENT MANAGEMENT,, +6382,"VisualEditor:
not always preventing editing in VE","As it stands, this is a dupe of bug 52141. I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.",1403416223,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"As it stands, this is a dupe of bug 52141. I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.","As it stands, this is a dupe of bug 52141. I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,50,NA,"['As it stands, this is a dupe of bug 52141.', ""I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.""]",NA,1,I've put back the original bug summary; it seems to me that WONTFIX is the appropriate resolution for this bug.,ACTION ON ISSUE,, +6383,"VisualEditor:
not always preventing editing in VE","James, that is bug 52141. This bug was about a specific problem with the existing code.",1383886236,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"James, that is bug 52141. This bug was about a specific problem with the existing code.","James, that is bug 52141. This bug was about a specific problem with the existing code.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,18,NA,"['James, that is bug 52141.', 'This bug was about a specific problem with the existing code.']",NA,1,"James, that is bug 52141.",ISSUE CONTENT MANAGEMENT,, +6383,"VisualEditor:
not always preventing editing in VE","James, that is bug 52141. This bug was about a specific problem with the existing code.",1383886236,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"James, that is bug 52141. This bug was about a specific problem with the existing code.","James, that is bug 52141. This bug was about a specific problem with the existing code.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,18,NA,"['James, that is bug 52141.', 'This bug was about a specific problem with the existing code.']",NA,1,This bug was about a specific problem with the existing code.,MOTIVATION,, +6384,"VisualEditor:
not always preventing editing in VE","Changing this to ""Provide a way to block VisualEditor from being active on a page""; I worry that this will lead to yet another magic word, but oh well.",1381342100,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"Changing this to ""Provide a way to block VisualEditor from being active on a page""; I worry that this will lead to yet another magic word, but oh well.","Changing this to ""Provide a way to block VisualEditor from being active on a page""; I worry that this will lead to yet another magic word, but oh well.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,14,NA,"['Changing this to ""Provide a way to block VisualEditor from being active on a page""; I worry that this will lead to yet another magic word, but oh well.']",NA,1,"Changing this to ""Provide a way to block VisualEditor from being active on a page""; I worry that this will lead to yet another magic word, but oh well.",ISSUE CONTENT MANAGEMENT,, +6385,"VisualEditor:
not always preventing editing in VE","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. + +This template is also being used to create a 'pre' text area on +https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit",1380637712,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. + +This template is also being used to create a 'pre' text area on +https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. + +This template is also being used to create a 'pre' text area on +URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,13,NA,"['I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.', ""Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser."", 'The toolbar is another way to override the protectedNode.', ""This template is also being used to create a 'pre' text area on\nURL""]",NA,1,"I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.",BUG REPRODUCTION,, +6385,"VisualEditor:
not always preventing editing in VE","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. + +This template is also being used to create a 'pre' text area on +https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit",1380637712,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. + +This template is also being used to create a 'pre' text area on +https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. + +This template is also being used to create a 'pre' text area on +URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,13,NA,"['I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.', ""Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser."", 'The toolbar is another way to override the protectedNode.', ""This template is also being used to create a 'pre' text area on\nURL""]",NA,1,The toolbar is another way to override the protectedNode.,WORKAROUNDS,, +6385,"VisualEditor:
not always preventing editing in VE","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. + +This template is also being used to create a 'pre' text area on +https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit",1380637712,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. + +This template is also being used to create a 'pre' text area on +https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. + +This template is also being used to create a 'pre' text area on +URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,13,NA,"['I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.', ""Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser."", 'The toolbar is another way to override the protectedNode.', ""This template is also being used to create a 'pre' text area on\nURL""]",NA,1,"Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser.",OBSERVED BUG BEHAVIOR,, +6385,"VisualEditor:
not always preventing editing in VE","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. + +This template is also being used to create a 'pre' text area on +https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit",1380637712,PHID-USER-oxd6f6xemkuyttw7z7wl,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. + +This template is also being used to create a 'pre' text area on +https://en.wikipedia.org/w/index.php?title=Morse_code&veaction=edit","I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article. Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser. The toolbar is another way to override the protectedNode. + +This template is also being used to create a 'pre' text area on +URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,13,NA,"['I was very easily able to reproduce this problem; I dont have exact steps to reproduce, but with a few clicks and keypresses in the content area, all content was removed and the text I typed appeared in the body of the article.', ""Undo appeared to work as expected, however 'Review your changes' did not return any results - it hung, but didnt lock up the browser."", 'The toolbar is another way to override the protectedNode.', ""This template is also being used to create a 'pre' text area on\nURL""]",NA,1,This template is also being used to create a 'pre' text area on\nURL,POTENTIAL NEW ISSUES AND REQUESTS,, +6386,"VisualEditor:
not always preventing editing in VE","**kwwilliams** wrote: + +Note https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=572094345&oldid=572076135 , where another 26,000 articles that VE mutilates have been identified. + +We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",1378671601,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: + +Note https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=572094345&oldid=572076135 , where another 26,000 articles that VE mutilates have been identified. + +We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.","**kwwilliams** wrote: + +Note URL , where another 26,000 articles that VE mutilates have been identified. + +We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['**kwwilliams** wrote:\n\nNote URL , where another 26,000 articles that VE mutilates have been identified.', 'We really need to have a method to shield articles from VE.', ""It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.""]",NA,1,"**kwwilliams** wrote:\n\nNote URL , where another 26,000 articles that VE mutilates have been identified.",INVESTIGATION AND EXPLORATION,, +6386,"VisualEditor:
not always preventing editing in VE","**kwwilliams** wrote: + +Note https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=572094345&oldid=572076135 , where another 26,000 articles that VE mutilates have been identified. + +We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",1378671601,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: + +Note https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=572094345&oldid=572076135 , where another 26,000 articles that VE mutilates have been identified. + +We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.","**kwwilliams** wrote: + +Note URL , where another 26,000 articles that VE mutilates have been identified. + +We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['**kwwilliams** wrote:\n\nNote URL , where another 26,000 articles that VE mutilates have been identified.', 'We really need to have a method to shield articles from VE.', ""It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.""]",NA,1,We really need to have a method to shield articles from VE.,MOTIVATION,, +6386,"VisualEditor:
not always preventing editing in VE","**kwwilliams** wrote: + +Note https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=572094345&oldid=572076135 , where another 26,000 articles that VE mutilates have been identified. + +We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",1378671601,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: + +Note https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=572094345&oldid=572076135 , where another 26,000 articles that VE mutilates have been identified. + +We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.","**kwwilliams** wrote: + +Note URL , where another 26,000 articles that VE mutilates have been identified. + +We really need to have a method to shield articles from VE. It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['**kwwilliams** wrote:\n\nNote URL , where another 26,000 articles that VE mutilates have been identified.', 'We really need to have a method to shield articles from VE.', ""It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.""]",NA,1,"It's critical to do, and beyond reason to expect that we will always modify articles to conform to VE's expectations.",SOLUTION USAGE,, +6387,"VisualEditor:
not always preventing editing in VE","I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP. + +At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ... + +https://en.wikipedia.org/w/index.php?title=User%3ANicoV%2FTest&diff=571628361&oldid=571542702",1378379690,PHID-USER-o34e5i3eq4nstbvcf26w,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP. + +At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ... + +https://en.wikipedia.org/w/index.php?title=User%3ANicoV%2FTest&diff=571628361&oldid=571542702","I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP. + +At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ... + +URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP.', 'At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ...\n\nURL']",NA,1,I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP.,TESTING,, +6387,"VisualEditor:
not always preventing editing in VE","I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP. + +At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ... + +https://en.wikipedia.org/w/index.php?title=User%3ANicoV%2FTest&diff=571628361&oldid=571542702",1378379690,PHID-USER-o34e5i3eq4nstbvcf26w,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP. + +At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ... + +https://en.wikipedia.org/w/index.php?title=User%3ANicoV%2FTest&diff=571628361&oldid=571542702","I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP. + +At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ... + +URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['I tried again on my test page on a different computer running Firefox 17.0.2 (ESR) under XP.', 'At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ...\n\nURL']",NA,1,"At first, it seemed that the protected node was working, but at some point (after clicking, double-clicking, typing, ...) I managed to write in the protected node: the result was an even greater mess than before: still the duplication, quotes added all over the place (they seem correct but unnecessary), pipes removed, space added, ...\n\nURL",OBSERVED BUG BEHAVIOR,, +6388,"VisualEditor:
not always preventing editing in VE","**kwwilliams** wrote: + +(In reply to comment #6) +> On the wider point, it's not clear if there's an actual long-term need for a +> proper VE-prevention system (or if it's all solvable with a few quick fixes +> of +> bad wikitext), but if there is, we should build a proper one, not rely on a +> hack that might break. + +What's unclear about that? + +I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",1378324543,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: + +(In reply to comment #6) +> On the wider point, it's not clear if there's an actual long-term need for a +> proper VE-prevention system (or if it's all solvable with a few quick fixes +> of +> bad wikitext), but if there is, we should build a proper one, not rely on a +> hack that might break. + +What's unclear about that? + +I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.","**kwwilliams** wrote: + +(In reply to comment #6) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +What's unclear about that? + +I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"[""**kwwilliams** wrote:\n\n(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's unclear about that?"", 'I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious.', 'As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.']",NA,1,"I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious.",MOTIVATION,, +6388,"VisualEditor:
not always preventing editing in VE","**kwwilliams** wrote: + +(In reply to comment #6) +> On the wider point, it's not clear if there's an actual long-term need for a +> proper VE-prevention system (or if it's all solvable with a few quick fixes +> of +> bad wikitext), but if there is, we should build a proper one, not rely on a +> hack that might break. + +What's unclear about that? + +I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",1378324543,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: + +(In reply to comment #6) +> On the wider point, it's not clear if there's an actual long-term need for a +> proper VE-prevention system (or if it's all solvable with a few quick fixes +> of +> bad wikitext), but if there is, we should build a proper one, not rely on a +> hack that might break. + +What's unclear about that? + +I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.","**kwwilliams** wrote: + +(In reply to comment #6) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +What's unclear about that? + +I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"[""**kwwilliams** wrote:\n\n(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's unclear about that?"", 'I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious.', 'As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.']",NA,1,"As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",MOTIVATION,, +6388,"VisualEditor:
not always preventing editing in VE","**kwwilliams** wrote: + +(In reply to comment #6) +> On the wider point, it's not clear if there's an actual long-term need for a +> proper VE-prevention system (or if it's all solvable with a few quick fixes +> of +> bad wikitext), but if there is, we should build a proper one, not rely on a +> hack that might break. + +What's unclear about that? + +I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",1378324543,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: + +(In reply to comment #6) +> On the wider point, it's not clear if there's an actual long-term need for a +> proper VE-prevention system (or if it's all solvable with a few quick fixes +> of +> bad wikitext), but if there is, we should build a proper one, not rely on a +> hack that might break. + +What's unclear about that? + +I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.","**kwwilliams** wrote: + +(In reply to comment #6) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +What's unclear about that? + +I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious. As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"[""**kwwilliams** wrote:\n\n(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's unclear about that?"", 'I agree that it would be better to do this with a category, but the need for VE to recognise some flag that tells it not to edit a given article seems fairly obvious.', 'As long as VE mutilates pages in response to inputs that behaved reasonably with the working software, we will require a mechanism to tell VE not to edit certain pages.']",NA,1,**kwwilliams** wrote:\n\n(In reply to comment #6)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's unclear about that?,SOCIAL CONVERSATION,, +6389,"VisualEditor:
not always preventing editing in VE","(In reply to comment #5) +> The div has been removed, so people need to look at +> https://en.wikipedia.org/w/index. +> php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632 + +In this particular case, note that the reason everything was broken in editing this page was because the was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: https://en.wikipedia.org/w/index.php?title=Teenage_Dream_(Katy_Perry_album)&diff=571550633&oldid=571540632 + +On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",1378323301,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"(In reply to comment #5) +> The div has been removed, so people need to look at +> https://en.wikipedia.org/w/index. +> php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632 + +In this particular case, note that the reason everything was broken in editing this page was because the was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: https://en.wikipedia.org/w/index.php?title=Teenage_Dream_(Katy_Perry_album)&diff=571550633&oldid=571540632 + +On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.","(In reply to comment #5) +QUOTE +QUOTE +QUOTE + +In this particular case, note that the reason everything was broken in editing this page was because the was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: URL + +On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,9,NA,"['(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nIn this particular case, note that the reason everything was broken in editing this page was because the was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed\'s edit to the page fixed the duplication so the desired protection is no longer needed: URL\n\nOn the wider point, it\'s not clear if there\'s an actual long-term need for a proper VE-prevention system (or if it\'s all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.']",NA,1,"(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nIn this particular case, note that the reason everything was broken in editing this page was because the was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed\",INVESTIGATION AND EXPLORATION,, +6389,"VisualEditor:
not always preventing editing in VE","(In reply to comment #5) +> The div has been removed, so people need to look at +> https://en.wikipedia.org/w/index. +> php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632 + +In this particular case, note that the reason everything was broken in editing this page was because the was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: https://en.wikipedia.org/w/index.php?title=Teenage_Dream_(Katy_Perry_album)&diff=571550633&oldid=571540632 + +On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",1378323301,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"(In reply to comment #5) +> The div has been removed, so people need to look at +> https://en.wikipedia.org/w/index. +> php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632 + +In this particular case, note that the reason everything was broken in editing this page was because the was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: https://en.wikipedia.org/w/index.php?title=Teenage_Dream_(Katy_Perry_album)&diff=571550633&oldid=571540632 + +On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.","(In reply to comment #5) +QUOTE +QUOTE +QUOTE + +In this particular case, note that the reason everything was broken in editing this page was because the was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: URL + +On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,9,NA,"['(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nIn this particular case, note that the reason everything was broken in editing this page was because the was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed\'s edit to the page fixed the duplication so the desired protection is no longer needed: URL\n\nOn the wider point, it\'s not clear if there\'s an actual long-term need for a proper VE-prevention system (or if it\'s all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.']",NA,1,s not clear if there\,NA,, +6389,"VisualEditor:
not always preventing editing in VE","(In reply to comment #5) +> The div has been removed, so people need to look at +> https://en.wikipedia.org/w/index. +> php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632 + +In this particular case, note that the reason everything was broken in editing this page was because the was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: https://en.wikipedia.org/w/index.php?title=Teenage_Dream_(Katy_Perry_album)&diff=571550633&oldid=571540632 + +On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",1378323301,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"(In reply to comment #5) +> The div has been removed, so people need to look at +> https://en.wikipedia.org/w/index. +> php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632 + +In this particular case, note that the reason everything was broken in editing this page was because the was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: https://en.wikipedia.org/w/index.php?title=Teenage_Dream_(Katy_Perry_album)&diff=571550633&oldid=571540632 + +On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.","(In reply to comment #5) +QUOTE +QUOTE +QUOTE + +In this particular case, note that the reason everything was broken in editing this page was because the was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed's edit to the page fixed the duplication so the desired protection is no longer needed: URL + +On the wider point, it's not clear if there's an actual long-term need for a proper VE-prevention system (or if it's all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,9,NA,"['(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\n\nIn this particular case, note that the reason everything was broken in editing this page was because the was defined outside of the table cell, in a the non-space between the end of the cell and the start of the row, and only happened to ""work"" in WT mode because of HTML Tidy moving it to somewhere sane - Ed\'s edit to the page fixed the duplication so the desired protection is no longer needed: URL\n\nOn the wider point, it\'s not clear if there\'s an actual long-term need for a proper VE-prevention system (or if it\'s all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.']",NA,1,"s all solvable with a few quick fixes of bad wikitext), but if there is, we should build a proper one, not rely on a hack that might break.",MOTIVATION,, +6390,"VisualEditor:
not always preventing editing in VE","**kwwilliams** wrote: + +The div has been removed, so people need to look at https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632",1378322920,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: + +The div has been removed, so people need to look at https://en.wikipedia.org/w/index.php?title=Teenage_Dream_%28Katy_Perry_album%29&oldid=571540632","**kwwilliams** wrote: + +The div has been removed, so people need to look at URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['**kwwilliams** wrote:\n\nThe div has been removed, so people need to look at URL']",NA,1,"**kwwilliams** wrote:\n\nThe div has been removed, so people need to look at URL",OBSERVED BUG BEHAVIOR,, +6391,"VisualEditor:
not always preventing editing in VE","**kwwilliams** wrote: + +(In reply to comment #3) +> According to the documentation, the div is only meant to block editing to a +> section of a page (although that section can be the whole text), so adding +> text +> before is correct, likewise you should be able to add text after the /div. +It's a change from the original behaviour. I agree that it's not technically wrong.",1378321376,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: + +(In reply to comment #3) +> According to the documentation, the div is only meant to block editing to a +> section of a page (although that section can be the whole text), so adding +> text +> before is correct, likewise you should be able to add text after the /div. +It's a change from the original behaviour. I agree that it's not technically wrong.","**kwwilliams** wrote: + +(In reply to comment #3) +QUOTE +QUOTE +QUOTE +QUOTE +It's a change from the original behaviour. I agree that it's not technically wrong.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"[""**kwwilliams** wrote:\n\n(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nIt's a change from the original behaviour."", ""I agree that it's not technically wrong.""]",NA,1,**kwwilliams** wrote:\n\n(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nIt's a change from the original behaviour.,OBSERVED BUG BEHAVIOR,, +6391,"VisualEditor:
not always preventing editing in VE","**kwwilliams** wrote: + +(In reply to comment #3) +> According to the documentation, the div is only meant to block editing to a +> section of a page (although that section can be the whole text), so adding +> text +> before is correct, likewise you should be able to add text after the /div. +It's a change from the original behaviour. I agree that it's not technically wrong.",1378321376,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: + +(In reply to comment #3) +> According to the documentation, the div is only meant to block editing to a +> section of a page (although that section can be the whole text), so adding +> text +> before is correct, likewise you should be able to add text after the /div. +It's a change from the original behaviour. I agree that it's not technically wrong.","**kwwilliams** wrote: + +(In reply to comment #3) +QUOTE +QUOTE +QUOTE +QUOTE +It's a change from the original behaviour. I agree that it's not technically wrong.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"[""**kwwilliams** wrote:\n\n(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nIt's a change from the original behaviour."", ""I agree that it's not technically wrong.""]",NA,1,I agree that it's not technically wrong.,SOCIAL CONVERSATION,, +6392,"VisualEditor:
not always preventing editing in VE","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div. + +The editing templates within the div does sound like a bug though. + +If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.",1378320819,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div. + +The editing templates within the div does sound like a bug though. + +If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div. + +The editing templates within the div does sound like a bug though. + +If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.', 'The editing templates within the div does sound like a bug though.', ""If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.""]",NA,1,The editing templates within the div does sound like a bug though.,SOCIAL CONVERSATION,, +6392,"VisualEditor:
not always preventing editing in VE","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div. + +The editing templates within the div does sound like a bug though. + +If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.",1378320819,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div. + +The editing templates within the div does sound like a bug though. + +If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.","According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div. + +The editing templates within the div does sound like a bug though. + +If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['According to the documentation, the div is only meant to block editing to a section of a page (although that section can be the whole text), so adding text before is correct, likewise you should be able to add text after the /div.', 'The editing templates within the div does sound like a bug though.', ""If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.""]",NA,1,If VE (or Parsoid possibly) is not treating the div as invariant then the div definitely isn't doing what it was intended to do.,INVESTIGATION AND EXPLORATION,, +6393,"VisualEditor:
not always preventing editing in VE","**kwwilliams** wrote: + +Firefox 23.0.1 on Windows 7. + +To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.",1378319066,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: + +Firefox 23.0.1 on Windows 7. + +To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.","**kwwilliams** wrote: + +Firefox 23.0.1 on Windows 7. + +To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['**kwwilliams** wrote:\n\nFirefox 23.0.1 on Windows 7.', 'To be clear, we are still prevented from editing the text.', 'We are not prevented from editing templates, and we can insert text before div.']",NA,1,**kwwilliams** wrote:\n\nFirefox 23.0.1 on Windows 7.,TESTING,, +6393,"VisualEditor:
not always preventing editing in VE","**kwwilliams** wrote: + +Firefox 23.0.1 on Windows 7. + +To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.",1378319066,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: + +Firefox 23.0.1 on Windows 7. + +To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.","**kwwilliams** wrote: + +Firefox 23.0.1 on Windows 7. + +To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['**kwwilliams** wrote:\n\nFirefox 23.0.1 on Windows 7.', 'To be clear, we are still prevented from editing the text.', 'We are not prevented from editing templates, and we can insert text before div.']",NA,1,"To be clear, we are still prevented from editing the text.",OBSERVED BUG BEHAVIOR,, +6393,"VisualEditor:
not always preventing editing in VE","**kwwilliams** wrote: + +Firefox 23.0.1 on Windows 7. + +To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.",1378319066,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"**kwwilliams** wrote: + +Firefox 23.0.1 on Windows 7. + +To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.","**kwwilliams** wrote: + +Firefox 23.0.1 on Windows 7. + +To be clear, we are still prevented from editing the text. We are not prevented from editing templates, and we can insert text before div.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['**kwwilliams** wrote:\n\nFirefox 23.0.1 on Windows 7.', 'To be clear, we are still prevented from editing the text.', 'We are not prevented from editing templates, and we can insert text before div.']",NA,1,"We are not prevented from editing templates, and we can insert text before div.",OBSERVED BUG BEHAVIOR,, +6394,"VisualEditor:
not always preventing editing in VE","The original person to report this noted that they were using Chrome 29 on Windows 7. + +I have been unable to reproduce this in Firefox 23 on Linux. + +Neither kww or the ip who can reproduce this have noted their system.",1378318792,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"The original person to report this noted that they were using Chrome 29 on Windows 7. + +I have been unable to reproduce this in Firefox 23 on Linux. + +Neither kww or the ip who can reproduce this have noted their system.","The original person to report this noted that they were using Chrome 29 on Windows 7. + +I have been unable to reproduce this in Firefox 23 on Linux. + +Neither kww or the ip who can reproduce this have noted their system.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['The original person to report this noted that they were using Chrome 29 on Windows 7.', 'I have been unable to reproduce this in Firefox 23 on Linux.', 'Neither kww or the ip who can reproduce this have noted their system.']",NA,1,The original person to report this noted that they were using Chrome 29 on Windows 7.,BUG REPRODUCTION,, +6394,"VisualEditor:
not always preventing editing in VE","The original person to report this noted that they were using Chrome 29 on Windows 7. + +I have been unable to reproduce this in Firefox 23 on Linux. + +Neither kww or the ip who can reproduce this have noted their system.",1378318792,PHID-USER-ysftv67jxeaxdwcakvwo,PHID-TASK-s47345xgplfmgixnp726,task_subcomment,"The original person to report this noted that they were using Chrome 29 on Windows 7. + +I have been unable to reproduce this in Firefox 23 on Linux. + +Neither kww or the ip who can reproduce this have noted their system.","The original person to report this noted that they were using Chrome 29 on Windows 7. + +I have been unable to reproduce this in Firefox 23 on Linux. + +Neither kww or the ip who can reproduce this have noted their system.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['The original person to report this noted that they were using Chrome 29 on Windows 7.', 'I have been unable to reproduce this in Firefox 23 on Linux.', 'Neither kww or the ip who can reproduce this have noted their system.']",NA,1,I have been unable to reproduce this in Firefox 23 on Linux.,BUG REPRODUCTION,, +7036,VisualEditor: Backspace should not delete list and line in same action,"**Author:** `mcdevitd` + +**Description:** +Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",1375729680,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_description,"VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** `mcdevitd` + +**Description:** +Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.","VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** CODE + +**Description:** +Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",Medium,50,NA,NA,open,TRUE,c1,3,FALSE,FALSE,5,NA,"['VisualEditor: Backspace should not delete list and line in same action.', '**Author:** CODE\n\n**Description:**\nTypically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more.', 'VisualEditor will completely delete the line itself and move the text to the end of the previous line.', 'This is not how OpenOffice or Word works.']",FALSE,1,VisualEditor: Backspace should not delete list and line in same action.,EXPECTED BEHAVIOR,, +7036,VisualEditor: Backspace should not delete list and line in same action,"**Author:** `mcdevitd` + +**Description:** +Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",1375729680,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_description,"VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** `mcdevitd` + +**Description:** +Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.","VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** CODE + +**Description:** +Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",Medium,50,NA,NA,open,TRUE,c1,3,FALSE,FALSE,5,NA,"['VisualEditor: Backspace should not delete list and line in same action.', '**Author:** CODE\n\n**Description:**\nTypically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more.', 'VisualEditor will completely delete the line itself and move the text to the end of the previous line.', 'This is not how OpenOffice or Word works.']",FALSE,1,"**Author:** CODE\n\n**Description:**\nTypically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more.",EXPECTED BEHAVIOR,, +7036,VisualEditor: Backspace should not delete list and line in same action,"**Author:** `mcdevitd` + +**Description:** +Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",1375729680,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_description,"VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** `mcdevitd` + +**Description:** +Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.","VisualEditor: Backspace should not delete list and line in same action./n/n**Author:** CODE + +**Description:** +Typically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more. VisualEditor will completely delete the line itself and move the text to the end of the previous line. This is not how OpenOffice or Word works.",Medium,50,NA,NA,open,TRUE,c1,3,FALSE,FALSE,5,NA,"['VisualEditor: Backspace should not delete list and line in same action.', '**Author:** CODE\n\n**Description:**\nTypically, the expected behavior from hitting backspace at the beginning of a list line is to remove the bullet/number at that indent level so it is no longer a list, and no more.', 'VisualEditor will completely delete the line itself and move the text to the end of the previous line.', 'This is not how OpenOffice or Word works.']",FALSE,1,VisualEditor will completely delete the line itself and move the text to the end of the previous line.,OBSERVED BUG BEHAVIOR,, +7038,VisualEditor: Backspace should not delete list and line in same action,"Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty. Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden �����no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",1650765546,PHID-USER-unpoeiyj52rmcfqi5rbw,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_subcomment,"Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty. Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden �����no equivalence in VE; second Backspace press: the paragraph is merged with previous element).","Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty. Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden �����no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,459,NA,"['Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty.', 'Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden ���\xa0no equivalence in VE; second Backspace press: the paragraph is merged with previous element).']",NA,1,"Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty.",EXPECTED BEHAVIOR,, +7038,VisualEditor: Backspace should not delete list and line in same action,"Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty. Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden �����no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",1650765546,PHID-USER-unpoeiyj52rmcfqi5rbw,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_subcomment,"Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty. Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden �����no equivalence in VE; second Backspace press: the paragraph is merged with previous element).","Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty. Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden �����no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,459,NA,"['Currently (for years), backspace LibreOffice make the paragraph exit the list only if it is empty.', 'Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden ���\xa0no equivalence in VE; second Backspace press: the paragraph is merged with previous element).']",NA,1,"Else, the behavior is pretty consistent with VisualEditor (first Backspace press: the bullet is hidden ���\xa0no equivalence in VE; second Backspace press: the paragraph is merged with previous element).",EXPECTED BEHAVIOR,, +7039,VisualEditor: Backspace should not delete list and line in same action,"Agreed. For + +|

  1. |

  2. Foo

+ +�����backspace at the cursor position indicated should convert the document into: + +|

|

  1. Foo

+ +��� with the initial

being a slug. + +For nested list items we should pop to the next level: + +|

  1. Foo

    1. |

    2. Foo

+ +-> + + +|

  1. Foo

  2. |

    1. Foo

+ +I think?",1394479004,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_subcomment,"Agreed. For + +|

  1. |

  2. Foo

+ +�����backspace at the cursor position indicated should convert the document into: + +|

|

  1. Foo

+ +��� with the initial

being a slug. + +For nested list items we should pop to the next level: + +|

  1. Foo

    1. |

    2. Foo

+ +-> + + +|

  1. Foo

  2. |

    1. Foo

+ +I think?","Agreed. For + +|

  1. |

  2. Foo

+ +�����backspace at the cursor position indicated should convert the document into: + +|

|

  1. Foo

+ +��� with the initial

being a slug. + +For nested list items we should pop to the next level: + +|

  1. Foo

    1. |

    2. Foo

+ +-> + + +|

  1. Foo

  2. |

    1. Foo

+ +I think?",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,36,NA,"['Agreed.', 'For\n\n|

  1. |

  2. Foo

\n\n���\xa0backspace at the cursor position indicated should convert the document into:\n\n|

|

  1. Foo

\n\n��� with the initial

being a slug.', 'For nested list items we should pop to the next level:\n\n|

  1. Foo

    1. |

    2. Foo

\n\n->\n\n\n|

  1. Foo

  2. |

    1. Foo

\n\nI think?']",NA,1,Agreed.,SOCIAL CONVERSATION,, +7039,VisualEditor: Backspace should not delete list and line in same action,"Agreed. For + +|

  1. |

  2. Foo

+ +�����backspace at the cursor position indicated should convert the document into: + +|

|

  1. Foo

+ +��� with the initial

being a slug. + +For nested list items we should pop to the next level: + +|

  1. Foo

    1. |

    2. Foo

+ +-> + + +|

  1. Foo

  2. |

    1. Foo

+ +I think?",1394479004,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_subcomment,"Agreed. For + +|

  1. |

  2. Foo

+ +�����backspace at the cursor position indicated should convert the document into: + +|

|

  1. Foo

+ +��� with the initial

being a slug. + +For nested list items we should pop to the next level: + +|

  1. Foo

    1. |

    2. Foo

+ +-> + + +|

  1. Foo

  2. |

    1. Foo

+ +I think?","Agreed. For + +|

  1. |

  2. Foo

+ +�����backspace at the cursor position indicated should convert the document into: + +|

|

  1. Foo

+ +��� with the initial

being a slug. + +For nested list items we should pop to the next level: + +|

  1. Foo

    1. |

    2. Foo

+ +-> + + +|

  1. Foo

  2. |

    1. Foo

+ +I think?",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,36,NA,"['Agreed.', 'For\n\n|

  1. |

  2. Foo

\n\n���\xa0backspace at the cursor position indicated should convert the document into:\n\n|

|

  1. Foo

\n\n��� with the initial

being a slug.', 'For nested list items we should pop to the next level:\n\n|

  1. Foo

    1. |

    2. Foo

\n\n->\n\n\n|

  1. Foo

  2. |

    1. Foo

\n\nI think?']",NA,1,For\n\n|

  1. |

  2. Foo

\n\n���\xa0backspace at the cursor position indicated should convert the document into:\n\n|

|

  1. Foo

\n\n��� with the initial

being a slug.,EXPECTED BEHAVIOR,, +7039,VisualEditor: Backspace should not delete list and line in same action,"Agreed. For + +|

  1. |

  2. Foo

+ +�����backspace at the cursor position indicated should convert the document into: + +|

|

  1. Foo

+ +��� with the initial

being a slug. + +For nested list items we should pop to the next level: + +|

  1. Foo

    1. |

    2. Foo

+ +-> + + +|

  1. Foo

  2. |

    1. Foo

+ +I think?",1394479004,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-vrzpbb2v2s74ml5e53ww,task_subcomment,"Agreed. For + +|

  1. |

  2. Foo

+ +�����backspace at the cursor position indicated should convert the document into: + +|

|

  1. Foo

+ +��� with the initial

being a slug. + +For nested list items we should pop to the next level: + +|

  1. Foo

    1. |

    2. Foo

+ +-> + + +|

  1. Foo

  2. |

    1. Foo

+ +I think?","Agreed. For + +|

  1. |

  2. Foo

+ +�����backspace at the cursor position indicated should convert the document into: + +|

|

  1. Foo

+ +��� with the initial

being a slug. + +For nested list items we should pop to the next level: + +|

  1. Foo

    1. |

    2. Foo

+ +-> + + +|

  1. Foo

  2. |

    1. Foo

+ +I think?",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,36,NA,"['Agreed.', 'For\n\n|

  1. |

  2. Foo

\n\n���\xa0backspace at the cursor position indicated should convert the document into:\n\n|

|

  1. Foo

\n\n��� with the initial

being a slug.', 'For nested list items we should pop to the next level:\n\n|

  1. Foo

    1. |

    2. Foo

\n\n->\n\n\n|

  1. Foo

  2. |

    1. Foo

\n\nI think?']",NA,1,For nested list items we should pop to the next level:\n\n|

  1. Foo

    1. |

    2. Foo

\n\n->\n\n\n|

  1. Foo

  2. |

    1. Foo

\n\nI think?,EXPECTED BEHAVIOR,, +7045,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Users are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki. + +-------------------------- +**Version**: wmf-deployment +**Severity**: normal +**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA",1375721160,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_description,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary./n/nUsers are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki. + +-------------------------- +**Version**: wmf-deployment +**Severity**: normal +**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA","Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary./n/nUsers are requesting VE August update (URL to be deployed in on hewiki. + +-------------------------- +**Version**: wmf-deployment +**Severity**: normal +**URL**: URL",Medium,50,1381515689,NA,resolved,TRUE,c1,3,FALSE,FALSE,5,NA,"['Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary.', 'Users are requesting VE August update (URL to be deployed in on hewiki.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal\n**URL**: URL']",FALSE,1,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary.",EXPECTED BEHAVIOR,, +7045,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Users are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki. + +-------------------------- +**Version**: wmf-deployment +**Severity**: normal +**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA",1375721160,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_description,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary./n/nUsers are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki. + +-------------------------- +**Version**: wmf-deployment +**Severity**: normal +**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA","Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary./n/nUsers are requesting VE August update (URL to be deployed in on hewiki. + +-------------------------- +**Version**: wmf-deployment +**Severity**: normal +**URL**: URL",Medium,50,1381515689,NA,resolved,TRUE,c1,3,FALSE,FALSE,5,NA,"['Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary.', 'Users are requesting VE August update (URL to be deployed in on hewiki.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal\n**URL**: URL']",FALSE,1,Users are requesting VE August update (URL to be deployed in on hewiki.,MOTIVATION,, +7045,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Users are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki. + +-------------------------- +**Version**: wmf-deployment +**Severity**: normal +**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA",1375721160,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_description,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary./n/nUsers are requesting VE August update (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to be deployed in on hewiki. + +-------------------------- +**Version**: wmf-deployment +**Severity**: normal +**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F#.D7.A9.D7.99.D7.A0.D7.95.D7.99_.D7.91.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA","Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary./n/nUsers are requesting VE August update (URL to be deployed in on hewiki. + +-------------------------- +**Version**: wmf-deployment +**Severity**: normal +**URL**: URL",Medium,50,1381515689,NA,resolved,TRUE,c1,3,FALSE,FALSE,5,NA,"['Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary.', 'Users are requesting VE August update (URL to be deployed in on hewiki.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal\n**URL**: URL']",FALSE,1,--------------------------\n**Version**: wmf-deployment\n**Severity**: normal\n**URL**: URL,OBSERVED BUG BEHAVIOR,, +7046,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary",Finally done; sorry for the delay.,1381515689,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,Finally done; sorry for the delay.,Finally done; sorry for the delay.,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,14,NA,['Finally done; sorry for the delay.'],NA,1,Finally done; sorry for the delay.,SOCIAL CONVERSATION,, +7047,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Change 87645 merged by Reedy: +Switch VisualEditor to secondary status on hewiki + +https://gerrit.wikimedia.org/r/87645",1381515513,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Change 87645 merged by Reedy: +Switch VisualEditor to secondary status on hewiki + +https://gerrit.wikimedia.org/r/87645","Change 87645 merged by Reedy: +Switch VisualEditor to secondary status on hewiki + +GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,14,NA,['Change 87645 merged by Reedy:\nSwitch VisualEditor to secondary status on hewiki\n\nGERRIT_URL'],NA,1,Change 87645 merged by Reedy:\nSwitch VisualEditor to secondary status on hewiki\n\nGERRIT_URL,TASK PROGRESS,, +7048,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #14) +> Change 87645 had a related patch set uploaded by Jforrester: +> Switch VisualEditor to secondary status on hewiki +> +> https://gerrit.wikimedia.org/r/87645 + +Will try to schedule this soon.",1380938287,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #14) +> Change 87645 had a related patch set uploaded by Jforrester: +> Switch VisualEditor to secondary status on hewiki +> +> https://gerrit.wikimedia.org/r/87645 + +Will try to schedule this soon.","(In reply to comment #14) +QUOTE +QUOTE +QUOTE +QUOTE + +Will try to schedule this soon.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,['(In reply to comment #14)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWill try to schedule this soon.'],NA,1,(In reply to comment #14)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWill try to schedule this soon.,FUTURE PLANS,, +7049,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Change 87645 had a related patch set uploaded by Jforrester: +Switch VisualEditor to secondary status on hewiki + +https://gerrit.wikimedia.org/r/87645",1380938237,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Change 87645 had a related patch set uploaded by Jforrester: +Switch VisualEditor to secondary status on hewiki + +https://gerrit.wikimedia.org/r/87645","Change 87645 had a related patch set uploaded by Jforrester: +Switch VisualEditor to secondary status on hewiki + +GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,13,NA,['Change 87645 had a related patch set uploaded by Jforrester:\nSwitch VisualEditor to secondary status on hewiki\n\nGERRIT_URL'],NA,1,Change 87645 had a related patch set uploaded by Jforrester:\nSwitch VisualEditor to secondary status on hewiki\n\nGERRIT_URL,TASK PROGRESS,, +7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +QUOTE +QUOTE +QUOTE + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +QUOTE +QUOTE + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.",SOCIAL CONVERSATION,, +7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +QUOTE +QUOTE +QUOTE + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +QUOTE +QUOTE + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,I think that it\,SOCIAL CONVERSATION,, +7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +QUOTE +QUOTE +QUOTE + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +QUOTE +QUOTE + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"t come to ""a decision"".",SOCIAL CONVERSATION,, +7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +QUOTE +QUOTE +QUOTE + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +QUOTE +QUOTE + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,:-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.,SOCIAL CONVERSATION,, +7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +QUOTE +QUOTE +QUOTE + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +QUOTE +QUOTE + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?",INVESTIGATION AND EXPLORATION,, +7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +QUOTE +QUOTE +QUOTE + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +QUOTE +QUOTE + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).",INVESTIGATION AND EXPLORATION,, +7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +QUOTE +QUOTE +QUOTE + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +QUOTE +QUOTE + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,But I see your point.,SOCIAL CONVERSATION,, +7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +QUOTE +QUOTE +QUOTE + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +QUOTE +QUOTE + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,Not sure.,SOCIAL CONVERSATION,, +7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +QUOTE +QUOTE +QUOTE + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +QUOTE +QUOTE + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis.",SOLUTION DISCUSSION,, +7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +QUOTE +QUOTE +QUOTE + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +QUOTE +QUOTE + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this.",SOCIAL CONVERSATION,, +7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +QUOTE +QUOTE +QUOTE + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +QUOTE +QUOTE + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing.",INVESTIGATION AND EXPLORATION,, +7050,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",1380937661,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #12) +> Thanks for adding the welcome message. +> +> I know there are discussions regarding these changes[1], but the change of +> the tab order (Edit and Edit source) is important for he wikipedia and Erik +> isn't totally against it [only ambivalent] :) +> +> [1] +> http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/ +> 000419.html + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +> Since VE is enabled only in the main NS and user NS, for editors who also +> edit in other namespaces, addition of the VE edit tab ""in the middle"" may +> cause confusion. + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +> For consistency the edit source option should be alway the first +> option [in order], while VE edit should be second. + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.","(In reply to comment #12) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +To speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki. + +There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis. I think that it's probably OK to do this, but I really haven't come to ""a decision"". However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this. :-( + +QUOTE +QUOTE +QUOTE + +That is certainly one argument. (Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin? For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out). But I see your point. + +QUOTE +QUOTE + +An alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing. + +Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow). Not sure. + +In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,13,NA,"['(In reply to comment #12)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nTo speak for Erik (:-)), his ambivalence is about changing it *globally*, not about changing it on a given wiki.', ""There's scope for a lot of concern about changing it for some wikis and not others, and so having a very inconsistent configuration for people that use multiple wikis."", 'I think that it\'s probably OK to do this, but I really haven\'t come to ""a decision"".', ""However, it's unfair to hewiki to have you hanging around waiting for me to make up my mind, and I'm sorry about this."", ':-(\n\nQUOTE\nQUOTE\nQUOTE\n\nThat is certainly one argument.', '(Though surely it only applies to people with a very narrow window, or the minority who use the Monobook skin?', 'For the others, the VisualEditor tab sits prone in namespaces they can use it in, and otherwise they get the tab they currently have to use until Flow is fully rolled out).', 'But I see your point.', ""QUOTE\nQUOTE\n\nAn alternative argument is that it's right that the first and primary tab is always the one they can use, and there may or may not be a secondary editor tab depending on the nature of the content they're editing."", ""Of course, we can partially 'fix' this by enabling VisualEditor in all the other namespaces that it's safe for (at the least, File, Portal, Category, Help; not Project, as that's normally signed and so should wait with *_Talk for Flow)."", 'Not sure.', ""In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.""]",NA,1,"In the mean time, I'm happy to move hewiki to [ Edit source | Edit ] for the time being, and would really welcome thoughts on my other points above.",WORKAROUNDS,, +7051,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Thanks for adding the welcome message. + +I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :) + +Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second. + +---- +[1] http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000419.html",1380883041,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Thanks for adding the welcome message. + +I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :) + +Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second. + +---- +[1] http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000419.html","Thanks for adding the welcome message. + +I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :) + +Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second. + +---- +[1] URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,13,NA,"['Thanks for adding the welcome message.', 'I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn\'t totally against it [only ambivalent] :)\n\nSince VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion.', 'For consistency the edit source option should be alway the first option [in order], while VE edit should be second.', '----\n[1] URL']",NA,1,Thanks for adding the welcome message.,SOCIAL CONVERSATION,, +7051,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Thanks for adding the welcome message. + +I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :) + +Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second. + +---- +[1] http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000419.html",1380883041,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Thanks for adding the welcome message. + +I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :) + +Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second. + +---- +[1] http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000419.html","Thanks for adding the welcome message. + +I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :) + +Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second. + +---- +[1] URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,13,NA,"['Thanks for adding the welcome message.', 'I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn\'t totally against it [only ambivalent] :)\n\nSince VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion.', 'For consistency the edit source option should be alway the first option [in order], while VE edit should be second.', '----\n[1] URL']",NA,1,"I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn\",SOLUTION USAGE,, +7051,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Thanks for adding the welcome message. + +I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :) + +Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second. + +---- +[1] http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000419.html",1380883041,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Thanks for adding the welcome message. + +I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :) + +Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second. + +---- +[1] http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000419.html","Thanks for adding the welcome message. + +I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn't totally against it [only ambivalent] :) + +Since VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion. For consistency the edit source option should be alway the first option [in order], while VE edit should be second. + +---- +[1] URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,13,NA,"['Thanks for adding the welcome message.', 'I know there are discussions regarding these changes[1], but the change of the tab order (Edit and Edit source) is important for he wikipedia and Erik isn\'t totally against it [only ambivalent] :)\n\nSince VE is enabled only in the main NS and user NS, for editors who also edit in other namespaces, addition of the VE edit tab ""in the middle"" may cause confusion.', 'For consistency the edit source option should be alway the first option [in order], while VE edit should be second.', '----\n[1] URL']",NA,1,in the middle,NA,, +7052,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Change 77269 merged by jenkins-bot: +Enable VisualEditor beta welcome notice for all wikis + +https://gerrit.wikimedia.org/r/77269",1378927706,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Change 77269 merged by jenkins-bot: +Enable VisualEditor beta welcome notice for all wikis + +https://gerrit.wikimedia.org/r/77269","Change 77269 merged by jenkins-bot: +Enable VisualEditor beta welcome notice for all wikis + +GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,10,NA,['Change 77269 merged by jenkins-bot:\nEnable VisualEditor beta welcome notice for all wikis\n\nGERRIT_URL'],NA,1,Change 77269 merged by jenkins-bot:\nEnable VisualEditor beta welcome notice for all wikis\n\nGERRIT_URL,TASK PROGRESS,, +7053,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","[Sorry for the delay in responding.] + +The beta welcome message is now queued up to go out on all wikis with the next release when available. + +We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",1378770465,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"[Sorry for the delay in responding.] + +The beta welcome message is now queued up to go out on all wikis with the next release when available. + +We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.","[Sorry for the delay in responding.] + +The beta welcome message is now queued up to go out on all wikis with the next release when available. + +We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,10,NA,"['[Sorry for the delay in responding.]', 'The beta welcome message is now queued up to go out on all wikis with the next release when available.', ""We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer."", 'Sorry.']",NA,1,[Sorry for the delay in responding.],SOCIAL CONVERSATION,, +7053,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","[Sorry for the delay in responding.] + +The beta welcome message is now queued up to go out on all wikis with the next release when available. + +We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",1378770465,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"[Sorry for the delay in responding.] + +The beta welcome message is now queued up to go out on all wikis with the next release when available. + +We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.","[Sorry for the delay in responding.] + +The beta welcome message is now queued up to go out on all wikis with the next release when available. + +We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,10,NA,"['[Sorry for the delay in responding.]', 'The beta welcome message is now queued up to go out on all wikis with the next release when available.', ""We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer."", 'Sorry.']",NA,1,The beta welcome message is now queued up to go out on all wikis with the next release when available.,SOLUTION DISCUSSION,, +7053,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","[Sorry for the delay in responding.] + +The beta welcome message is now queued up to go out on all wikis with the next release when available. + +We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",1378770465,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"[Sorry for the delay in responding.] + +The beta welcome message is now queued up to go out on all wikis with the next release when available. + +We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.","[Sorry for the delay in responding.] + +The beta welcome message is now queued up to go out on all wikis with the next release when available. + +We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,10,NA,"['[Sorry for the delay in responding.]', 'The beta welcome message is now queued up to go out on all wikis with the next release when available.', ""We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer."", 'Sorry.']",NA,1,Sorry.,SOCIAL CONVERSATION,, +7053,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","[Sorry for the delay in responding.] + +The beta welcome message is now queued up to go out on all wikis with the next release when available. + +We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",1378770465,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"[Sorry for the delay in responding.] + +The beta welcome message is now queued up to go out on all wikis with the next release when available. + +We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.","[Sorry for the delay in responding.] + +The beta welcome message is now queued up to go out on all wikis with the next release when available. + +We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer. Sorry.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,10,NA,"['[Sorry for the delay in responding.]', 'The beta welcome message is now queued up to go out on all wikis with the next release when available.', ""We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer."", 'Sorry.']",NA,1,"We're still not decided on the way forward for the edit source/edit labelling split, so this is delayed until we have a proper answer.",TASK PROGRESS,, +7054,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","We are now in September so enough time have passed since August change, and the community have voted for deploying the changes. Please let us know when this change is planned for deployment.",1378147154,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"We are now in September so enough time have passed since August change, and the community have voted for deploying the changes. Please let us know when this change is planned for deployment.","We are now in September so enough time have passed since August change, and the community have voted for deploying the changes. Please let us know when this change is planned for deployment.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['We are now in September so enough time have passed since August change, and the community have voted for deploying the changes.', 'Please let us know when this change is planned for deployment.']",NA,1,"We are now in September so enough time have passed since August change, and the community have voted for deploying the changes.",SOLUTION DISCUSSION,, +7054,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","We are now in September so enough time have passed since August change, and the community have voted for deploying the changes. Please let us know when this change is planned for deployment.",1378147154,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"We are now in September so enough time have passed since August change, and the community have voted for deploying the changes. Please let us know when this change is planned for deployment.","We are now in September so enough time have passed since August change, and the community have voted for deploying the changes. Please let us know when this change is planned for deployment.",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,9,NA,"['We are now in September so enough time have passed since August change, and the community have voted for deploying the changes.', 'Please let us know when this change is planned for deployment.']",NA,1,Please let us know when this change is planned for deployment.,TASK PROGRESS,, +7055,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","There is is large support for the change in the village pump. + +https://he.wikipedia.org/w/index.php?title=%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9E%D7%96%D7%A0%D7%95%D7%9F&oldid=14551521#.D7.94.D7.97.D7.9C.D7.A4.D7.AA_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_.D7.A2.D7.9D_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA",1377842346,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"There is is large support for the change in the village pump. + +https://he.wikipedia.org/w/index.php?title=%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9E%D7%96%D7%A0%D7%95%D7%9F&oldid=14551521#.D7.94.D7.97.D7.9C.D7.A4.D7.AA_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_.D7.A2.D7.9D_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA","There is is large support for the change in the village pump. + +URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,8,NA,"['There is is large support for the change in the village pump.', 'URL']",NA,1,There is is large support for the change in the village pump.,MOTIVATION,, +7055,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","There is is large support for the change in the village pump. + +https://he.wikipedia.org/w/index.php?title=%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9E%D7%96%D7%A0%D7%95%D7%9F&oldid=14551521#.D7.94.D7.97.D7.9C.D7.A4.D7.AA_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_.D7.A2.D7.9D_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA",1377842346,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"There is is large support for the change in the village pump. + +https://he.wikipedia.org/w/index.php?title=%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9E%D7%96%D7%A0%D7%95%D7%9F&oldid=14551521#.D7.94.D7.97.D7.9C.D7.A4.D7.AA_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.94.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94_.D7.91.D7.A7.D7.95.D7.93_.D7.9E.D7.A7.D7.95.D7.A8.22_.D7.A2.D7.9D_.D7.9E.D7.99.D7.A7.D7.95.D7.9D_.D7.A7.D7.99.D7.A9.D7.95.D7.A8_.22.D7.A2.D7.A8.D7.99.D7.9B.D7.94.22_-_.D7.9B.D7.9E.D7.95_.D7.91.D7.95.D7.95.D7.99.D7.A7.D7.99.D7.A4.D7.93.D7.99.D7.94_.D7.94.D7.90.D7.A0.D7.92.D7.9C.D7.99.D7.AA","There is is large support for the change in the village pump. + +URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,8,NA,"['There is is large support for the change in the village pump.', 'URL']",NA,1,URL,NA,, +7056,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary",All of these,1377020909,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,All of these,All of these,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,7,NA,['All of these'],NA,1,All of these,SOCIAL CONVERSATION,, +7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"Hey,\n\nWhich of the bits of the update do you mean?",SOCIAL CONVERSATION,, +7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,1,NA,, +7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,2,NA,, +7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,Giving a welcome message when you open VisualEditor for the first time?,SOLUTION DISCUSSION,, +7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,3,NA,, +7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?",SOLUTION DISCUSSION,, +7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,4,NA,, +7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,"Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?",SOLUTION DISCUSSION,x, +7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,5,NA,, +7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,Removing the animation on section edit links?,SOLUTION DISCUSSION,, +7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,All of these?,SOCIAL CONVERSATION,, +7057,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",1376948752,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.","Hey, + +Which of the bits of the update do you mean? + +1. The re-ordered tabs and section edit links, so that the VE tab is second? +2. Giving a welcome message when you open VisualEditor for the first time? +3. Adding ""beta"" as a suffix after the VisualEditor tab and section edit link? +4. Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency? +5. Removing the animation on section edit links? + +All of these? Items 4 and 5 are already done.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,7,NA,"['Hey,\n\nWhich of the bits of the update do you mean?', '1.', 'The re-ordered tabs and section edit links, so that the VE tab is second?', '2.', 'Giving a welcome message when you open VisualEditor for the first time?', '3.', 'Adding ""beta"" as a suffix after the VisualEditor tab and section edit link?', '4.', 'Changing ""edit"" to ""edit source"" on non-VisualEditor pages for consistency?', '5.', 'Removing the animation on section edit links?', 'All of these?', 'Items 4 and 5 are already done.']",NA,1,Items 4 and 5 are already done.,TASK PROGRESS,, +7058,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary",is there any progress with the request?,1376848108,PHID-USER-cfsvvgbtlqnbt2yokfjf,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,is there any progress with the request?,is there any progress with the request?,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,6,NA,['is there any progress with the request?'],NA,1,is there any progress with the request?,TASK PROGRESS,, +7059,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary",Gerrit change 77269 will handle part of this. They were just waiting on translations of the messages before enabling it.,1375862146,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,Gerrit change 77269 will handle part of this. They were just waiting on translations of the messages before enabling it.,Gerrit change 77269 will handle part of this. They were just waiting on translations of the messages before enabling it.,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,5,NA,"['Gerrit change 77269 will handle part of this.', 'They were just waiting on translations of the messages before enabling it.']",NA,1,Gerrit change 77269 will handle part of this.,TASK PROGRESS,, +7059,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary",Gerrit change 77269 will handle part of this. They were just waiting on translations of the messages before enabling it.,1375862146,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,Gerrit change 77269 will handle part of this. They were just waiting on translations of the messages before enabling it.,Gerrit change 77269 will handle part of this. They were just waiting on translations of the messages before enabling it.,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,5,NA,"['Gerrit change 77269 will handle part of this.', 'They were just waiting on translations of the messages before enabling it.']",NA,1,They were just waiting on translations of the messages before enabling it.,SOCIAL CONVERSATION,, +7060,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary",added in the url field.,1375792847,PHID-USER-u7udgblfyop6qd5wxot6,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,added in the url field.,added in the url field.,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,5,NA,['added in the url field.'],NA,1,added in the url field.,SOCIAL CONVERSATION,, +7061,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary","(In reply to comment #0) +> Users are requesting VE August update +> (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to +> be deployed in on hewiki. + +Please provide a link to these requests, if possible.",1375791382,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,"(In reply to comment #0) +> Users are requesting VE August update +> (https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update) to +> be deployed in on hewiki. + +Please provide a link to these requests, if possible.","(In reply to comment #0) +QUOTE +QUOTE +QUOTE + +Please provide a link to these requests, if possible.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,5,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nPlease provide a link to these requests, if possible.']",NA,1,"(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nPlease provide a link to these requests, if possible.",ISSUE CONTENT MANAGEMENT,, +7062,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary",Please mark the targeted milestone when it is known. Thanks,1375721827,PHID-USER-u7udgblfyop6qd5wxot6,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,Please mark the targeted milestone when it is known. Thanks,Please mark the targeted milestone when it is known. Thanks,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,5,NA,"['Please mark the targeted milestone when it is known.', 'Thanks']",NA,1,Please mark the targeted milestone when it is known.,ISSUE CONTENT MANAGEMENT,, +7062,"Change the order of the ""edit"" (VE) and ""edit source"" (WT) tabs on hewiki to have WT as primary",Please mark the targeted milestone when it is known. Thanks,1375721827,PHID-USER-u7udgblfyop6qd5wxot6,PHID-TASK-wvcrw2fz7zto4p5xyqav,task_subcomment,Please mark the targeted milestone when it is known. Thanks,Please mark the targeted milestone when it is known. Thanks,NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,5,NA,"['Please mark the targeted milestone when it is known.', 'Thanks']",NA,1,Thanks,SOCIAL CONVERSATION,, +9571,mw.hook listeners for GuidedTour for shouldSkip,"Investigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. + +If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). + +-------------------------- +**Version**: master +**Severity**: enhancement",1368612900,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-xj7stom4ugsmlhxmz6az,task_description,"mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. + +If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). + +-------------------------- +**Version**: master +**Severity**: enhancement","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. + +If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). + +-------------------------- +**Version**: master +**Severity**: enhancement",Medium,50,1402344878,NA,resolved,TRUE,c1,1,TRUE,FALSE,-7,NA,"['mw.hook listeners for GuidedTour for shouldSkip.', 'Investigate how mw.hook could be useful for GuidedTour.', 'One idea is subscribing to state changes for shouldSkip.', 'For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.', 'If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",FALSE,1,mw.hook listeners for GuidedTour for shouldSkip.,EXPECTED BEHAVIOR,, +9571,mw.hook listeners for GuidedTour for shouldSkip,"Investigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. + +If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). + +-------------------------- +**Version**: master +**Severity**: enhancement",1368612900,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-xj7stom4ugsmlhxmz6az,task_description,"mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. + +If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). + +-------------------------- +**Version**: master +**Severity**: enhancement","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. + +If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). + +-------------------------- +**Version**: master +**Severity**: enhancement",Medium,50,1402344878,NA,resolved,TRUE,c1,1,TRUE,FALSE,-7,NA,"['mw.hook listeners for GuidedTour for shouldSkip.', 'Investigate how mw.hook could be useful for GuidedTour.', 'One idea is subscribing to state changes for shouldSkip.', 'For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.', 'If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",FALSE,1,Investigate how mw.hook could be useful for GuidedTour.,INVESTIGATION AND EXPLORATION,, +9571,mw.hook listeners for GuidedTour for shouldSkip,"Investigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. + +If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). + +-------------------------- +**Version**: master +**Severity**: enhancement",1368612900,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-xj7stom4ugsmlhxmz6az,task_description,"mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. + +If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). + +-------------------------- +**Version**: master +**Severity**: enhancement","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. + +If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). + +-------------------------- +**Version**: master +**Severity**: enhancement",Medium,50,1402344878,NA,resolved,TRUE,c1,1,TRUE,FALSE,-7,NA,"['mw.hook listeners for GuidedTour for shouldSkip.', 'Investigate how mw.hook could be useful for GuidedTour.', 'One idea is subscribing to state changes for shouldSkip.', 'For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.', 'If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",FALSE,1,One idea is subscribing to state changes for shouldSkip.,FUTURE PLANS,, +9571,mw.hook listeners for GuidedTour for shouldSkip,"Investigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. + +If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). + +-------------------------- +**Version**: master +**Severity**: enhancement",1368612900,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-xj7stom4ugsmlhxmz6az,task_description,"mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. + +If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). + +-------------------------- +**Version**: master +**Severity**: enhancement","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. + +If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). + +-------------------------- +**Version**: master +**Severity**: enhancement",Medium,50,1402344878,NA,resolved,TRUE,c1,1,TRUE,FALSE,-7,NA,"['mw.hook listeners for GuidedTour for shouldSkip.', 'Investigate how mw.hook could be useful for GuidedTour.', 'One idea is subscribing to state changes for shouldSkip.', 'For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.', 'If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",FALSE,1,"If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).",FUTURE PLANS,, +9571,mw.hook listeners for GuidedTour for shouldSkip,"Investigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. + +If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). + +-------------------------- +**Version**: master +**Severity**: enhancement",1368612900,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-xj7stom4ugsmlhxmz6az,task_description,"mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. + +If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). + +-------------------------- +**Version**: master +**Severity**: enhancement","mw.hook listeners for GuidedTour for shouldSkip./n/nInvestigate how mw.hook could be useful for GuidedTour. One idea is subscribing to state changes for shouldSkip. For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages. + +If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this). + +-------------------------- +**Version**: master +**Severity**: enhancement",Medium,50,1402344878,NA,resolved,TRUE,c1,1,TRUE,FALSE,-7,NA,"['mw.hook listeners for GuidedTour for shouldSkip.', 'Investigate how mw.hook could be useful for GuidedTour.', 'One idea is subscribing to state changes for shouldSkip.', 'For instance, UploadWizard has an AJAX-type interface where you go from step to step without changing pages.', 'If we could listen to those steps, we could trigger the shouldSkip check (by calling guiders.resume or maybe another method that only checks this).', '--------------------------\n**Version**: master\n**Severity**: enhancement']",FALSE,1,--------------------------\n**Version**: master\n**Severity**: enhancement,FUTURE PLANS,, +9572,mw.hook listeners for GuidedTour for shouldSkip,"Change 116228 merged by jenkins-bot: +Refactor and add non-linear tours, with tests + +https://gerrit.wikimedia.org/r/116228",1402332994,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-xj7stom4ugsmlhxmz6az,task_subcomment,"Change 116228 merged by jenkins-bot: +Refactor and add non-linear tours, with tests + +https://gerrit.wikimedia.org/r/116228","Change 116228 merged by jenkins-bot: +Refactor and add non-linear tours, with tests + +GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,49,NA,"['Change 116228 merged by jenkins-bot:\nRefactor and add non-linear tours, with tests\n\nGERRIT_URL']",NA,1,"Change 116228 merged by jenkins-bot:\nRefactor and add non-linear tours, with tests\n\nGERRIT_URL",TASK PROGRESS,, +9573,mw.hook listeners for GuidedTour for shouldSkip,"Change 116228 had a related patch set uploaded by Mattflaschen: +WIP: Refactor and add non-linear tours, with tests + +https://gerrit.wikimedia.org/r/116228",1397707892,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-xj7stom4ugsmlhxmz6az,task_subcomment,"Change 116228 had a related patch set uploaded by Mattflaschen: +WIP: Refactor and add non-linear tours, with tests + +https://gerrit.wikimedia.org/r/116228","Change 116228 had a related patch set uploaded by Mattflaschen: +WIP: Refactor and add non-linear tours, with tests + +GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c1,3,FALSE,NA,41,NA,"['Change 116228 had a related patch set uploaded by Mattflaschen:\nWIP: Refactor and add non-linear tours, with tests\n\nGERRIT_URL']",NA,1,"Change 116228 had a related patch set uploaded by Mattflaschen:\nWIP: Refactor and add non-linear tours, with tests\n\nGERRIT_URL",TASK PROGRESS,, +9574,mw.hook listeners for GuidedTour for shouldSkip,"This is done for VisualEditor. I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.",1374693237,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-xj7stom4ugsmlhxmz6az,task_subcomment,"This is done for VisualEditor. I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.","This is done for VisualEditor. I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,3,NA,"['This is done for VisualEditor.', 'I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.']",NA,1,This is done for VisualEditor.,TASK PROGRESS,, +9574,mw.hook listeners for GuidedTour for shouldSkip,"This is done for VisualEditor. I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.",1374693237,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-xj7stom4ugsmlhxmz6az,task_subcomment,"This is done for VisualEditor. I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.","This is done for VisualEditor. I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.",NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,3,NA,"['This is done for VisualEditor.', 'I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.']",NA,1,"I made this a tracking bug, and opened a separate one (bug 51985) for UploadWizard.",ISSUE CONTENT MANAGEMENT,, +9575,mw.hook listeners for GuidedTour for shouldSkip,I'm working on a change set right now that uses mw.hook for VE like this.,1373067339,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-xj7stom4ugsmlhxmz6az,task_subcomment,I'm working on a change set right now that uses mw.hook for VE like this.,I'm working on a change set right now that uses mw.hook for VE like this.,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,0,NA,"[""I'm working on a change set right now that uses mw.hook for VE like this.""]",NA,1,I'm working on a change set right now that uses mw.hook for VE like this.,TASK PROGRESS,, +11493,VisualEditor: Suppression of Cite error in templates still paints a phantom,"Screenshot + +Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. + +-------------------------- +**Version**: unspecified +**Severity**: minor + +**Attached**: {F11227}",1373635140,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-v6t7ev5julnky6rafmtd,task_description,"VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot + +Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. + +-------------------------- +**Version**: unspecified +**Severity**: minor + +**Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot + +Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. + +-------------------------- +**Version**: unspecified +**Severity**: minor + +**Attached**: {F11227}",Low,25,1392426157,NA,resolved,TRUE,c1,3,FALSE,FALSE,1,NA,"['VisualEditor: Suppression of Cite error in templates still paints a phantom.', 'Screenshot\n\nPreviously we had an issue that the cite extension would throw an error if you had a reference inside a template.', 'That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message.', 'See screenshot.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F11227}']",FALSE,1,VisualEditor: Suppression of Cite error in templates still paints a phantom.,OBSERVED BUG BEHAVIOR,, +11493,VisualEditor: Suppression of Cite error in templates still paints a phantom,"Screenshot + +Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. + +-------------------------- +**Version**: unspecified +**Severity**: minor + +**Attached**: {F11227}",1373635140,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-v6t7ev5julnky6rafmtd,task_description,"VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot + +Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. + +-------------------------- +**Version**: unspecified +**Severity**: minor + +**Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot + +Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. + +-------------------------- +**Version**: unspecified +**Severity**: minor + +**Attached**: {F11227}",Low,25,1392426157,NA,resolved,TRUE,c1,3,FALSE,FALSE,1,NA,"['VisualEditor: Suppression of Cite error in templates still paints a phantom.', 'Screenshot\n\nPreviously we had an issue that the cite extension would throw an error if you had a reference inside a template.', 'That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message.', 'See screenshot.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F11227}']",FALSE,1,Screenshot\n\nPreviously we had an issue that the cite extension would throw an error if you had a reference inside a template.,OBSERVED BUG BEHAVIOR,, +11493,VisualEditor: Suppression of Cite error in templates still paints a phantom,"Screenshot + +Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. + +-------------------------- +**Version**: unspecified +**Severity**: minor + +**Attached**: {F11227}",1373635140,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-v6t7ev5julnky6rafmtd,task_description,"VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot + +Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. + +-------------------------- +**Version**: unspecified +**Severity**: minor + +**Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot + +Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. + +-------------------------- +**Version**: unspecified +**Severity**: minor + +**Attached**: {F11227}",Low,25,1392426157,NA,resolved,TRUE,c1,3,FALSE,FALSE,1,NA,"['VisualEditor: Suppression of Cite error in templates still paints a phantom.', 'Screenshot\n\nPreviously we had an issue that the cite extension would throw an error if you had a reference inside a template.', 'That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message.', 'See screenshot.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F11227}']",FALSE,1,"That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message.",OBSERVED BUG BEHAVIOR,, +11493,VisualEditor: Suppression of Cite error in templates still paints a phantom,"Screenshot + +Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. + +-------------------------- +**Version**: unspecified +**Severity**: minor + +**Attached**: {F11227}",1373635140,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-v6t7ev5julnky6rafmtd,task_description,"VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot + +Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. + +-------------------------- +**Version**: unspecified +**Severity**: minor + +**Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot + +Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. + +-------------------------- +**Version**: unspecified +**Severity**: minor + +**Attached**: {F11227}",Low,25,1392426157,NA,resolved,TRUE,c1,3,FALSE,FALSE,1,NA,"['VisualEditor: Suppression of Cite error in templates still paints a phantom.', 'Screenshot\n\nPreviously we had an issue that the cite extension would throw an error if you had a reference inside a template.', 'That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message.', 'See screenshot.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F11227}']",FALSE,1,See screenshot.,INVESTIGATION AND EXPLORATION,, +11493,VisualEditor: Suppression of Cite error in templates still paints a phantom,"Screenshot + +Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. + +-------------------------- +**Version**: unspecified +**Severity**: minor + +**Attached**: {F11227}",1373635140,PHID-USER-j5ma2nageni56xp567v5,PHID-TASK-v6t7ev5julnky6rafmtd,task_description,"VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot + +Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. + +-------------------------- +**Version**: unspecified +**Severity**: minor + +**Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot + +Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot. + +-------------------------- +**Version**: unspecified +**Severity**: minor + +**Attached**: {F11227}",Low,25,1392426157,NA,resolved,TRUE,c1,3,FALSE,FALSE,1,NA,"['VisualEditor: Suppression of Cite error in templates still paints a phantom.', 'Screenshot\n\nPreviously we had an issue that the cite extension would throw an error if you had a reference inside a template.', 'That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message.', 'See screenshot.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F11227}']",FALSE,1,--------------------------\n**Version**: unspecified\n**Severity**: minor\n\n**Attached**: {F11227},OBSERVED BUG BEHAVIOR,, +11494,VisualEditor: Suppression of Cite error in templates still paints a phantom,I believe that this has been fixed for some time; I cannot replicate now.,1392426157,PHID-USER-ydswvwhh5pm4lshahjje,PHID-TASK-v6t7ev5julnky6rafmtd,task_subcomment,I believe that this has been fixed for some time; I cannot replicate now.,I believe that this has been fixed for some time; I cannot replicate now.,NA,NA,NA,NA,NA,TRUE,c1,3,TRUE,NA,32,NA,['I believe that this has been fixed for some time; I cannot replicate now.'],NA,1,I believe that this has been fixed for some time; I cannot replicate now.,BUG REPRODUCTION,, +12556,VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars,"Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. + +The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. + +And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",1359158880,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-fbrnpd67ntdl7dxrvivk,task_description,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. + +The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. + +And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. + +The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. + +And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",Low,25,NA,NA,open,TRUE,c1,1,TRUE,FALSE,-23,NA,"['VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.', 'Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.', ""The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."", ""And we're currently duplicating this internal logic at the cost of decentralisation."", 'So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.,OBSERVED BUG BEHAVIOR,, +12556,VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars,"Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. + +The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. + +And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",1359158880,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-fbrnpd67ntdl7dxrvivk,task_description,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. + +The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. + +And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. + +The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. + +And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",Low,25,NA,NA,open,TRUE,c1,1,TRUE,FALSE,-23,NA,"['VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.', 'Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.', ""The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."", ""And we're currently duplicating this internal logic at the cost of decentralisation."", 'So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,"Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.",EXPECTED BEHAVIOR,, +12556,VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars,"Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. + +The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. + +And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",1359158880,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-fbrnpd67ntdl7dxrvivk,task_description,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. + +The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. + +And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. + +The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. + +And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",Low,25,NA,NA,open,TRUE,c1,1,TRUE,FALSE,-23,NA,"['VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.', 'Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.', ""The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."", ""And we're currently duplicating this internal logic at the cost of decentralisation."", 'So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,"So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.",SOLUTION USAGE,, +12556,VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars,"Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. + +The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. + +And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",1359158880,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-fbrnpd67ntdl7dxrvivk,task_description,"VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. + +The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. + +And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement","VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars./n/nShould perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively. + +The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that. + +And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this. + +-------------------------- +**Version**: unspecified +**Severity**: enhancement",Low,25,NA,NA,open,TRUE,c1,1,TRUE,FALSE,-23,NA,"['VisualEditor: Clean up duplication of Mac/PC command/ctrl in all command registrars.', 'Should perhaps have some kind of magic alias ""trigger"" that maps to meta/ctrl respectively.', ""The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that."", ""And we're currently duplicating this internal logic at the cost of decentralisation."", 'So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,--------------------------\n**Version**: unspecified\n**Severity**: enhancement,OBSERVED BUG BEHAVIOR,, +13803,Force HTTPS for /token if the Consumer is not using an RSA key,"We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. + +rfc5849 - 2.3 says that: + + Since the request results in the transmission of plain text + credentials in the HTTP response, the server MUST require the use of + a transport-layer mechanism such as TLS or SSL (or a secure channel + with equivalent protections). + +However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. + +-------------------------- +**Version**: master +**Severity**: normal",1379118240,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-eltc3unjgxsy26lpygu6,task_description,"Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. + +rfc5849 - 2.3 says that: + + Since the request results in the transmission of plain text + credentials in the HTTP response, the server MUST require the use of + a transport-layer mechanism such as TLS or SSL (or a secure channel + with equivalent protections). + +However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. + +-------------------------- +**Version**: master +**Severity**: normal","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. + +rfc5849 - 2.3 says that: + + Since the request results in the transmission of plain text + credentials in the HTTP response, the server MUST require the use of + a transport-layer mechanism such as TLS or SSL (or a secure channel + with equivalent protections). + +However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. + +-------------------------- +**Version**: master +**Severity**: normal",Needs Triage,90,1380551043,NA,resolved,TRUE,c2,3,TRUE,FALSE,2,TRUE,"['Force HTTPS for /token if the Consumer is not using an RSA key.', ""We currently don't require HTTPS for the consumer to get the authorization token."", ""The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."", 'rfc5849 - 2.3 says that:\n\n Since the request results in the transmission of plain text\n credentials in the HTTP response, the server MUST require the use of\n a transport-layer mechanism such as TLS or SSL (or a secure channel\n with equivalent protections).', ""However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,1,Force HTTPS for /token if the Consumer is not using an RSA key.,EXPECTED BEHAVIOR,, +13803,Force HTTPS for /token if the Consumer is not using an RSA key,"We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. + +rfc5849 - 2.3 says that: + + Since the request results in the transmission of plain text + credentials in the HTTP response, the server MUST require the use of + a transport-layer mechanism such as TLS or SSL (or a secure channel + with equivalent protections). + +However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. + +-------------------------- +**Version**: master +**Severity**: normal",1379118240,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-eltc3unjgxsy26lpygu6,task_description,"Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. + +rfc5849 - 2.3 says that: + + Since the request results in the transmission of plain text + credentials in the HTTP response, the server MUST require the use of + a transport-layer mechanism such as TLS or SSL (or a secure channel + with equivalent protections). + +However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. + +-------------------------- +**Version**: master +**Severity**: normal","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. + +rfc5849 - 2.3 says that: + + Since the request results in the transmission of plain text + credentials in the HTTP response, the server MUST require the use of + a transport-layer mechanism such as TLS or SSL (or a secure channel + with equivalent protections). + +However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. + +-------------------------- +**Version**: master +**Severity**: normal",Needs Triage,90,1380551043,NA,resolved,TRUE,c2,3,TRUE,FALSE,2,TRUE,"['Force HTTPS for /token if the Consumer is not using an RSA key.', ""We currently don't require HTTPS for the consumer to get the authorization token."", ""The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."", 'rfc5849 - 2.3 says that:\n\n Since the request results in the transmission of plain text\n credentials in the HTTP response, the server MUST require the use of\n a transport-layer mechanism such as TLS or SSL (or a secure channel\n with equivalent protections).', ""However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,1,"rfc5849 - 2.3 says that:\n\n Since the request results in the transmission of plain text\n credentials in the HTTP response, the server MUST require the use of\n a transport-layer mechanism such as TLS or SSL (or a secure channel\n with equivalent protections).",OBSERVED BUG BEHAVIOR,, +13803,Force HTTPS for /token if the Consumer is not using an RSA key,"We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. + +rfc5849 - 2.3 says that: + + Since the request results in the transmission of plain text + credentials in the HTTP response, the server MUST require the use of + a transport-layer mechanism such as TLS or SSL (or a secure channel + with equivalent protections). + +However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. + +-------------------------- +**Version**: master +**Severity**: normal",1379118240,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-eltc3unjgxsy26lpygu6,task_description,"Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. + +rfc5849 - 2.3 says that: + + Since the request results in the transmission of plain text + credentials in the HTTP response, the server MUST require the use of + a transport-layer mechanism such as TLS or SSL (or a secure channel + with equivalent protections). + +However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. + +-------------------------- +**Version**: master +**Severity**: normal","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. + +rfc5849 - 2.3 says that: + + Since the request results in the transmission of plain text + credentials in the HTTP response, the server MUST require the use of + a transport-layer mechanism such as TLS or SSL (or a secure channel + with equivalent protections). + +However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. + +-------------------------- +**Version**: master +**Severity**: normal",Needs Triage,90,1380551043,NA,resolved,TRUE,c2,3,TRUE,FALSE,2,TRUE,"['Force HTTPS for /token if the Consumer is not using an RSA key.', ""We currently don't require HTTPS for the consumer to get the authorization token."", ""The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."", 'rfc5849 - 2.3 says that:\n\n Since the request results in the transmission of plain text\n credentials in the HTTP response, the server MUST require the use of\n a transport-layer mechanism such as TLS or SSL (or a secure channel\n with equivalent protections).', ""However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,1,--------------------------\n**Version**: master\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, +13803,Force HTTPS for /token if the Consumer is not using an RSA key,"We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. + +rfc5849 - 2.3 says that: + + Since the request results in the transmission of plain text + credentials in the HTTP response, the server MUST require the use of + a transport-layer mechanism such as TLS or SSL (or a secure channel + with equivalent protections). + +However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. + +-------------------------- +**Version**: master +**Severity**: normal",1379118240,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-eltc3unjgxsy26lpygu6,task_description,"Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. + +rfc5849 - 2.3 says that: + + Since the request results in the transmission of plain text + credentials in the HTTP response, the server MUST require the use of + a transport-layer mechanism such as TLS or SSL (or a secure channel + with equivalent protections). + +However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. + +-------------------------- +**Version**: master +**Severity**: normal","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. + +rfc5849 - 2.3 says that: + + Since the request results in the transmission of plain text + credentials in the HTTP response, the server MUST require the use of + a transport-layer mechanism such as TLS or SSL (or a secure channel + with equivalent protections). + +However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. + +-------------------------- +**Version**: master +**Severity**: normal",Needs Triage,90,1380551043,NA,resolved,TRUE,c2,3,TRUE,FALSE,2,TRUE,"['Force HTTPS for /token if the Consumer is not using an RSA key.', ""We currently don't require HTTPS for the consumer to get the authorization token."", ""The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."", 'rfc5849 - 2.3 says that:\n\n Since the request results in the transmission of plain text\n credentials in the HTTP response, the server MUST require the use of\n a transport-layer mechanism such as TLS or SSL (or a secure channel\n with equivalent protections).', ""However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,1,We currently don't require HTTPS for the consumer to get the authorization token.,INVESTIGATION AND EXPLORATION,, +13803,Force HTTPS for /token if the Consumer is not using an RSA key,"We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. + +rfc5849 - 2.3 says that: + + Since the request results in the transmission of plain text + credentials in the HTTP response, the server MUST require the use of + a transport-layer mechanism such as TLS or SSL (or a secure channel + with equivalent protections). + +However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. + +-------------------------- +**Version**: master +**Severity**: normal",1379118240,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-eltc3unjgxsy26lpygu6,task_description,"Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. + +rfc5849 - 2.3 says that: + + Since the request results in the transmission of plain text + credentials in the HTTP response, the server MUST require the use of + a transport-layer mechanism such as TLS or SSL (or a secure channel + with equivalent protections). + +However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. + +-------------------------- +**Version**: master +**Severity**: normal","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. + +rfc5849 - 2.3 says that: + + Since the request results in the transmission of plain text + credentials in the HTTP response, the server MUST require the use of + a transport-layer mechanism such as TLS or SSL (or a secure channel + with equivalent protections). + +However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. + +-------------------------- +**Version**: master +**Severity**: normal",Needs Triage,90,1380551043,NA,resolved,TRUE,c2,3,TRUE,FALSE,2,TRUE,"['Force HTTPS for /token if the Consumer is not using an RSA key.', ""We currently don't require HTTPS for the consumer to get the authorization token."", ""The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."", 'rfc5849 - 2.3 says that:\n\n Since the request results in the transmission of plain text\n credentials in the HTTP response, the server MUST require the use of\n a transport-layer mechanism such as TLS or SSL (or a secure channel\n with equivalent protections).', ""However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,1,"The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic.",INVESTIGATION AND EXPLORATION,, +13803,Force HTTPS for /token if the Consumer is not using an RSA key,"We currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. + +rfc5849 - 2.3 says that: + + Since the request results in the transmission of plain text + credentials in the HTTP response, the server MUST require the use of + a transport-layer mechanism such as TLS or SSL (or a secure channel + with equivalent protections). + +However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. + +-------------------------- +**Version**: master +**Severity**: normal",1379118240,PHID-USER-doeppszazlm3r7xah4il,PHID-TASK-eltc3unjgxsy26lpygu6,task_description,"Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. + +rfc5849 - 2.3 says that: + + Since the request results in the transmission of plain text + credentials in the HTTP response, the server MUST require the use of + a transport-layer mechanism such as TLS or SSL (or a secure channel + with equivalent protections). + +However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. + +-------------------------- +**Version**: master +**Severity**: normal","Force HTTPS for /token if the Consumer is not using an RSA key./n/nWe currently don't require HTTPS for the consumer to get the authorization token. The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic. + +rfc5849 - 2.3 says that: + + Since the request results in the transmission of plain text + credentials in the HTTP response, the server MUST require the use of + a transport-layer mechanism such as TLS or SSL (or a secure channel + with equivalent protections). + +However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call. + +-------------------------- +**Version**: master +**Severity**: normal",Needs Triage,90,1380551043,NA,resolved,TRUE,c2,3,TRUE,FALSE,2,TRUE,"['Force HTTPS for /token if the Consumer is not using an RSA key.', ""We currently don't require HTTPS for the consumer to get the authorization token."", ""The auth token's secret is combined with the consumer's secret for an HMAC signature, so part of the signing key would be known to an attacker if they can sniff this traffic."", 'rfc5849 - 2.3 says that:\n\n Since the request results in the transmission of plain text\n credentials in the HTTP response, the server MUST require the use of\n a transport-layer mechanism such as TLS or SSL (or a secure channel\n with equivalent protections).', ""However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call."", '--------------------------\n**Version**: master\n**Severity**: normal']",TRUE,1,"However, if the Consumer is using an RSA key, then the authorization token's secret isn't used, so the security isn't affected by not using SSL for the /token call.",INVESTIGATION AND EXPLORATION,, +13804,Force HTTPS for /token if the Consumer is not using an RSA key,"Change 85218 merged by jenkins-bot: +Use HTTPS for Special:MWOAuth/token + +https://gerrit.wikimedia.org/r/85218",1380396294,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-eltc3unjgxsy26lpygu6,task_subcomment,"Change 85218 merged by jenkins-bot: +Use HTTPS for Special:MWOAuth/token + +https://gerrit.wikimedia.org/r/85218","Change 85218 merged by jenkins-bot: +Use HTTPS for Special:MWOAuth/token + +GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,4,TRUE,['Change 85218 merged by jenkins-bot:\nUse HTTPS for Special:MWOAuth/token\n\nGERRIT_URL'],NA,1,Change 85218 merged by jenkins-bot:\nUse HTTPS for Special:MWOAuth/token\n\nGERRIT_URL,TASK PROGRESS,, +13805,Force HTTPS for /token if the Consumer is not using an RSA key,"Change 85218 had a related patch set uploaded by Anomie: +Use HTTPS for Special:MWOAuth/token + +https://gerrit.wikimedia.org/r/85218",1379691008,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-eltc3unjgxsy26lpygu6,task_subcomment,"Change 85218 had a related patch set uploaded by Anomie: +Use HTTPS for Special:MWOAuth/token + +https://gerrit.wikimedia.org/r/85218","Change 85218 had a related patch set uploaded by Anomie: +Use HTTPS for Special:MWOAuth/token + +GERRIT_URL",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,3,TRUE,['Change 85218 had a related patch set uploaded by Anomie:\nUse HTTPS for Special:MWOAuth/token\n\nGERRIT_URL'],NA,1,Change 85218 had a related patch set uploaded by Anomie:\nUse HTTPS for Special:MWOAuth/token\n\nGERRIT_URL,TASK PROGRESS,, +13806,Force HTTPS for /token if the Consumer is not using an RSA key,"(In reply to comment #0) +> However, if the Consumer is using an RSA key, then the authorization token's +> secret isn't used, so the security isn't affected by not using SSL for the +> /token call. + +What about the token credentials returned in the response? Those are still plain text.",1379690874,PHID-USER-uqcn2l4ng4murmyfnvyp,PHID-TASK-eltc3unjgxsy26lpygu6,task_subcomment,"(In reply to comment #0) +> However, if the Consumer is using an RSA key, then the authorization token's +> secret isn't used, so the security isn't affected by not using SSL for the +> /token call. + +What about the token credentials returned in the response? Those are still plain text.","(In reply to comment #0) +QUOTE +QUOTE +QUOTE + +What about the token credentials returned in the response? Those are still plain text.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,3,TRUE,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nWhat about the token credentials returned in the response?', 'Those are still plain text.']",NA,1,(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nWhat about the token credentials returned in the response?,INVESTIGATION AND EXPLORATION,, +13806,Force HTTPS for /token if the Consumer is not using an RSA key,"(In reply to comment #0) +> However, if the Consumer is using an RSA key, then the authorization token's +> secret isn't used, so the security isn't affected by not using SSL for the +> /token call. + +What about the token credentials returned in the response? Those are still plain text.",1379690874,PHID-USER-uqcn2l4ng4murmyfnvyp,PHID-TASK-eltc3unjgxsy26lpygu6,task_subcomment,"(In reply to comment #0) +> However, if the Consumer is using an RSA key, then the authorization token's +> secret isn't used, so the security isn't affected by not using SSL for the +> /token call. + +What about the token credentials returned in the response? Those are still plain text.","(In reply to comment #0) +QUOTE +QUOTE +QUOTE + +What about the token credentials returned in the response? Those are still plain text.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,3,TRUE,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nWhat about the token credentials returned in the response?', 'Those are still plain text.']",NA,1,Those are still plain text.,INVESTIGATION AND EXPLORATION,, +14314,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),"This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. + +When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1379948580,PHID-USER-2trxtywh5ma4onasf4kq,PHID-TASK-zre4dw2by7umnxgdzcwg,task_description,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. + +When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. + +When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. + +-------------------------- +**Version**: unspecified +**Severity**: normal",Medium,50,1389207325,NA,invalid,TRUE,c2,3,FALSE,FALSE,3,TRUE,"['Using the secure API is breaking the Flickr upload (using HTTPSEverywhere).', ""This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure."", 'When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result.', 'When not having the extension active, the result is made to api.flickr.com and works as expected.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere).,OBSERVED BUG BEHAVIOR,, +14314,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),"This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. + +When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1379948580,PHID-USER-2trxtywh5ma4onasf4kq,PHID-TASK-zre4dw2by7umnxgdzcwg,task_description,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. + +When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. + +When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. + +-------------------------- +**Version**: unspecified +**Severity**: normal",Medium,50,1389207325,NA,invalid,TRUE,c2,3,FALSE,FALSE,3,TRUE,"['Using the secure API is breaking the Flickr upload (using HTTPSEverywhere).', ""This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure."", 'When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result.', 'When not having the extension active, the result is made to api.flickr.com and works as expected.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result.",OBSERVED BUG BEHAVIOR,, +14314,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),"This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. + +When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1379948580,PHID-USER-2trxtywh5ma4onasf4kq,PHID-TASK-zre4dw2by7umnxgdzcwg,task_description,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. + +When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. + +When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. + +-------------------------- +**Version**: unspecified +**Severity**: normal",Medium,50,1389207325,NA,invalid,TRUE,c2,3,FALSE,FALSE,3,TRUE,"['Using the secure API is breaking the Flickr upload (using HTTPSEverywhere).', ""This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure."", 'When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result.', 'When not having the extension active, the result is made to api.flickr.com and works as expected.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"When not having the extension active, the result is made to api.flickr.com and works as expected.",OBSERVED BUG BEHAVIOR,, +14314,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),"This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. + +When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1379948580,PHID-USER-2trxtywh5ma4onasf4kq,PHID-TASK-zre4dw2by7umnxgdzcwg,task_description,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. + +When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. + +When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. + +-------------------------- +**Version**: unspecified +**Severity**: normal",Medium,50,1389207325,NA,invalid,TRUE,c2,3,FALSE,FALSE,3,TRUE,"['Using the secure API is breaking the Flickr upload (using HTTPSEverywhere).', ""This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure."", 'When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result.', 'When not having the extension active, the result is made to api.flickr.com and works as expected.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, +14314,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),"This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. + +When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1379948580,PHID-USER-2trxtywh5ma4onasf4kq,PHID-TASK-zre4dw2by7umnxgdzcwg,task_description,"Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. + +When making a request for a flickr image such as https://secure.flickr.com/photos/sludgeulper/7447549052/in/photostream/ from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)./n/nThis could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure. + +When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result. When not having the extension active, the result is made to api.flickr.com and works as expected. + +-------------------------- +**Version**: unspecified +**Severity**: normal",Medium,50,1389207325,NA,invalid,TRUE,c2,3,FALSE,FALSE,3,TRUE,"['Using the secure API is breaking the Flickr upload (using HTTPSEverywhere).', ""This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure."", 'When making a request for a flickr image such as URL from UploadWizard while having HTTPSEverywhere active, the API request to secure.flickr.com returns an empty result.', 'When not having the extension active, the result is made to api.flickr.com and works as expected.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"This could be an upstream bug, either in HTTPSEverywhere or Flickr API, but I'm not sure.",INVESTIGATION AND EXPLORATION,, +14315,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),Can't reproduce this. It seems Flickr changed how they handle HTTPS and there is no redirect now.,1389059684,PHID-USER-a6p24cvyblhfzc7we7nc,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,Can't reproduce this. It seems Flickr changed how they handle HTTPS and there is no redirect now.,Can't reproduce this. It seems Flickr changed how they handle HTTPS and there is no redirect now.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,18,TRUE,"[""Can't reproduce this."", 'It seems Flickr changed how they handle HTTPS and there is no redirect now.']",NA,1,It seems Flickr changed how they handle HTTPS and there is no redirect now.,INVESTIGATION AND EXPLORATION,, +14315,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),Can't reproduce this. It seems Flickr changed how they handle HTTPS and there is no redirect now.,1389059684,PHID-USER-a6p24cvyblhfzc7we7nc,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,Can't reproduce this. It seems Flickr changed how they handle HTTPS and there is no redirect now.,Can't reproduce this. It seems Flickr changed how they handle HTTPS and there is no redirect now.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,18,TRUE,"[""Can't reproduce this."", 'It seems Flickr changed how they handle HTTPS and there is no redirect now.']",NA,1,Can't reproduce this.,BUG REPRODUCTION,, +14316,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.,1384972951,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.,I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. URL redirects to URL which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''URL making the request SSL/TLS protected for all users.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,12,TRUE,"['I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin.', 'URL redirects to URL which causes the XHR request to hang/fail.', ""This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?'"", ""to ''URL making the request SSL/TLS protected for all users.""]",NA,1,I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin.,INVESTIGATION AND EXPLORATION,, +14316,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.,1384972951,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.,I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. URL redirects to URL which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''URL making the request SSL/TLS protected for all users.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,12,TRUE,"['I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin.', 'URL redirects to URL which causes the XHR request to hang/fail.', ""This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?'"", ""to ''URL making the request SSL/TLS protected for all users.""]",NA,1,URL redirects to URL which causes the XHR request to hang/fail.,INVESTIGATION AND EXPLORATION,, +14316,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.,1384972951,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. https://api.flickr.com redirects to https://secure.flickr.com which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''https://secure.flickr.com/services/rest/?' making the request SSL/TLS protected for all users.,I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin. URL redirects to URL which causes the XHR request to hang/fail. This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?' to ''URL making the request SSL/TLS protected for all users.,NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,12,TRUE,"['I think that this is problem in the UploadWizard javascript triggered by HTTPSEverywhere plugin.', 'URL redirects to URL which causes the XHR request to hang/fail.', ""This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?'"", ""to ''URL making the request SSL/TLS protected for all users.""]",NA,1,This fix for this may be as easy as changing 'flickrApiUrl' in UploadWizard.config.php from '//api.flickr.com/services/rest/?',WORKAROUNDS,, +14317,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),"The bug that we decided this duplicated seemed similar at the time, but it is actually very different.",1381880122,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,"The bug that we decided this duplicated seemed similar at the time, but it is actually very different.","The bug that we decided this duplicated seemed similar at the time, but it is actually very different.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,6,TRUE,"['The bug that we decided this duplicated seemed similar at the time, but it is actually very different.']",NA,1,"The bug that we decided this duplicated seemed similar at the time, but it is actually very different.",ISSUE CONTENT MANAGEMENT,, +14318,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere)," + +*** This bug has been marked as a duplicate of bug 42468 ***",1381426891,PHID-USER-edlps6xg553cjlnvd4ao,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment," + +*** This bug has been marked as a duplicate of bug 42468 ***"," + +*** This bug has been marked as a duplicate of bug 42468 ***",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,6,TRUE,['\n\n*** This bug has been marked as a duplicate of bug 42468 ***'],NA,1,\n\n*** This bug has been marked as a duplicate of bug 42468 ***,ISSUE CONTENT MANAGEMENT,, +14319,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),"(In reply to comment #1) +> A related improvement would be to use the secure API endpoint when the user +> is using https on the mediawiki site. + +Only if it works. ;-)",1379997214,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,"(In reply to comment #1) +> A related improvement would be to use the secure API endpoint when the user +> is using https on the mediawiki site. + +Only if it works. ;-)","(In reply to comment #1) +QUOTE +QUOTE + +Only if it works. ;-)",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,3,TRUE,"['(In reply to comment #1)\nQUOTE\nQUOTE\n\nOnly if it works.', ';-)']",NA,1,(In reply to comment #1)\nQUOTE\nQUOTE\n\nOnly if it works.,SOCIAL CONVERSATION,, +14320,Using the secure API is breaking the Flickr upload (using HTTPSEverywhere),A related improvement would be to use the secure API endpoint when the user is using https on the mediawiki site.,1379948656,PHID-USER-2trxtywh5ma4onasf4kq,PHID-TASK-zre4dw2by7umnxgdzcwg,task_subcomment,A related improvement would be to use the secure API endpoint when the user is using https on the mediawiki site.,A related improvement would be to use the secure API endpoint when the user is using https on the mediawiki site.,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,3,TRUE,['A related improvement would be to use the secure API endpoint when the user is using https on the mediawiki site.'],NA,1,A related improvement would be to use the secure API endpoint when the user is using https on the mediawiki site.,FUTURE PLANS,, +15541,Wikidata.org is using the SSL certificate for *.wikimedia.org,"Wikidata.org is using the SSL certificate for *.wikimedia.org + +Reedy says this is RT #3803, creating bug here so no one else does. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1351286160,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_description,"Wikidata.org is using the SSL certificate for *.wikimedia.org./n/nWikidata.org is using the SSL certificate for *.wikimedia.org + +Reedy says this is RT #3803, creating bug here so no one else does. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Wikidata.org is using the SSL certificate for *.wikimedia.org./n/nWikidata.org is using the SSL certificate for *.wikimedia.org + +Reedy says this is RT #3803, creating bug here so no one else does. + +-------------------------- +**Version**: unspecified +**Severity**: normal",High,80,1366938213,NA,resolved,TRUE,c2,1,TRUE,FALSE,-44,TRUE,"['Wikidata.org is using the SSL certificate for *.wikimedia.org.', 'Wikidata.org is using the SSL certificate for *.wikimedia.org\n\nReedy says this is RT #3803, creating bug here so no one else does.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,Wikidata.org is using the SSL certificate for *.wikimedia.org.,INVESTIGATION AND EXPLORATION,, +15541,Wikidata.org is using the SSL certificate for *.wikimedia.org,"Wikidata.org is using the SSL certificate for *.wikimedia.org + +Reedy says this is RT #3803, creating bug here so no one else does. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1351286160,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_description,"Wikidata.org is using the SSL certificate for *.wikimedia.org./n/nWikidata.org is using the SSL certificate for *.wikimedia.org + +Reedy says this is RT #3803, creating bug here so no one else does. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Wikidata.org is using the SSL certificate for *.wikimedia.org./n/nWikidata.org is using the SSL certificate for *.wikimedia.org + +Reedy says this is RT #3803, creating bug here so no one else does. + +-------------------------- +**Version**: unspecified +**Severity**: normal",High,80,1366938213,NA,resolved,TRUE,c2,1,TRUE,FALSE,-44,TRUE,"['Wikidata.org is using the SSL certificate for *.wikimedia.org.', 'Wikidata.org is using the SSL certificate for *.wikimedia.org\n\nReedy says this is RT #3803, creating bug here so no one else does.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,"Wikidata.org is using the SSL certificate for *.wikimedia.org\n\nReedy says this is RT #3803, creating bug here so no one else does.",OBSERVED BUG BEHAVIOR,, +15541,Wikidata.org is using the SSL certificate for *.wikimedia.org,"Wikidata.org is using the SSL certificate for *.wikimedia.org + +Reedy says this is RT #3803, creating bug here so no one else does. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1351286160,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_description,"Wikidata.org is using the SSL certificate for *.wikimedia.org./n/nWikidata.org is using the SSL certificate for *.wikimedia.org + +Reedy says this is RT #3803, creating bug here so no one else does. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Wikidata.org is using the SSL certificate for *.wikimedia.org./n/nWikidata.org is using the SSL certificate for *.wikimedia.org + +Reedy says this is RT #3803, creating bug here so no one else does. + +-------------------------- +**Version**: unspecified +**Severity**: normal",High,80,1366938213,NA,resolved,TRUE,c2,1,TRUE,FALSE,-44,TRUE,"['Wikidata.org is using the SSL certificate for *.wikimedia.org.', 'Wikidata.org is using the SSL certificate for *.wikimedia.org\n\nReedy says this is RT #3803, creating bug here so no one else does.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, +15542,Wikidata.org is using the SSL certificate for *.wikimedia.org,Verified in Wikidata demo time,1378307160,PHID-USER-ydl4ek3zzlyuz7f7upgt,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,Verified in Wikidata demo time,Verified in Wikidata demo time,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,1,TRUE,['Verified in Wikidata demo time'],NA,1,Verified in Wikidata demo time,BUG REPRODUCTION,, +15543,Wikidata.org is using the SSL certificate for *.wikimedia.org,"openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 + +Certificate chain + 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA + + Verify return code: 0 (ok)",1366938159,PHID-USER-fo56wm4wxiwpoofn2xdu,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 + +Certificate chain + 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA + + Verify return code: 0 (ok)","openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 + +Certificate chain + 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA + + Verify return code: 0 (ok)",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-18,TRUE,"['openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443\n\nCertificate chain\n 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA\n\n Verify return code: 0 (ok)']",NA,1,"openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443\n\nCertificate chain\n 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA\n\n Verify return code: 0 (ok)",BUG REPRODUCTION,, +15544,Wikidata.org is using the SSL certificate for *.wikimedia.org,"dzahn: Could you take a look at comment 13, please (as you reviewed the initial patch in comment 12)?",1366907051,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"dzahn: Could you take a look at comment 13, please (as you reviewed the initial patch in comment 12)?","dzahn: Could you take a look at comment 13, please (as you reviewed the initial patch in comment 12)?",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-18,TRUE,"['dzahn: Could you take a look at comment 13, please (as you reviewed the initial patch in comment 12)?']",NA,1,"dzahn: Could you take a look at comment 13, please (as you reviewed the initial patch in comment 12)?",CONTRIBUTION AND COMMITMENT ,, +15545,Wikidata.org is using the SSL certificate for *.wikimedia.org,"(In reply to comment #12) +> RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. +> Closing too, thanks for the ping. + +IMHO the diff doesn't look like a fix :( + +If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: + +$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 +CONNECTED(00000003) +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=20:unable to get local issuer certificate +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=27:certificate not trusted +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=21:unable to verify the first certificate +verify return:1 +--- +Certificate chain + 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA + i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA +^^^ + This is wrong. + + It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. + +--- +Server certificate +-----BEGIN CERTIFICATE----- +[...cut...] +-----END CERTIFICATE----- +subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org +issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 +--- +No client certificate CA names sent +--- +SSL handshake has read 3159 bytes and written 542 bytes +--- +New, TLSv1/SSLv3, Cipher is RC4-SHA +[...cut...] + Verify return code: 21 (unable to verify the first certificate) +--- +QUIT +DONE +$ + +Reopening again.",1354282713,PHID-USER-gct3jslngczd4jvmyy6e,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"(In reply to comment #12) +> RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. +> Closing too, thanks for the ping. + +IMHO the diff doesn't look like a fix :( + +If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: + +$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 +CONNECTED(00000003) +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=20:unable to get local issuer certificate +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=27:certificate not trusted +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=21:unable to verify the first certificate +verify return:1 +--- +Certificate chain + 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA + i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA +^^^ + This is wrong. + + It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. + +--- +Server certificate +-----BEGIN CERTIFICATE----- +[...cut...] +-----END CERTIFICATE----- +subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org +issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 +--- +No client certificate CA names sent +--- +SSL handshake has read 3159 bytes and written 542 bytes +--- +New, TLSv1/SSLv3, Cipher is RC4-SHA +[...cut...] + Verify return code: 21 (unable to verify the first certificate) +--- +QUIT +DONE +$ + +Reopening again.","(In reply to comment #12) +QUOTE +QUOTE + +IMHO the diff doesn't look like a fix :( + +If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: + +$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 +CONNECTED(00000003) +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=20:unable to get local issuer certificate +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=27:certificate not trusted +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=21:unable to verify the first certificate +verify return:1 +--- +Certificate chain + 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA + i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA +^^^ + This is wrong. + + It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. + +--- +Server certificate +-----BEGIN CERTIFICATE----- +[...cut...] +-----END CERTIFICATE----- +subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org +issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 +--- +No client certificate CA names sent +--- +SSL handshake has read 3159 bytes and written 542 bytes +--- +New, TLSv1/SSLv3, Cipher is RC4-SHA +[...cut...] + Verify return code: 21 (unable to verify the first certificate) +--- +QUIT +DONE +$ + +Reopening again.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-39,TRUE,"['(In reply to comment #12)\nQUOTE\nQUOTE\n\nIMHO the diff doesn\'t look like a fix :(\n\nIf my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate:\n\n$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443\nCONNECTED(00000003)\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=20:unable to get local issuer certificate\nverify return:1\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=27:certificate not trusted\nverify return:1\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=21:unable to verify the first certificate\nverify return:1\n---\nCertificate chain\n 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n^^^\n This is wrong.', 'It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert.', '---\nServer certificate\n-----BEGIN CERTIFICATE-----\n[...cut...]\n-----END CERTIFICATE-----\nsubject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\nissuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n---\nNo client certificate CA names sent\n---\nSSL handshake has read 3159 bytes and written 542 bytes\n---\nNew, TLSv1/SSLv3, Cipher is RC4-SHA\n[...cut...]\n Verify return code: 21 (unable to verify the first certificate)\n---\nQUIT\nDONE\n$ \n\nReopening again.']",NA,1,(In reply to comment #12)\nQUOTE\nQUOTE\n\nIMHO the diff doesn\,INVESTIGATION AND EXPLORATION,, +15545,Wikidata.org is using the SSL certificate for *.wikimedia.org,"(In reply to comment #12) +> RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. +> Closing too, thanks for the ping. + +IMHO the diff doesn't look like a fix :( + +If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: + +$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 +CONNECTED(00000003) +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=20:unable to get local issuer certificate +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=27:certificate not trusted +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=21:unable to verify the first certificate +verify return:1 +--- +Certificate chain + 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA + i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA +^^^ + This is wrong. + + It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. + +--- +Server certificate +-----BEGIN CERTIFICATE----- +[...cut...] +-----END CERTIFICATE----- +subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org +issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 +--- +No client certificate CA names sent +--- +SSL handshake has read 3159 bytes and written 542 bytes +--- +New, TLSv1/SSLv3, Cipher is RC4-SHA +[...cut...] + Verify return code: 21 (unable to verify the first certificate) +--- +QUIT +DONE +$ + +Reopening again.",1354282713,PHID-USER-gct3jslngczd4jvmyy6e,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"(In reply to comment #12) +> RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. +> Closing too, thanks for the ping. + +IMHO the diff doesn't look like a fix :( + +If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: + +$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 +CONNECTED(00000003) +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=20:unable to get local issuer certificate +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=27:certificate not trusted +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=21:unable to verify the first certificate +verify return:1 +--- +Certificate chain + 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA + i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA +^^^ + This is wrong. + + It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. + +--- +Server certificate +-----BEGIN CERTIFICATE----- +[...cut...] +-----END CERTIFICATE----- +subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org +issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 +--- +No client certificate CA names sent +--- +SSL handshake has read 3159 bytes and written 542 bytes +--- +New, TLSv1/SSLv3, Cipher is RC4-SHA +[...cut...] + Verify return code: 21 (unable to verify the first certificate) +--- +QUIT +DONE +$ + +Reopening again.","(In reply to comment #12) +QUOTE +QUOTE + +IMHO the diff doesn't look like a fix :( + +If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: + +$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 +CONNECTED(00000003) +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=20:unable to get local issuer certificate +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=27:certificate not trusted +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=21:unable to verify the first certificate +verify return:1 +--- +Certificate chain + 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA + i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA +^^^ + This is wrong. + + It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. + +--- +Server certificate +-----BEGIN CERTIFICATE----- +[...cut...] +-----END CERTIFICATE----- +subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org +issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 +--- +No client certificate CA names sent +--- +SSL handshake has read 3159 bytes and written 542 bytes +--- +New, TLSv1/SSLv3, Cipher is RC4-SHA +[...cut...] + Verify return code: 21 (unable to verify the first certificate) +--- +QUIT +DONE +$ + +Reopening again.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-39,TRUE,"['(In reply to comment #12)\nQUOTE\nQUOTE\n\nIMHO the diff doesn\'t look like a fix :(\n\nIf my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate:\n\n$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443\nCONNECTED(00000003)\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=20:unable to get local issuer certificate\nverify return:1\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=27:certificate not trusted\nverify return:1\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=21:unable to verify the first certificate\nverify return:1\n---\nCertificate chain\n 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n^^^\n This is wrong.', 'It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert.', '---\nServer certificate\n-----BEGIN CERTIFICATE-----\n[...cut...]\n-----END CERTIFICATE-----\nsubject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\nissuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n---\nNo client certificate CA names sent\n---\nSSL handshake has read 3159 bytes and written 542 bytes\n---\nNew, TLSv1/SSLv3, Cipher is RC4-SHA\n[...cut...]\n Verify return code: 21 (unable to verify the first certificate)\n---\nQUIT\nDONE\n$ \n\nReopening again.']",NA,1,"Wikimedia Foundation, Inc.",NA,, +15545,Wikidata.org is using the SSL certificate for *.wikimedia.org,"(In reply to comment #12) +> RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. +> Closing too, thanks for the ping. + +IMHO the diff doesn't look like a fix :( + +If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: + +$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 +CONNECTED(00000003) +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=20:unable to get local issuer certificate +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=27:certificate not trusted +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=21:unable to verify the first certificate +verify return:1 +--- +Certificate chain + 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA + i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA +^^^ + This is wrong. + + It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. + +--- +Server certificate +-----BEGIN CERTIFICATE----- +[...cut...] +-----END CERTIFICATE----- +subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org +issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 +--- +No client certificate CA names sent +--- +SSL handshake has read 3159 bytes and written 542 bytes +--- +New, TLSv1/SSLv3, Cipher is RC4-SHA +[...cut...] + Verify return code: 21 (unable to verify the first certificate) +--- +QUIT +DONE +$ + +Reopening again.",1354282713,PHID-USER-gct3jslngczd4jvmyy6e,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"(In reply to comment #12) +> RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. +> Closing too, thanks for the ping. + +IMHO the diff doesn't look like a fix :( + +If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: + +$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 +CONNECTED(00000003) +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=20:unable to get local issuer certificate +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=27:certificate not trusted +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=21:unable to verify the first certificate +verify return:1 +--- +Certificate chain + 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA + i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA +^^^ + This is wrong. + + It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. + +--- +Server certificate +-----BEGIN CERTIFICATE----- +[...cut...] +-----END CERTIFICATE----- +subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org +issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 +--- +No client certificate CA names sent +--- +SSL handshake has read 3159 bytes and written 542 bytes +--- +New, TLSv1/SSLv3, Cipher is RC4-SHA +[...cut...] + Verify return code: 21 (unable to verify the first certificate) +--- +QUIT +DONE +$ + +Reopening again.","(In reply to comment #12) +QUOTE +QUOTE + +IMHO the diff doesn't look like a fix :( + +If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: + +$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 +CONNECTED(00000003) +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=20:unable to get local issuer certificate +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=27:certificate not trusted +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=21:unable to verify the first certificate +verify return:1 +--- +Certificate chain + 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA + i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA +^^^ + This is wrong. + + It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. + +--- +Server certificate +-----BEGIN CERTIFICATE----- +[...cut...] +-----END CERTIFICATE----- +subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org +issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 +--- +No client certificate CA names sent +--- +SSL handshake has read 3159 bytes and written 542 bytes +--- +New, TLSv1/SSLv3, Cipher is RC4-SHA +[...cut...] + Verify return code: 21 (unable to verify the first certificate) +--- +QUIT +DONE +$ + +Reopening again.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-39,TRUE,"['(In reply to comment #12)\nQUOTE\nQUOTE\n\nIMHO the diff doesn\'t look like a fix :(\n\nIf my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate:\n\n$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443\nCONNECTED(00000003)\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=20:unable to get local issuer certificate\nverify return:1\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=27:certificate not trusted\nverify return:1\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=21:unable to verify the first certificate\nverify return:1\n---\nCertificate chain\n 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n^^^\n This is wrong.', 'It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert.', '---\nServer certificate\n-----BEGIN CERTIFICATE-----\n[...cut...]\n-----END CERTIFICATE-----\nsubject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\nissuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n---\nNo client certificate CA names sent\n---\nSSL handshake has read 3159 bytes and written 542 bytes\n---\nNew, TLSv1/SSLv3, Cipher is RC4-SHA\n[...cut...]\n Verify return code: 21 (unable to verify the first certificate)\n---\nQUIT\nDONE\n$ \n\nReopening again.']",NA,1,"Wikimedia Foundation, Inc.",NA,, +15545,Wikidata.org is using the SSL certificate for *.wikimedia.org,"(In reply to comment #12) +> RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. +> Closing too, thanks for the ping. + +IMHO the diff doesn't look like a fix :( + +If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: + +$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 +CONNECTED(00000003) +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=20:unable to get local issuer certificate +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=27:certificate not trusted +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=21:unable to verify the first certificate +verify return:1 +--- +Certificate chain + 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA + i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA +^^^ + This is wrong. + + It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. + +--- +Server certificate +-----BEGIN CERTIFICATE----- +[...cut...] +-----END CERTIFICATE----- +subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org +issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 +--- +No client certificate CA names sent +--- +SSL handshake has read 3159 bytes and written 542 bytes +--- +New, TLSv1/SSLv3, Cipher is RC4-SHA +[...cut...] + Verify return code: 21 (unable to verify the first certificate) +--- +QUIT +DONE +$ + +Reopening again.",1354282713,PHID-USER-gct3jslngczd4jvmyy6e,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"(In reply to comment #12) +> RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. +> Closing too, thanks for the ping. + +IMHO the diff doesn't look like a fix :( + +If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: + +$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 +CONNECTED(00000003) +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=20:unable to get local issuer certificate +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=27:certificate not trusted +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=21:unable to verify the first certificate +verify return:1 +--- +Certificate chain + 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA + i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA +^^^ + This is wrong. + + It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. + +--- +Server certificate +-----BEGIN CERTIFICATE----- +[...cut...] +-----END CERTIFICATE----- +subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org +issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 +--- +No client certificate CA names sent +--- +SSL handshake has read 3159 bytes and written 542 bytes +--- +New, TLSv1/SSLv3, Cipher is RC4-SHA +[...cut...] + Verify return code: 21 (unable to verify the first certificate) +--- +QUIT +DONE +$ + +Reopening again.","(In reply to comment #12) +QUOTE +QUOTE + +IMHO the diff doesn't look like a fix :( + +If my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate: + +$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443 +CONNECTED(00000003) +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=20:unable to get local issuer certificate +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=27:certificate not trusted +verify return:1 +depth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org +verify error:num=21:unable to verify the first certificate +verify return:1 +--- +Certificate chain + 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA + i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA +^^^ + This is wrong. + + It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert. + +--- +Server certificate +-----BEGIN CERTIFICATE----- +[...cut...] +-----END CERTIFICATE----- +subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org +issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 +--- +No client certificate CA names sent +--- +SSL handshake has read 3159 bytes and written 542 bytes +--- +New, TLSv1/SSLv3, Cipher is RC4-SHA +[...cut...] + Verify return code: 21 (unable to verify the first certificate) +--- +QUIT +DONE +$ + +Reopening again.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-39,TRUE,"['(In reply to comment #12)\nQUOTE\nQUOTE\n\nIMHO the diff doesn\'t look like a fix :(\n\nIf my understanding is correct, currently the certificate chain would let OpenSSL fail to verify the server certificate:\n\n$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect www.wikidata.org:443\nCONNECTED(00000003)\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=20:unable to get local issuer certificate\nverify return:1\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=27:certificate not trusted\nverify return:1\ndepth=0 C = US, ST = California, L = San Francisco, O = ""Wikimedia Foundation, Inc."", CN = *.wikidata.org\nverify error:num=21:unable to verify the first certificate\nverify return:1\n---\nCertificate chain\n 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n^^^\n This is wrong.', 'It should be the issuer for cert 0, not a random CA that has nothing to do with the previous cert.', '---\nServer certificate\n-----BEGIN CERTIFICATE-----\n[...cut...]\n-----END CERTIFICATE-----\nsubject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\nissuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n---\nNo client certificate CA names sent\n---\nSSL handshake has read 3159 bytes and written 542 bytes\n---\nNew, TLSv1/SSLv3, Cipher is RC4-SHA\n[...cut...]\n Verify return code: 21 (unable to verify the first certificate)\n---\nQUIT\nDONE\n$ \n\nReopening again.']",NA,1,"Wikimedia Foundation, Inc.",NA,, +15546,Wikidata.org is using the SSL certificate for *.wikimedia.org,"RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. +Closing too, thanks for the ping.",1354281045,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"RT #3803 resolved, https://gerrit.wikimedia.org/r/#/c/30307/ merged. +Closing too, thanks for the ping.","RT #3803 resolved, URL merged. +Closing too, thanks for the ping.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-39,TRUE,"['RT #3803 resolved, URL merged.', 'Closing too, thanks for the ping.']",NA,1,"Closing too, thanks for the ping.",ACTION ON ISSUE,, +15547,Wikidata.org is using the SSL certificate for *.wikimedia.org,Is this still open?,1354271269,PHID-USER-o4wy22wrannrbargenyn,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,Is this still open?,Is this still open?,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-39,TRUE,['Is this still open?'],NA,1,Is this still open?,ISSUE CONTENT MANAGEMENT,, +15548,Wikidata.org is using the SSL certificate for *.wikimedia.org,"I see this bug is now tagged with the ""shell"" keyword. I wonder if it should actually be tagged with the ""ops"" keyword instead.",1353704583,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"I see this bug is now tagged with the ""shell"" keyword. I wonder if it should actually be tagged with the ""ops"" keyword instead.","I see this bug is now tagged with the ""shell"" keyword. I wonder if it should actually be tagged with the ""ops"" keyword instead.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-40,TRUE,"['I see this bug is now tagged with the ""shell"" keyword.', 'I wonder if it should actually be tagged with the ""ops"" keyword instead.']",NA,1,"I see this bug is now tagged with the ""shell"" keyword.",ISSUE CONTENT MANAGEMENT,, +15548,Wikidata.org is using the SSL certificate for *.wikimedia.org,"I see this bug is now tagged with the ""shell"" keyword. I wonder if it should actually be tagged with the ""ops"" keyword instead.",1353704583,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"I see this bug is now tagged with the ""shell"" keyword. I wonder if it should actually be tagged with the ""ops"" keyword instead.","I see this bug is now tagged with the ""shell"" keyword. I wonder if it should actually be tagged with the ""ops"" keyword instead.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-40,TRUE,"['I see this bug is now tagged with the ""shell"" keyword.', 'I wonder if it should actually be tagged with the ""ops"" keyword instead.']",NA,1,"I wonder if it should actually be tagged with the ""ops"" keyword instead.",ISSUE CONTENT MANAGEMENT,, +15549,Wikidata.org is using the SSL certificate for *.wikimedia.org,"The certificate chain seems to be erroneously configured, a wrong CA ""Wikimedia CA"" is being appended to the chain instead of the issuer ""DigiCert High Assurance CA-3"": + +--- +Certificate chain + 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA + i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA +--- + +Therefore: + +$ curl -v https://www.wikidata.org +* About to connect() to www.wikidata.org port 443 (#0) +* Trying 2620:0:861:ed1a::12... +* connected +[...cut...] +* SSLv3, TLS alert, Server hello (2): +* SSL certificate problem: unable to get local issuer certificate +* Closing connection #0",1353416642,PHID-USER-gct3jslngczd4jvmyy6e,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"The certificate chain seems to be erroneously configured, a wrong CA ""Wikimedia CA"" is being appended to the chain instead of the issuer ""DigiCert High Assurance CA-3"": + +--- +Certificate chain + 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA + i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA +--- + +Therefore: + +$ curl -v https://www.wikidata.org +* About to connect() to www.wikidata.org port 443 (#0) +* Trying 2620:0:861:ed1a::12... +* connected +[...cut...] +* SSLv3, TLS alert, Server hello (2): +* SSL certificate problem: unable to get local issuer certificate +* Closing connection #0","The certificate chain seems to be erroneously configured, a wrong CA ""Wikimedia CA"" is being appended to the chain instead of the issuer ""DigiCert High Assurance CA-3"": + +--- +Certificate chain + 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org + i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3 + 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA + i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA +--- + +Therefore: + +$ curl -v URL +* About to connect() to www.wikidata.org port 443 (#0) +* Trying 2620:0:861:ed1a::12... +* connected +[...cut...] +* SSLv3, TLS alert, Server hello (2): +* SSL certificate problem: unable to get local issuer certificate +* Closing connection #0",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-41,TRUE,"['The certificate chain seems to be erroneously configured, a wrong CA ""Wikimedia CA"" is being appended to the chain instead of the issuer ""DigiCert High Assurance CA-3"":\n\n---\nCertificate chain\n 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n---\n\nTherefore:\n\n$ curl -v URL\n* About to connect() to www.wikidata.org port 443 (#0)\n* Trying 2620:0:861:ed1a::12...\n* connected\n[...cut...]\n* SSLv3, TLS alert, Server hello (2):\n* SSL certificate problem: unable to get local issuer certificate\n* Closing connection #0']",NA,1,"The certificate chain seems to be erroneously configured, a wrong CA ""Wikimedia CA"" is being appended to the chain instead of the issuer ""DigiCert High Assurance CA-3"":\n\n---\nCertificate chain\n 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikidata.org\n i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3\n 1 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n i:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation/CN=Wikimedia CA\n---\n\nTherefore:\n\n$ curl -v URL\n* About to connect() to www.wikidata.org port 443 (#0)\n* Trying 2620:0:861:ed1a::12...\n* connected\n[...cut...]\n* SSLv3, TLS alert, Server hello (2):\n* SSL certificate problem: unable to get local issuer certificate\n* Closing connection #0",INVESTIGATION AND EXPLORATION,, +15550,Wikidata.org is using the SSL certificate for *.wikimedia.org,"* https://wikidata.org +* https://www.wikidata.org +* https://example.wikidata.org +* https://fr.wikidata.org",1351544273,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"* https://wikidata.org +* https://www.wikidata.org +* https://example.wikidata.org +* https://fr.wikidata.org","* URL +* URL +* URL +* URL",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,['* URL\n* URL\n* URL\n* URL'],NA,1,* URL\n* URL\n* URL\n* URL,NA,, +15551,Wikidata.org is using the SSL certificate for *.wikimedia.org," Ah so wikidata SSL is working now +<^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. +<^demon> Krenair: Apache config is correct. It needs further DNS work. + +And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",1351534738,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment," Ah so wikidata SSL is working now +<^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. +<^demon> Krenair: Apache config is correct. It needs further DNS work. + +And Wikidata SUL autologin has been re-enabled with Gerrit change 30623."," Ah so wikidata SSL is working now +<^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. +<^demon> Krenair: Apache config is correct. It needs further DNS work. + +And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"[' Ah so wikidata SSL is working now\n<^demon> Krenair: For wikidata.org & www.wikidata.org.', 'Lang subdomains need a little further tweaking.', '<^demon> Krenair: Apache config is correct.', 'It needs further DNS work.', 'And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.']",NA,1,Lang subdomains need a little further tweaking.,FUTURE PLANS,, +15551,Wikidata.org is using the SSL certificate for *.wikimedia.org," Ah so wikidata SSL is working now +<^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. +<^demon> Krenair: Apache config is correct. It needs further DNS work. + +And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",1351534738,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment," Ah so wikidata SSL is working now +<^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. +<^demon> Krenair: Apache config is correct. It needs further DNS work. + +And Wikidata SUL autologin has been re-enabled with Gerrit change 30623."," Ah so wikidata SSL is working now +<^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. +<^demon> Krenair: Apache config is correct. It needs further DNS work. + +And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"[' Ah so wikidata SSL is working now\n<^demon> Krenair: For wikidata.org & www.wikidata.org.', 'Lang subdomains need a little further tweaking.', '<^demon> Krenair: Apache config is correct.', 'It needs further DNS work.', 'And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.']",NA,1,<^demon> Krenair: Apache config is correct.,SOLUTION DISCUSSION,, +15551,Wikidata.org is using the SSL certificate for *.wikimedia.org," Ah so wikidata SSL is working now +<^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. +<^demon> Krenair: Apache config is correct. It needs further DNS work. + +And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",1351534738,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment," Ah so wikidata SSL is working now +<^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. +<^demon> Krenair: Apache config is correct. It needs further DNS work. + +And Wikidata SUL autologin has been re-enabled with Gerrit change 30623."," Ah so wikidata SSL is working now +<^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. +<^demon> Krenair: Apache config is correct. It needs further DNS work. + +And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"[' Ah so wikidata SSL is working now\n<^demon> Krenair: For wikidata.org & www.wikidata.org.', 'Lang subdomains need a little further tweaking.', '<^demon> Krenair: Apache config is correct.', 'It needs further DNS work.', 'And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.']",NA,1,It needs further DNS work.,FUTURE PLANS,, +15551,Wikidata.org is using the SSL certificate for *.wikimedia.org," Ah so wikidata SSL is working now +<^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. +<^demon> Krenair: Apache config is correct. It needs further DNS work. + +And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",1351534738,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment," Ah so wikidata SSL is working now +<^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. +<^demon> Krenair: Apache config is correct. It needs further DNS work. + +And Wikidata SUL autologin has been re-enabled with Gerrit change 30623."," Ah so wikidata SSL is working now +<^demon> Krenair: For wikidata.org & www.wikidata.org. Lang subdomains need a little further tweaking. +<^demon> Krenair: Apache config is correct. It needs further DNS work. + +And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"[' Ah so wikidata SSL is working now\n<^demon> Krenair: For wikidata.org & www.wikidata.org.', 'Lang subdomains need a little further tweaking.', '<^demon> Krenair: Apache config is correct.', 'It needs further DNS work.', 'And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.']",NA,1,And Wikidata SUL autologin has been re-enabled with Gerrit change 30623.,TASK PROGRESS,, +15552,Wikidata.org is using the SSL certificate for *.wikimedia.org,I've disabled auto-login to .wikidata.org until we fix SSL.,1351516871,PHID-USER-oetk6bbl6omm354ejz3b,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,I've disabled auto-login to .wikidata.org until we fix SSL.,I've disabled auto-login to .wikidata.org until we fix SSL.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"[""I've disabled auto-login to .wikidata.org until we fix SSL.""]",NA,1,I've disabled auto-login to .wikidata.org until we fix SSL.,TASK PROGRESS,, +15553,Wikidata.org is using the SSL certificate for *.wikimedia.org,*** Bug 41486 has been marked as a duplicate of this bug. ***,1351515542,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,*** Bug 41486 has been marked as a duplicate of this bug. ***,*** Bug 41486 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"['*** Bug 41486 has been marked as a duplicate of this bug.', '***']",NA,1,*** Bug 41486 has been marked as a duplicate of this bug.,ISSUE CONTENT MANAGEMENT,, +15553,Wikidata.org is using the SSL certificate for *.wikimedia.org,*** Bug 41486 has been marked as a duplicate of this bug. ***,1351515542,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,*** Bug 41486 has been marked as a duplicate of this bug. ***,*** Bug 41486 has been marked as a duplicate of this bug. ***,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"['*** Bug 41486 has been marked as a duplicate of this bug.', '***']",NA,1,***,NA,, +15554,Wikidata.org is using the SSL certificate for *.wikimedia.org,"(In reply to comment #3) +> Knocking down to normal/normal as it's not a high priority as it's currently a +> test site + +It is a test site, but due to SUL und the image after login and logout you will get a error in the browser (at least IE), which can make wmf wikis (except wikidata) feeling untrusted by other users. So this should fixed asap.",1351409516,PHID-USER-a6jwrurphpx6yl4coupk,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"(In reply to comment #3) +> Knocking down to normal/normal as it's not a high priority as it's currently a +> test site + +It is a test site, but due to SUL und the image after login and logout you will get a error in the browser (at least IE), which can make wmf wikis (except wikidata) feeling untrusted by other users. So this should fixed asap.","(In reply to comment #3) +QUOTE +QUOTE + +It is a test site, but due to SUL und the image after login and logout you will get a error in the browser (at least IE), which can make wmf wikis (except wikidata) feeling untrusted by other users. So this should fixed asap.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-44,TRUE,"['(In reply to comment #3)\nQUOTE\nQUOTE\n\nIt is a test site, but due to SUL und the image after login and logout you will get a error in the browser (at least IE), which can make wmf wikis (except wikidata) feeling untrusted by other users.', 'So this should fixed asap.']",NA,1,"(In reply to comment #3)\nQUOTE\nQUOTE\n\nIt is a test site, but due to SUL und the image after login and logout you will get a error in the browser (at least IE), which can make wmf wikis (except wikidata) feeling untrusted by other users.",OBSERVED BUG BEHAVIOR,, +15554,Wikidata.org is using the SSL certificate for *.wikimedia.org,"(In reply to comment #3) +> Knocking down to normal/normal as it's not a high priority as it's currently a +> test site + +It is a test site, but due to SUL und the image after login and logout you will get a error in the browser (at least IE), which can make wmf wikis (except wikidata) feeling untrusted by other users. So this should fixed asap.",1351409516,PHID-USER-a6jwrurphpx6yl4coupk,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"(In reply to comment #3) +> Knocking down to normal/normal as it's not a high priority as it's currently a +> test site + +It is a test site, but due to SUL und the image after login and logout you will get a error in the browser (at least IE), which can make wmf wikis (except wikidata) feeling untrusted by other users. So this should fixed asap.","(In reply to comment #3) +QUOTE +QUOTE + +It is a test site, but due to SUL und the image after login and logout you will get a error in the browser (at least IE), which can make wmf wikis (except wikidata) feeling untrusted by other users. So this should fixed asap.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-44,TRUE,"['(In reply to comment #3)\nQUOTE\nQUOTE\n\nIt is a test site, but due to SUL und the image after login and logout you will get a error in the browser (at least IE), which can make wmf wikis (except wikidata) feeling untrusted by other users.', 'So this should fixed asap.']",NA,1,So this should fixed asap.,MOTIVATION,, +15555,Wikidata.org is using the SSL certificate for *.wikimedia.org,"(In reply to comment #2) +> Doesn't seem to have fixed it... Or just hasn't been deployed. + +It was a guess as it looked spurious. Daniel did confirm it was supposed to be deployed by puppet, and then restarted the ssl proxies/terminators + + +Knocking down to normal/normal as it's not a high priority as it's currently a test site",1351377712,PHID-USER-6vzzsmi22zem6yttr6vp,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"(In reply to comment #2) +> Doesn't seem to have fixed it... Or just hasn't been deployed. + +It was a guess as it looked spurious. Daniel did confirm it was supposed to be deployed by puppet, and then restarted the ssl proxies/terminators + + +Knocking down to normal/normal as it's not a high priority as it's currently a test site","(In reply to comment #2) +QUOTE + +It was a guess as it looked spurious. Daniel did confirm it was supposed to be deployed by puppet, and then restarted the ssl proxies/terminators + + +Knocking down to normal/normal as it's not a high priority as it's currently a test site",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"['(In reply to comment #2)\nQUOTE\n\nIt was a guess as it looked spurious.', ""Daniel did confirm it was supposed to be deployed by puppet, and then restarted the ssl proxies/terminators\n\n\nKnocking down to normal/normal as it's not a high priority as it's currently a test site""]",NA,1,(In reply to comment #2)\nQUOTE\n\nIt was a guess as it looked spurious.,SOCIAL CONVERSATION,, +15555,Wikidata.org is using the SSL certificate for *.wikimedia.org,"(In reply to comment #2) +> Doesn't seem to have fixed it... Or just hasn't been deployed. + +It was a guess as it looked spurious. Daniel did confirm it was supposed to be deployed by puppet, and then restarted the ssl proxies/terminators + + +Knocking down to normal/normal as it's not a high priority as it's currently a test site",1351377712,PHID-USER-6vzzsmi22zem6yttr6vp,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,"(In reply to comment #2) +> Doesn't seem to have fixed it... Or just hasn't been deployed. + +It was a guess as it looked spurious. Daniel did confirm it was supposed to be deployed by puppet, and then restarted the ssl proxies/terminators + + +Knocking down to normal/normal as it's not a high priority as it's currently a test site","(In reply to comment #2) +QUOTE + +It was a guess as it looked spurious. Daniel did confirm it was supposed to be deployed by puppet, and then restarted the ssl proxies/terminators + + +Knocking down to normal/normal as it's not a high priority as it's currently a test site",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,"['(In reply to comment #2)\nQUOTE\n\nIt was a guess as it looked spurious.', ""Daniel did confirm it was supposed to be deployed by puppet, and then restarted the ssl proxies/terminators\n\n\nKnocking down to normal/normal as it's not a high priority as it's currently a test site""]",NA,1,"Daniel did confirm it was supposed to be deployed by puppet, and then restarted the ssl proxies/terminators\n\n\nKnocking down to normal/normal as it's not a high priority as it's currently a test site",INVESTIGATION AND EXPLORATION,, +15557,Wikidata.org is using the SSL certificate for *.wikimedia.org,https://gerrit.wikimedia.org/r/#/c/30307/,1351294636,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-tbrir7a33onbjeho4xwr,task_subcomment,https://gerrit.wikimedia.org/r/#/c/30307/,URL,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-44,TRUE,['URL'],NA,1,URL,NA,, +16731,MWHttpRequest may have to require_once() GlobalFunctions.php,"**Author:** `raphael.droz` + +**Description:** +If +* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), +* and you don't have curl (should I ?) + +=> then you're getting failures because wfIniGetBool() is not yet defined + +There should be a way to require(GlobalFunctions.php) in such a case. + +HTTP component set to ""redirect"", feel free to change this. + +-------------------------- +**Version**: 1.20.x +**Severity**: minor",1321628700,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_description,"MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** `raphael.droz` + +**Description:** +If +* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), +* and you don't have curl (should I ?) + +=> then you're getting failures because wfIniGetBool() is not yet defined + +There should be a way to require(GlobalFunctions.php) in such a case. + +HTTP component set to ""redirect"", feel free to change this. + +-------------------------- +**Version**: 1.20.x +**Severity**: minor","MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** CODE + +**Description:** +If +* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), +* and you don't have curl (should I ?) + +=> then you're getting failures because wfIniGetBool() is not yet defined + +There should be a way to require(GlobalFunctions.php) in such a case. + +HTTP component set to ""redirect"", feel free to change this. + +-------------------------- +**Version**: 1.20.x +**Severity**: minor",Needs Triage,90,1321890399,NA,declined,TRUE,c2,1,FALSE,FALSE,-93,TRUE,"['MWHttpRequest may have to require_once() GlobalFunctions.php.', ""**Author:** CODE\n\n**Description:**\nIf\n* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension),\n* and you don't have curl (should I ?)"", ""=> then you're getting failures because wfIniGetBool() is not yet defined\n\nThere should be a way to require(GlobalFunctions.php) in such a case."", 'HTTP component set to ""redirect"", feel free to change this.', '--------------------------\n**Version**: 1.20.x\n**Severity**: minor']",TRUE,1,MWHttpRequest may have to require_once() GlobalFunctions.php.,MOTIVATION,, +16731,MWHttpRequest may have to require_once() GlobalFunctions.php,"**Author:** `raphael.droz` + +**Description:** +If +* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), +* and you don't have curl (should I ?) + +=> then you're getting failures because wfIniGetBool() is not yet defined + +There should be a way to require(GlobalFunctions.php) in such a case. + +HTTP component set to ""redirect"", feel free to change this. + +-------------------------- +**Version**: 1.20.x +**Severity**: minor",1321628700,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_description,"MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** `raphael.droz` + +**Description:** +If +* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), +* and you don't have curl (should I ?) + +=> then you're getting failures because wfIniGetBool() is not yet defined + +There should be a way to require(GlobalFunctions.php) in such a case. + +HTTP component set to ""redirect"", feel free to change this. + +-------------------------- +**Version**: 1.20.x +**Severity**: minor","MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** CODE + +**Description:** +If +* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), +* and you don't have curl (should I ?) + +=> then you're getting failures because wfIniGetBool() is not yet defined + +There should be a way to require(GlobalFunctions.php) in such a case. + +HTTP component set to ""redirect"", feel free to change this. + +-------------------------- +**Version**: 1.20.x +**Severity**: minor",Needs Triage,90,1321890399,NA,declined,TRUE,c2,1,FALSE,FALSE,-93,TRUE,"['MWHttpRequest may have to require_once() GlobalFunctions.php.', ""**Author:** CODE\n\n**Description:**\nIf\n* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension),\n* and you don't have curl (should I ?)"", ""=> then you're getting failures because wfIniGetBool() is not yet defined\n\nThere should be a way to require(GlobalFunctions.php) in such a case."", 'HTTP component set to ""redirect"", feel free to change this.', '--------------------------\n**Version**: 1.20.x\n**Severity**: minor']",TRUE,1,"HTTP component set to ""redirect"", feel free to change this.",OBSERVED BUG BEHAVIOR,, +16731,MWHttpRequest may have to require_once() GlobalFunctions.php,"**Author:** `raphael.droz` + +**Description:** +If +* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), +* and you don't have curl (should I ?) + +=> then you're getting failures because wfIniGetBool() is not yet defined + +There should be a way to require(GlobalFunctions.php) in such a case. + +HTTP component set to ""redirect"", feel free to change this. + +-------------------------- +**Version**: 1.20.x +**Severity**: minor",1321628700,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_description,"MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** `raphael.droz` + +**Description:** +If +* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), +* and you don't have curl (should I ?) + +=> then you're getting failures because wfIniGetBool() is not yet defined + +There should be a way to require(GlobalFunctions.php) in such a case. + +HTTP component set to ""redirect"", feel free to change this. + +-------------------------- +**Version**: 1.20.x +**Severity**: minor","MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** CODE + +**Description:** +If +* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), +* and you don't have curl (should I ?) + +=> then you're getting failures because wfIniGetBool() is not yet defined + +There should be a way to require(GlobalFunctions.php) in such a case. + +HTTP component set to ""redirect"", feel free to change this. + +-------------------------- +**Version**: 1.20.x +**Severity**: minor",Needs Triage,90,1321890399,NA,declined,TRUE,c2,1,FALSE,FALSE,-93,TRUE,"['MWHttpRequest may have to require_once() GlobalFunctions.php.', ""**Author:** CODE\n\n**Description:**\nIf\n* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension),\n* and you don't have curl (should I ?)"", ""=> then you're getting failures because wfIniGetBool() is not yet defined\n\nThere should be a way to require(GlobalFunctions.php) in such a case."", 'HTTP component set to ""redirect"", feel free to change this.', '--------------------------\n**Version**: 1.20.x\n**Severity**: minor']",TRUE,1,--------------------------\n**Version**: 1.20.x\n**Severity**: minor,OBSERVED BUG BEHAVIOR,, +16731,MWHttpRequest may have to require_once() GlobalFunctions.php,"**Author:** `raphael.droz` + +**Description:** +If +* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), +* and you don't have curl (should I ?) + +=> then you're getting failures because wfIniGetBool() is not yet defined + +There should be a way to require(GlobalFunctions.php) in such a case. + +HTTP component set to ""redirect"", feel free to change this. + +-------------------------- +**Version**: 1.20.x +**Severity**: minor",1321628700,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_description,"MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** `raphael.droz` + +**Description:** +If +* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), +* and you don't have curl (should I ?) + +=> then you're getting failures because wfIniGetBool() is not yet defined + +There should be a way to require(GlobalFunctions.php) in such a case. + +HTTP component set to ""redirect"", feel free to change this. + +-------------------------- +**Version**: 1.20.x +**Severity**: minor","MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** CODE + +**Description:** +If +* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), +* and you don't have curl (should I ?) + +=> then you're getting failures because wfIniGetBool() is not yet defined + +There should be a way to require(GlobalFunctions.php) in such a case. + +HTTP component set to ""redirect"", feel free to change this. + +-------------------------- +**Version**: 1.20.x +**Severity**: minor",Needs Triage,90,1321890399,NA,declined,TRUE,c2,1,FALSE,FALSE,-93,TRUE,"['MWHttpRequest may have to require_once() GlobalFunctions.php.', ""**Author:** CODE\n\n**Description:**\nIf\n* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension),\n* and you don't have curl (should I ?)"", ""=> then you're getting failures because wfIniGetBool() is not yet defined\n\nThere should be a way to require(GlobalFunctions.php) in such a case."", 'HTTP component set to ""redirect"", feel free to change this.', '--------------------------\n**Version**: 1.20.x\n**Severity**: minor']",TRUE,1,"**Author:** CODE\n\n**Description:**\nIf\n* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension),\n* and you don't have curl (should I ?)",BUG REPRODUCTION,, +16731,MWHttpRequest may have to require_once() GlobalFunctions.php,"**Author:** `raphael.droz` + +**Description:** +If +* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), +* and you don't have curl (should I ?) + +=> then you're getting failures because wfIniGetBool() is not yet defined + +There should be a way to require(GlobalFunctions.php) in such a case. + +HTTP component set to ""redirect"", feel free to change this. + +-------------------------- +**Version**: 1.20.x +**Severity**: minor",1321628700,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_description,"MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** `raphael.droz` + +**Description:** +If +* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), +* and you don't have curl (should I ?) + +=> then you're getting failures because wfIniGetBool() is not yet defined + +There should be a way to require(GlobalFunctions.php) in such a case. + +HTTP component set to ""redirect"", feel free to change this. + +-------------------------- +**Version**: 1.20.x +**Severity**: minor","MWHttpRequest may have to require_once() GlobalFunctions.php./n/n**Author:** CODE + +**Description:** +If +* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension), +* and you don't have curl (should I ?) + +=> then you're getting failures because wfIniGetBool() is not yet defined + +There should be a way to require(GlobalFunctions.php) in such a case. + +HTTP component set to ""redirect"", feel free to change this. + +-------------------------- +**Version**: 1.20.x +**Severity**: minor",Needs Triage,90,1321890399,NA,declined,TRUE,c2,1,FALSE,FALSE,-93,TRUE,"['MWHttpRequest may have to require_once() GlobalFunctions.php.', ""**Author:** CODE\n\n**Description:**\nIf\n* you attempt to MWHttpRequest::factory() (eg, during bootstrap, from an extension),\n* and you don't have curl (should I ?)"", ""=> then you're getting failures because wfIniGetBool() is not yet defined\n\nThere should be a way to require(GlobalFunctions.php) in such a case."", 'HTTP component set to ""redirect"", feel free to change this.', '--------------------------\n**Version**: 1.20.x\n**Severity**: minor']",TRUE,1,then you're getting failures because wfIniGetBool() is not yet defined\n\nThere should be a way to require(GlobalFunctions.php) in such a case.,EXPECTED BEHAVIOR,, +16732,MWHttpRequest may have to require_once() GlobalFunctions.php,"**raphael.droz** wrote: + +I need MWHttpRequest during Auth::authenticate. +Just tested and it happens that wfIniGetBool *is* defined at this time. +(thus I'm fine with WONTFIX) + +*but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.",1321656772,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,"**raphael.droz** wrote: + +I need MWHttpRequest during Auth::authenticate. +Just tested and it happens that wfIniGetBool *is* defined at this time. +(thus I'm fine with WONTFIX) + +*but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.","**raphael.droz** wrote: + +I need MWHttpRequest during Auth::authenticate. +Just tested and it happens that wfIniGetBool *is* defined at this time. +(thus I'm fine with WONTFIX) + +*but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-93,TRUE,"['**raphael.droz** wrote:\n\nI need MWHttpRequest during Auth::authenticate.', 'Just tested and it happens that wfIniGetBool *is* defined at this time.', ""(thus I'm fine with WONTFIX)\n\n*but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.""]",NA,1,**raphael.droz** wrote:\n\nI need MWHttpRequest during Auth::authenticate.,INVESTIGATION AND EXPLORATION,, +16732,MWHttpRequest may have to require_once() GlobalFunctions.php,"**raphael.droz** wrote: + +I need MWHttpRequest during Auth::authenticate. +Just tested and it happens that wfIniGetBool *is* defined at this time. +(thus I'm fine with WONTFIX) + +*but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.",1321656772,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,"**raphael.droz** wrote: + +I need MWHttpRequest during Auth::authenticate. +Just tested and it happens that wfIniGetBool *is* defined at this time. +(thus I'm fine with WONTFIX) + +*but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.","**raphael.droz** wrote: + +I need MWHttpRequest during Auth::authenticate. +Just tested and it happens that wfIniGetBool *is* defined at this time. +(thus I'm fine with WONTFIX) + +*but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-93,TRUE,"['**raphael.droz** wrote:\n\nI need MWHttpRequest during Auth::authenticate.', 'Just tested and it happens that wfIniGetBool *is* defined at this time.', ""(thus I'm fine with WONTFIX)\n\n*but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.""]",NA,1,Just tested and it happens that wfIniGetBool *is* defined at this time.,BUG REPRODUCTION ,, +16732,MWHttpRequest may have to require_once() GlobalFunctions.php,"**raphael.droz** wrote: + +I need MWHttpRequest during Auth::authenticate. +Just tested and it happens that wfIniGetBool *is* defined at this time. +(thus I'm fine with WONTFIX) + +*but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.",1321656772,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,"**raphael.droz** wrote: + +I need MWHttpRequest during Auth::authenticate. +Just tested and it happens that wfIniGetBool *is* defined at this time. +(thus I'm fine with WONTFIX) + +*but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.","**raphael.droz** wrote: + +I need MWHttpRequest during Auth::authenticate. +Just tested and it happens that wfIniGetBool *is* defined at this time. +(thus I'm fine with WONTFIX) + +*but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-93,TRUE,"['**raphael.droz** wrote:\n\nI need MWHttpRequest during Auth::authenticate.', 'Just tested and it happens that wfIniGetBool *is* defined at this time.', ""(thus I'm fine with WONTFIX)\n\n*but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.""]",NA,1,(thus I'm fine with WONTFIX)\n\n*but* if I wanted to use it during the *constructor* of my Auth plugin it would have failed.,ACTION ON ISSUE,, +16733,MWHttpRequest may have to require_once() GlobalFunctions.php,You'll want to create a $wgAuth instance I think (or should even that not run until wgExtensionFunctions time? quite possibly) but you definitely should NOT be actively attempting to use framework features as nothing may be set up yet.,1321644785,PHID-USER-yek7ymogrv4qc67oilhf,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,You'll want to create a $wgAuth instance I think (or should even that not run until wgExtensionFunctions time? quite possibly) but you definitely should NOT be actively attempting to use framework features as nothing may be set up yet.,You'll want to create a $wgAuth instance I think (or should even that not run until wgExtensionFunctions time? quite possibly) but you definitely should NOT be actively attempting to use framework features as nothing may be set up yet.,NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-93,TRUE,"[""You'll want to create a $wgAuth instance I think (or should even that not run until wgExtensionFunctions time?"", 'quite possibly) but you definitely should NOT be actively attempting to use framework features as nothing may be set up yet.']",NA,1,You'll want to create a $wgAuth instance I think (or should even that not run until wgExtensionFunctions time?,SOLUTION USAGE,, +16734,MWHttpRequest may have to require_once() GlobalFunctions.php,"**raphael.droz** wrote: + +But shouldn't Auth-related extensions be used in LocalSettings in order to setup wgAuth instead of using wgExtensionFunctions ? +If so, then does it mean that such extension can't rely on MW HTTP facilities ?",1321634939,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,"**raphael.droz** wrote: + +But shouldn't Auth-related extensions be used in LocalSettings in order to setup wgAuth instead of using wgExtensionFunctions ? +If so, then does it mean that such extension can't rely on MW HTTP facilities ?","**raphael.droz** wrote: + +But shouldn't Auth-related extensions be used in LocalSettings in order to setup wgAuth instead of using wgExtensionFunctions ? +If so, then does it mean that such extension can't rely on MW HTTP facilities ?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-93,TRUE,"[""**raphael.droz** wrote:\n\nBut shouldn't Auth-related extensions be used in LocalSettings in order to setup wgAuth instead of using wgExtensionFunctions ?"", ""If so, then does it mean that such extension can't rely on MW HTTP facilities ?""]",NA,1,**raphael.droz** wrote:\n\nBut shouldn't Auth-related extensions be used in LocalSettings in order to setup wgAuth instead of using wgExtensionFunctions ?,SOLUTION DISCUSSION,, +16734,MWHttpRequest may have to require_once() GlobalFunctions.php,"**raphael.droz** wrote: + +But shouldn't Auth-related extensions be used in LocalSettings in order to setup wgAuth instead of using wgExtensionFunctions ? +If so, then does it mean that such extension can't rely on MW HTTP facilities ?",1321634939,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,"**raphael.droz** wrote: + +But shouldn't Auth-related extensions be used in LocalSettings in order to setup wgAuth instead of using wgExtensionFunctions ? +If so, then does it mean that such extension can't rely on MW HTTP facilities ?","**raphael.droz** wrote: + +But shouldn't Auth-related extensions be used in LocalSettings in order to setup wgAuth instead of using wgExtensionFunctions ? +If so, then does it mean that such extension can't rely on MW HTTP facilities ?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-93,TRUE,"[""**raphael.droz** wrote:\n\nBut shouldn't Auth-related extensions be used in LocalSettings in order to setup wgAuth instead of using wgExtensionFunctions ?"", ""If so, then does it mean that such extension can't rely on MW HTTP facilities ?""]",NA,1,"If so, then does it mean that such extension can't rely on MW HTTP facilities ?",INVESTIGATION AND EXPLORATION,, +16735,MWHttpRequest may have to require_once() GlobalFunctions.php,"Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.",1321629327,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,"Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.","Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-93,TRUE,"['Are you using MWHttpRequest::factory() directly in the extension setup code?', 'If so, suggest WONTFIX.', ""It's expected that not everything are initialized at that time."", ""There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.""]",NA,1,Are you using MWHttpRequest::factory() directly in the extension setup code?,INVESTIGATION AND EXPLORATION,, +16735,MWHttpRequest may have to require_once() GlobalFunctions.php,"Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.",1321629327,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,"Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.","Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-93,TRUE,"['Are you using MWHttpRequest::factory() directly in the extension setup code?', 'If so, suggest WONTFIX.', ""It's expected that not everything are initialized at that time."", ""There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.""]",NA,1,"If so, suggest WONTFIX.",ACTION ON ISSUE,, +16735,MWHttpRequest may have to require_once() GlobalFunctions.php,"Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.",1321629327,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,"Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.","Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-93,TRUE,"['Are you using MWHttpRequest::factory() directly in the extension setup code?', 'If so, suggest WONTFIX.', ""It's expected that not everything are initialized at that time."", ""There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.""]",NA,1,It's expected that not everything are initialized at that time.,EXPECTED BEHAVIOR,, +16735,MWHttpRequest may have to require_once() GlobalFunctions.php,"Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.",1321629327,PHID-USER-zjzhrhmn36icnzbckqy4,PHID-TASK-okehmm44iuapntenizn5,task_subcomment,"Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.","Are you using MWHttpRequest::factory() directly in the extension setup code? If so, suggest WONTFIX. It's expected that not everything are initialized at that time. There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-93,TRUE,"['Are you using MWHttpRequest::factory() directly in the extension setup code?', 'If so, suggest WONTFIX.', ""It's expected that not everything are initialized at that time."", ""There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.""]",NA,1,There's also a [[mw:Manual:$wgExtensionFunctions]] for code which requires a fully initialized environment.,INVESTIGATION AND EXPLORATION,, +16809,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git + +fails with error: + +RPC failed; result=22, HTTP code = 500 + +Related bugs and mailing list posts: +* https://code.google.com/p/gerrit/issues/detail?id=769 +* http://www.gossamer-threads.com/lists/wiki/wikitech/278195 +* http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 +* http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 + +Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. + +If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. + +Should your server's memory size be increased ? + +-------------------------- +**Version**: unspecified +**Severity**: major",1334342220,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_description,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git + +fails with error: + +RPC failed; result=22, HTTP code = 500 + +Related bugs and mailing list posts: +* https://code.google.com/p/gerrit/issues/detail?id=769 +* http://www.gossamer-threads.com/lists/wiki/wikitech/278195 +* http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 +* http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 + +Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. + +If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. + +Should your server's memory size be increased ? + +-------------------------- +**Version**: unspecified +**Severity**: major","Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 URL + +fails with error: + +RPC failed; result=22, HTTP code = 500 + +Related bugs and mailing list posts: +* URL +* URL +* URL +* URL + +Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. + +If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. + +Should your server's memory size be increased ? + +-------------------------- +**Version**: unspecified +**Severity**: major",High,80,1336156231,NA,resolved,TRUE,c2,1,FALSE,FALSE,-72,TRUE,"['Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500.', '$ git clone --depth 1 URL \n\nfails with error: \n\nRPC failed; result=22, HTTP code = 500\n\nRelated bugs and mailing list posts:\n* URL\n* URL\n* URL\n* URL\n\nTested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6.', ""If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major."", ""Should your server's memory size be increased ?"", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,1,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500.",OBSERVED BUG BEHAVIOR ,, +16809,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git + +fails with error: + +RPC failed; result=22, HTTP code = 500 + +Related bugs and mailing list posts: +* https://code.google.com/p/gerrit/issues/detail?id=769 +* http://www.gossamer-threads.com/lists/wiki/wikitech/278195 +* http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 +* http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 + +Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. + +If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. + +Should your server's memory size be increased ? + +-------------------------- +**Version**: unspecified +**Severity**: major",1334342220,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_description,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git + +fails with error: + +RPC failed; result=22, HTTP code = 500 + +Related bugs and mailing list posts: +* https://code.google.com/p/gerrit/issues/detail?id=769 +* http://www.gossamer-threads.com/lists/wiki/wikitech/278195 +* http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 +* http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 + +Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. + +If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. + +Should your server's memory size be increased ? + +-------------------------- +**Version**: unspecified +**Severity**: major","Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 URL + +fails with error: + +RPC failed; result=22, HTTP code = 500 + +Related bugs and mailing list posts: +* URL +* URL +* URL +* URL + +Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. + +If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. + +Should your server's memory size be increased ? + +-------------------------- +**Version**: unspecified +**Severity**: major",High,80,1336156231,NA,resolved,TRUE,c2,1,FALSE,FALSE,-72,TRUE,"['Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500.', '$ git clone --depth 1 URL \n\nfails with error: \n\nRPC failed; result=22, HTTP code = 500\n\nRelated bugs and mailing list posts:\n* URL\n* URL\n* URL\n* URL\n\nTested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6.', ""If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major."", ""Should your server's memory size be increased ?"", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,1,"$ git clone --depth 1 URL \n\nfails with error: \n\nRPC failed; result=22, HTTP code = 500\n\nRelated bugs and mailing list posts:\n* URL\n* URL\n* URL\n* URL\n\nTested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6.",OBSERVED BUG BEHAVIOR ,, +16809,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git + +fails with error: + +RPC failed; result=22, HTTP code = 500 + +Related bugs and mailing list posts: +* https://code.google.com/p/gerrit/issues/detail?id=769 +* http://www.gossamer-threads.com/lists/wiki/wikitech/278195 +* http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 +* http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 + +Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. + +If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. + +Should your server's memory size be increased ? + +-------------------------- +**Version**: unspecified +**Severity**: major",1334342220,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_description,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git + +fails with error: + +RPC failed; result=22, HTTP code = 500 + +Related bugs and mailing list posts: +* https://code.google.com/p/gerrit/issues/detail?id=769 +* http://www.gossamer-threads.com/lists/wiki/wikitech/278195 +* http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 +* http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 + +Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. + +If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. + +Should your server's memory size be increased ? + +-------------------------- +**Version**: unspecified +**Severity**: major","Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 URL + +fails with error: + +RPC failed; result=22, HTTP code = 500 + +Related bugs and mailing list posts: +* URL +* URL +* URL +* URL + +Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. + +If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. + +Should your server's memory size be increased ? + +-------------------------- +**Version**: unspecified +**Severity**: major",High,80,1336156231,NA,resolved,TRUE,c2,1,FALSE,FALSE,-72,TRUE,"['Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500.', '$ git clone --depth 1 URL \n\nfails with error: \n\nRPC failed; result=22, HTTP code = 500\n\nRelated bugs and mailing list posts:\n* URL\n* URL\n* URL\n* URL\n\nTested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6.', ""If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major."", ""Should your server's memory size be increased ?"", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,1,--------------------------\n**Version**: unspecified\n**Severity**: major,OBSERVED BUG BEHAVIOR ,, +16809,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git + +fails with error: + +RPC failed; result=22, HTTP code = 500 + +Related bugs and mailing list posts: +* https://code.google.com/p/gerrit/issues/detail?id=769 +* http://www.gossamer-threads.com/lists/wiki/wikitech/278195 +* http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 +* http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 + +Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. + +If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. + +Should your server's memory size be increased ? + +-------------------------- +**Version**: unspecified +**Severity**: major",1334342220,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_description,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git + +fails with error: + +RPC failed; result=22, HTTP code = 500 + +Related bugs and mailing list posts: +* https://code.google.com/p/gerrit/issues/detail?id=769 +* http://www.gossamer-threads.com/lists/wiki/wikitech/278195 +* http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 +* http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 + +Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. + +If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. + +Should your server's memory size be increased ? + +-------------------------- +**Version**: unspecified +**Severity**: major","Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 URL + +fails with error: + +RPC failed; result=22, HTTP code = 500 + +Related bugs and mailing list posts: +* URL +* URL +* URL +* URL + +Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. + +If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. + +Should your server's memory size be increased ? + +-------------------------- +**Version**: unspecified +**Severity**: major",High,80,1336156231,NA,resolved,TRUE,c2,1,FALSE,FALSE,-72,TRUE,"['Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500.', '$ git clone --depth 1 URL \n\nfails with error: \n\nRPC failed; result=22, HTTP code = 500\n\nRelated bugs and mailing list posts:\n* URL\n* URL\n* URL\n* URL\n\nTested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6.', ""If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major."", ""Should your server's memory size be increased ?"", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,1,"If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major.",MOTIVATION,, +16809,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git + +fails with error: + +RPC failed; result=22, HTTP code = 500 + +Related bugs and mailing list posts: +* https://code.google.com/p/gerrit/issues/detail?id=769 +* http://www.gossamer-threads.com/lists/wiki/wikitech/278195 +* http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 +* http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 + +Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. + +If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. + +Should your server's memory size be increased ? + +-------------------------- +**Version**: unspecified +**Severity**: major",1334342220,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_description,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git + +fails with error: + +RPC failed; result=22, HTTP code = 500 + +Related bugs and mailing list posts: +* https://code.google.com/p/gerrit/issues/detail?id=769 +* http://www.gossamer-threads.com/lists/wiki/wikitech/278195 +* http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60018/focus=60060 +* http://comments.gmane.org/gmane.comp.desktop.trinity.devel/3757 + +Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. + +If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. + +Should your server's memory size be increased ? + +-------------------------- +**Version**: unspecified +**Severity**: major","Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500./n/n$ git clone --depth 1 URL + +fails with error: + +RPC failed; result=22, HTTP code = 500 + +Related bugs and mailing list posts: +* URL +* URL +* URL +* URL + +Tested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6. + +If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major. + +Should your server's memory size be increased ? + +-------------------------- +**Version**: unspecified +**Severity**: major",High,80,1336156231,NA,resolved,TRUE,c2,1,FALSE,FALSE,-72,TRUE,"['Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500.', '$ git clone --depth 1 URL \n\nfails with error: \n\nRPC failed; result=22, HTTP code = 500\n\nRelated bugs and mailing list posts:\n* URL\n* URL\n* URL\n* URL\n\nTested (not working) with git versions 1.7.1, 1.7.9.2, 1.7.9.6.', ""If the --depth option really crashes the git server, then sending this command could be possibly used for a DoS attack -> That's why I set severity to major."", ""Should your server's memory size be increased ?"", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,1,Should your server's memory size be increased ?,INVESTIGATION AND EXPLORATION,, +16810,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","for info only (2012-05-19) ++ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git ==> 84M ++ git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git ==> 184M",1337408281,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"for info only (2012-05-19) ++ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git ==> 84M ++ git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git ==> 184M","for info only (2012-05-19) ++ git clone --depth 1 URL ==> 84M ++ git clone URL ==> 184M",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-67,TRUE,['for info only (2012-05-19)\n+ git clone --depth 1 URL ==> 84M\n+ git clone URL ==> 184M'],NA,1,for info only (2012-05-19)\n+ git clone --depth 1 URL ==> 84M\n+ git clone URL ==> 184M,INVESTIGATION AND EXPLORATION,, +16811,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","some more examples, where shallow clones are smaller: + +git clone git://gitorious.org/owncloud/owncloud.git ==> 39M + +git clone --depth 1 git://gitorious.org/owncloud/owncloud.git ==> 34M + + + +git clone https://github.com/Pita/etherpad-lite.git ==> 4,8M + +git clone --depth 1 https://github.com/Pita/etherpad-lite.git ==> 2,6M",1336159366,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"some more examples, where shallow clones are smaller: + +git clone git://gitorious.org/owncloud/owncloud.git ==> 39M + +git clone --depth 1 git://gitorious.org/owncloud/owncloud.git ==> 34M + + + +git clone https://github.com/Pita/etherpad-lite.git ==> 4,8M + +git clone --depth 1 https://github.com/Pita/etherpad-lite.git ==> 2,6M","some more examples, where shallow clones are smaller: + +git clone git://gitorious.org/owncloud/owncloud.git ==> 39M + +git clone --depth 1 git://gitorious.org/owncloud/owncloud.git ==> 34M + + + +git clone URL ==> 4,8M + +git clone --depth 1 URL ==> 2,6M",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-69,TRUE,"['some more examples, where shallow clones are smaller:\n\ngit clone git://gitorious.org/owncloud/owncloud.git ==> 39M\n\ngit clone --depth 1 git://gitorious.org/owncloud/owncloud.git ==> 34M\n\n\n\ngit clone URL ==> 4,8M\n\ngit clone --depth 1 URL ==> 2,6M']",NA,1,"some more examples, where shallow clones are smaller:\n\ngit clone git://gitorious.org/owncloud/owncloud.git ==> 39M\n\ngit clone --depth 1 git://gitorious.org/owncloud/owncloud.git ==> 34M\n\n\n\ngit clone URL ==> 4,8M\n\ngit clone --depth 1 URL ==> 2,6M",BUG REPRODUCTION,, +16812,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","Hmmmm, strange is my following observation (each clone into a fresh directory): + +git clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 178 MB + +git clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 360 MB [sic] + +==> Shallow clone needs 360 MB ??? I am puzzled.",1336158461,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"Hmmmm, strange is my following observation (each clone into a fresh directory): + +git clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 178 MB + +git clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 360 MB [sic] + +==> Shallow clone needs 360 MB ??? I am puzzled.","Hmmmm, strange is my following observation (each clone into a fresh directory): + +git clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 178 MB + +git clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 360 MB [sic] + +==> Shallow clone needs 360 MB ??? I am puzzled.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-69,TRUE,"['Hmmmm, strange is my following observation (each clone into a fresh directory):\n\ngit clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 178 MB\n\ngit clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 360 MB [sic]\n\n==> Shallow clone needs 360 MB ?', '??', 'I am puzzled.']",NA,1,"Hmmmm, strange is my following observation (each clone into a fresh directory):\n\ngit clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .",INVESTIGATION AND EXPLORATION,, +16812,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","Hmmmm, strange is my following observation (each clone into a fresh directory): + +git clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 178 MB + +git clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 360 MB [sic] + +==> Shallow clone needs 360 MB ??? I am puzzled.",1336158461,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"Hmmmm, strange is my following observation (each clone into a fresh directory): + +git clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 178 MB + +git clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 360 MB [sic] + +==> Shallow clone needs 360 MB ??? I am puzzled.","Hmmmm, strange is my following observation (each clone into a fresh directory): + +git clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 178 MB + +git clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 360 MB [sic] + +==> Shallow clone needs 360 MB ??? I am puzzled.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-69,TRUE,"['Hmmmm, strange is my following observation (each clone into a fresh directory):\n\ngit clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 178 MB\n\ngit clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 360 MB [sic]\n\n==> Shallow clone needs 360 MB ?', '??', 'I am puzzled.']",NA,1,178 MB\n\ngit clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .,INVESTIGATION AND EXPLORATION,, +16812,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","Hmmmm, strange is my following observation (each clone into a fresh directory): + +git clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 178 MB + +git clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 360 MB [sic] + +==> Shallow clone needs 360 MB ??? I am puzzled.",1336158461,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"Hmmmm, strange is my following observation (each clone into a fresh directory): + +git clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 178 MB + +git clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 360 MB [sic] + +==> Shallow clone needs 360 MB ??? I am puzzled.","Hmmmm, strange is my following observation (each clone into a fresh directory): + +git clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 178 MB + +git clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 360 MB [sic] + +==> Shallow clone needs 360 MB ??? I am puzzled.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-69,TRUE,"['Hmmmm, strange is my following observation (each clone into a fresh directory):\n\ngit clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 178 MB\n\ngit clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 360 MB [sic]\n\n==> Shallow clone needs 360 MB ?', '??', 'I am puzzled.']",NA,1,360 MB [sic]\n\n==> Shallow clone needs 360 MB ?,INVESTIGATION AND EXPLORATION,, +16812,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","Hmmmm, strange is my following observation (each clone into a fresh directory): + +git clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 178 MB + +git clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 360 MB [sic] + +==> Shallow clone needs 360 MB ??? I am puzzled.",1336158461,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"Hmmmm, strange is my following observation (each clone into a fresh directory): + +git clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 178 MB + +git clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 360 MB [sic] + +==> Shallow clone needs 360 MB ??? I am puzzled.","Hmmmm, strange is my following observation (each clone into a fresh directory): + +git clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 178 MB + +git clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 360 MB [sic] + +==> Shallow clone needs 360 MB ??? I am puzzled.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-69,TRUE,"['Hmmmm, strange is my following observation (each clone into a fresh directory):\n\ngit clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 178 MB\n\ngit clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 360 MB [sic]\n\n==> Shallow clone needs 360 MB ?', '??', 'I am puzzled.']",NA,1,??,SOCIAL CONVERSATION,, +16812,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","Hmmmm, strange is my following observation (each clone into a fresh directory): + +git clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 178 MB + +git clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 360 MB [sic] + +==> Shallow clone needs 360 MB ??? I am puzzled.",1336158461,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"Hmmmm, strange is my following observation (each clone into a fresh directory): + +git clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 178 MB + +git clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 360 MB [sic] + +==> Shallow clone needs 360 MB ??? I am puzzled.","Hmmmm, strange is my following observation (each clone into a fresh directory): + +git clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 178 MB + +git clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git +du -h . +==> 360 MB [sic] + +==> Shallow clone needs 360 MB ??? I am puzzled.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-69,TRUE,"['Hmmmm, strange is my following observation (each clone into a fresh directory):\n\ngit clone ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 178 MB\n\ngit clone --depth 1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git\ndu -h .', '==> 360 MB [sic]\n\n==> Shallow clone needs 360 MB ?', '??', 'I am puzzled.']",NA,1,I am puzzled.,SOCIAL CONVERSATION,, +16813,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","Works for me with the 2.3 upgrade: + +$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git test-shallow-clone +Cloning into 'test-shallow-clone'... +remote: Counting objects: 31773, done +remote: Finding sources: 100% (31773/31773) +remote: Total 31773 (delta 12783), reused 16435 (delta 12783) +Receiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done. +Resolving deltas: 100% (12783/12783), done. + +Marking FIXED.",1336156231,PHID-USER-oetk6bbl6omm354ejz3b,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"Works for me with the 2.3 upgrade: + +$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git test-shallow-clone +Cloning into 'test-shallow-clone'... +remote: Counting objects: 31773, done +remote: Finding sources: 100% (31773/31773) +remote: Total 31773 (delta 12783), reused 16435 (delta 12783) +Receiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done. +Resolving deltas: 100% (12783/12783), done. + +Marking FIXED.","Works for me with the 2.3 upgrade: + +$ git clone --depth 1 URL test-shallow-clone +Cloning into 'test-shallow-clone'... +remote: Counting objects: 31773, done +remote: Finding sources: 100% (31773/31773) +remote: Total 31773 (delta 12783), reused 16435 (delta 12783) +Receiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done. +Resolving deltas: 100% (12783/12783), done. + +Marking FIXED.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-69,TRUE,"[""Works for me with the 2.3 upgrade:\n\n$ git clone --depth 1 URL test-shallow-clone\nCloning into 'test-shallow-clone'...\nremote: Counting objects: 31773, done\nremote: Finding sources: 100% (31773/31773)\nremote: Total 31773 (delta 12783), reused 16435 (delta 12783)\nReceiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done."", 'Resolving deltas: 100% (12783/12783), done.', 'Marking FIXED.']",NA,1,"Resolving deltas: 100% (12783/12783), done.",TASK PROGRESS,, +16813,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","Works for me with the 2.3 upgrade: + +$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git test-shallow-clone +Cloning into 'test-shallow-clone'... +remote: Counting objects: 31773, done +remote: Finding sources: 100% (31773/31773) +remote: Total 31773 (delta 12783), reused 16435 (delta 12783) +Receiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done. +Resolving deltas: 100% (12783/12783), done. + +Marking FIXED.",1336156231,PHID-USER-oetk6bbl6omm354ejz3b,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"Works for me with the 2.3 upgrade: + +$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git test-shallow-clone +Cloning into 'test-shallow-clone'... +remote: Counting objects: 31773, done +remote: Finding sources: 100% (31773/31773) +remote: Total 31773 (delta 12783), reused 16435 (delta 12783) +Receiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done. +Resolving deltas: 100% (12783/12783), done. + +Marking FIXED.","Works for me with the 2.3 upgrade: + +$ git clone --depth 1 URL test-shallow-clone +Cloning into 'test-shallow-clone'... +remote: Counting objects: 31773, done +remote: Finding sources: 100% (31773/31773) +remote: Total 31773 (delta 12783), reused 16435 (delta 12783) +Receiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done. +Resolving deltas: 100% (12783/12783), done. + +Marking FIXED.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-69,TRUE,"[""Works for me with the 2.3 upgrade:\n\n$ git clone --depth 1 URL test-shallow-clone\nCloning into 'test-shallow-clone'...\nremote: Counting objects: 31773, done\nremote: Finding sources: 100% (31773/31773)\nremote: Total 31773 (delta 12783), reused 16435 (delta 12783)\nReceiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done."", 'Resolving deltas: 100% (12783/12783), done.', 'Marking FIXED.']",NA,1,Marking FIXED.,ACTION ON ISSSUE,, +16813,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","Works for me with the 2.3 upgrade: + +$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git test-shallow-clone +Cloning into 'test-shallow-clone'... +remote: Counting objects: 31773, done +remote: Finding sources: 100% (31773/31773) +remote: Total 31773 (delta 12783), reused 16435 (delta 12783) +Receiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done. +Resolving deltas: 100% (12783/12783), done. + +Marking FIXED.",1336156231,PHID-USER-oetk6bbl6omm354ejz3b,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"Works for me with the 2.3 upgrade: + +$ git clone --depth 1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git test-shallow-clone +Cloning into 'test-shallow-clone'... +remote: Counting objects: 31773, done +remote: Finding sources: 100% (31773/31773) +remote: Total 31773 (delta 12783), reused 16435 (delta 12783) +Receiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done. +Resolving deltas: 100% (12783/12783), done. + +Marking FIXED.","Works for me with the 2.3 upgrade: + +$ git clone --depth 1 URL test-shallow-clone +Cloning into 'test-shallow-clone'... +remote: Counting objects: 31773, done +remote: Finding sources: 100% (31773/31773) +remote: Total 31773 (delta 12783), reused 16435 (delta 12783) +Receiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done. +Resolving deltas: 100% (12783/12783), done. + +Marking FIXED.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-69,TRUE,"[""Works for me with the 2.3 upgrade:\n\n$ git clone --depth 1 URL test-shallow-clone\nCloning into 'test-shallow-clone'...\nremote: Counting objects: 31773, done\nremote: Finding sources: 100% (31773/31773)\nremote: Total 31773 (delta 12783), reused 16435 (delta 12783)\nReceiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done."", 'Resolving deltas: 100% (12783/12783), done.', 'Marking FIXED.']",NA,1,"Works for me with the 2.3 upgrade:\n\n$ git clone --depth 1 URL test-shallow-clone\nCloning into 'test-shallow-clone'...\nremote: Counting objects: 31773, done\nremote: Finding sources: 100% (31773/31773)\nremote: Total 31773 (delta 12783), reused 16435 (delta 12783)\nReceiving objects: 100% (31773/31773), 291.11 MiB | 1.82 MiB/s, done.",TESTING,, +16814,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","(In reply to comment #2) +> And for the record, it doesn't *crash* gerrit. It hits an exception that's +> logged and it fails for the user, but it doesn't *crash* + +Thanks for investigating this in the logs, and for reporting!",1334344512,PHID-USER-ppvnwr24o32pux3le5ov,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"(In reply to comment #2) +> And for the record, it doesn't *crash* gerrit. It hits an exception that's +> logged and it fails for the user, but it doesn't *crash* + +Thanks for investigating this in the logs, and for reporting!","(In reply to comment #2) +QUOTE +QUOTE + +Thanks for investigating this in the logs, and for reporting!",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-72,TRUE,"['(In reply to comment #2)\nQUOTE\nQUOTE\n\nThanks for investigating this in the logs, and for reporting!']",NA,1,"(In reply to comment #2)\nQUOTE\nQUOTE\n\nThanks for investigating this in the logs, and for reporting!",SOCIAL CONVERSATION,, +16815,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","And for the record, it doesn't *crash* gerrit. It hits an exception that's logged and it fails for the user, but it doesn't *crash*",1334344084,PHID-USER-oetk6bbl6omm354ejz3b,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"And for the record, it doesn't *crash* gerrit. It hits an exception that's logged and it fails for the user, but it doesn't *crash*","And for the record, it doesn't *crash* gerrit. It hits an exception that's logged and it fails for the user, but it doesn't *crash*",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-72,TRUE,"[""And for the record, it doesn't *crash* gerrit."", ""It hits an exception that's logged and it fails for the user, but it doesn't *crash*""]",NA,1,"And for the record, it doesn't *crash* gerrit.",INVESTIGATION AND EXPLORATION,, +16815,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","And for the record, it doesn't *crash* gerrit. It hits an exception that's logged and it fails for the user, but it doesn't *crash*",1334344084,PHID-USER-oetk6bbl6omm354ejz3b,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"And for the record, it doesn't *crash* gerrit. It hits an exception that's logged and it fails for the user, but it doesn't *crash*","And for the record, it doesn't *crash* gerrit. It hits an exception that's logged and it fails for the user, but it doesn't *crash*",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-72,TRUE,"[""And for the record, it doesn't *crash* gerrit."", ""It hits an exception that's logged and it fails for the user, but it doesn't *crash*""]",NA,1,"It hits an exception that's logged and it fails for the user, but it doesn't *crash*",INVESTIGATION AND EXPLORATION,, +16816,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","If this is indeed issue 769, I suspect it will be fixed by the 2.3 upgrade (since they upgraded JGit to 1.1). + +We can test again then.",1334343935,PHID-USER-oetk6bbl6omm354ejz3b,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"If this is indeed issue 769, I suspect it will be fixed by the 2.3 upgrade (since they upgraded JGit to 1.1). + +We can test again then.","If this is indeed issue 769, I suspect it will be fixed by the 2.3 upgrade (since they upgraded JGit to 1.1). + +We can test again then.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-72,TRUE,"['If this is indeed issue 769, I suspect it will be fixed by the 2.3 upgrade (since they upgraded JGit to 1.1).', 'We can test again then.']",NA,1,"If this is indeed issue 769, I suspect it will be fixed by the 2.3 upgrade (since they upgraded JGit to 1.1).",FUTURE PLANS,, +16816,"Shallow clones fail with errors: git clone --depth 1 fails with error: RPC failed; result=22, HTTP code = 500","If this is indeed issue 769, I suspect it will be fixed by the 2.3 upgrade (since they upgraded JGit to 1.1). + +We can test again then.",1334343935,PHID-USER-oetk6bbl6omm354ejz3b,PHID-TASK-usesppigdvp4zycaytoi,task_subcomment,"If this is indeed issue 769, I suspect it will be fixed by the 2.3 upgrade (since they upgraded JGit to 1.1). + +We can test again then.","If this is indeed issue 769, I suspect it will be fixed by the 2.3 upgrade (since they upgraded JGit to 1.1). + +We can test again then.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-72,TRUE,"['If this is indeed issue 769, I suspect it will be fixed by the 2.3 upgrade (since they upgraded JGit to 1.1).', 'We can test again then.']",NA,1,We can test again then.,TESTING,, +16857,NewUserMessage extensions breaks login,"I installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker",1326123000,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_description,"NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker","NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker",High,80,1350964208,NA,declined,TRUE,c2,1,FALSE,FALSE,-86,TRUE,"['NewUserMessage extensions breaks login.', 'I installed this extension and it works fine for a new user signing up, but it breaks login for existing users.', 'Logging in as an existing user generates the error:\n\nLogin error\nYou have not specified a valid username.', 'Disabling the extension resolved the issue for me.', 'This is using MediaWiki 1.18.0.', 'Nothing showed up in the error log.', '--------------------------\n**Version**: unspecified\n**Severity**: blocker']",TRUE,1,NewUserMessage extensions breaks login.,OBSERVED BUG BEHAVIOR,, +16857,NewUserMessage extensions breaks login,"I installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker",1326123000,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_description,"NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker","NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker",High,80,1350964208,NA,declined,TRUE,c2,1,FALSE,FALSE,-86,TRUE,"['NewUserMessage extensions breaks login.', 'I installed this extension and it works fine for a new user signing up, but it breaks login for existing users.', 'Logging in as an existing user generates the error:\n\nLogin error\nYou have not specified a valid username.', 'Disabling the extension resolved the issue for me.', 'This is using MediaWiki 1.18.0.', 'Nothing showed up in the error log.', '--------------------------\n**Version**: unspecified\n**Severity**: blocker']",TRUE,1,"I installed this extension and it works fine for a new user signing up, but it breaks login for existing users.",OBSERVED BUG BEHAVIOR,, +16857,NewUserMessage extensions breaks login,"I installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker",1326123000,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_description,"NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker","NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker",High,80,1350964208,NA,declined,TRUE,c2,1,FALSE,FALSE,-86,TRUE,"['NewUserMessage extensions breaks login.', 'I installed this extension and it works fine for a new user signing up, but it breaks login for existing users.', 'Logging in as an existing user generates the error:\n\nLogin error\nYou have not specified a valid username.', 'Disabling the extension resolved the issue for me.', 'This is using MediaWiki 1.18.0.', 'Nothing showed up in the error log.', '--------------------------\n**Version**: unspecified\n**Severity**: blocker']",TRUE,1,Logging in as an existing user generates the error:\n\nLogin error\nYou have not specified a valid username.,OBSERVED BUG BEHAVIOR ,, +16857,NewUserMessage extensions breaks login,"I installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker",1326123000,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_description,"NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker","NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker",High,80,1350964208,NA,declined,TRUE,c2,1,FALSE,FALSE,-86,TRUE,"['NewUserMessage extensions breaks login.', 'I installed this extension and it works fine for a new user signing up, but it breaks login for existing users.', 'Logging in as an existing user generates the error:\n\nLogin error\nYou have not specified a valid username.', 'Disabling the extension resolved the issue for me.', 'This is using MediaWiki 1.18.0.', 'Nothing showed up in the error log.', '--------------------------\n**Version**: unspecified\n**Severity**: blocker']",TRUE,1,Disabling the extension resolved the issue for me.,WORKAROUNDS,, +16857,NewUserMessage extensions breaks login,"I installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker",1326123000,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_description,"NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker","NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker",High,80,1350964208,NA,declined,TRUE,c2,1,FALSE,FALSE,-86,TRUE,"['NewUserMessage extensions breaks login.', 'I installed this extension and it works fine for a new user signing up, but it breaks login for existing users.', 'Logging in as an existing user generates the error:\n\nLogin error\nYou have not specified a valid username.', 'Disabling the extension resolved the issue for me.', 'This is using MediaWiki 1.18.0.', 'Nothing showed up in the error log.', '--------------------------\n**Version**: unspecified\n**Severity**: blocker']",TRUE,1,Nothing showed up in the error log.,INVESTIGATION AND EXPLORATION,, +16857,NewUserMessage extensions breaks login,"I installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker",1326123000,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_description,"NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker","NewUserMessage extensions breaks login./n/nI installed this extension and it works fine for a new user signing up, but it breaks login for existing users. Logging in as an existing user generates the error: + +Login error +You have not specified a valid username. + +Disabling the extension resolved the issue for me. This is using MediaWiki 1.18.0. Nothing showed up in the error log. + +-------------------------- +**Version**: unspecified +**Severity**: blocker",High,80,1350964208,NA,declined,TRUE,c2,1,FALSE,FALSE,-86,TRUE,"['NewUserMessage extensions breaks login.', 'I installed this extension and it works fine for a new user signing up, but it breaks login for existing users.', 'Logging in as an existing user generates the error:\n\nLogin error\nYou have not specified a valid username.', 'Disabling the extension resolved the issue for me.', 'This is using MediaWiki 1.18.0.', 'Nothing showed up in the error log.', '--------------------------\n**Version**: unspecified\n**Severity**: blocker']",TRUE,1,--------------------------\n**Version**: unspecified\n**Severity**: blocker,OBSERVED BUG BEHAVIOR,, +16858,NewUserMessage extensions breaks login,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",1358809691,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.","Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-32,TRUE,"['Sorry to go silent on this thread.', ""I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception."", 'For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated.', 'If I deactivate it I can login.', ""I'm not going to reopen this, I'll try to debug further."", ""I'm very confused about what is happening.""]",NA,1,Sorry to go silent on this thread.,SOCIAL CONVERSATION,, +16858,NewUserMessage extensions breaks login,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",1358809691,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.","Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-32,TRUE,"['Sorry to go silent on this thread.', ""I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception."", 'For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated.', 'If I deactivate it I can login.', ""I'm not going to reopen this, I'll try to debug further."", ""I'm very confused about what is happening.""]",NA,1,For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated.,OBSERVED BUG BEHAVIOR,, +16858,NewUserMessage extensions breaks login,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",1358809691,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.","Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-32,TRUE,"['Sorry to go silent on this thread.', ""I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception."", 'For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated.', 'If I deactivate it I can login.', ""I'm not going to reopen this, I'll try to debug further."", ""I'm very confused about what is happening.""]",NA,1,If I deactivate it I can login.,WORKAROUNDS,, +16858,NewUserMessage extensions breaks login,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",1358809691,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.","Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-32,TRUE,"['Sorry to go silent on this thread.', ""I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception."", 'For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated.', 'If I deactivate it I can login.', ""I'm not going to reopen this, I'll try to debug further."", ""I'm very confused about what is happening.""]",NA,1,"I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception.",BUG REPRODUCTION,, +16858,NewUserMessage extensions breaks login,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",1358809691,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.","Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-32,TRUE,"['Sorry to go silent on this thread.', ""I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception."", 'For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated.', 'If I deactivate it I can login.', ""I'm not going to reopen this, I'll try to debug further."", ""I'm very confused about what is happening.""]",NA,1,"I'm not going to reopen this, I'll try to debug further.",CONTRIBUTION AND COMMITMENT,, +16858,NewUserMessage extensions breaks login,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",1358809691,PHID-USER-m4lc24apros2wn24aqyu,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.","Sorry to go silent on this thread. I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception. For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated. If I deactivate it I can login. I'm not going to reopen this, I'll try to debug further. I'm very confused about what is happening.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-32,TRUE,"['Sorry to go silent on this thread.', ""I'm now using NewUserMessage on a number of wikis and indeed it works fine, with one exception."", 'For some reason I have one instance where my user account (and seemingly no others) cannot log in if NewUserMessage is activated.', 'If I deactivate it I can login.', ""I'm not going to reopen this, I'll try to debug further."", ""I'm very confused about what is happening.""]",NA,1,I'm very confused about what is happening.,SOCIAL CONVERSATION,, +16859,NewUserMessage extensions breaks login,"Unfortunately closing this report as no further information has been provided. + +Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see http://www.mediawiki.org/wiki/Version_lifecycle ). Thanks!",1350964208,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"Unfortunately closing this report as no further information has been provided. + +Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see http://www.mediawiki.org/wiki/Version_lifecycle ). Thanks!","Unfortunately closing this report as no further information has been provided. + +Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see URL ). Thanks!",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-45,TRUE,"['Unfortunately closing this report as no further information has been provided.', 'Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see URL ).', 'Thanks!']",NA,1,Unfortunately closing this report as no further information has been provided.,ACTION ON ISSUE,, +16859,NewUserMessage extensions breaks login,"Unfortunately closing this report as no further information has been provided. + +Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see http://www.mediawiki.org/wiki/Version_lifecycle ). Thanks!",1350964208,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"Unfortunately closing this report as no further information has been provided. + +Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see http://www.mediawiki.org/wiki/Version_lifecycle ). Thanks!","Unfortunately closing this report as no further information has been provided. + +Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see URL ). Thanks!",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-45,TRUE,"['Unfortunately closing this report as no further information has been provided.', 'Jamie: Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent supported version (see URL ).', 'Thanks!']",NA,1,Thanks!,SOCIAL CONVERSATION,, +16860,NewUserMessage extensions breaks login,"**AzianAlex** wrote: + +Works fine for me too. Have you tried clearing your cache?",1337632645,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"**AzianAlex** wrote: + +Works fine for me too. Have you tried clearing your cache?","**AzianAlex** wrote: + +Works fine for me too. Have you tried clearing your cache?",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-67,TRUE,"['**AzianAlex** wrote:\n\nWorks fine for me too.', 'Have you tried clearing your cache?']",NA,1,Have you tried clearing your cache?,INVESTIGATION AND EXPLORATION,, +16861,NewUserMessage extensions breaks login,"**vivekee047** wrote: + +This works fine for me. Can you check it once again please. +Thanks",1335110687,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"**vivekee047** wrote: + +This works fine for me. Can you check it once again please. +Thanks","**vivekee047** wrote: + +This works fine for me. Can you check it once again please. +Thanks",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"['**vivekee047** wrote:\n\nThis works fine for me.', 'Can you check it once again please.', 'Thanks']",NA,1,Can you check it once again please.,CONTRIBUTION AND COMMITMENT,, +16861,NewUserMessage extensions breaks login,"**vivekee047** wrote: + +This works fine for me. Can you check it once again please. +Thanks",1335110687,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-ses3qd5xfsiawguaqdlu,task_subcomment,"**vivekee047** wrote: + +This works fine for me. Can you check it once again please. +Thanks","**vivekee047** wrote: + +This works fine for me. Can you check it once again please. +Thanks",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,"['**vivekee047** wrote:\n\nThis works fine for me.', 'Can you check it once again please.', 'Thanks']",NA,1,Thanks,SOCIAL CONVERSATION,, +17237,"Notification emails should link to https, not http","Just got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 +for all changes since your last visit. See +http://en.wikipedia.org/wiki/User_talk:Multichill for the current +revision. + +To contact the editor, visit +http://en.wikipedia.org/wiki/User:Magicpiano + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you +would like to switch off your notifications, visit +http://en.wikipedia.org/wiki/Special:Preferences + +Feedback and further assistance: +http://en.wikipedia.org/wiki/Help:Contents + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1322836380,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_description,"Notification emails should link to https, not http./n/nJust got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 +for all changes since your last visit. See +http://en.wikipedia.org/wiki/User_talk:Multichill for the current +revision. + +To contact the editor, visit +http://en.wikipedia.org/wiki/User:Magicpiano + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you +would like to switch off your notifications, visit +http://en.wikipedia.org/wiki/Special:Preferences + +Feedback and further assistance: +http://en.wikipedia.org/wiki/Help:Contents + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Notification emails should link to https, not http./n/nJust got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +URL +for all changes since your last visit. See +URL for the current +revision. + +To contact the editor, visit +URL + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see URL If you +would like to switch off your notifications, visit +URL + +Feedback and further assistance: +URL + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal",Medium,50,1404092595,NA,resolved,TRUE,c2,1,FALSE,FALSE,-91,TRUE,"['Notification emails should link to https, not http.', 'Just got a new message notification:\n\nDear Multichill,\n\n\nThe Wikipedia page ""User talk:Multichill"" has been changed on\n2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking\non National Register of Historic Places in Lowell, Massachusetts */ link\nfix \n\nSee\nURL\nfor all changes since your last visit.', 'See\nURL for the current\nrevision.', 'To contact the editor, visit\nURL\n\nNote that additional changes to the page ""User talk:Multichill"" will not\nresult in any further notifications, until you have logged in and\nvisited the page.', 'Your friendly Wikipedia notification system\n\n--\n\nThis email notification feature was enabled on English Wikipedia in May\n2011 - see URL If you\nwould like to switch off your notifications, visit\nURL\n\nFeedback and further assistance:\nURL\n\n(end)\n\nAll links should be https now we properly implemented ssl.', 'If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"Notification emails should link to https, not http.",EXPECTED BEHAVIOR,, +17237,"Notification emails should link to https, not http","Just got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 +for all changes since your last visit. See +http://en.wikipedia.org/wiki/User_talk:Multichill for the current +revision. + +To contact the editor, visit +http://en.wikipedia.org/wiki/User:Magicpiano + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you +would like to switch off your notifications, visit +http://en.wikipedia.org/wiki/Special:Preferences + +Feedback and further assistance: +http://en.wikipedia.org/wiki/Help:Contents + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1322836380,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_description,"Notification emails should link to https, not http./n/nJust got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 +for all changes since your last visit. See +http://en.wikipedia.org/wiki/User_talk:Multichill for the current +revision. + +To contact the editor, visit +http://en.wikipedia.org/wiki/User:Magicpiano + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you +would like to switch off your notifications, visit +http://en.wikipedia.org/wiki/Special:Preferences + +Feedback and further assistance: +http://en.wikipedia.org/wiki/Help:Contents + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Notification emails should link to https, not http./n/nJust got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +URL +for all changes since your last visit. See +URL for the current +revision. + +To contact the editor, visit +URL + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see URL If you +would like to switch off your notifications, visit +URL + +Feedback and further assistance: +URL + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal",Medium,50,1404092595,NA,resolved,TRUE,c2,1,FALSE,FALSE,-91,TRUE,"['Notification emails should link to https, not http.', 'Just got a new message notification:\n\nDear Multichill,\n\n\nThe Wikipedia page ""User talk:Multichill"" has been changed on\n2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking\non National Register of Historic Places in Lowell, Massachusetts */ link\nfix \n\nSee\nURL\nfor all changes since your last visit.', 'See\nURL for the current\nrevision.', 'To contact the editor, visit\nURL\n\nNote that additional changes to the page ""User talk:Multichill"" will not\nresult in any further notifications, until you have logged in and\nvisited the page.', 'Your friendly Wikipedia notification system\n\n--\n\nThis email notification feature was enabled on English Wikipedia in May\n2011 - see URL If you\nwould like to switch off your notifications, visit\nURL\n\nFeedback and further assistance:\nURL\n\n(end)\n\nAll links should be https now we properly implemented ssl.', 'If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"Just got a new message notification:\n\nDear Multichill,\n\n\nThe Wikipedia page ""User talk:Multichill"" has been changed on\n2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking\non National Register of Historic Places in Lowell, Massachusetts */ link\nfix \n\nSee\nURL\nfor all changes since your last visit.",OBSERVED BUG BEHAVIOR,, +17237,"Notification emails should link to https, not http","Just got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 +for all changes since your last visit. See +http://en.wikipedia.org/wiki/User_talk:Multichill for the current +revision. + +To contact the editor, visit +http://en.wikipedia.org/wiki/User:Magicpiano + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you +would like to switch off your notifications, visit +http://en.wikipedia.org/wiki/Special:Preferences + +Feedback and further assistance: +http://en.wikipedia.org/wiki/Help:Contents + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1322836380,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_description,"Notification emails should link to https, not http./n/nJust got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 +for all changes since your last visit. See +http://en.wikipedia.org/wiki/User_talk:Multichill for the current +revision. + +To contact the editor, visit +http://en.wikipedia.org/wiki/User:Magicpiano + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you +would like to switch off your notifications, visit +http://en.wikipedia.org/wiki/Special:Preferences + +Feedback and further assistance: +http://en.wikipedia.org/wiki/Help:Contents + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Notification emails should link to https, not http./n/nJust got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +URL +for all changes since your last visit. See +URL for the current +revision. + +To contact the editor, visit +URL + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see URL If you +would like to switch off your notifications, visit +URL + +Feedback and further assistance: +URL + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal",Medium,50,1404092595,NA,resolved,TRUE,c2,1,FALSE,FALSE,-91,TRUE,"['Notification emails should link to https, not http.', 'Just got a new message notification:\n\nDear Multichill,\n\n\nThe Wikipedia page ""User talk:Multichill"" has been changed on\n2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking\non National Register of Historic Places in Lowell, Massachusetts */ link\nfix \n\nSee\nURL\nfor all changes since your last visit.', 'See\nURL for the current\nrevision.', 'To contact the editor, visit\nURL\n\nNote that additional changes to the page ""User talk:Multichill"" will not\nresult in any further notifications, until you have logged in and\nvisited the page.', 'Your friendly Wikipedia notification system\n\n--\n\nThis email notification feature was enabled on English Wikipedia in May\n2011 - see URL If you\nwould like to switch off your notifications, visit\nURL\n\nFeedback and further assistance:\nURL\n\n(end)\n\nAll links should be https now we properly implemented ssl.', 'If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,See\nURL for the current\nrevision.,INVESTIGATION AND EXPLORATION,, +17237,"Notification emails should link to https, not http","Just got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 +for all changes since your last visit. See +http://en.wikipedia.org/wiki/User_talk:Multichill for the current +revision. + +To contact the editor, visit +http://en.wikipedia.org/wiki/User:Magicpiano + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you +would like to switch off your notifications, visit +http://en.wikipedia.org/wiki/Special:Preferences + +Feedback and further assistance: +http://en.wikipedia.org/wiki/Help:Contents + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1322836380,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_description,"Notification emails should link to https, not http./n/nJust got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 +for all changes since your last visit. See +http://en.wikipedia.org/wiki/User_talk:Multichill for the current +revision. + +To contact the editor, visit +http://en.wikipedia.org/wiki/User:Magicpiano + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you +would like to switch off your notifications, visit +http://en.wikipedia.org/wiki/Special:Preferences + +Feedback and further assistance: +http://en.wikipedia.org/wiki/Help:Contents + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Notification emails should link to https, not http./n/nJust got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +URL +for all changes since your last visit. See +URL for the current +revision. + +To contact the editor, visit +URL + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see URL If you +would like to switch off your notifications, visit +URL + +Feedback and further assistance: +URL + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal",Medium,50,1404092595,NA,resolved,TRUE,c2,1,FALSE,FALSE,-91,TRUE,"['Notification emails should link to https, not http.', 'Just got a new message notification:\n\nDear Multichill,\n\n\nThe Wikipedia page ""User talk:Multichill"" has been changed on\n2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking\non National Register of Historic Places in Lowell, Massachusetts */ link\nfix \n\nSee\nURL\nfor all changes since your last visit.', 'See\nURL for the current\nrevision.', 'To contact the editor, visit\nURL\n\nNote that additional changes to the page ""User talk:Multichill"" will not\nresult in any further notifications, until you have logged in and\nvisited the page.', 'Your friendly Wikipedia notification system\n\n--\n\nThis email notification feature was enabled on English Wikipedia in May\n2011 - see URL If you\nwould like to switch off your notifications, visit\nURL\n\nFeedback and further assistance:\nURL\n\n(end)\n\nAll links should be https now we properly implemented ssl.', 'If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,"To contact the editor, visit\nURL\n\nNote that additional changes to the page ""User talk:Multichill"" will not\nresult in any further notifications, until you have logged in and\nvisited the page.",OBSERVED BUG BEHAVIOR,, +17237,"Notification emails should link to https, not http","Just got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 +for all changes since your last visit. See +http://en.wikipedia.org/wiki/User_talk:Multichill for the current +revision. + +To contact the editor, visit +http://en.wikipedia.org/wiki/User:Magicpiano + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you +would like to switch off your notifications, visit +http://en.wikipedia.org/wiki/Special:Preferences + +Feedback and further assistance: +http://en.wikipedia.org/wiki/Help:Contents + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1322836380,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_description,"Notification emails should link to https, not http./n/nJust got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 +for all changes since your last visit. See +http://en.wikipedia.org/wiki/User_talk:Multichill for the current +revision. + +To contact the editor, visit +http://en.wikipedia.org/wiki/User:Magicpiano + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you +would like to switch off your notifications, visit +http://en.wikipedia.org/wiki/Special:Preferences + +Feedback and further assistance: +http://en.wikipedia.org/wiki/Help:Contents + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Notification emails should link to https, not http./n/nJust got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +URL +for all changes since your last visit. See +URL for the current +revision. + +To contact the editor, visit +URL + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see URL If you +would like to switch off your notifications, visit +URL + +Feedback and further assistance: +URL + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal",Medium,50,1404092595,NA,resolved,TRUE,c2,1,FALSE,FALSE,-91,TRUE,"['Notification emails should link to https, not http.', 'Just got a new message notification:\n\nDear Multichill,\n\n\nThe Wikipedia page ""User talk:Multichill"" has been changed on\n2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking\non National Register of Historic Places in Lowell, Massachusetts */ link\nfix \n\nSee\nURL\nfor all changes since your last visit.', 'See\nURL for the current\nrevision.', 'To contact the editor, visit\nURL\n\nNote that additional changes to the page ""User talk:Multichill"" will not\nresult in any further notifications, until you have logged in and\nvisited the page.', 'Your friendly Wikipedia notification system\n\n--\n\nThis email notification feature was enabled on English Wikipedia in May\n2011 - see URL If you\nwould like to switch off your notifications, visit\nURL\n\nFeedback and further assistance:\nURL\n\n(end)\n\nAll links should be https now we properly implemented ssl.', 'If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution.,SOLUTION DISCUSSION,, +17237,"Notification emails should link to https, not http","Just got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 +for all changes since your last visit. See +http://en.wikipedia.org/wiki/User_talk:Multichill for the current +revision. + +To contact the editor, visit +http://en.wikipedia.org/wiki/User:Magicpiano + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you +would like to switch off your notifications, visit +http://en.wikipedia.org/wiki/Special:Preferences + +Feedback and further assistance: +http://en.wikipedia.org/wiki/Help:Contents + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal",1322836380,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_description,"Notification emails should link to https, not http./n/nJust got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +http://en.wikipedia.org/w/index.php?title=User_talk:Multichill&diff=0&oldid=463665500 +for all changes since your last visit. See +http://en.wikipedia.org/wiki/User_talk:Multichill for the current +revision. + +To contact the editor, visit +http://en.wikipedia.org/wiki/User:Magicpiano + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see http://en.wikipedia.org/wiki/Help:Email_notification. If you +would like to switch off your notifications, visit +http://en.wikipedia.org/wiki/Special:Preferences + +Feedback and further assistance: +http://en.wikipedia.org/wiki/Help:Contents + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal","Notification emails should link to https, not http./n/nJust got a new message notification: + +Dear Multichill, + + +The Wikipedia page ""User talk:Multichill"" has been changed on +2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking +on National Register of Historic Places in Lowell, Massachusetts */ link +fix + +See +URL +for all changes since your last visit. See +URL for the current +revision. + +To contact the editor, visit +URL + +Note that additional changes to the page ""User talk:Multichill"" will not +result in any further notifications, until you have logged in and +visited the page. + + Your friendly Wikipedia notification system + +-- + +This email notification feature was enabled on English Wikipedia in May +2011 - see URL If you +would like to switch off your notifications, visit +URL + +Feedback and further assistance: +URL + +(end) + +All links should be https now we properly implemented ssl. +If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution. + +-------------------------- +**Version**: unspecified +**Severity**: normal",Medium,50,1404092595,NA,resolved,TRUE,c2,1,FALSE,FALSE,-91,TRUE,"['Notification emails should link to https, not http.', 'Just got a new message notification:\n\nDear Multichill,\n\n\nThe Wikipedia page ""User talk:Multichill"" has been changed on\n2 December 2011 by Magicpiano, with the edit summary: /* Bot is breaking\non National Register of Historic Places in Lowell, Massachusetts */ link\nfix \n\nSee\nURL\nfor all changes since your last visit.', 'See\nURL for the current\nrevision.', 'To contact the editor, visit\nURL\n\nNote that additional changes to the page ""User talk:Multichill"" will not\nresult in any further notifications, until you have logged in and\nvisited the page.', 'Your friendly Wikipedia notification system\n\n--\n\nThis email notification feature was enabled on English Wikipedia in May\n2011 - see URL If you\nwould like to switch off your notifications, visit\nURL\n\nFeedback and further assistance:\nURL\n\n(end)\n\nAll links should be https now we properly implemented ssl.', 'If this is a bridge too far for now a user setting to prefer http or https would probably be a good intermediate solution.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,1,--------------------------\n**Version**: unspecified\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, +17238,"Notification emails should link to https, not http",Notification e-mails now use HTTPS,1404092595,PHID-USER-sx63fwaih5kjt7bz4u6z,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,Notification e-mails now use HTTPS,Notification e-mails now use HTTPS,NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,43,TRUE,['Notification e-mails now use HTTPS'],NA,1,Notification e-mails now use HTTPS,TASK PROGRESS,, +17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,WORKSFORME would be a valid resolution if this were attached to a general component.,ACTION ON ISSUE,, +17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,LATER would be the valid resolution here.,ACTION ON ISSUE,, +17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,And just since you said it.,SOCIAL CONVERSATION,, +17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,"The fact that people ""should never use http"" isn\",EXPECTED BEHAVIOR,, +17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,", ""Even though they shouldn",SOLUTION USAGE,, +17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,t use http doesn,NA,, +17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,"re a minority."", ",NA,, +17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,Since it's already possible to configure $wgCanonicalServer to put https links into the emails.,WORKAROUNDS,, +17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things.,SOLUTION USAGE,, +17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,And naturally this isn't a bug tracking when https will be fully deployed.,ISSUE CONTENT MANAGEMENT,, +17239,"Notification emails should link to https, not http","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",1343038044,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.","WORKSFORME would be a valid resolution if this were attached to a general component. Since it's already possible to configure $wgCanonicalServer to put https links into the emails. + +LATER would be the valid resolution here. Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things. And this bug sitting here isn't going to change that schedule. +And naturally this isn't a bug tracking when https will be fully deployed. + +And just since you said it. The fact that people ""should never use http"" isn't really relevant. Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do. The only people that pay attention to these kind of things are us techy people. And well, we're a minority. +So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"['WORKSFORME would be a valid resolution if this were attached to a general component.', ""Since it's already possible to configure $wgCanonicalServer to put https links into the emails."", 'LATER would be the valid resolution here.', ""Since this bug isn't going to change anything since this will automatically be handled when the https rollout is finished to a degree that we can default to https for a number of things."", ""And this bug sitting here isn't going to change that schedule."", ""And naturally this isn't a bug tracking when https will be fully deployed."", 'And just since you said it.', 'The fact that people ""should never use http"" isn\'t really relevant.', ""Even though they shouldn't the fact is that most people shouldn't use http doesn't change the fact that they do."", 'The only people that pay attention to these kind of things are us techy people.', ""And well, we're a minority."", 'So the point that the load on the https servers would be vastly different between now and when we default https on for logged-in users is a fact.']",NA,1,", 'The only people that pay attention to these kind of things are us techy people.', ",SOCIAL CONVERSATION,, +17240,"Notification emails should link to https, not http","You can't just close this as worksforme because it doesn't work. +Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. + +Added this one to the tracker",1343032593,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"You can't just close this as worksforme because it doesn't work. +Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. + +Added this one to the tracker","You can't just close this as worksforme because it doesn't work. +Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. + +Added this one to the tracker",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"[""You can't just close this as worksforme because it doesn't work."", ""Where do you base your assumption on that the SSL cluster can't handle the load?"", 'How many logged in users are now use http and how many users https?', 'In this day in age logged in users should never use http.', 'Added this one to the tracker']",NA,1,How many logged in users are now use http and how many users https?,INVESTIGATION AND EXPLORATION,, +17240,"Notification emails should link to https, not http","You can't just close this as worksforme because it doesn't work. +Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. + +Added this one to the tracker",1343032593,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"You can't just close this as worksforme because it doesn't work. +Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. + +Added this one to the tracker","You can't just close this as worksforme because it doesn't work. +Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. + +Added this one to the tracker",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"[""You can't just close this as worksforme because it doesn't work."", ""Where do you base your assumption on that the SSL cluster can't handle the load?"", 'How many logged in users are now use http and how many users https?', 'In this day in age logged in users should never use http.', 'Added this one to the tracker']",NA,1,In this day in age logged in users should never use http.,EXPECTED BEHAVIOR,, +17240,"Notification emails should link to https, not http","You can't just close this as worksforme because it doesn't work. +Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. + +Added this one to the tracker",1343032593,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"You can't just close this as worksforme because it doesn't work. +Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. + +Added this one to the tracker","You can't just close this as worksforme because it doesn't work. +Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. + +Added this one to the tracker",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"[""You can't just close this as worksforme because it doesn't work."", ""Where do you base your assumption on that the SSL cluster can't handle the load?"", 'How many logged in users are now use http and how many users https?', 'In this day in age logged in users should never use http.', 'Added this one to the tracker']",NA,1,Added this one to the tracker,ACTION ON ISSUE,, +17240,"Notification emails should link to https, not http","You can't just close this as worksforme because it doesn't work. +Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. + +Added this one to the tracker",1343032593,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"You can't just close this as worksforme because it doesn't work. +Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. + +Added this one to the tracker","You can't just close this as worksforme because it doesn't work. +Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. + +Added this one to the tracker",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"[""You can't just close this as worksforme because it doesn't work."", ""Where do you base your assumption on that the SSL cluster can't handle the load?"", 'How many logged in users are now use http and how many users https?', 'In this day in age logged in users should never use http.', 'Added this one to the tracker']",NA,1,You can't just close this as worksforme because it doesn't work.,ACTION ON ISSUE,, +17240,"Notification emails should link to https, not http","You can't just close this as worksforme because it doesn't work. +Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. + +Added this one to the tracker",1343032593,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"You can't just close this as worksforme because it doesn't work. +Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. + +Added this one to the tracker","You can't just close this as worksforme because it doesn't work. +Where do you base your assumption on that the SSL cluster can't handle the load? How many logged in users are now use http and how many users https? In this day in age logged in users should never use http. + +Added this one to the tracker",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-58,TRUE,"[""You can't just close this as worksforme because it doesn't work."", ""Where do you base your assumption on that the SSL cluster can't handle the load?"", 'How many logged in users are now use http and how many users https?', 'In this day in age logged in users should never use http.', 'Added this one to the tracker']",NA,1,Where do you base your assumption on that the SSL cluster can't handle the load?,INVESTIGATION AND EXPLORATION,, +17241,"Notification emails should link to https, not http","Marking works for me, it is a duplicate of several other bugs: + +* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) +* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. + +Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",1342801588,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"Marking works for me, it is a duplicate of several other bugs: + +* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) +* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. + +Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).","Marking works for me, it is a duplicate of several other bugs: + +* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) +* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. + +Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-58,TRUE,"['Marking works for me, it is a duplicate of several other bugs:\n\n* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11)\n* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages.', 'Note that to enable https by default, all we need to do is set wgCanonicalServer to https.', ""That's just a configuration change, no software change."", 'The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone.', 'There is a bug open about that already.', 'See also the tracking bug about secure access (bug 27946).']",NA,1,"Marking works for me, it is a duplicate of several other bugs:\n\n* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11)\n* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages.",ACTION ON ISSUE,, +17241,"Notification emails should link to https, not http","Marking works for me, it is a duplicate of several other bugs: + +* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) +* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. + +Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",1342801588,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"Marking works for me, it is a duplicate of several other bugs: + +* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) +* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. + +Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).","Marking works for me, it is a duplicate of several other bugs: + +* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) +* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. + +Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-58,TRUE,"['Marking works for me, it is a duplicate of several other bugs:\n\n* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11)\n* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages.', 'Note that to enable https by default, all we need to do is set wgCanonicalServer to https.', ""That's just a configuration change, no software change."", 'The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone.', 'There is a bug open about that already.', 'See also the tracking bug about secure access (bug 27946).']",NA,1,"Note that to enable https by default, all we need to do is set wgCanonicalServer to https.",SOLUTION DISCUSSION,, +17241,"Notification emails should link to https, not http","Marking works for me, it is a duplicate of several other bugs: + +* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) +* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. + +Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",1342801588,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"Marking works for me, it is a duplicate of several other bugs: + +* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) +* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. + +Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).","Marking works for me, it is a duplicate of several other bugs: + +* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) +* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. + +Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-58,TRUE,"['Marking works for me, it is a duplicate of several other bugs:\n\n* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11)\n* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages.', 'Note that to enable https by default, all we need to do is set wgCanonicalServer to https.', ""That's just a configuration change, no software change."", 'The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone.', 'There is a bug open about that already.', 'See also the tracking bug about secure access (bug 27946).']",NA,1,The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone.,SOLUTION DISCUSSION,, +17241,"Notification emails should link to https, not http","Marking works for me, it is a duplicate of several other bugs: + +* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) +* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. + +Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",1342801588,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"Marking works for me, it is a duplicate of several other bugs: + +* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) +* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. + +Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).","Marking works for me, it is a duplicate of several other bugs: + +* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) +* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. + +Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-58,TRUE,"['Marking works for me, it is a duplicate of several other bugs:\n\n* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11)\n* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages.', 'Note that to enable https by default, all we need to do is set wgCanonicalServer to https.', ""That's just a configuration change, no software change."", 'The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone.', 'There is a bug open about that already.', 'See also the tracking bug about secure access (bug 27946).']",NA,1,There is a bug open about that already.,ISSUE CONTENT MANAGEMENT,, +17241,"Notification emails should link to https, not http","Marking works for me, it is a duplicate of several other bugs: + +* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) +* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. + +Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",1342801588,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"Marking works for me, it is a duplicate of several other bugs: + +* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) +* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. + +Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).","Marking works for me, it is a duplicate of several other bugs: + +* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11) +* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages. + +Note that to enable https by default, all we need to do is set wgCanonicalServer to https. That's just a configuration change, no software change. The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone. There is a bug open about that already. See also the tracking bug about secure access (bug 27946).",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-58,TRUE,"['Marking works for me, it is a duplicate of several other bugs:\n\n* (bug 29898) User preference for enforcing HTTPS (see also bug 29898 comment 11)\n* (bug 29878) Fix inconsistency in resolution of protocol-independent wgServer for email messages.', 'Note that to enable https by default, all we need to do is set wgCanonicalServer to https.', ""That's just a configuration change, no software change."", 'The reason this is not going to be done soon is because the SSL cluster is not big or stable enough to take a default load for everyone.', 'There is a bug open about that already.', 'See also the tracking bug about secure access (bug 27946).']",NA,1,"That's just a configuration change, no software change.",SOLUTION DISCUSSION,, +17242,"Notification emails should link to https, not http","I say fix this one. It's a pretty easy fix ;-) + +You should leave #29878 open as a MediaWiki enhancement.",1326146714,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"I say fix this one. It's a pretty easy fix ;-) + +You should leave #29878 open as a MediaWiki enhancement.","I say fix this one. It's a pretty easy fix ;-) + +You should leave #29878 open as a MediaWiki enhancement.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-86,TRUE,"['I say fix this one.', ""It's a pretty easy fix ;-)\n\nYou should leave #29878 open as a MediaWiki enhancement.""]",NA,1,I say fix this one.,CONTRIBUTION AND COMMITMENT,, +17242,"Notification emails should link to https, not http","I say fix this one. It's a pretty easy fix ;-) + +You should leave #29878 open as a MediaWiki enhancement.",1326146714,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"I say fix this one. It's a pretty easy fix ;-) + +You should leave #29878 open as a MediaWiki enhancement.","I say fix this one. It's a pretty easy fix ;-) + +You should leave #29878 open as a MediaWiki enhancement.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-86,TRUE,"['I say fix this one.', ""It's a pretty easy fix ;-)\n\nYou should leave #29878 open as a MediaWiki enhancement.""]",NA,1,It's a pretty easy fix ;-)\n\nYou should leave #29878 open as a MediaWiki enhancement.,ISSUE CONTENT MANAGEMENT,, +17243,"Notification emails should link to https, not http","(In reply to comment #2) +> This is not a duplicate. #29878 is about user preferences. This bug is about +> setting everything to https by default (instead of the current http). + +The two bugs cannot both be solved, though. I do prefer this solution. We'll have to choose one.",1323443836,PHID-USER-ogbcrxm45oo3n3xe5q25,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"(In reply to comment #2) +> This is not a duplicate. #29878 is about user preferences. This bug is about +> setting everything to https by default (instead of the current http). + +The two bugs cannot both be solved, though. I do prefer this solution. We'll have to choose one.","(In reply to comment #2) +QUOTE +QUOTE + +The two bugs cannot both be solved, though. I do prefer this solution. We'll have to choose one.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-90,TRUE,"['(In reply to comment #2)\nQUOTE\nQUOTE\n\nThe two bugs cannot both be solved, though.', 'I do prefer this solution.', ""We'll have to choose one.""]",NA,1,"(In reply to comment #2)\nQUOTE\nQUOTE\n\nThe two bugs cannot both be solved, though.",SOLUTION DISCUSSION,, +17243,"Notification emails should link to https, not http","(In reply to comment #2) +> This is not a duplicate. #29878 is about user preferences. This bug is about +> setting everything to https by default (instead of the current http). + +The two bugs cannot both be solved, though. I do prefer this solution. We'll have to choose one.",1323443836,PHID-USER-ogbcrxm45oo3n3xe5q25,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"(In reply to comment #2) +> This is not a duplicate. #29878 is about user preferences. This bug is about +> setting everything to https by default (instead of the current http). + +The two bugs cannot both be solved, though. I do prefer this solution. We'll have to choose one.","(In reply to comment #2) +QUOTE +QUOTE + +The two bugs cannot both be solved, though. I do prefer this solution. We'll have to choose one.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-90,TRUE,"['(In reply to comment #2)\nQUOTE\nQUOTE\n\nThe two bugs cannot both be solved, though.', 'I do prefer this solution.', ""We'll have to choose one.""]",NA,1,I do prefer this solution.,SOLUTION DISCUSSION,, +17243,"Notification emails should link to https, not http","(In reply to comment #2) +> This is not a duplicate. #29878 is about user preferences. This bug is about +> setting everything to https by default (instead of the current http). + +The two bugs cannot both be solved, though. I do prefer this solution. We'll have to choose one.",1323443836,PHID-USER-ogbcrxm45oo3n3xe5q25,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,"(In reply to comment #2) +> This is not a duplicate. #29878 is about user preferences. This bug is about +> setting everything to https by default (instead of the current http). + +The two bugs cannot both be solved, though. I do prefer this solution. We'll have to choose one.","(In reply to comment #2) +QUOTE +QUOTE + +The two bugs cannot both be solved, though. I do prefer this solution. We'll have to choose one.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-90,TRUE,"['(In reply to comment #2)\nQUOTE\nQUOTE\n\nThe two bugs cannot both be solved, though.', 'I do prefer this solution.', ""We'll have to choose one.""]",NA,1,We'll have to choose one.,SOLUTION DISCUSSION,, +17244,"Notification emails should link to https, not http",This is not a duplicate. #29878 is about user preferences. This bug is about setting everything to https by default (instead of the current http).,1323441932,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,This is not a duplicate. #29878 is about user preferences. This bug is about setting everything to https by default (instead of the current http).,This is not a duplicate. #29878 is about user preferences. This bug is about setting everything to https by default (instead of the current http).,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-90,TRUE,"['This is not a duplicate.', '#29878 is about user preferences.', 'This bug is about setting everything to https by default (instead of the current http).']",NA,1,This is not a duplicate.,ISSUE CONTENT MANAGEMENT,, +17244,"Notification emails should link to https, not http",This is not a duplicate. #29878 is about user preferences. This bug is about setting everything to https by default (instead of the current http).,1323441932,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,This is not a duplicate. #29878 is about user preferences. This bug is about setting everything to https by default (instead of the current http).,This is not a duplicate. #29878 is about user preferences. This bug is about setting everything to https by default (instead of the current http).,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-90,TRUE,"['This is not a duplicate.', '#29878 is about user preferences.', 'This bug is about setting everything to https by default (instead of the current http).']",NA,1,#29878 is about user preferences.,ISSUE CONTENT MANAGEMENT,, +17244,"Notification emails should link to https, not http",This is not a duplicate. #29878 is about user preferences. This bug is about setting everything to https by default (instead of the current http).,1323441932,PHID-USER-cw4amt4ewxdze5qcjdca,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment,This is not a duplicate. #29878 is about user preferences. This bug is about setting everything to https by default (instead of the current http).,This is not a duplicate. #29878 is about user preferences. This bug is about setting everything to https by default (instead of the current http).,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-90,TRUE,"['This is not a duplicate.', '#29878 is about user preferences.', 'This bug is about setting everything to https by default (instead of the current http).']",NA,1,This bug is about setting everything to https by default (instead of the current http).,INVESTIGATION AND EXPLORATION,, +17245,"Notification emails should link to https, not http"," + +%%%*** This bug has been marked as a duplicate of bug 29878 ***%%%",1322838348,PHID-USER-gibrlx54k2riiuit5paf,PHID-TASK-7vfqohbuaxe5jz7heehg,task_subcomment," + +%%%*** This bug has been marked as a duplicate of bug 29878 ***%%%"," + +%%%*** This bug has been marked as a duplicate of bug 29878 ***%%%",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-91,TRUE,['\n\n%%%*** This bug has been marked as a duplicate of bug 29878 ***%%%'],NA,1,\n\n%%%*** This bug has been marked as a duplicate of bug 29878 ***%%%,ACTION ON ISSUE,, +17529,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"For https://commons.wikimedia.org/wiki/File:Carbon_River_pano_01A.jpg + +http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg + +Some sort of Guru meditation. + +-------------------------- +**Version**: wmf-deployment +**Severity**: normal",1335143940,PHID-USER-wqc7ciyvfzunj3l2tvjt,PHID-TASK-2sndzb2ydzwochmrxplf,task_description,"HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file./n/nFor https://commons.wikimedia.org/wiki/File:Carbon_River_pano_01A.jpg + +http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg + +Some sort of Guru meditation. + +-------------------------- +**Version**: wmf-deployment +**Severity**: normal","HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file./n/nFor URL + +URL + +Some sort of Guru meditation. + +-------------------------- +**Version**: wmf-deployment +**Severity**: normal",Lowest,10,1569621040,PHID-USER-j7jwnj5chzo76nqqvgqc,duplicate,TRUE,c2,1,FALSE,FALSE,-71,TRUE,"['HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file.', 'For URL\n\nURL\n\nSome sort of Guru meditation.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal']",FALSE,1,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file.,OBSERVED BUG BEHAVIOR,, +17529,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"For https://commons.wikimedia.org/wiki/File:Carbon_River_pano_01A.jpg + +http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg + +Some sort of Guru meditation. + +-------------------------- +**Version**: wmf-deployment +**Severity**: normal",1335143940,PHID-USER-wqc7ciyvfzunj3l2tvjt,PHID-TASK-2sndzb2ydzwochmrxplf,task_description,"HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file./n/nFor https://commons.wikimedia.org/wiki/File:Carbon_River_pano_01A.jpg + +http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg + +Some sort of Guru meditation. + +-------------------------- +**Version**: wmf-deployment +**Severity**: normal","HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file./n/nFor URL + +URL + +Some sort of Guru meditation. + +-------------------------- +**Version**: wmf-deployment +**Severity**: normal",Lowest,10,1569621040,PHID-USER-j7jwnj5chzo76nqqvgqc,duplicate,TRUE,c2,1,FALSE,FALSE,-71,TRUE,"['HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file.', 'For URL\n\nURL\n\nSome sort of Guru meditation.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal']",FALSE,1,For URL\n\nURL\n\nSome sort of Guru meditation.,OBSERVED BUG BEHAVIOR,, +17529,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"For https://commons.wikimedia.org/wiki/File:Carbon_River_pano_01A.jpg + +http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg + +Some sort of Guru meditation. + +-------------------------- +**Version**: wmf-deployment +**Severity**: normal",1335143940,PHID-USER-wqc7ciyvfzunj3l2tvjt,PHID-TASK-2sndzb2ydzwochmrxplf,task_description,"HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file./n/nFor https://commons.wikimedia.org/wiki/File:Carbon_River_pano_01A.jpg + +http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg + +Some sort of Guru meditation. + +-------------------------- +**Version**: wmf-deployment +**Severity**: normal","HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file./n/nFor URL + +URL + +Some sort of Guru meditation. + +-------------------------- +**Version**: wmf-deployment +**Severity**: normal",Lowest,10,1569621040,PHID-USER-j7jwnj5chzo76nqqvgqc,duplicate,TRUE,c2,1,FALSE,FALSE,-71,TRUE,"['HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file.', 'For URL\n\nURL\n\nSome sort of Guru meditation.', '--------------------------\n**Version**: wmf-deployment\n**Severity**: normal']",FALSE,1,--------------------------\n**Version**: wmf-deployment\n**Severity**: normal,OBSERVED BUG BEHAVIOR,, +17530,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"This is same as T200313, closing as duplicate.",1569621031,PHID-USER-j7jwnj5chzo76nqqvgqc,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"This is same as T200313, closing as duplicate.","This is same as T200313, closing as duplicate.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,317,TRUE,"['This is same as T200313, closing as duplicate.']",NA,1,"This is same as T200313, closing as duplicate.",ACTION ON ISSUE,, +17531,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"https://upload.wikimedia.org/wikipedia/commons/thumb/8/84/Logiz_de_la_Lune_Rousse-Affiche1900.jpg/120px-Logiz_de_la_Lune_Rousse-Affiche1900.jpg + +``` + +Error generating thumbnail + +There have been too many recent failed attempts (4 or more) to render this thumbnail. Please try again later. +```",1432295639,PHID-USER-nuf2sujf7qrx4v5ixbs3,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"https://upload.wikimedia.org/wikipedia/commons/thumb/8/84/Logiz_de_la_Lune_Rousse-Affiche1900.jpg/120px-Logiz_de_la_Lune_Rousse-Affiche1900.jpg + +``` + +Error generating thumbnail + +There have been too many recent failed attempts (4 or more) to render this thumbnail. Please try again later. +```","URL + +``CODE``",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,90,TRUE,['URL\n\n``CODE``'],NA,1,URL\n\n``CODE``,NA,, +17532,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +> http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ +> Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg +> +> Some sort of Guru meditation. + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +> I determined that I'd hit bug 17645, saved the file as a baseline optimized +> JPEG rather than progressive and now the thumbnails work. Sorry for the +> noise. +> +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",1400351520,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +> http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ +> Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg +> +> Some sort of Guru meditation. + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +> I determined that I'd hit bug 17645, saved the file as a baseline optimized +> JPEG rather than progressive and now the thumbnails work. Sorry for the +> noise. +> +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.","Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +QUOTE +QUOTE +QUOTE +QUOTE + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,37,TRUE,"['Error code 137 = out of memory.', ""(In reply to Jasper Deng from comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's the use case for generating a 6000px wide thumbnail?"", '(In reply to earthsound from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that would do it.', 'Progressive images are much more memory intensive to scale.', '----\nNote: the Carbon river file is a baseline jpeg.', ""Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail."", 'I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.']",NA,1,Error code 137 = out of memory.,OBSERVED BUG BEHAVIOR,, +17532,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +> http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ +> Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg +> +> Some sort of Guru meditation. + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +> I determined that I'd hit bug 17645, saved the file as a baseline optimized +> JPEG rather than progressive and now the thumbnails work. Sorry for the +> noise. +> +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",1400351520,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +> http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ +> Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg +> +> Some sort of Guru meditation. + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +> I determined that I'd hit bug 17645, saved the file as a baseline optimized +> JPEG rather than progressive and now the thumbnails work. Sorry for the +> noise. +> +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.","Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +QUOTE +QUOTE +QUOTE +QUOTE + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,37,TRUE,"['Error code 137 = out of memory.', ""(In reply to Jasper Deng from comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's the use case for generating a 6000px wide thumbnail?"", '(In reply to earthsound from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that would do it.', 'Progressive images are much more memory intensive to scale.', '----\nNote: the Carbon river file is a baseline jpeg.', ""Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail."", 'I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.']",NA,1,"(In reply to earthsound from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that would do it.",SOCIAL CONVERSATION,, +17532,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +> http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ +> Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg +> +> Some sort of Guru meditation. + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +> I determined that I'd hit bug 17645, saved the file as a baseline optimized +> JPEG rather than progressive and now the thumbnails work. Sorry for the +> noise. +> +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",1400351520,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +> http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ +> Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg +> +> Some sort of Guru meditation. + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +> I determined that I'd hit bug 17645, saved the file as a baseline optimized +> JPEG rather than progressive and now the thumbnails work. Sorry for the +> noise. +> +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.","Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +QUOTE +QUOTE +QUOTE +QUOTE + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,37,TRUE,"['Error code 137 = out of memory.', ""(In reply to Jasper Deng from comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's the use case for generating a 6000px wide thumbnail?"", '(In reply to earthsound from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that would do it.', 'Progressive images are much more memory intensive to scale.', '----\nNote: the Carbon river file is a baseline jpeg.', ""Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail."", 'I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.']",NA,1,Progressive images are much more memory intensive to scale.,INVESTIGATION AND EXPLORATION,, +17532,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +> http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ +> Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg +> +> Some sort of Guru meditation. + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +> I determined that I'd hit bug 17645, saved the file as a baseline optimized +> JPEG rather than progressive and now the thumbnails work. Sorry for the +> noise. +> +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",1400351520,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +> http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ +> Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg +> +> Some sort of Guru meditation. + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +> I determined that I'd hit bug 17645, saved the file as a baseline optimized +> JPEG rather than progressive and now the thumbnails work. Sorry for the +> noise. +> +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.","Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +QUOTE +QUOTE +QUOTE +QUOTE + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,37,TRUE,"['Error code 137 = out of memory.', ""(In reply to Jasper Deng from comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's the use case for generating a 6000px wide thumbnail?"", '(In reply to earthsound from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that would do it.', 'Progressive images are much more memory intensive to scale.', '----\nNote: the Carbon river file is a baseline jpeg.', ""Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail."", 'I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.']",NA,1,----\nNote: the Carbon river file is a baseline jpeg.,INVESTIGATION AND EXPLORATION,, +17532,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +> http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ +> Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg +> +> Some sort of Guru meditation. + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +> I determined that I'd hit bug 17645, saved the file as a baseline optimized +> JPEG rather than progressive and now the thumbnails work. Sorry for the +> noise. +> +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",1400351520,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +> http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ +> Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg +> +> Some sort of Guru meditation. + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +> I determined that I'd hit bug 17645, saved the file as a baseline optimized +> JPEG rather than progressive and now the thumbnails work. Sorry for the +> noise. +> +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.","Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +QUOTE +QUOTE +QUOTE +QUOTE + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,37,TRUE,"['Error code 137 = out of memory.', ""(In reply to Jasper Deng from comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's the use case for generating a 6000px wide thumbnail?"", '(In reply to earthsound from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that would do it.', 'Progressive images are much more memory intensive to scale.', '----\nNote: the Carbon river file is a baseline jpeg.', ""Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail."", 'I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.']",NA,1,I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.,ACTION ON ISSUE,, +17532,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +> http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ +> Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg +> +> Some sort of Guru meditation. + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +> I determined that I'd hit bug 17645, saved the file as a baseline optimized +> JPEG rather than progressive and now the thumbnails work. Sorry for the +> noise. +> +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",1400351520,PHID-USER-dpu5hmqvprhycqlkdzrk,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +> http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/ +> Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg +> +> Some sort of Guru meditation. + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +> I determined that I'd hit bug 17645, saved the file as a baseline optimized +> JPEG rather than progressive and now the thumbnails work. Sorry for the +> noise. +> +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.","Error code 137 = out of memory. + +(In reply to Jasper Deng from comment #0) +QUOTE +QUOTE +QUOTE +QUOTE + +What's the use case for generating a 6000px wide thumbnail? + +(In reply to earthsound from comment #10) +QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +Yep, that would do it. Progressive images are much more memory intensive to scale. + +---- +Note: the Carbon river file is a baseline jpeg. + +Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail. I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,37,TRUE,"['Error code 137 = out of memory.', ""(In reply to Jasper Deng from comment #0)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nWhat's the use case for generating a 6000px wide thumbnail?"", '(In reply to earthsound from comment #10)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYep, that would do it.', 'Progressive images are much more memory intensive to scale.', '----\nNote: the Carbon river file is a baseline jpeg.', ""Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail."", 'I feel like this bug should be wontfixed unless people have a compelling reason to need such huge thumbnails.']",NA,1,Honestly I don't find it that surprising that it runs out of memory when you try to make a 66 megapixel thumbnail.,INVESTIGATION AND EXPLORATION,, +17533,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"(In reply to earthsound from comment #10) +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. +It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",1393968377,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"(In reply to earthsound from comment #10) +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. +It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.","(In reply to earthsound from comment #10) +QUOTE + +Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. +It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,26,TRUE,"['(In reply to earthsound from comment #10)\nQUOTE\n\nOuch.', 'We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever.', ""I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot."", 'It\'s also possible that whatever you did (a null ""convert"" run?)', 'fixed *other* things.']",NA,1,(In reply to earthsound from comment #10)\nQUOTE\n\nOuch.,SOCIAL CONVERSATION,, +17533,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"(In reply to earthsound from comment #10) +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. +It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",1393968377,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"(In reply to earthsound from comment #10) +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. +It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.","(In reply to earthsound from comment #10) +QUOTE + +Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. +It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,26,TRUE,"['(In reply to earthsound from comment #10)\nQUOTE\n\nOuch.', 'We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever.', ""I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot."", 'It\'s also possible that whatever you did (a null ""convert"" run?)', 'fixed *other* things.']",NA,1,"We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever.",TESTING ,, +17533,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"(In reply to earthsound from comment #10) +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. +It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",1393968377,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"(In reply to earthsound from comment #10) +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. +It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.","(In reply to earthsound from comment #10) +QUOTE + +Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. +It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,26,TRUE,"['(In reply to earthsound from comment #10)\nQUOTE\n\nOuch.', 'We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever.', ""I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot."", 'It\'s also possible that whatever you did (a null ""convert"" run?)', 'fixed *other* things.']",NA,1,It\,NA,, +17533,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"(In reply to earthsound from comment #10) +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. +It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",1393968377,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"(In reply to earthsound from comment #10) +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. +It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.","(In reply to earthsound from comment #10) +QUOTE + +Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. +It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,26,TRUE,"['(In reply to earthsound from comment #10)\nQUOTE\n\nOuch.', 'We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever.', ""I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot."", 'It\'s also possible that whatever you did (a null ""convert"" run?)', 'fixed *other* things.']",NA,1,"I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot.",SOLUTION DISCUSSION ,, +17533,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"(In reply to earthsound from comment #10) +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. +It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",1393968377,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"(In reply to earthsound from comment #10) +> Perhaps the images reported in this bug are saved similarly (progressive)? + +Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. +It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.","(In reply to earthsound from comment #10) +QUOTE + +Ouch. We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever. I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot. +It's also possible that whatever you did (a null ""convert"" run?) fixed *other* things.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,26,TRUE,"['(In reply to earthsound from comment #10)\nQUOTE\n\nOuch.', 'We have lists of progressive images, attachment 11220 and attachment 11500, and you can easily test the cases above with exiftools or whatever.', ""I think we've replaced by bot (most) of the bigger ones, but there may be other factors beyond size that make them fail: in that case, it would be nice to determine what they are, to fix them by bot."", 'It\'s also possible that whatever you did (a null ""convert"" run?)', 'fixed *other* things.']",NA,1,convert,NA,, +17534,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**earthsound** wrote: + +I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. + +Perhaps the images reported in this bug are saved similarly (progressive)?",1393957092,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**earthsound** wrote: + +I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. + +Perhaps the images reported in this bug are saved similarly (progressive)?","**earthsound** wrote: + +I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. + +Perhaps the images reported in this bug are saved similarly (progressive)?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,26,TRUE,"[""**earthsound** wrote:\n\nI determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work."", 'Sorry for the noise.', 'Perhaps the images reported in this bug are saved similarly (progressive)?']",NA,1,Sorry for the noise.,SOCIAL CONVERSATION,, +17534,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**earthsound** wrote: + +I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. + +Perhaps the images reported in this bug are saved similarly (progressive)?",1393957092,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**earthsound** wrote: + +I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. + +Perhaps the images reported in this bug are saved similarly (progressive)?","**earthsound** wrote: + +I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. + +Perhaps the images reported in this bug are saved similarly (progressive)?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,26,TRUE,"[""**earthsound** wrote:\n\nI determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work."", 'Sorry for the noise.', 'Perhaps the images reported in this bug are saved similarly (progressive)?']",NA,1,Perhaps the images reported in this bug are saved similarly (progressive)?,INVESTIGATION AND EXPLORATION,, +17534,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**earthsound** wrote: + +I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. + +Perhaps the images reported in this bug are saved similarly (progressive)?",1393957092,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**earthsound** wrote: + +I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. + +Perhaps the images reported in this bug are saved similarly (progressive)?","**earthsound** wrote: + +I determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work. Sorry for the noise. + +Perhaps the images reported in this bug are saved similarly (progressive)?",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,26,TRUE,"[""**earthsound** wrote:\n\nI determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work."", 'Sorry for the noise.', 'Perhaps the images reported in this bug are saved similarly (progressive)?']",NA,1,"**earthsound** wrote:\n\nI determined that I'd hit bug 17645, saved the file as a baseline optimized JPEG rather than progressive and now the thumbnails work.",WORKAROUND,, +17535,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**earthsound** wrote: + +I have been seeing this error (as mentioned in comment 8, it's generating ""Error code:137"" now) for this particular image: + +https://commons.wikimedia.org/wiki/File:Aerial_drawing,_1885,_of_Birmingham,_Alabama.jpg + +The preview on that page (1280px width) is broken: + +https://upload.wikimedia.org/wikipedia/commons/thumb/6/66/Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg/1280px-Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg + +After a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later."" + +I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.",1393954894,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**earthsound** wrote: + +I have been seeing this error (as mentioned in comment 8, it's generating ""Error code:137"" now) for this particular image: + +https://commons.wikimedia.org/wiki/File:Aerial_drawing,_1885,_of_Birmingham,_Alabama.jpg + +The preview on that page (1280px width) is broken: + +https://upload.wikimedia.org/wikipedia/commons/thumb/6/66/Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg/1280px-Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg + +After a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later."" + +I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.","**earthsound** wrote: + +I have been seeing this error (as mentioned in comment 8, it's generating ""Error code:137"" now) for this particular image: + +URL + +The preview on that page (1280px width) is broken: + +URL + +After a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later."" + +I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,26,TRUE,"['**earthsound** wrote:\n\nI have been seeing this error (as mentioned in comment 8, it\'s generating ""Error code:137"" now) for this particular image: \n\nURL\n\nThe preview on that page (1280px width) is broken:\n\nURL\n\nAfter a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail.', 'Please try again later.""', 'I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.']",NA,1,"**earthsound** wrote:\n\nI have been seeing this error (as mentioned in comment 8, it\",OBSERVED BUG BEHAVIOR,, +17535,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**earthsound** wrote: + +I have been seeing this error (as mentioned in comment 8, it's generating ""Error code:137"" now) for this particular image: + +https://commons.wikimedia.org/wiki/File:Aerial_drawing,_1885,_of_Birmingham,_Alabama.jpg + +The preview on that page (1280px width) is broken: + +https://upload.wikimedia.org/wikipedia/commons/thumb/6/66/Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg/1280px-Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg + +After a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later."" + +I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.",1393954894,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**earthsound** wrote: + +I have been seeing this error (as mentioned in comment 8, it's generating ""Error code:137"" now) for this particular image: + +https://commons.wikimedia.org/wiki/File:Aerial_drawing,_1885,_of_Birmingham,_Alabama.jpg + +The preview on that page (1280px width) is broken: + +https://upload.wikimedia.org/wikipedia/commons/thumb/6/66/Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg/1280px-Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg + +After a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later."" + +I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.","**earthsound** wrote: + +I have been seeing this error (as mentioned in comment 8, it's generating ""Error code:137"" now) for this particular image: + +URL + +The preview on that page (1280px width) is broken: + +URL + +After a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later."" + +I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,26,TRUE,"['**earthsound** wrote:\n\nI have been seeing this error (as mentioned in comment 8, it\'s generating ""Error code:137"" now) for this particular image: \n\nURL\n\nThe preview on that page (1280px width) is broken:\n\nURL\n\nAfter a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail.', 'Please try again later.""', 'I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.']",NA,1,Error code:137,OBSERVED BUG BEHAVIOR,, +17535,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**earthsound** wrote: + +I have been seeing this error (as mentioned in comment 8, it's generating ""Error code:137"" now) for this particular image: + +https://commons.wikimedia.org/wiki/File:Aerial_drawing,_1885,_of_Birmingham,_Alabama.jpg + +The preview on that page (1280px width) is broken: + +https://upload.wikimedia.org/wikipedia/commons/thumb/6/66/Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg/1280px-Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg + +After a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later."" + +I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.",1393954894,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**earthsound** wrote: + +I have been seeing this error (as mentioned in comment 8, it's generating ""Error code:137"" now) for this particular image: + +https://commons.wikimedia.org/wiki/File:Aerial_drawing,_1885,_of_Birmingham,_Alabama.jpg + +The preview on that page (1280px width) is broken: + +https://upload.wikimedia.org/wikipedia/commons/thumb/6/66/Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg/1280px-Aerial_drawing%2C_1885%2C_of_Birmingham%2C_Alabama.jpg + +After a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later."" + +I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.","**earthsound** wrote: + +I have been seeing this error (as mentioned in comment 8, it's generating ""Error code:137"" now) for this particular image: + +URL + +The preview on that page (1280px width) is broken: + +URL + +After a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail. Please try again later."" + +I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.",NA,NA,NA,NA,NA,TRUE,c2,3,FALSE,NA,26,TRUE,"['**earthsound** wrote:\n\nI have been seeing this error (as mentioned in comment 8, it\'s generating ""Error code:137"" now) for this particular image: \n\nURL\n\nThe preview on that page (1280px width) is broken:\n\nURL\n\nAfter a few failed attempts, it will generate this error: ""Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail.', 'Please try again later.""', 'I have found that any size thumbnail up to a width of 1234px will generate OK, but anything 1235px width or larger fails 100% of the time, even though the full resolution image is OK.']",NA,1,"Error generating thumbnail - There have been too many recent failed attempts (5 or more) to render this thumbnail.', 'Please try again later.",OBSERVED BUG BEHAVIOR,, +17536,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"I get ""Error code: 137"" nowadays.",1393621965,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"I get ""Error code: 137"" nowadays.","I get ""Error code: 137"" nowadays.",NA,NA,NA,NA,NA,TRUE,c2,3,TRUE,NA,26,TRUE,"['I get ""Error code: 137"" nowadays.']",NA,1,"I get ""Error code: 137"" nowadays.",OBSERVED BUG BEHAVIOR,, +17537,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"(In reply to comment #6) +> I am getting a similar error when trying to download van Gogh: + +That's covered in bug 44071 instead.",1358500573,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"(In reply to comment #6) +> I am getting a similar error when trying to download van Gogh: + +That's covered in bug 44071 instead.","(In reply to comment #6) +QUOTE + +That's covered in bug 44071 instead.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-32,TRUE,"[""(In reply to comment #6)\nQUOTE\n\nThat's covered in bug 44071 instead.""]",NA,1,(In reply to comment #6)\nQUOTE\n\nThat's covered in bug 44071 instead.,ISSUE CONTENT MANAGEMENT,, +17538,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**DIA.Keyser** wrote: + +I am getting a similar error when trying to download any size larger than 2048px for this van Gogh: + +http://commons.wikimedia.org/wiki/File:Vincent_van_Gogh_-_De_slaapkamer_-_Google_Art_Project.jpg#file",1358449619,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**DIA.Keyser** wrote: + +I am getting a similar error when trying to download any size larger than 2048px for this van Gogh: + +http://commons.wikimedia.org/wiki/File:Vincent_van_Gogh_-_De_slaapkamer_-_Google_Art_Project.jpg#file","**DIA.Keyser** wrote: + +I am getting a similar error when trying to download any size larger than 2048px for this van Gogh: + +URL",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-32,TRUE,['**DIA.Keyser** wrote:\n\nI am getting a similar error when trying to download any size larger than 2048px for this van Gogh:\n\nURL'],NA,1,**DIA.Keyser** wrote:\n\nI am getting a similar error when trying to download any size larger than 2048px for this van Gogh:\n\nURL,BUG REPRODUCTION,, +17539,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**sumanah** wrote: + +Still reproducible at + +http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg + +When I change the width: + +https://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/72px-Carbon_River_pano_01A.jpg + +then it's fine. + +This may be related to bug 13493 (""Can't create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?"").",1351149257,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**sumanah** wrote: + +Still reproducible at + +http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg + +When I change the width: + +https://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/72px-Carbon_River_pano_01A.jpg + +then it's fine. + +This may be related to bug 13493 (""Can't create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?"").","**sumanah** wrote: + +Still reproducible at + +URL + +When I change the width: + +URL + +then it's fine. + +This may be related to bug 13493 (""Can't create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?"").",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-44,TRUE,"[""**sumanah** wrote:\n\nStill reproducible at\n\nURL\n\nWhen I change the width:\n\nURL\n\nthen it's fine."", 'This may be related to bug 13493 (""Can\'t create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?', '"").']",NA,1,**sumanah** wrote:\n\nStill reproducible at\n\nURL\n\nWhen I change the width:\n\nURL\n\nthen it's fine.,WORKAROUND,, +17539,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**sumanah** wrote: + +Still reproducible at + +http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg + +When I change the width: + +https://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/72px-Carbon_River_pano_01A.jpg + +then it's fine. + +This may be related to bug 13493 (""Can't create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?"").",1351149257,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**sumanah** wrote: + +Still reproducible at + +http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/6565px-Carbon_River_pano_01A.jpg + +When I change the width: + +https://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Carbon_River_pano_01A.jpg/72px-Carbon_River_pano_01A.jpg + +then it's fine. + +This may be related to bug 13493 (""Can't create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?"").","**sumanah** wrote: + +Still reproducible at + +URL + +When I change the width: + +URL + +then it's fine. + +This may be related to bug 13493 (""Can't create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?"").",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-44,TRUE,"[""**sumanah** wrote:\n\nStill reproducible at\n\nURL\n\nWhen I change the width:\n\nURL\n\nthen it's fine."", 'This may be related to bug 13493 (""Can\'t create thumbnail of images with a peculiar aspect ratio"") and bug 20312 (""Error creating thumbnail: Image was not scaled, is the requested width bigger than the source?', '"").']",NA,1,) and bug 20312 (,NA,, +17540,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"(In reply to comment #3) +> my guess is that it's failing to resize to a thumbnail that is 6565 pixels +> wide. It works for smaller images. + +Is it a Wikimedia or a MediaWiki issue then? (Still happening.)",1345141253,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"(In reply to comment #3) +> my guess is that it's failing to resize to a thumbnail that is 6565 pixels +> wide. It works for smaller images. + +Is it a Wikimedia or a MediaWiki issue then? (Still happening.)","(In reply to comment #3) +QUOTE +QUOTE + +Is it a Wikimedia or a MediaWiki issue then? (Still happening.)",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-54,TRUE,"['(In reply to comment #3)\nQUOTE\nQUOTE\n\nIs it a Wikimedia or a MediaWiki issue then?', '(Still happening.)']",NA,1,(In reply to comment #3)\nQUOTE\nQUOTE\n\nIs it a Wikimedia or a MediaWiki issue then?,INVESTIGATION AND EXPLORATION,, +17540,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"(In reply to comment #3) +> my guess is that it's failing to resize to a thumbnail that is 6565 pixels +> wide. It works for smaller images. + +Is it a Wikimedia or a MediaWiki issue then? (Still happening.)",1345141253,PHID-USER-v7bwpq3rs3zdxegibdbh,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"(In reply to comment #3) +> my guess is that it's failing to resize to a thumbnail that is 6565 pixels +> wide. It works for smaller images. + +Is it a Wikimedia or a MediaWiki issue then? (Still happening.)","(In reply to comment #3) +QUOTE +QUOTE + +Is it a Wikimedia or a MediaWiki issue then? (Still happening.)",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-54,TRUE,"['(In reply to comment #3)\nQUOTE\nQUOTE\n\nIs it a Wikimedia or a MediaWiki issue then?', '(Still happening.)']",NA,1,(Still happening.),SOCIAL CONVERSATION,, +17541,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**bhartshorne** wrote: + +my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.",1335995479,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**bhartshorne** wrote: + +my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.","**bhartshorne** wrote: + +my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-69,TRUE,"[""**bhartshorne** wrote:\n\nmy guess is that it's failing to resize to a thumbnail that is 6565 pixels wide."", 'It works for smaller images.', 'fwiw, convert is failing with exit code 153.']",NA,1,It works for smaller images.,TESTING ,, +17541,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**bhartshorne** wrote: + +my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.",1335995479,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**bhartshorne** wrote: + +my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.","**bhartshorne** wrote: + +my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-69,TRUE,"[""**bhartshorne** wrote:\n\nmy guess is that it's failing to resize to a thumbnail that is 6565 pixels wide."", 'It works for smaller images.', 'fwiw, convert is failing with exit code 153.']",NA,1,"fwiw, convert is failing with exit code 153.",OBSERVED BUG BEHAVIOR,, +17541,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"**bhartshorne** wrote: + +my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.",1335995479,PHID-USER-ynivjflmc2dcl6w5ut5v,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"**bhartshorne** wrote: + +my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.","**bhartshorne** wrote: + +my guess is that it's failing to resize to a thumbnail that is 6565 pixels wide. It works for smaller images. fwiw, convert is failing with exit code 153.",NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-69,TRUE,"[""**bhartshorne** wrote:\n\nmy guess is that it's failing to resize to a thumbnail that is 6565 pixels wide."", 'It works for smaller images.', 'fwiw, convert is failing with exit code 153.']",NA,1,**bhartshorne** wrote:\n\nmy guess is that it's failing to resize to a thumbnail that is 6565 pixels wide.,INVESTIGATION AND EXPLORATION,, +17542,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,"(In reply to comment #1) +> XID: 1391948384 + +This XID value seems to change on page refresh, by the way.",1335222024,PHID-USER-hyfm4swq76s4j642w46x,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,"(In reply to comment #1) +> XID: 1391948384 + +This XID value seems to change on page refresh, by the way.","(In reply to comment #1) +QUOTE + +This XID value seems to change on page refresh, by the way.",NA,NA,NA,NA,NA,TRUE,c2,1,TRUE,NA,-71,TRUE,"['(In reply to comment #1)\nQUOTE\n\nThis XID value seems to change on page refresh, by the way.']",NA,1,"(In reply to comment #1)\nQUOTE\n\nThis XID value seems to change on page refresh, by the way.",INVESTIGATION AND EXPLORATION,, +17543,HTTP 500 error when generating 6000px wide thumbnail of a 6912px wide and 12.5MB JPEG file,XID: 1391948384,1335214085,PHID-USER-ogbcrxm45oo3n3xe5q25,PHID-TASK-2sndzb2ydzwochmrxplf,task_subcomment,XID: 1391948384,XID: 1391948384,NA,NA,NA,NA,NA,TRUE,c2,1,FALSE,NA,-71,TRUE,['XID: 1391948384'],NA,1,XID: 1391948384,NA,, +20295,"Default upload visibility should be ""Public (No Login Required)""","Upstream: https://secure.phabricator.com/T6564 + +The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. + +If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",1415752813,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_description,"Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: https://secure.phabricator.com/T6564 + +The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. + +If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,","Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: URL + +The default visibility for files created at URL should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. + +If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",Low,25,1418242965,PHID-USER-hgn5uw2jafgjgfvxibhh,resolved,TRUE,c3,1,TRUE,FALSE,-34,TRUE,"['Default upload visibility should be ""Public (No Login Required)"".', 'Upstream: URL\n\nThe default visibility for files created at URL should be ""Public (No Login Required)"".', 'This is the same behavior as Bugzilla.', 'Currently, the default is ""All Users"" which requires a login.', 'If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,']",TRUE,1,"Default upload visibility should be ""Public (No Login Required)"".",EXPECTED BEHAVIOR,, +20295,"Default upload visibility should be ""Public (No Login Required)""","Upstream: https://secure.phabricator.com/T6564 + +The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. + +If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",1415752813,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_description,"Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: https://secure.phabricator.com/T6564 + +The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. + +If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,","Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: URL + +The default visibility for files created at URL should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. + +If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",Low,25,1418242965,PHID-USER-hgn5uw2jafgjgfvxibhh,resolved,TRUE,c3,1,TRUE,FALSE,-34,TRUE,"['Default upload visibility should be ""Public (No Login Required)"".', 'Upstream: URL\n\nThe default visibility for files created at URL should be ""Public (No Login Required)"".', 'This is the same behavior as Bugzilla.', 'Currently, the default is ""All Users"" which requires a login.', 'If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,']",TRUE,1,"Upstream: URL\n\nThe default visibility for files created at URL should be ""Public (No Login Required)"".",EXPECTED BEHAVIOR,, +20295,"Default upload visibility should be ""Public (No Login Required)""","Upstream: https://secure.phabricator.com/T6564 + +The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. + +If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",1415752813,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_description,"Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: https://secure.phabricator.com/T6564 + +The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. + +If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,","Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: URL + +The default visibility for files created at URL should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. + +If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",Low,25,1418242965,PHID-USER-hgn5uw2jafgjgfvxibhh,resolved,TRUE,c3,1,TRUE,FALSE,-34,TRUE,"['Default upload visibility should be ""Public (No Login Required)"".', 'Upstream: URL\n\nThe default visibility for files created at URL should be ""Public (No Login Required)"".', 'This is the same behavior as Bugzilla.', 'Currently, the default is ""All Users"" which requires a login.', 'If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,']",TRUE,1,This is the same behavior as Bugzilla.,INVESTIGATION AND EXPLORATION,, +20295,"Default upload visibility should be ""Public (No Login Required)""","Upstream: https://secure.phabricator.com/T6564 + +The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. + +If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",1415752813,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_description,"Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: https://secure.phabricator.com/T6564 + +The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. + +If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,","Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: URL + +The default visibility for files created at URL should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. + +If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",Low,25,1418242965,PHID-USER-hgn5uw2jafgjgfvxibhh,resolved,TRUE,c3,1,TRUE,FALSE,-34,TRUE,"['Default upload visibility should be ""Public (No Login Required)"".', 'Upstream: URL\n\nThe default visibility for files created at URL should be ""Public (No Login Required)"".', 'This is the same behavior as Bugzilla.', 'Currently, the default is ""All Users"" which requires a login.', 'If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,']",TRUE,1,"Currently, the default is ""All Users"" which requires a login.",INVESTIGATION AND EXPLORATION,, +20295,"Default upload visibility should be ""Public (No Login Required)""","Upstream: https://secure.phabricator.com/T6564 + +The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. + +If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",1415752813,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_description,"Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: https://secure.phabricator.com/T6564 + +The default visibility for files created at https://phabricator.wikimedia.org/file/upload/ should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. + +If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,","Default upload visibility should be ""Public (No Login Required)""./n/nUpstream: URL + +The default visibility for files created at URL should be ""Public (No Login Required)"". This is the same behavior as Bugzilla. Currently, the default is ""All Users"" which requires a login. + +If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",Low,25,1418242965,PHID-USER-hgn5uw2jafgjgfvxibhh,resolved,TRUE,c3,1,TRUE,FALSE,-34,TRUE,"['Default upload visibility should be ""Public (No Login Required)"".', 'Upstream: URL\n\nThe default visibility for files created at URL should be ""Public (No Login Required)"".', 'This is the same behavior as Bugzilla.', 'Currently, the default is ""All Users"" which requires a login.', 'If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,']",TRUE,1,"If possible, creating non-public files (or changing visibility of an existing file to non-public) should be limited to the Security group,",EXPECTED BEHAVIOR,, +20296,"Default upload visibility should be ""Public (No Login Required)""","This is the case now. + +https://phabricator.wikimedia.org/applications/view/PhabricatorFilesApplication/ states +> Default View Policy: Public (No Login Required) + +and going to https://phabricator.wikimedia.org/file/upload/ shows ""Public"" as default.",1418242965,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"This is the case now. + +https://phabricator.wikimedia.org/applications/view/PhabricatorFilesApplication/ states +> Default View Policy: Public (No Login Required) + +and going to https://phabricator.wikimedia.org/file/upload/ shows ""Public"" as default.","This is the case now. + +URL states +QUOTE + +and going to URL shows ""Public"" as default.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-30,TRUE,"['This is the case now.', 'URL states\nQUOTE\n\nand going to URL shows ""Public"" as default.']",NA,1,This is the case now.,TASK PROGRESS,, +20296,"Default upload visibility should be ""Public (No Login Required)""","This is the case now. + +https://phabricator.wikimedia.org/applications/view/PhabricatorFilesApplication/ states +> Default View Policy: Public (No Login Required) + +and going to https://phabricator.wikimedia.org/file/upload/ shows ""Public"" as default.",1418242965,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"This is the case now. + +https://phabricator.wikimedia.org/applications/view/PhabricatorFilesApplication/ states +> Default View Policy: Public (No Login Required) + +and going to https://phabricator.wikimedia.org/file/upload/ shows ""Public"" as default.","This is the case now. + +URL states +QUOTE + +and going to URL shows ""Public"" as default.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-30,TRUE,"['This is the case now.', 'URL states\nQUOTE\n\nand going to URL shows ""Public"" as default.']",NA,1,"URL states\nQUOTE\n\nand going to URL shows ""Public"" as default.",TASK PROGRESS,, +20297,"Default upload visibility should be ""Public (No Login Required)""","Upstream has resolved its part (creating the policy). https://secure.phabricator.com/applications/view/PhabricatorFilesApplication/ now specifies + +> Default View Policy: All Users + +After upgrading Wikimedia Phabricator, we need to set this policy as ""Public (No Login Required"".",1417378008,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"Upstream has resolved its part (creating the policy). https://secure.phabricator.com/applications/view/PhabricatorFilesApplication/ now specifies + +> Default View Policy: All Users + +After upgrading Wikimedia Phabricator, we need to set this policy as ""Public (No Login Required"".","Upstream has resolved its part (creating the policy). URL now specifies + +QUOTE + +After upgrading Wikimedia Phabricator, we need to set this policy as ""Public (No Login Required"".",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-31,TRUE,"['Upstream has resolved its part (creating the policy).', 'URL now specifies\n\nQUOTE\n\nAfter upgrading Wikimedia Phabricator, we need to set this policy as ""Public (No Login Required"".']",NA,1,Upstream has resolved its part (creating the policy).,TASK PROGRESS,, +20297,"Default upload visibility should be ""Public (No Login Required)""","Upstream has resolved its part (creating the policy). https://secure.phabricator.com/applications/view/PhabricatorFilesApplication/ now specifies + +> Default View Policy: All Users + +After upgrading Wikimedia Phabricator, we need to set this policy as ""Public (No Login Required"".",1417378008,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"Upstream has resolved its part (creating the policy). https://secure.phabricator.com/applications/view/PhabricatorFilesApplication/ now specifies + +> Default View Policy: All Users + +After upgrading Wikimedia Phabricator, we need to set this policy as ""Public (No Login Required"".","Upstream has resolved its part (creating the policy). URL now specifies + +QUOTE + +After upgrading Wikimedia Phabricator, we need to set this policy as ""Public (No Login Required"".",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-31,TRUE,"['Upstream has resolved its part (creating the policy).', 'URL now specifies\n\nQUOTE\n\nAfter upgrading Wikimedia Phabricator, we need to set this policy as ""Public (No Login Required"".']",NA,1,"URL now specifies\n\nQUOTE\n\nAfter upgrading Wikimedia Phabricator, we need to set this policy as ""Public (No Login Required"".",CONTRIBUTION AND COMMITMENT,, +20298,"Default upload visibility should be ""Public (No Login Required)""",This is Low priority upstream.,1417076243,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,This is Low priority upstream.,This is Low priority upstream.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-31,TRUE,['This is Low priority upstream.'],NA,1,This is Low priority upstream.,ISSUE CONTENT MANAGEMENT,, +20299,"Default upload visibility should be ""Public (No Login Required)""",">>! In T1248#21573, @Aklapper wrote: +> /me wondering why this is set to high priority? + +Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). + +>> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket. + +Thanks. + +>>! In T1248#21580, @Qgil wrote: +> I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +Filed as https://secure.phabricator.com/T6564 (""Set default permissions for file uploads to same as File application"") + +> I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +Filed as https://secure.phabricator.com/T6565 (""Allow limiting which ""Can View"" settings can be used for files""). +",1416018869,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,">>! In T1248#21573, @Aklapper wrote: +> /me wondering why this is set to high priority? + +Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). + +>> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket. + +Thanks. + +>>! In T1248#21580, @Qgil wrote: +> I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +Filed as https://secure.phabricator.com/T6564 (""Set default permissions for file uploads to same as File application"") + +> I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +Filed as https://secure.phabricator.com/T6565 (""Allow limiting which ""Can View"" settings can be used for files""). +","QUOTE +QUOTE + +Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). + +QUOTE + +Thanks. + +QUOTE +QUOTE + +Filed as URL (""Set default permissions for file uploads to same as File application"") + +QUOTE + +Filed as URL (""Allow limiting which ""Can View"" settings can be used for files""). +",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-33,TRUE,"[""QUOTE\nQUOTE\n\nBecause it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files."", ""However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it)."", 'QUOTE\n\nThanks.', 'QUOTE\nQUOTE\n\nFiled as URL (""Set default permissions for file uploads to same as File application"")\n \nQUOTE\n\nFiled as URL (""Allow limiting which ""Can View"" settings can be used for files"").']",NA,1,QUOTE\n\nThanks.,SOCIAL CONVERSATION,, +20299,"Default upload visibility should be ""Public (No Login Required)""",">>! In T1248#21573, @Aklapper wrote: +> /me wondering why this is set to high priority? + +Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). + +>> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket. + +Thanks. + +>>! In T1248#21580, @Qgil wrote: +> I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +Filed as https://secure.phabricator.com/T6564 (""Set default permissions for file uploads to same as File application"") + +> I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +Filed as https://secure.phabricator.com/T6565 (""Allow limiting which ""Can View"" settings can be used for files""). +",1416018869,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,">>! In T1248#21573, @Aklapper wrote: +> /me wondering why this is set to high priority? + +Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). + +>> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket. + +Thanks. + +>>! In T1248#21580, @Qgil wrote: +> I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +Filed as https://secure.phabricator.com/T6564 (""Set default permissions for file uploads to same as File application"") + +> I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +Filed as https://secure.phabricator.com/T6565 (""Allow limiting which ""Can View"" settings can be used for files""). +","QUOTE +QUOTE + +Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). + +QUOTE + +Thanks. + +QUOTE +QUOTE + +Filed as URL (""Set default permissions for file uploads to same as File application"") + +QUOTE + +Filed as URL (""Allow limiting which ""Can View"" settings can be used for files""). +",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-33,TRUE,"[""QUOTE\nQUOTE\n\nBecause it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files."", ""However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it)."", 'QUOTE\n\nThanks.', 'QUOTE\nQUOTE\n\nFiled as URL (""Set default permissions for file uploads to same as File application"")\n \nQUOTE\n\nFiled as URL (""Allow limiting which ""Can View"" settings can be used for files"").']",NA,1,"QUOTE\nQUOTE\n\nFiled as URL (""Set default permissions for file uploads to same as File application"")\n \nQUOTE\n\nFiled as URL (""Allow limiting which ""Can View"" settings can be used for files"").",ISSUE CONTENT MANAGEMENT,, +20299,"Default upload visibility should be ""Public (No Login Required)""",">>! In T1248#21573, @Aklapper wrote: +> /me wondering why this is set to high priority? + +Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). + +>> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket. + +Thanks. + +>>! In T1248#21580, @Qgil wrote: +> I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +Filed as https://secure.phabricator.com/T6564 (""Set default permissions for file uploads to same as File application"") + +> I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +Filed as https://secure.phabricator.com/T6565 (""Allow limiting which ""Can View"" settings can be used for files""). +",1416018869,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,">>! In T1248#21573, @Aklapper wrote: +> /me wondering why this is set to high priority? + +Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). + +>> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket. + +Thanks. + +>>! In T1248#21580, @Qgil wrote: +> I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +Filed as https://secure.phabricator.com/T6564 (""Set default permissions for file uploads to same as File application"") + +> I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +Filed as https://secure.phabricator.com/T6565 (""Allow limiting which ""Can View"" settings can be used for files""). +","QUOTE +QUOTE + +Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). + +QUOTE + +Thanks. + +QUOTE +QUOTE + +Filed as URL (""Set default permissions for file uploads to same as File application"") + +QUOTE + +Filed as URL (""Allow limiting which ""Can View"" settings can be used for files""). +",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-33,TRUE,"[""QUOTE\nQUOTE\n\nBecause it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files."", ""However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it)."", 'QUOTE\n\nThanks.', 'QUOTE\nQUOTE\n\nFiled as URL (""Set default permissions for file uploads to same as File application"")\n \nQUOTE\n\nFiled as URL (""Allow limiting which ""Can View"" settings can be used for files"").']",NA,1,QUOTE\nQUOTE\n\nBecause it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files.,SOLUTION USAGE,, +20299,"Default upload visibility should be ""Public (No Login Required)""",">>! In T1248#21573, @Aklapper wrote: +> /me wondering why this is set to high priority? + +Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). + +>> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket. + +Thanks. + +>>! In T1248#21580, @Qgil wrote: +> I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +Filed as https://secure.phabricator.com/T6564 (""Set default permissions for file uploads to same as File application"") + +> I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +Filed as https://secure.phabricator.com/T6565 (""Allow limiting which ""Can View"" settings can be used for files""). +",1416018869,PHID-USER-dw53c5cb2qfhyemej57o,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,">>! In T1248#21573, @Aklapper wrote: +> /me wondering why this is set to high priority? + +Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). + +>> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket. + +Thanks. + +>>! In T1248#21580, @Qgil wrote: +> I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +Filed as https://secure.phabricator.com/T6564 (""Set default permissions for file uploads to same as File application"") + +> I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +Filed as https://secure.phabricator.com/T6565 (""Allow limiting which ""Can View"" settings can be used for files""). +","QUOTE +QUOTE + +Because it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files. However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it). + +QUOTE + +Thanks. + +QUOTE +QUOTE + +Filed as URL (""Set default permissions for file uploads to same as File application"") + +QUOTE + +Filed as URL (""Allow limiting which ""Can View"" settings can be used for files""). +",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-33,TRUE,"[""QUOTE\nQUOTE\n\nBecause it's important that users (simply using the default setting without thinking about it) don't create a huge mess of incorrectly-permissioned files."", ""However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it)."", 'QUOTE\n\nThanks.', 'QUOTE\nQUOTE\n\nFiled as URL (""Set default permissions for file uploads to same as File application"")\n \nQUOTE\n\nFiled as URL (""Allow limiting which ""Can View"" settings can be used for files"").']",NA,1,"However, it's true that on further review it's not that bad since most people probably won't even know about the upload file page (the drag and drop message when you click the upload icon does not currently mention it).",SOLUTION USAGE,, +20300,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781265,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. +SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"First I wanted to check whether the files created via drag&drop are public, and they are.",INVESTIGATION AND EXPLORATION,, +20300,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781265,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. +SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"Then I checked the files at bugzillapreview, and they are also public.",INVESTIGATION AND EXPLORATION,, +20300,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781265,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. +SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority.",INVESTIGATION AND EXPLORATION,, +20300,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781265,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. +SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,I could not find in phab-01 any configuration to set the default to Public.,INVESTIGATION AND EXPLORATION,, +20300,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781265,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. +SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).",SOLUTION DISCUSSION,, +20300,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781265,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. +SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",CONTRIBUTION AND COMMITMENT,, +20300,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781265,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. +SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problem affects exclusively files uploaded via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private.",INVESTIGATION AND EXPLORATION,, +20301,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781207,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via URL Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. +SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problems affects exclusively via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"First I wanted to check whether the files created via drag&drop are public, and they are.",INVESTIGATION AND EXPLORATION,, +20301,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781207,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via URL Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. +SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problems affects exclusively via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"Then I checked the files at bugzillapreview, and they are also public.",INVESTIGATION AND EXPLORATION,, +20301,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781207,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via URL Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. +SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problems affects exclusively via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"Therefore, this problems affects exclusively via URL Still a problem, but not high priority.",INVESTIGATION AND EXPLORATION,, +20301,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781207,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via URL Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. +SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problems affects exclusively via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,I could not find in phab-01 any configuration to set the default to Public.,INVESTIGATION AND EXPLORATION,, +20301,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781207,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via URL Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. +SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problems affects exclusively via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).",SOLUTION DISCUSSION,, +20301,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781207,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via URL Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. +SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problems affects exclusively via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",CONTRIBUTION AND COMMITMENT,, +20301,"Default upload visibility should be ""Public (No Login Required)""","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",1415781207,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via https://phabricator.wikimedia.org/file/upload/. Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. + +@Mattflaschen , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).","First I wanted to check whether the files created via drag&drop are public, and they are. Then I checked the files at bugzillapreview, and they are also public. Therefore, this problems affects exclusively via URL Still a problem, but not high priority. + +I could not find in phab-01 any configuration to set the default to Public. It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public). + +I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private. +SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['First I wanted to check whether the files created via drag&drop are public, and they are.', 'Then I checked the files at bugzillapreview, and they are also public.', 'Therefore, this problems affects exclusively via URL Still a problem, but not high priority.', 'I could not find in phab-01 any configuration to set the default to Public.', 'It would make sense for new uploads to have the same default Can View policy as ""Can Use Application"" (which is set to Public).', ""I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private."", 'SCREEN_NAME , since you have experience reporting problems upstream, would you like to report these two (separate or together, your choice).']",NA,1,"I couldn't find either a policy to limit who can set the Can View policy of files uploaded (just like Maniphest has one, and this is why regular users only have the option of public/private.",INVESTIGATION AND EXPLORATION,, +20302,"Default upload visibility should be ""Public (No Login Required)""","Test uploading F783 right here. + +{F783}",1415780409,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"Test uploading F783 right here. + +{F783}","Test uploading F783 right here. + +{F783}",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['Test uploading F783 right here.', '{F783}']",NA,1,Test uploading F783 right here.,TESTING ,, +20302,"Default upload visibility should be ""Public (No Login Required)""","Test uploading F783 right here. + +{F783}",1415780409,PHID-USER-lluzkul4z7us4sxkayss,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"Test uploading F783 right here. + +{F783}","Test uploading F783 right here. + +{F783}",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['Test uploading F783 right here.', '{F783}']",NA,1,{F783},NA,, +20303,"Default upload visibility should be ""Public (No Login Required)""","/me wondering why this is set to high priority? + +> (or changing visibility of an existing file to non-public) + +For the records, https://www.mediawiki.org/wiki/Phabricator/Help#Uploading_file_attachments states: +> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket.",1415755584,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"/me wondering why this is set to high priority? + +> (or changing visibility of an existing file to non-public) + +For the records, https://www.mediawiki.org/wiki/Phabricator/Help#Uploading_file_attachments states: +> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket.","/me wondering why this is set to high priority? + +QUOTE + +For the records, URL states: +QUOTE",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['/me wondering why this is set to high priority?', 'QUOTE\n\nFor the records, URL states:\nQUOTE']",NA,1,/me wondering why this is set to high priority?,ISSUE CONTENT MANAGEMENT,, +20303,"Default upload visibility should be ""Public (No Login Required)""","/me wondering why this is set to high priority? + +> (or changing visibility of an existing file to non-public) + +For the records, https://www.mediawiki.org/wiki/Phabricator/Help#Uploading_file_attachments states: +> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket.",1415755584,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-x2m6e5ivyo5hc3pydkvx,task_subcomment,"/me wondering why this is set to high priority? + +> (or changing visibility of an existing file to non-public) + +For the records, https://www.mediawiki.org/wiki/Phabricator/Help#Uploading_file_attachments states: +> Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a restricted security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricted access together with the creation of a restricted (security) ticket.","/me wondering why this is set to high priority? + +QUOTE + +For the records, URL states: +QUOTE",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-34,TRUE,"['/me wondering why this is set to high priority?', 'QUOTE\n\nFor the records, URL states:\nQUOTE']",NA,1,"QUOTE\n\nFor the records, URL states:\nQUOTE",SOCIAL CONVERSATION,, +21119,Fix cert handling in our ldap servers,"We just had an ldap outage because the ldap cert setup is... unexpected. + + +[4:55pm] paravoid: this is pretty broken in general +[4:55pm] Coren: paravoid: What was the issue? +[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA +[4:55pm] paravoid: which is pretty broken +[4:55pm] paravoid: that's a single intermediate CA, not a certificate store +[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root +[4:56pm] paravoid: also quite broken +... +paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",1433369195,PHID-USER-22bsa5u75jz3ci3wnplu,PHID-TASK-yw6zst7vw2qunulr4wp3,task_description,"Fix cert handling in our ldap servers./n/nWe just had an ldap outage because the ldap cert setup is... unexpected. + + +[4:55pm] paravoid: this is pretty broken in general +[4:55pm] Coren: paravoid: What was the issue? +[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA +[4:55pm] paravoid: which is pretty broken +[4:55pm] paravoid: that's a single intermediate CA, not a certificate store +[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root +[4:56pm] paravoid: also quite broken +... +paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain","Fix cert handling in our ldap servers./n/nWe just had an ldap outage because the ldap cert setup is... unexpected. + + +[4:55pm] paravoid: this is pretty broken in general +[4:55pm] Coren: paravoid: What was the issue? +[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA +[4:55pm] paravoid: which is pretty broken +[4:55pm] paravoid: that's a single intermediate CA, not a certificate store +[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root +[4:56pm] paravoid: also quite broken +... +paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",Needs Triage,90,1433372141,PHID-USER-ktuojnvco4fpzmyhzyaf,resolved,TRUE,c3,1,TRUE,FALSE,-5,TRUE,"['Fix cert handling in our ldap servers.', 'We just had an ldap outage because the ldap cert setup is... unexpected.', '[4:55pm] paravoid: this is pretty broken in general\n[4:55pm] Coren: paravoid: What was the issue?', ""[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA\n[4:55pm] paravoid: which is pretty broken\n[4:55pm] paravoid: that's a single intermediate CA, not a certificate store\n[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root\n[4:56pm] paravoid: also quite broken\n...\nparavoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain""]",TRUE,1,Fix cert handling in our ldap servers.,OBSERVED BUG BEHAVIOR,, +21119,Fix cert handling in our ldap servers,"We just had an ldap outage because the ldap cert setup is... unexpected. + + +[4:55pm] paravoid: this is pretty broken in general +[4:55pm] Coren: paravoid: What was the issue? +[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA +[4:55pm] paravoid: which is pretty broken +[4:55pm] paravoid: that's a single intermediate CA, not a certificate store +[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root +[4:56pm] paravoid: also quite broken +... +paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",1433369195,PHID-USER-22bsa5u75jz3ci3wnplu,PHID-TASK-yw6zst7vw2qunulr4wp3,task_description,"Fix cert handling in our ldap servers./n/nWe just had an ldap outage because the ldap cert setup is... unexpected. + + +[4:55pm] paravoid: this is pretty broken in general +[4:55pm] Coren: paravoid: What was the issue? +[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA +[4:55pm] paravoid: which is pretty broken +[4:55pm] paravoid: that's a single intermediate CA, not a certificate store +[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root +[4:56pm] paravoid: also quite broken +... +paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain","Fix cert handling in our ldap servers./n/nWe just had an ldap outage because the ldap cert setup is... unexpected. + + +[4:55pm] paravoid: this is pretty broken in general +[4:55pm] Coren: paravoid: What was the issue? +[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA +[4:55pm] paravoid: which is pretty broken +[4:55pm] paravoid: that's a single intermediate CA, not a certificate store +[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root +[4:56pm] paravoid: also quite broken +... +paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",Needs Triage,90,1433372141,PHID-USER-ktuojnvco4fpzmyhzyaf,resolved,TRUE,c3,1,TRUE,FALSE,-5,TRUE,"['Fix cert handling in our ldap servers.', 'We just had an ldap outage because the ldap cert setup is... unexpected.', '[4:55pm] paravoid: this is pretty broken in general\n[4:55pm] Coren: paravoid: What was the issue?', ""[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA\n[4:55pm] paravoid: which is pretty broken\n[4:55pm] paravoid: that's a single intermediate CA, not a certificate store\n[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root\n[4:56pm] paravoid: also quite broken\n...\nparavoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain""]",TRUE,1,We just had an ldap outage because the ldap cert setup is... unexpected.,OBSERVED BUG BEHAVIOR,, +21119,Fix cert handling in our ldap servers,"We just had an ldap outage because the ldap cert setup is... unexpected. + + +[4:55pm] paravoid: this is pretty broken in general +[4:55pm] Coren: paravoid: What was the issue? +[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA +[4:55pm] paravoid: which is pretty broken +[4:55pm] paravoid: that's a single intermediate CA, not a certificate store +[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root +[4:56pm] paravoid: also quite broken +... +paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",1433369195,PHID-USER-22bsa5u75jz3ci3wnplu,PHID-TASK-yw6zst7vw2qunulr4wp3,task_description,"Fix cert handling in our ldap servers./n/nWe just had an ldap outage because the ldap cert setup is... unexpected. + + +[4:55pm] paravoid: this is pretty broken in general +[4:55pm] Coren: paravoid: What was the issue? +[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA +[4:55pm] paravoid: which is pretty broken +[4:55pm] paravoid: that's a single intermediate CA, not a certificate store +[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root +[4:56pm] paravoid: also quite broken +... +paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain","Fix cert handling in our ldap servers./n/nWe just had an ldap outage because the ldap cert setup is... unexpected. + + +[4:55pm] paravoid: this is pretty broken in general +[4:55pm] Coren: paravoid: What was the issue? +[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA +[4:55pm] paravoid: which is pretty broken +[4:55pm] paravoid: that's a single intermediate CA, not a certificate store +[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root +[4:56pm] paravoid: also quite broken +... +paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",Needs Triage,90,1433372141,PHID-USER-ktuojnvco4fpzmyhzyaf,resolved,TRUE,c3,1,TRUE,FALSE,-5,TRUE,"['Fix cert handling in our ldap servers.', 'We just had an ldap outage because the ldap cert setup is... unexpected.', '[4:55pm] paravoid: this is pretty broken in general\n[4:55pm] Coren: paravoid: What was the issue?', ""[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA\n[4:55pm] paravoid: which is pretty broken\n[4:55pm] paravoid: that's a single intermediate CA, not a certificate store\n[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root\n[4:56pm] paravoid: also quite broken\n...\nparavoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain""]",TRUE,1,[4:55pm] paravoid: this is pretty broken in general\n[4:55pm] Coren: paravoid: What was the issue?,INVESTIGATION AND EXPLORATION,, +21119,Fix cert handling in our ldap servers,"We just had an ldap outage because the ldap cert setup is... unexpected. + + +[4:55pm] paravoid: this is pretty broken in general +[4:55pm] Coren: paravoid: What was the issue? +[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA +[4:55pm] paravoid: which is pretty broken +[4:55pm] paravoid: that's a single intermediate CA, not a certificate store +[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root +[4:56pm] paravoid: also quite broken +... +paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",1433369195,PHID-USER-22bsa5u75jz3ci3wnplu,PHID-TASK-yw6zst7vw2qunulr4wp3,task_description,"Fix cert handling in our ldap servers./n/nWe just had an ldap outage because the ldap cert setup is... unexpected. + + +[4:55pm] paravoid: this is pretty broken in general +[4:55pm] Coren: paravoid: What was the issue? +[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA +[4:55pm] paravoid: which is pretty broken +[4:55pm] paravoid: that's a single intermediate CA, not a certificate store +[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root +[4:56pm] paravoid: also quite broken +... +paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain","Fix cert handling in our ldap servers./n/nWe just had an ldap outage because the ldap cert setup is... unexpected. + + +[4:55pm] paravoid: this is pretty broken in general +[4:55pm] Coren: paravoid: What was the issue? +[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA +[4:55pm] paravoid: which is pretty broken +[4:55pm] paravoid: that's a single intermediate CA, not a certificate store +[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root +[4:56pm] paravoid: also quite broken +... +paravoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",Needs Triage,90,1433372141,PHID-USER-ktuojnvco4fpzmyhzyaf,resolved,TRUE,c3,1,TRUE,FALSE,-5,TRUE,"['Fix cert handling in our ldap servers.', 'We just had an ldap outage because the ldap cert setup is... unexpected.', '[4:55pm] paravoid: this is pretty broken in general\n[4:55pm] Coren: paravoid: What was the issue?', ""[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA\n[4:55pm] paravoid: which is pretty broken\n[4:55pm] paravoid: that's a single intermediate CA, not a certificate store\n[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root\n[4:56pm] paravoid: also quite broken\n...\nparavoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain""]",TRUE,1,"[4:55pm] paravoid: ldap.conf was pointing to /etc/ssl/certs/GlobalSign_CA.pem as the CA\n[4:55pm] paravoid: which is pretty broken\n[4:55pm] paravoid: that's a single intermediate CA, not a certificate store\n[4:56pm] paravoid: also, OpenDJ seems to serve just its certificate, not a chain up to a root\n[4:56pm] paravoid: also quite broken\n...\nparavoid: there is no easy way to fix this, the easiest one would be to fix OpenDJ to serve the full chain",INVESTIGATION AND EXPLORATION,, +21120,Fix cert handling in our ldap servers,"This is fixed in puppet with rOPUP1a195544eaed. The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus. `openssl s_client` seems to verify that the full chain is being served now.",1433372134,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-yw6zst7vw2qunulr4wp3,task_subcomment,"This is fixed in puppet with rOPUP1a195544eaed. The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus. `openssl s_client` seems to verify that the full chain is being served now.","This is fixed in puppet with rOPUP1a195544eaed. The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus. CODE seems to verify that the full chain is being served now.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-5,TRUE,"['This is fixed in puppet with rOPUP1a195544eaed.', ""The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus."", 'CODE seems to verify that the full chain is being served now.']",NA,1,This is fixed in puppet with rOPUP1a195544eaed.,TASK PROGRESS,, +21120,Fix cert handling in our ldap servers,"This is fixed in puppet with rOPUP1a195544eaed. The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus. `openssl s_client` seems to verify that the full chain is being served now.",1433372134,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-yw6zst7vw2qunulr4wp3,task_subcomment,"This is fixed in puppet with rOPUP1a195544eaed. The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus. `openssl s_client` seems to verify that the full chain is being served now.","This is fixed in puppet with rOPUP1a195544eaed. The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus. CODE seems to verify that the full chain is being served now.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-5,TRUE,"['This is fixed in puppet with rOPUP1a195544eaed.', ""The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus."", 'CODE seems to verify that the full chain is being served now.']",NA,1,CODE seems to verify that the full chain is being served now.,TASK PROGRESS,, +21120,Fix cert handling in our ldap servers,"This is fixed in puppet with rOPUP1a195544eaed. The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus. `openssl s_client` seems to verify that the full chain is being served now.",1433372134,PHID-USER-ktuojnvco4fpzmyhzyaf,PHID-TASK-yw6zst7vw2qunulr4wp3,task_subcomment,"This is fixed in puppet with rOPUP1a195544eaed. The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus. `openssl s_client` seems to verify that the full chain is being served now.","This is fixed in puppet with rOPUP1a195544eaed. The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus. CODE seems to verify that the full chain is being served now.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-5,TRUE,"['This is fixed in puppet with rOPUP1a195544eaed.', ""The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus."", 'CODE seems to verify that the full chain is being served now.']",NA,1,"The puppet code is pretty bad though and it wouldn't automatically regenerate the PKCS12 bundle, so I did this manually and restarted OpenDJ on both neptunium and nembus.",CONTRIBUTION AND COMMITMENT,, +21121,Fix cert handling in our ldap servers,"Change 215808 merged by Faidon Liambotis: +ldap: serve the full certificate chain for TLS + +[[https://gerrit.wikimedia.org/r/215808]]",1433371991,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-yw6zst7vw2qunulr4wp3,task_subcomment,"Change 215808 merged by Faidon Liambotis: +ldap: serve the full certificate chain for TLS + +[[https://gerrit.wikimedia.org/r/215808]]","Change 215808 merged by Faidon Liambotis: +ldap: serve the full certificate chain for TLS + +[[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-5,TRUE,['Change 215808 merged by Faidon Liambotis:\nldap: serve the full certificate chain for TLS\n\n[[GERRIT_URL]]'],NA,1,Change 215808 merged by Faidon Liambotis:\nldap: serve the full certificate chain for TLS\n\n[[GERRIT_URL]],TASK PROGRESS,, +21122,Fix cert handling in our ldap servers,"Change 215808 had a related patch set uploaded (by Faidon Liambotis): +ldap: serve the full certificate chain for TLS + +[[https://gerrit.wikimedia.org/r/215808]] +",1433371918,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-yw6zst7vw2qunulr4wp3,task_subcomment,"Change 215808 had a related patch set uploaded (by Faidon Liambotis): +ldap: serve the full certificate chain for TLS + +[[https://gerrit.wikimedia.org/r/215808]] +","Change 215808 had a related patch set uploaded (by Faidon Liambotis): +ldap: serve the full certificate chain for TLS + +[[GERRIT_URL]] +",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-5,TRUE,['Change 215808 had a related patch set uploaded (by Faidon Liambotis):\nldap: serve the full certificate chain for TLS\n\n[[GERRIT_URL]]'],NA,1,Change 215808 had a related patch set uploaded (by Faidon Liambotis):\nldap: serve the full certificate chain for TLS\n\n[[GERRIT_URL]],TASK PROGRESS,, +22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL + + - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,openssl 1.0.2 packaging for jessie.,EXPECTED BEHAVIOR,, +22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL + + - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.,SOLUTION DISCUSSION,, +22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL + + - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.,SOLUTION DISCUSSION,, +22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL + + - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,"Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",SOLUTION DISCUSSION,, +22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL + + - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN.",SOLUTION DISCUSSION,, +22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL + + - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,"It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment.",SOLUTION DISCUSSION,, +22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL + + - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,"Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]].",POTENTIAL NEW ISSUES AND REQUESTS,, +22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL + + - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,"Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has.",INVESTIGATION AND EXPLORATION,, +22432,openssl 1.0.2 packaging for jessie,"We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",1435522095,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_description,"openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ https://packages.debian.org/stretch/openssl | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ + + - **Sec Non-Issue** According to [[ https://security-tracker.debian.org/tracker/source-package/openssl | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ https://security-tracker.debian.org/tracker/CVE-2015-4000 | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.","openssl 1.0.2 packaging for jessie./n/nWe need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN. + +It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment. + +Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here: + + - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]. Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices. Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards. Cloudflare's general blog post on the topic: URL + + - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has. I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this: + 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue. + 2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC. Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.",Medium,50,1435783333,PHID-USER-lhtlnmkdbzlz6pbxaqdd,resolved,TRUE,c3,2,TRUE,TRUE,-1,TRUE,"['openssl 1.0.2 packaging for jessie.', ""We need to switch to openssl 1.0.2 on jessie in support of multiple certs for ECDSA in the short term, and regardless of that we're going to need it by later this year to start trying out HTTP/2 + ALPN."", ""It's currently [[ URL | available in Stretch ]], and I've installed the stretch binary packages straight onto a jessie test host without issue, but we'd want to rebuild for any real deployment."", ""Aside from the basic re-build on jessie, I think there's one extra patch we should consider, and one security non-issue that should at least be mentioned here:\n\n - **Patch** - We could patch in [[ URL | a high-perf implementation of chacha20poly1305 from Cloudflare ]]."", 'Supposedly this is a secure option for reducing mobile CPU usage (and thus slowness) and is supported by at least some Android 5 devices.', 'Deciding whether to include this patch would be separate from actually turning on support for it in our cipher list, but I think we may as well add the patch to give ourselves the option and then we can make the ciphersuite decision afterwards.', ""Cloudflare's general blog post on the topic: URL\n\n - **Sec Non-Issue** According to [[ URL | Debian's Security Tracker ]], the Stretch 1.0.2c-1 package lacks fixes for [[ URL | CVE-2015-4000 / Logjam ]] which our jessie 1.0.1 package already has."", ""I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue."", '2. openssl-1.0.2 already limits the attack further by setting minimum key sizes for DHE and EC.', 'Even if we did for some unfathomable reason turn DHE_EXPORT ciphers on, the downgrade would be limited to 768-bit rather than the 512-bit possible with unpatched 1.0.1.']",TRUE,1,"I bring this up mostly because if I didn't, someone else probably would, but I don't think we need to patch for this:\n 1. we're not enabling DHE or export-grade ciphers in our server configs, so we're not generally vulnerable to this in the first place due to our configuration, regardless of the code-level issue.",INVESTIGATION AND EXPLORATION,, +22433,openssl 1.0.2 packaging for jessie,">>! In T104143#1877286, @Remware wrote: +> My question was related to standard Debian, thanks for the answer, I hope your are pushing upstream at some point... + +jessie will stick with 1.0.1, the update to 1.0.2 was requested by the OpenSSL maintainer during the freeze, but declined by the release managers: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767661",1450092543,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,">>! In T104143#1877286, @Remware wrote: +> My question was related to standard Debian, thanks for the answer, I hope your are pushing upstream at some point... + +jessie will stick with 1.0.1, the update to 1.0.2 was requested by the OpenSSL maintainer during the freeze, but declined by the release managers: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767661","QUOTE +QUOTE + +jessie will stick with 1.0.1, the update to 1.0.2 was requested by the OpenSSL maintainer during the freeze, but declined by the release managers: URL",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,23,TRUE,"['QUOTE\nQUOTE\n\njessie will stick with 1.0.1, the update to 1.0.2 was requested by the OpenSSL maintainer during the freeze, but declined by the release managers: URL']",NA,1,"QUOTE\nQUOTE\n\njessie will stick with 1.0.1, the update to 1.0.2 was requested by the OpenSSL maintainer during the freeze, but declined by the release managers: URL",SOLUTION USAGE,, +22434,openssl 1.0.2 packaging for jessie,"My question was related to standard Debian, thanks for the answer, I hope your are pushing upstream at some point...",1450092286,PHID-USER-3rlfi3mnvi7zx76ucrz2,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"My question was related to standard Debian, thanks for the answer, I hope your are pushing upstream at some point...","My question was related to standard Debian, thanks for the answer, I hope your are pushing upstream at some point...",NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,23,TRUE,"['My question was related to standard Debian, thanks for the answer, I hope your are pushing upstream at some point...']",NA,1,"My question was related to standard Debian, thanks for the answer, I hope your are pushing upstream at some point...",CONTRIBUTION AND COMMITMENT ,, +22435,openssl 1.0.2 packaging for jessie,"I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g. nginx) against it as well.",1450092042,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g. nginx) against it as well.","I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g. nginx) against it as well.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,23,TRUE,"[""I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g."", 'nginx) against it as well.']",NA,1,nginx) against it as well.,NA,, +22435,openssl 1.0.2 packaging for jessie,"I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g. nginx) against it as well.",1450092042,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g. nginx) against it as well.","I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g. nginx) against it as well.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,23,TRUE,"[""I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g."", 'nginx) against it as well.']",NA,1,"I'm not sure what the context of your question is, but yes we have been running an openssl-1.0.2 package on our jessie hosts from our jessie-wikimedia repo since back when this was resolved, and rebuilding some of our other custom packages (e.g.",INVESTIGATION AND EXPLORATION,, +22436,openssl 1.0.2 packaging for jessie,"@remware: If you're referring with stable to standard Debian jessie, then no. The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.",1450091917,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"@remware: If you're referring with stable to standard Debian jessie, then no. The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.","SCREEN_NAME: If you're referring with stable to standard Debian jessie, then no. The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,23,TRUE,"[""SCREEN_NAME: If you're referring with stable to standard Debian jessie, then no."", 'The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.']",NA,1,"The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.",SOLUTION DISCUSSION ,, +22436,openssl 1.0.2 packaging for jessie,"@remware: If you're referring with stable to standard Debian jessie, then no. The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.",1450091917,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"@remware: If you're referring with stable to standard Debian jessie, then no. The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.","SCREEN_NAME: If you're referring with stable to standard Debian jessie, then no. The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.",NA,NA,NA,NA,NA,TRUE,c3,3,TRUE,NA,23,TRUE,"[""SCREEN_NAME: If you're referring with stable to standard Debian jessie, then no."", 'The latest version of openssl 1.0.2 is available in jessie-wikimedia, though.']",NA,1,"SCREEN_NAME: If you're referring with stable to standard Debian jessie, then no.",SOLUTION DISCUSSION,, +22437,openssl 1.0.2 packaging for jessie,Do we have jessie package already in stable ?,1450091718,PHID-USER-3rlfi3mnvi7zx76ucrz2,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,Do we have jessie package already in stable ?,Do we have jessie package already in stable ?,NA,NA,NA,NA,NA,TRUE,c3,3,FALSE,NA,23,TRUE,['Do we have jessie package already in stable ?'],NA,1,Do we have jessie package already in stable ?,INVESTIGATION AND EXPLORATION,, +22438,openssl 1.0.2 packaging for jessie,">>! In T104143#1411211, @BBlack wrote: +> (or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?) + +That would work as well; the udebs are only needed for d-i.",1435605939,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,">>! In T104143#1411211, @BBlack wrote: +> (or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?) + +That would work as well; the udebs are only needed for d-i.","QUOTE +QUOTE + +That would work as well; the udebs are only needed for d-i.",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,['QUOTE\nQUOTE\n\nThat would work as well; the udebs are only needed for d-i.'],NA,1,QUOTE\nQUOTE\n\nThat would work as well; the udebs are only needed for d-i.,SOLUTION DISCUSSION,, +22439,openssl 1.0.2 packaging for jessie,"(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?)",1435605409,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?)","(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?)",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"[""(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?)""]",NA,1,"(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?)",SOLUTION DISCUSSION,, +22440,openssl 1.0.2 packaging for jessie,"(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?",1435605399,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?","(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"[""(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?""]",NA,1,"(or alternatively, should I just ignore the udeb error because we don't care about 1.0.2c during install-time?",SOLUTION DISCUSSION,, +22441,openssl 1.0.2 packaging for jessie,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``` +root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes +.changes put in a distribution not listed within it! +Ignoring as --ignore=wrongdistribution given. +Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! +``` + +This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? +``` +Origin: Wikimedia +Label: Wikimedia +Suite: jessie-wikimedia +Codename: jessie-wikimedia +AlsoAcceptFor: jessie jessie-backports +Version: 8 +Architectures: source amd64 i386 +Components: main backports thirdparty +UDebComponents: main +Update: hwraid cassandra +Description: Wikimedia packages for Debian Jessie +SignWith: default +DebOverride: deb-override +Log: + log +``` + +But I'm not sure if the right answer is to fix it there or not...",1435598476,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``` +root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes +.changes put in a distribution not listed within it! +Ignoring as --ignore=wrongdistribution given. +Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! +``` + +This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? +``` +Origin: Wikimedia +Label: Wikimedia +Suite: jessie-wikimedia +Codename: jessie-wikimedia +AlsoAcceptFor: jessie jessie-backports +Version: 8 +Architectures: source amd64 i386 +Components: main backports thirdparty +UDebComponents: main +Update: hwraid cassandra +Description: Wikimedia packages for Debian Jessie +SignWith: default +DebOverride: deb-override +Log: + log +``` + +But I'm not sure if the right answer is to fix it there or not...","I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE`` + +But I'm not sure if the right answer is to fix it there or not...",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"[""I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine."", 'That makes this a trivial backport as well.', 'Per IRC discussion, I\'ve uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL\n\nI\'ve rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia.', ""However, the reprepro command had some failure output:\n``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE``\n\nBut I'm not sure if the right answer is to fix it there or not...""]",NA,1,That makes this a trivial backport as well.,SOLUTION DISCUSSION,, +22441,openssl 1.0.2 packaging for jessie,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``` +root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes +.changes put in a distribution not listed within it! +Ignoring as --ignore=wrongdistribution given. +Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! +``` + +This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? +``` +Origin: Wikimedia +Label: Wikimedia +Suite: jessie-wikimedia +Codename: jessie-wikimedia +AlsoAcceptFor: jessie jessie-backports +Version: 8 +Architectures: source amd64 i386 +Components: main backports thirdparty +UDebComponents: main +Update: hwraid cassandra +Description: Wikimedia packages for Debian Jessie +SignWith: default +DebOverride: deb-override +Log: + log +``` + +But I'm not sure if the right answer is to fix it there or not...",1435598476,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``` +root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes +.changes put in a distribution not listed within it! +Ignoring as --ignore=wrongdistribution given. +Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! +``` + +This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? +``` +Origin: Wikimedia +Label: Wikimedia +Suite: jessie-wikimedia +Codename: jessie-wikimedia +AlsoAcceptFor: jessie jessie-backports +Version: 8 +Architectures: source amd64 i386 +Components: main backports thirdparty +UDebComponents: main +Update: hwraid cassandra +Description: Wikimedia packages for Debian Jessie +SignWith: default +DebOverride: deb-override +Log: + log +``` + +But I'm not sure if the right answer is to fix it there or not...","I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE`` + +But I'm not sure if the right answer is to fix it there or not...",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"[""I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine."", 'That makes this a trivial backport as well.', 'Per IRC discussion, I\'ve uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL\n\nI\'ve rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia.', ""However, the reprepro command had some failure output:\n``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE``\n\nBut I'm not sure if the right answer is to fix it there or not...""]",NA,1,"Per IRC discussion, I\",NA,, +22441,openssl 1.0.2 packaging for jessie,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``` +root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes +.changes put in a distribution not listed within it! +Ignoring as --ignore=wrongdistribution given. +Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! +``` + +This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? +``` +Origin: Wikimedia +Label: Wikimedia +Suite: jessie-wikimedia +Codename: jessie-wikimedia +AlsoAcceptFor: jessie jessie-backports +Version: 8 +Architectures: source amd64 i386 +Components: main backports thirdparty +UDebComponents: main +Update: hwraid cassandra +Description: Wikimedia packages for Debian Jessie +SignWith: default +DebOverride: deb-override +Log: + log +``` + +But I'm not sure if the right answer is to fix it there or not...",1435598476,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``` +root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes +.changes put in a distribution not listed within it! +Ignoring as --ignore=wrongdistribution given. +Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! +``` + +This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? +``` +Origin: Wikimedia +Label: Wikimedia +Suite: jessie-wikimedia +Codename: jessie-wikimedia +AlsoAcceptFor: jessie jessie-backports +Version: 8 +Architectures: source amd64 i386 +Components: main backports thirdparty +UDebComponents: main +Update: hwraid cassandra +Description: Wikimedia packages for Debian Jessie +SignWith: default +DebOverride: deb-override +Log: + log +``` + +But I'm not sure if the right answer is to fix it there or not...","I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE`` + +But I'm not sure if the right answer is to fix it there or not...",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"[""I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine."", 'That makes this a trivial backport as well.', 'Per IRC discussion, I\'ve uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL\n\nI\'ve rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia.', ""However, the reprepro command had some failure output:\n``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE``\n\nBut I'm not sure if the right answer is to fix it there or not...""]",NA,1,"ve rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia.",INVESTIGATION AND EXPLORATION,, +22441,openssl 1.0.2 packaging for jessie,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``` +root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes +.changes put in a distribution not listed within it! +Ignoring as --ignore=wrongdistribution given. +Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! +``` + +This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? +``` +Origin: Wikimedia +Label: Wikimedia +Suite: jessie-wikimedia +Codename: jessie-wikimedia +AlsoAcceptFor: jessie jessie-backports +Version: 8 +Architectures: source amd64 i386 +Components: main backports thirdparty +UDebComponents: main +Update: hwraid cassandra +Description: Wikimedia packages for Debian Jessie +SignWith: default +DebOverride: deb-override +Log: + log +``` + +But I'm not sure if the right answer is to fix it there or not...",1435598476,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``` +root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes +.changes put in a distribution not listed within it! +Ignoring as --ignore=wrongdistribution given. +Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! +``` + +This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? +``` +Origin: Wikimedia +Label: Wikimedia +Suite: jessie-wikimedia +Codename: jessie-wikimedia +AlsoAcceptFor: jessie jessie-backports +Version: 8 +Architectures: source amd64 i386 +Components: main backports thirdparty +UDebComponents: main +Update: hwraid cassandra +Description: Wikimedia packages for Debian Jessie +SignWith: default +DebOverride: deb-override +Log: + log +``` + +But I'm not sure if the right answer is to fix it there or not...","I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE`` + +But I'm not sure if the right answer is to fix it there or not...",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"[""I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine."", 'That makes this a trivial backport as well.', 'Per IRC discussion, I\'ve uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL\n\nI\'ve rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia.', ""However, the reprepro command had some failure output:\n``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE``\n\nBut I'm not sure if the right answer is to fix it there or not...""]",NA,1,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine.",CONTRIBUTION AND COMMITMENT,, +22441,openssl 1.0.2 packaging for jessie,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``` +root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes +.changes put in a distribution not listed within it! +Ignoring as --ignore=wrongdistribution given. +Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! +``` + +This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? +``` +Origin: Wikimedia +Label: Wikimedia +Suite: jessie-wikimedia +Codename: jessie-wikimedia +AlsoAcceptFor: jessie jessie-backports +Version: 8 +Architectures: source amd64 i386 +Components: main backports thirdparty +UDebComponents: main +Update: hwraid cassandra +Description: Wikimedia packages for Debian Jessie +SignWith: default +DebOverride: deb-override +Log: + log +``` + +But I'm not sure if the right answer is to fix it there or not...",1435598476,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``` +root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes +.changes put in a distribution not listed within it! +Ignoring as --ignore=wrongdistribution given. +Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! +``` + +This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? +``` +Origin: Wikimedia +Label: Wikimedia +Suite: jessie-wikimedia +Codename: jessie-wikimedia +AlsoAcceptFor: jessie jessie-backports +Version: 8 +Architectures: source amd64 i386 +Components: main backports thirdparty +UDebComponents: main +Update: hwraid cassandra +Description: Wikimedia packages for Debian Jessie +SignWith: default +DebOverride: deb-override +Log: + log +``` + +But I'm not sure if the right answer is to fix it there or not...","I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE`` + +But I'm not sure if the right answer is to fix it there or not...",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"[""I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine."", 'That makes this a trivial backport as well.', 'Per IRC discussion, I\'ve uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL\n\nI\'ve rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia.', ""However, the reprepro command had some failure output:\n``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE``\n\nBut I'm not sure if the right answer is to fix it there or not...""]",NA,1,upstream,NA,, +22441,openssl 1.0.2 packaging for jessie,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``` +root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes +.changes put in a distribution not listed within it! +Ignoring as --ignore=wrongdistribution given. +Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! +``` + +This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? +``` +Origin: Wikimedia +Label: Wikimedia +Suite: jessie-wikimedia +Codename: jessie-wikimedia +AlsoAcceptFor: jessie jessie-backports +Version: 8 +Architectures: source amd64 i386 +Components: main backports thirdparty +UDebComponents: main +Update: hwraid cassandra +Description: Wikimedia packages for Debian Jessie +SignWith: default +DebOverride: deb-override +Log: + log +``` + +But I'm not sure if the right answer is to fix it there or not...",1435598476,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``` +root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes +.changes put in a distribution not listed within it! +Ignoring as --ignore=wrongdistribution given. +Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! +``` + +This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? +``` +Origin: Wikimedia +Label: Wikimedia +Suite: jessie-wikimedia +Codename: jessie-wikimedia +AlsoAcceptFor: jessie jessie-backports +Version: 8 +Architectures: source amd64 i386 +Components: main backports thirdparty +UDebComponents: main +Update: hwraid cassandra +Description: Wikimedia packages for Debian Jessie +SignWith: default +DebOverride: deb-override +Log: + log +``` + +But I'm not sure if the right answer is to fix it there or not...","I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE`` + +But I'm not sure if the right answer is to fix it there or not...",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"[""I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine."", 'That makes this a trivial backport as well.', 'Per IRC discussion, I\'ve uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL\n\nI\'ve rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia.', ""However, the reprepro command had some failure output:\n``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE``\n\nBut I'm not sure if the right answer is to fix it there or not...""]",NA,1,master,NA,, +22441,openssl 1.0.2 packaging for jessie,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``` +root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes +.changes put in a distribution not listed within it! +Ignoring as --ignore=wrongdistribution given. +Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! +``` + +This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? +``` +Origin: Wikimedia +Label: Wikimedia +Suite: jessie-wikimedia +Codename: jessie-wikimedia +AlsoAcceptFor: jessie jessie-backports +Version: 8 +Architectures: source amd64 i386 +Components: main backports thirdparty +UDebComponents: main +Update: hwraid cassandra +Description: Wikimedia packages for Debian Jessie +SignWith: default +DebOverride: deb-override +Log: + log +``` + +But I'm not sure if the right answer is to fix it there or not...",1435598476,PHID-USER-lhtlnmkdbzlz6pbxaqdd,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: http://git.wikimedia.org/summary/operations%2Fdebs%2Fopenssl + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``` +root@carbon:~# reprepro -C backports --ignore=wrongdistribution include jessie-wikimedia ~bblack/ossl/*.changes +.changes put in a distribution not listed within it! +Ignoring as --ignore=wrongdistribution given. +Cannot put file 'libcrypto1.0.0-udeb_1.0.2c-1_amd64.udeb' into component 'backports', as it is not listed in UDebComponents! +``` + +This seems to be related to `/srv/wikimedia/conf/distributions` jessie stanza lacking backports in UDebComponents? +``` +Origin: Wikimedia +Label: Wikimedia +Suite: jessie-wikimedia +Codename: jessie-wikimedia +AlsoAcceptFor: jessie jessie-backports +Version: 8 +Architectures: source amd64 i386 +Components: main backports thirdparty +UDebComponents: main +Update: hwraid cassandra +Description: Wikimedia packages for Debian Jessie +SignWith: default +DebOverride: deb-override +Log: + log +``` + +But I'm not sure if the right answer is to fix it there or not...","I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine. That makes this a trivial backport as well. Per IRC discussion, I've uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL + +I've rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia. However, the reprepro command had some failure output: +``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE`` + +But I'm not sure if the right answer is to fix it there or not...",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"[""I'm willing to skip the chacha20poly1305 thing if you'd rather, that's fine."", 'That makes this a trivial backport as well.', 'Per IRC discussion, I\'ve uploaded to gerrit with ""upstream"" branch tracking openssl.org orig tarballs and ""master"" starting with the 1.0.2c-1 debian/ stuff here: URL\n\nI\'ve rebuilt that on copper with a standard git-pbuilder for jessie and uploaded to carbon in component ""backport"" of jessie-wikimedia.', ""However, the reprepro command had some failure output:\n``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE``\n\nBut I'm not sure if the right answer is to fix it there or not...""]",NA,1,"However, the reprepro command had some failure output:\n``CODE`CODE/srv/wikimedia/conf/distributionsCODE`CODE``\n\nBut I'm not sure if the right answer is to fix it there or not...",OBSERVED BUG BEHAVIOR,, +22442,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565060,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).,INVESTIGATION AND EXPLORATION,, +22442,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565060,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,I think we should update our openssl build by following their point releases.,SOLUTION DISCUSSION,, +22442,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565060,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,"So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000.",SOLUTION DISCUSSION,, +22442,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565060,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation.,SOLUTION DISCUSSION,, +22442,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565060,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,I'd rather wait until it has seen some upstream scrutiny.,CONTRIBUTION AND COMMITMENT,, +22442,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565060,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there.,SOLUTION DISCUSSION,, +22442,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565060,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,"They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now).",INVESTIGATION AND EXPLORATION,, +22442,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565060,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,"Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL",INVESTIGATION AND EXPLORATION ,, +22443,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565037,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).,INVESTIGATION AND EXPLORATION ,, +22443,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565037,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,I think we should update our openssl build by following their point releases.,SOLUTION DISCUSSION ,, +22443,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565037,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,"So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000.",SOLUTION DISCUSSION ,, +22443,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565037,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation.,SOLUTION DISCUSSION,, +22443,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565037,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,I'd rather wait until it has seen some upstream scrutiny.,CONTRIBUTION AND COMMITMENT ,, +22443,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565037,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there.,SOLUTION DISCUSSION,, +22443,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565037,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,"They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now).",INVESTIGATION AND EXPLORATION,, +22443,openssl 1.0.2 packaging for jessie,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ",1435565037,PHID-USER-abszjqutasfjxgagymds,PHID-TASK-mflsvd7ub7fvyve43xva,task_subcomment,"I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (https://git.openssl.org/?p=openssl.git;a=commit;h=10a70da729948bb573d27cef4459077c49f3eb46) as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639). ","I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off: +The current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768). So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000. + +I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation. I'd rather wait until it has seen some upstream scrutiny. + +As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there. I think we should update our openssl build by following their point releases. They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now). Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL ",NA,NA,NA,NA,NA,TRUE,c3,2,TRUE,NA,-1,TRUE,"['I checked and the data for CVE-2015-4000 in the Debian Security Tracker seems slightly off:\nThe current 1.0.2c from unstable includes the same fix (URL as what is currently in jessie-security (bumping the minimum length to 768).', ""So, there's no regression here, but only a different interpretation between what constitutes a fix for CVE-2015-4000."", ""I'm not really comfortable with including the cloudfare patch; they don't seem to have submitted it upstream over at least four months and the OpenSSL developers are working on their own implementation."", ""I'd rather wait until it has seen some upstream scrutiny."", ""As for maintaining the backport: I'd say we import 1.0.2c in operations/debs/openssl and proceed from there."", 'I think we should update our openssl build by following their point releases.', ""They had a recent lapse which broke the ABI in 1.0.2b, but otherwise the selection of backports to the stable branchs is fairly conservative (I'm following openssl commit logs for a while now)."", ""Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL""]",NA,1,"Currently the Debian packages for jessie-security backport the isolated security fixes, but it's also planned to switch to ship the openssl point releases in the future (URL",INVESTIGATION AND EXPLORATION,, +23461,Occasionally getting 403 HTTP Method not allowed from bits,For example I just received this error while trying to GET http://bits.beta.wmflabs.org/static-master/extensions/VisualEditor/modules/ve-mw/init/ve.init.mw.js,1426632739,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-nr2rykz2i64vicqql4ad,task_description,Occasionally getting 403 HTTP Method not allowed from bits./n/nFor example I just received this error while trying to GET http://bits.beta.wmflabs.org/static-master/extensions/VisualEditor/modules/ve-mw/init/ve.init.mw.js,Occasionally getting 403 HTTP Method not allowed from bits./n/nFor example I just received this error while trying to GET URL,Needs Triage,90,1430784755,PHID-USER-orzyp3dswemhdgdznro5,duplicate,TRUE,c3,1,TRUE,FALSE,-16,TRUE,"['Occasionally getting 403 HTTP Method not allowed from bits.', 'For example I just received this error while trying to GET URL']",TRUE,1,Occasionally getting 403 HTTP Method not allowed from bits.,OBSERVED BUG BEHAVIOR,, +23461,Occasionally getting 403 HTTP Method not allowed from bits,For example I just received this error while trying to GET http://bits.beta.wmflabs.org/static-master/extensions/VisualEditor/modules/ve-mw/init/ve.init.mw.js,1426632739,PHID-USER-x7ti5ksby4ubsabntlxa,PHID-TASK-nr2rykz2i64vicqql4ad,task_description,Occasionally getting 403 HTTP Method not allowed from bits./n/nFor example I just received this error while trying to GET http://bits.beta.wmflabs.org/static-master/extensions/VisualEditor/modules/ve-mw/init/ve.init.mw.js,Occasionally getting 403 HTTP Method not allowed from bits./n/nFor example I just received this error while trying to GET URL,Needs Triage,90,1430784755,PHID-USER-orzyp3dswemhdgdznro5,duplicate,TRUE,c3,1,TRUE,FALSE,-16,TRUE,"['Occasionally getting 403 HTTP Method not allowed from bits.', 'For example I just received this error while trying to GET URL']",TRUE,1,For example I just received this error while trying to GET URL,OBSERVED BUG BEHAVIOR,, +23462,Occasionally getting 403 HTTP Method not allowed from bits,See T98046 for a more documented bug report :),1430784783,PHID-USER-orzyp3dswemhdgdznro5,PHID-TASK-nr2rykz2i64vicqql4ad,task_subcomment,See T98046 for a more documented bug report :),See T98046 for a more documented bug report :),NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-9,TRUE,['See T98046 for a more documented bug report :)'],NA,1,See T98046 for a more documented bug report :),ISSUE CONTENT MANAGEMENT,, +23463,Occasionally getting 403 HTTP Method not allowed from bits,Works for me.,1430763846,PHID-USER-sai77mtxmpqnm6pycyvz,PHID-TASK-nr2rykz2i64vicqql4ad,task_subcomment,Works for me.,Works for me.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-9,TRUE,['Works for me.'],NA,1,Works for me.,SOCIAL CONVERSATION,, +23464,Occasionally getting 403 HTTP Method not allowed from bits,Still an issue?,1429295849,PHID-USER-hgn5uw2jafgjgfvxibhh,PHID-TASK-nr2rykz2i64vicqql4ad,task_subcomment,Still an issue?,Still an issue?,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-11,TRUE,['Still an issue?'],NA,1,Still an issue?,SOCIAL CONVERSATION,, +23679,HttpError should not be logged as an unhandled exception.,"HttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",1420465532,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-cgood7sc62oac3adwbux,task_description,"HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.","HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",Needs Triage,90,1426705982,PHID-USER-2mey32xhshfnf7rz7jjn,resolved,TRUE,c3,1,TRUE,FALSE,-26,TRUE,"['HttpError should not be logged as an unhandled exception.. \n\nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500).', 'Thus, writing it to ""the exception log"" with wfDebugLog( \'exception\', ... ) is misleading.', 'I suggest the following behavior: \n* HttpError::isLoggable should return false if $this->httpCode < 500.', '* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400\n\nAlternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e.', '""http-error"" instead of the generic ""exception"" log.', 'To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.']",TRUE,1,"HttpError should not be logged as an unhandled exception.. \n\nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500).",EXPECTED BEHAVIOR,, +23679,HttpError should not be logged as an unhandled exception.,"HttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",1420465532,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-cgood7sc62oac3adwbux,task_description,"HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.","HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",Needs Triage,90,1426705982,PHID-USER-2mey32xhshfnf7rz7jjn,resolved,TRUE,c3,1,TRUE,FALSE,-26,TRUE,"['HttpError should not be logged as an unhandled exception.. \n\nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500).', 'Thus, writing it to ""the exception log"" with wfDebugLog( \'exception\', ... ) is misleading.', 'I suggest the following behavior: \n* HttpError::isLoggable should return false if $this->httpCode < 500.', '* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400\n\nAlternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e.', '""http-error"" instead of the generic ""exception"" log.', 'To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.']",TRUE,1,"Thus, writing it to ""the exception log"" with wfDebugLog( \",NA,, +23679,HttpError should not be logged as an unhandled exception.,"HttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",1420465532,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-cgood7sc62oac3adwbux,task_description,"HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.","HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",Needs Triage,90,1426705982,PHID-USER-2mey32xhshfnf7rz7jjn,resolved,TRUE,c3,1,TRUE,FALSE,-26,TRUE,"['HttpError should not be logged as an unhandled exception.. \n\nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500).', 'Thus, writing it to ""the exception log"" with wfDebugLog( \'exception\', ... ) is misleading.', 'I suggest the following behavior: \n* HttpError::isLoggable should return false if $this->httpCode < 500.', '* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400\n\nAlternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e.', '""http-error"" instead of the generic ""exception"" log.', 'To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.']",TRUE,1,", ... ) is misleading.",NA,, +23679,HttpError should not be logged as an unhandled exception.,"HttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",1420465532,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-cgood7sc62oac3adwbux,task_description,"HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.","HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",Needs Triage,90,1426705982,PHID-USER-2mey32xhshfnf7rz7jjn,resolved,TRUE,c3,1,TRUE,FALSE,-26,TRUE,"['HttpError should not be logged as an unhandled exception.. \n\nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500).', 'Thus, writing it to ""the exception log"" with wfDebugLog( \'exception\', ... ) is misleading.', 'I suggest the following behavior: \n* HttpError::isLoggable should return false if $this->httpCode < 500.', '* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400\n\nAlternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e.', '""http-error"" instead of the generic ""exception"" log.', 'To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.']",TRUE,1,I suggest the following behavior: \n* HttpError::isLoggable should return false if $this->httpCode < 500.,EXPECTED BEHAVIOR,, +23679,HttpError should not be logged as an unhandled exception.,"HttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",1420465532,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-cgood7sc62oac3adwbux,task_description,"HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.","HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",Needs Triage,90,1426705982,PHID-USER-2mey32xhshfnf7rz7jjn,resolved,TRUE,c3,1,TRUE,FALSE,-26,TRUE,"['HttpError should not be logged as an unhandled exception.. \n\nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500).', 'Thus, writing it to ""the exception log"" with wfDebugLog( \'exception\', ... ) is misleading.', 'I suggest the following behavior: \n* HttpError::isLoggable should return false if $this->httpCode < 500.', '* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400\n\nAlternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e.', '""http-error"" instead of the generic ""exception"" log.', 'To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.']",TRUE,1,"* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400\n\nAlternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e.",EXPECTED BEHAVIOR,, +23679,HttpError should not be logged as an unhandled exception.,"HttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",1420465532,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-cgood7sc62oac3adwbux,task_description,"HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.","HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",Needs Triage,90,1426705982,PHID-USER-2mey32xhshfnf7rz7jjn,resolved,TRUE,c3,1,TRUE,FALSE,-26,TRUE,"['HttpError should not be logged as an unhandled exception.. \n\nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500).', 'Thus, writing it to ""the exception log"" with wfDebugLog( \'exception\', ... ) is misleading.', 'I suggest the following behavior: \n* HttpError::isLoggable should return false if $this->httpCode < 500.', '* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400\n\nAlternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e.', '""http-error"" instead of the generic ""exception"" log.', 'To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.']",TRUE,1,"""http-error"" instead of the generic ""exception"" log.",SOLUTION DISCUSSION,, +23679,HttpError should not be logged as an unhandled exception.,"HttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",1420465532,PHID-USER-5dqihbanu3caaj7pigif,PHID-TASK-cgood7sc62oac3adwbux,task_description,"HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.","HttpError should not be logged as an unhandled exception../n/nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500). Thus, writing it to ""the exception log"" with wfDebugLog( 'exception', ... ) is misleading. + +I suggest the following behavior: +* HttpError::isLoggable should return false if $this->httpCode < 500. +* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400 + +Alternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e. ""http-error"" instead of the generic ""exception"" log. To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",Needs Triage,90,1426705982,PHID-USER-2mey32xhshfnf7rz7jjn,resolved,TRUE,c3,1,TRUE,FALSE,-26,TRUE,"['HttpError should not be logged as an unhandled exception.. \n\nHttpError is a way to signal an issue to the client, it does not generally imply a programming error or failure on the server side (at least for status codes < 500).', 'Thus, writing it to ""the exception log"" with wfDebugLog( \'exception\', ... ) is misleading.', 'I suggest the following behavior: \n* HttpError::isLoggable should return false if $this->httpCode < 500.', '* HttpError::report should write to the web server error log (via wfLogWarning or error_log) if $this->httpCode >= 400\n\nAlternatively, MWExceptionHandler::logException could implement a special case for HttpError, using a different log stream, i.e.', '""http-error"" instead of the generic ""exception"" log.', 'To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.']",TRUE,1,"To avoid the special case in MWExceptionHandler, MWException could get a getLogStream() method that would return ""exception"" per default.",SOLUTION DISCUSSION,, +23680,HttpError should not be logged as an unhandled exception.,"Change 183020 merged by jenkins-bot: +Don't log HttpErrors in the exception log, use MWLogger + +[[https://gerrit.wikimedia.org/r/183020]]",1426694449,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"Change 183020 merged by jenkins-bot: +Don't log HttpErrors in the exception log, use MWLogger + +[[https://gerrit.wikimedia.org/r/183020]]","Change 183020 merged by jenkins-bot: +Don't log HttpErrors in the exception log, use MWLogger + +[[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-16,TRUE,"[""Change 183020 merged by jenkins-bot:\nDon't log HttpErrors in the exception log, use MWLogger\n\n[[GERRIT_URL]]""]",NA,1,"Change 183020 merged by jenkins-bot:\nDon't log HttpErrors in the exception log, use MWLogger\n\n[[GERRIT_URL]]",TASK PROGRESS,, +23681,HttpError should not be logged as an unhandled exception.,"Change 197503 merged by Legoktm: +Log HttpErrors with a 500 code + +[[https://gerrit.wikimedia.org/r/197503]]",1426693431,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"Change 197503 merged by Legoktm: +Log HttpErrors with a 500 code + +[[https://gerrit.wikimedia.org/r/197503]]","Change 197503 merged by Legoktm: +Log HttpErrors with a 500 code + +[[GERRIT_URL]]",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-16,TRUE,['Change 197503 merged by Legoktm:\nLog HttpErrors with a 500 code\n\n[[GERRIT_URL]]'],NA,1,Change 197503 merged by Legoktm:\nLog HttpErrors with a 500 code\n\n[[GERRIT_URL]],TASK PROGRESS,, +23682,HttpError should not be logged as an unhandled exception.,"Change 197503 had a related patch set uploaded (by Hoo man): +Log HttpErrors with a 500 code + +[[https://gerrit.wikimedia.org/r/197503]] +",1426674262,PHID-USER-idceizaw6elwiwm5xshb,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"Change 197503 had a related patch set uploaded (by Hoo man): +Log HttpErrors with a 500 code + +[[https://gerrit.wikimedia.org/r/197503]] +","Change 197503 had a related patch set uploaded (by Hoo man): +Log HttpErrors with a 500 code + +[[GERRIT_URL]] +",NA,NA,NA,NA,NA,TRUE,c3,1,FALSE,NA,-16,TRUE,['Change 197503 had a related patch set uploaded (by Hoo man):\nLog HttpErrors with a 500 code\n\n[[GERRIT_URL]]'],NA,1,Change 197503 had a related patch set uploaded (by Hoo man):\nLog HttpErrors with a 500 code\n\n[[GERRIT_URL]],TASK PROGRESS,, +23683,HttpError should not be logged as an unhandled exception.,">>! In T85795#960163, @Legoktm wrote: +>>>! In T85795#960109, @JanZerebecki wrote: +>> The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +> +> Actually, we now have structured logging in MW: `MWLogger::getInstance('HttpError')` will return an instance of `Psr\Log\LoggerInterface` that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). + +The severity filter stuff will hit group0 today. \o/ No config updates have been done to use it yet.",1420658816,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,">>! In T85795#960163, @Legoktm wrote: +>>>! In T85795#960109, @JanZerebecki wrote: +>> The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +> +> Actually, we now have structured logging in MW: `MWLogger::getInstance('HttpError')` will return an instance of `Psr\Log\LoggerInterface` that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). + +The severity filter stuff will hit group0 today. \o/ No config updates have been done to use it yet.","QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +The severity filter stuff will hit group0 today. \o/ No config updates have been done to use it yet.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThe severity filter stuff will hit group0 today.', '\\o/ No config updates have been done to use it yet.']",NA,1,QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThe severity filter stuff will hit group0 today.,TASK PROGRESS,, +23683,HttpError should not be logged as an unhandled exception.,">>! In T85795#960163, @Legoktm wrote: +>>>! In T85795#960109, @JanZerebecki wrote: +>> The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +> +> Actually, we now have structured logging in MW: `MWLogger::getInstance('HttpError')` will return an instance of `Psr\Log\LoggerInterface` that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). + +The severity filter stuff will hit group0 today. \o/ No config updates have been done to use it yet.",1420658816,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,">>! In T85795#960163, @Legoktm wrote: +>>>! In T85795#960109, @JanZerebecki wrote: +>> The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +> +> Actually, we now have structured logging in MW: `MWLogger::getInstance('HttpError')` will return an instance of `Psr\Log\LoggerInterface` that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). + +The severity filter stuff will hit group0 today. \o/ No config updates have been done to use it yet.","QUOTE +QUOTE +QUOTE +QUOTE +QUOTE + +The severity filter stuff will hit group0 today. \o/ No config updates have been done to use it yet.",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThe severity filter stuff will hit group0 today.', '\\o/ No config updates have been done to use it yet.']",NA,1,\\o/ No config updates have been done to use it yet.,SOLUTION DISCUSSION,, +23684,HttpError should not be logged as an unhandled exception.,">>! In T85795#960109, @JanZerebecki wrote: +> The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. + +Actually, we now have structured logging in MW: `MWLogger::getInstance('HttpError')` will return an instance of `Psr\Log\LoggerInterface` that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). +",1420654141,PHID-USER-v7vgzvvcw7v2umf737ri,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,">>! In T85795#960109, @JanZerebecki wrote: +> The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. + +Actually, we now have structured logging in MW: `MWLogger::getInstance('HttpError')` will return an instance of `Psr\Log\LoggerInterface` that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). +","QUOTE +QUOTE + +Actually, we now have structured logging in MW: CODE will return an instance of CODE that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). +",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['QUOTE\nQUOTE\n\nActually, we now have structured logging in MW: CODE will return an instance of CODE that you can use.', 'You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though).']",NA,1,"QUOTE\nQUOTE\n\nActually, we now have structured logging in MW: CODE will return an instance of CODE that you can use.",TASK PROGRESS,, +23684,HttpError should not be logged as an unhandled exception.,">>! In T85795#960109, @JanZerebecki wrote: +> The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. + +Actually, we now have structured logging in MW: `MWLogger::getInstance('HttpError')` will return an instance of `Psr\Log\LoggerInterface` that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). +",1420654141,PHID-USER-v7vgzvvcw7v2umf737ri,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,">>! In T85795#960109, @JanZerebecki wrote: +> The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. + +Actually, we now have structured logging in MW: `MWLogger::getInstance('HttpError')` will return an instance of `Psr\Log\LoggerInterface` that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). +","QUOTE +QUOTE + +Actually, we now have structured logging in MW: CODE will return an instance of CODE that you can use. You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though). +",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['QUOTE\nQUOTE\n\nActually, we now have structured logging in MW: CODE will return an instance of CODE that you can use.', 'You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though).']",NA,1,You can also set a minimum log severity level in $wgDebugLogGroups (unsure if that has been deployed yet though).,SOLUTION USAGE,, +23685,HttpError should not be logged as an unhandled exception.,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",1420653258,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?","The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['The goal is that everything that is logged can be easily differentiated according to its severity.', 'Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation.', 'A 404 of this case is the later case.', 'AFAIK in Mediawiki the log group is the only thing that can be currently used for this.', 'To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group.', 'How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?']",NA,1,The goal is that everything that is logged can be easily differentiated according to its severity.,MOTIVATION,, +23685,HttpError should not be logged as an unhandled exception.,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",1420653258,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?","The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['The goal is that everything that is logged can be easily differentiated according to its severity.', 'Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation.', 'A 404 of this case is the later case.', 'AFAIK in Mediawiki the log group is the only thing that can be currently used for this.', 'To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group.', 'How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?']",NA,1,Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation.,MOTIVATION,, +23685,HttpError should not be logged as an unhandled exception.,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",1420653258,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?","The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['The goal is that everything that is logged can be easily differentiated according to its severity.', 'Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation.', 'A 404 of this case is the later case.', 'AFAIK in Mediawiki the log group is the only thing that can be currently used for this.', 'To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group.', 'How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?']",NA,1,A 404 of this case is the later case.,SOLUTION DISCUSSION ,, +23685,HttpError should not be logged as an unhandled exception.,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",1420653258,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?","The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['The goal is that everything that is logged can be easily differentiated according to its severity.', 'Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation.', 'A 404 of this case is the later case.', 'AFAIK in Mediawiki the log group is the only thing that can be currently used for this.', 'To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group.', 'How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?']",NA,1,AFAIK in Mediawiki the log group is the only thing that can be currently used for this.,INVESTIGATION AND EXPLORATION,, +23685,HttpError should not be logged as an unhandled exception.,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",1420653258,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?","The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['The goal is that everything that is logged can be easily differentiated according to its severity.', 'Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation.', 'A 404 of this case is the later case.', 'AFAIK in Mediawiki the log group is the only thing that can be currently used for this.', 'To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group.', 'How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?']",NA,1,To have isLoggable() return false but then have the exception log itself inside report() is more of a workaround for the lack of being able to specify the log group.,WORKAROUNDS,, +23685,HttpError should not be logged as an unhandled exception.,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",1420653258,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,"The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?","The goal is that everything that is logged can be easily differentiated according to its severity. Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation. A 404 of this case is the later case. AFAIK in Mediawiki the log group is the only thing that can be currently used for this. +To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group. How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?",NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['The goal is that everything that is logged can be easily differentiated according to its severity.', 'Like fatals/errors/warnings/notices vs things that might be helpful for debugging something but are normal operation.', 'A 404 of this case is the later case.', 'AFAIK in Mediawiki the log group is the only thing that can be currently used for this.', 'To have isLoggable() return false but then have the exception log itself inside report() is more of a WORKAROUNDS for the lack of being able to specify the log group.', 'How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?']",NA,1,How about having logGroups() in MWException which MWExceptionHandler then uses instead of isLoggable() to determine to log the exception to the normal exception channel?,SOLUTION DISCUSSION,, +23686,HttpError should not be logged as an unhandled exception.,Thx. No wonder searching for type in that file didn't find where it was set to HttpError.,1420565761,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,Thx. No wonder searching for type in that file didn't find where it was set to HttpError.,Thx. No wonder searching for type in that file didn't find where it was set to HttpError.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['Thx.', ""No wonder searching for type in that file didn't find where it was set to HttpError.""]",NA,1,Thx.,SOCIAL CONVERSATION,, +23686,HttpError should not be logged as an unhandled exception.,Thx. No wonder searching for type in that file didn't find where it was set to HttpError.,1420565761,PHID-USER-mdihg2tyzmlvyhn3h32y,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,Thx. No wonder searching for type in that file didn't find where it was set to HttpError.,Thx. No wonder searching for type in that file didn't find where it was set to HttpError.,NA,NA,NA,NA,NA,TRUE,c3,1,TRUE,NA,-26,TRUE,"['Thx.', ""No wonder searching for type in that file didn't find where it was set to HttpError.""]",NA,1,No wonder searching for type in that file didn't find where it was set to HttpError.,SOCIAL CONVERSATION,, +23687,HttpError should not be logged as an unhandled exception.,">>! In T85795#957697, @JanZerebecki wrote: +> I can't figure out why currently these show up in logstash as type:HttpError instead of type:exception. Any ideas? + +It happens from the exception-json event processing. See ",1420565282,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,">>! In T85795#957697, @JanZerebecki wrote: +> I can't figure out why currently these show up in logstash as type:HttpError instead of type:exception. Any ideas? + +It happens from the exception-json event processing. See ","QUOTE +QUOTE + +It happens from the exception-json event processing. See >! In T85795#957697, @JanZerebecki wrote: +> I can't figure out why currently these show up in logstash as type:HttpError instead of type:exception. Any ideas? + +It happens from the exception-json event processing. See ",1420565282,PHID-USER-ll6tmaogat2b5q7tnqas,PHID-TASK-cgood7sc62oac3adwbux,task_subcomment,">>! In T85795#957697, @JanZerebecki wrote: +> I can't figure out why currently these show up in logstash as type:HttpError instead of type:exception. Any ideas? + +It happens from the exception-json event processing. See ","QUOTE +QUOTE + +It happens from the exception-json event processing. See