디스코urses 셀프 호스팅 초기에 “플러그인 재빌드 실패” 문제에 시달린 경험이 있어, 검증된 좋은 버전들을 코어에 번들링하려는 욕구를 잘 이해합니다. 또한 더 풍부한 기능 선택지를 제공할 수도 있겠죠.
고객 중심의 조직이라면 코어 플러그인 방향성, 적어도 그 시기에 대한 설문조사를 실시할 수 있었을 것입니다. 제가 놓친 것일 수도 있겠지요. 고객(즉, 최종 사용자)에게 IT 도구를 제공하면서 실제 업무를 처리하려는 입장에서, 많은 제품들이 과도한 복잡성으로 인해 결국 대체되는 것을 목격해왔습니다. 이제 셀프 호스터들은 필요 없는 플러그인을 'rm -fr’로 지울 것입니다. 저는 이를 이해하며, 그 모임에 합류할 수도 있습니다. 제 경험상, 추가 코드는 통합 복잡성을 높이고, 설정 실수 위험과 공격 표면을 증가시킵니다. 하지만 개발자가 존재한다고 가정하는 것을 제거하면, 결국 무언가가 깨질 것입니다.
저는 디스코어스 '제다이’들의 노력이 이미지 클라우드 저장소(CDN 통합 포함)를 위한 견고하고 유지보수되며 스크립트화된 방법을 개발하는 데 투입되었으면 훨씬 좋았을 것입니다. 비교하면 SMTP 이메일 통합은 자명하며, MailGun 등의 변경으로 인해 셀프 호스팅 사이트들이 곤란을 겪은 적이 있지만, 그 정도는 아니었습니다.
실제로, 이러한 플러그인에 대해 rm -rf를 사용하는 것을 강력히 권장하지 않습니다. 말씀하신 대로, 미래의 예상치 못한 상호 의존성으로 인한 위험이 있습니다. 또한, 핵심 git 저장소에 diff가 생성되어 docker_manager를 통한 UI 업데이트가 거의 확실하게 실패하게 됩니다.
물론, 이러한 플러그인을 기본 ‘비활성화’ 상태로 두는 것은 완전히 지원되며, 측정 가능한 성능 영향을 미치지 않도록 보장합니다.
이 게시물에 언급된 각 플러그인의 GitHub URL을 스크래핑해 주세요 https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574#p-1810533-affected-plugins-3
이를 목록으로 정리하고, 해당 Discourse의 containers/app.yml 파일에서 ‘git clone’ 명령에 이미 언급되어 있는지 확인하는 unix 명령어를 만들어 주세요
휴, 이번 업데이트는 정말 험난했습니다. 재빌드 로그라는 혼란 속에서 문제를 파악하는 것 자체가 쉽지 않은데, 문제를 찾은 뒤에도 설정에서 제거해야 할 플러그인을 두 번이나 놓쳐서 결국 세 번째 재빌드 시도에서야 해당 단계를 통과할 수 있었습니다. 처음부터 설정이 조정되어야 한다는 점을 확인하고 경고해 주었으면 정말 도움이 되었을 텐데 말입니다. discourse-doctor는 설정 내 플러그인을 확인하는 체크(너무 단순하지만, 시작점으로는 충분합니다)를 수행하므로, 이를 기반으로 삼을 수 있습니다. 이제 3주가 지난 시점에서 말하기는 아마도 늦었을 테지만, 어쨌든…
하지만 이것만이 전부는 아니었습니다. db:migrate 오류에도 직면했습니다. 두 번 다시 시도한 뒤 discourse-doctor를 실행했는데, 이 과정에서 재빌드도 함께 실행되었고, 이상하게도 성공했습니다. 코드를 확인해 보니, 재빌드 전에 아무런 변경 사항도 없이(변경 없음) 재빌드를 우리가 실행하는 것과 정확히 같은 방식으로 호출하고 있었습니다. 따라서 db:migrate가 어떤 이유로든 세 번째 시도에서 성공한 것으로 보입니다. 해당 스레드를 읽어 보니, 대량의 추가된 플러그인이 종속성을 추가하여 이전에 사용되던 것들과 충돌하거나 더 오래된 버전일 수 있다고 하더군요. 다행히도 다른 사용자들처럼 수동 플러그인 제거 단계, 종속성 조정 또는 데이터베이스 변경이 필요하지 않았습니다. db:migrate를 여러 번 실행하면 결국 성공할 것이라는 것이 어떤 식으로든 예상되는 일일까요? 아무것도 깨지지 않았기를 바랄 뿐입니다…
이 문제에 대해 이 의견에 전적으로 동의합니다. 갑자기 플러그인을 한꺼번에 대량으로 추가하지 마세요. 특정 기능이 모든(초기) 인스턴스에 매우 유익하다고 판단된다면, 개별적으로 하나씩 논의해야 합니다. 그렇게 하면 플러그인으로 유지하면서 유지보수자를 참여시키는 것보다, Discourse에 네이티브로 추가하는 것(설정에서 토글 가능)이 더 나을 수도 있습니다. 우리는 현재 설정에 제거 단계를 추가할지, 그리고 기본적으로 활성화되어 있는 플러그인들은 어떻게 할지 고려하고 있습니다. 이는 우리가 의도하지 않았던 Discourse 인스턴스의 변경을 의미하며, 실제로 지금(현지 시간 자정 이후) 테스트하고 생각할 시간이 전혀 없는데, 업그레이드 혼란과 수정을 위해 필요한 조사 덕분이기도 합니다…
이와 관련하여 질문이 있습니다: 일부 기능이 플러그인으로 전환되었나요? 이전에는 기억하지 못하는 ‘narrative bot’ 플러그인을 보고 있습니다. 설명에는 "스태프를 소개합니다"라고 되어 있어, 처음에는 스태프(모드/관리자/…) 전용으로 discobot에 추가된 것이라고 생각했습니다. 하지만 설정을 보면 실제로 discobot이 맞지 않나요? 이제 활성화된 것으로 나타나지만 설정을 통해 능동적으로 설치하지 않았던 모든 플러그인들은 이전에 이미 존재했던 기능들인가요?
우리는 사전에 이에 대해 고려하지 않았기 때문에 일부 승인 상태가 누락되었을 수 있습니다. 하지만 Crowdin의 플러그인 프로젝트에서 코어로 상당 부분을 이전하는 데 성공했습니다. 이제 프로젝트 간 승인을 이전할 수 있는 도구를 갖추었으므로 다음에는 더 잘 처리할 것입니다.
아니요, 사전에는 확인하지 않았습니다. 하지만 사후에는 확인했습니다. Crowdin에서 어떤 플러그인에도 답변되지 않은 코멘트는 없었습니다. 우리는 Crowdin 플러그인에 게시된 모든 코멘트를 저장하는 내부 도구를 가지고 있습니다. 이 도구를 사용하면 Crowdin에 누락된 코멘트를 다시 게시할 수도 있습니다. 예를 들어, 소스 문자열이 업데이트되어 Crowdin이 코멘트를 삭제하는 경우와 같은 상황에서요. 다만 이를 구현하는 것은 우선순위가 아니었습니다.
이 의견에 동의합니다. 개인적으로 진정한 문제는 그것들을 여전히 플러그인으로 분류해 두는 것입니다.
통합된 후에는 플러그인이 설치 가능한 선택적 구성 요소로 인식되는 반면, 메인 프로그램의 일부인 것과 혼동되지 않도록 "Core Features"와 같은 브랜드 네이밍으로 이동해야 합니다. 따라서 제거할 의도가 없는 상태에서 그것들을 여전히 플러그인으로 분류하는 것은 개인적으로 명칭이 부당하다고 생각합니다.
이는 "personal bubbles"와 같이 코어에 통합된 TC(테마 구성 요소)와 유사합니다. 해당 TC는 Theme Components 목록에 나타나지 않습니다. 물론 그 특정 경우에는 해당 TC를 비활성화할 수 없습니다. 이전 상태로 되돌리려면 변경 사항을 되돌리는 TC를 생성해야 했습니다.
추가 필터링 옵션에 대해서는 전적으로 동의합니다. 비활성화된 플러그인을 위한 옵션도 함께 있으면 좋겠습니다.
다만 더 깊이 생각해 보고 다른 게시물들을 더 읽은 결과, 플러그인이 코어와 통합된다면 더 이상 플러그인으로 불리거나 플러그인 목록에 표시되지 않는 것이 오히려 적절할 것 같습니다. 대신 핵심 기능이나 선택적 기능과 같은 이름이 좋을 것 같습니다. 더 이상 이들을 제거할 수 없기 때문입니다.
적절하게 설계된 포럼 소프트웨어가 광고 코드를 실행하는 데 필수적으로 요구해야 할 이유는 없습니다.
Discourse가 반기능(anti-features)을 내장하기로 결정한다면, 그것은 사람들이 Discourse를 포크하거나 다른 것으로 이주하도록 강요하는 것뿐입니다. 빅테크/광고 관련 사항을 싫어하는 우리들은 이 문제에 대해 매우 강한 의견을 가지고 있습니다. 아무리 강하게 밀어붙여도 Discourse가 우리에게 이를 강요하지는 않을 것입니다. (우분투(Ubuntu)가 우리에게 이렇게 시도했고, 이제 제 가장 높은 별점을 받은 저장소는 광고를 제거하는 것입니다 ;))
글쎄요, 무슨 말씀이신지 잘 모르겠습니다. 광고 코드란 코어 제품에 통합된 플러그인을 말씀하시는 건지, 아니면 선택적 추가 기능/설치로 남아있는 것을 말씀하시는 건지요. 과거로 돌아가 보면 "광고 코드"가 코어에 통합된 사례가 다양하게 있었습니다.
DeV 팀의 관점에서 보면, 많은 플러그인들이 처음에는 코어 프로그램에 통합하기 전에 더 유연한 테스트를 허용하기 위한 목적으로 시작되었을 수 있다고 이해합니다.
어떤 소프트웨어든 사람들이 사용하지 않거나 비활성화하기를 선택하는 기능이 있는 경우가 많으며, 기능을 언인스톨하는 방법을 찾는 것이 중요하다는 점은 이해합니다.
최근에 통합된 많은 플러그인 중 제가 실제로 사용하지 않을 것 같은 것이 많다는 점은 인정합니다. 하지만 이를 간단히 비활성화하고 필터링할 수 있다는 것은 모두에게 좋은 일입니다.
팀이 언급했듯이, 셀프 호스팅 사용자를 위한 추가 기능을 통해 작업을 더 쉽게 만드는 것이 의도라는 점은 이해합니다.
개인적으로 관리자 인터페이스가 과거처럼 더 커스터마이징 가능해야 한다고 생각합니다. 이는 다른 플랫폼에서 이관하는 사람들이 기존 플랫폼과 유사한 레이아웃의 관리자를 로드할 수 있게 함으로써 도움이 될 수 있기 때문입니다. 리눅스가 다른 OS를 모방하는 일부 기능으로 이를 수행하는 방식과 매우 유사합니다. 하지만 그것은 또 다른 주제입니다.
디스커스가 불필요한 기능으로 부풀어 오르기 시작하고 있다는 느낌을 공감할 수 있습니다. 리액터(Reactors)는 Windows NT가 얼마나 더 경량화될 수 있었는지를 보여줬습니다.
