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