diss下載 - diss源代碼下載

diss

其他源碼

1.0.0

下載

注意！

在將項目發佈到[email protected]之後，我注意到，Foss社區中的人可能會擔心使用Github這樣的專有Devleplement系統。

我將把這個作為遺產目的作為我們第一周的努力的檔案。

未來的更新將在Gitlab的新項目Home和Gitlab上的新項目Wiki上進行。

我感謝大家對這個項目的興趣，歡迎您在Gitlab上關注我們。我將努力更新開發渠道中的IRC機器人，以支持新系統的Webhook通知。我不會進一步更新此項目頁面。

Diss- Debian綜合支持系統

雄心勃勃的目標是協同整合所有Debian的支持資源，並為經過良好測試的診斷程序提供簡單而直觀的界面。

這絕不是要替換，實際上很大程度上取決於我們所有現有的資源。這裡的理由是我們的系統正在成倍增長，我們是“通用OS”，並且我們的支持資源有限，並不是每個人都知道如何以及以什麼順序使用它們，從而導致許多知名且易於觀察的問題。

我們要解決的問題

通過重複處理來支持團隊倦怠，我們已經解決的已知問題，必須解釋我們的程序和政策，並收集（有時會偷取）與手頭問題相關的信息等
用戶疏遠因缺乏對系統的理解以及與支持者等的非生產性互動。在我們一些最好的支持者中，這是一種有記錄在上面的思維方式，我本人包括我們真的不希望那些沒有經驗的用戶，因為他們只會在不為我們的項目做出貢獻的情況下成為我們的資源。這也是一個很容易觀察到的事實，即開發人員和經驗豐富的用戶通常是最後一個發現錯誤和問題的人，因為他們不僅在嘗試不同的軟件時往往不那麼冒險，因為他們已經知道自己喜歡和使用的東西，而且他們以打算使用的方式使用它。它需要一個沒有經驗的人嘗試各種選擇，並以揭示晦澀難懂的錯誤方式使用事物。這是一種有價值的商品，可以讓大量不經驗的用戶對我們不斷增長的軟件基礎進行搜索，從而發現我們否則會錯過的問題。但是，我們需要確保我們從這個寶貴的資源中獲得的反饋是有意義的，並且在正確的位置浮出水面，而不會出現上述問題，因此我們需要一種滿足他們需求以及我們的需求的過濾器。
我們還需要確保利用這兩個問題的所有努力。也就是說，我們不能讓用戶以自我利益來解決問題，並且由於未正確記錄了這一問題，因此努力不足。一些用戶回來並共享問題的解決方案，有時我們會創建一個事實，有時最終會有Wiki頁面，錯誤報告等。但是大多數情況下並非如此。此外，當問題再次出現時，我們並不總是知道這已經完成。我們當前的系統依靠我們的支持者來記住這些事情，當那些記住它當時沒有看的人時，我們可以回落回頭＃2並疏遠了我們的用戶，或者根本無法記錄或解決該問題，即使是無效的。

軟件組件

客戶端/前端（讀取線，詛咒，GTK，QT），診斷（簽名的診斷樹文件），bot（irc），服務器（問題跟踪器）

客戶

The client will be a reportbug style wizard that will allow a user to select a program (on lower skill levels, use generic names like "filemanager" and have it automatically detect the actual program name or use a grab fuction where the user can click on a window and get the command) and enter a description of their issue and should have various classes of issues (Network, Sound, Crashes, Build errors, Package system problems, etc.) and optionally a CC address (email can be masked by the帶有發行ID和電子郵件的跟踪器向用戶彈跳以尋求隱私，並使用戶能夠通過通過ID向跟踪器發送電子郵件來選擇進一步的CC，並告訴其停止）。

然後，第一個層將使用診斷來執行簡單的測試並詢問更多的Quetions，並收集信息並在此問題上編譯報告/登錄。

日誌最有可能被解析/序列化/消毒以刪除或替換個人數據，例如IPS，Mac ID，用戶名，甚至是路徑/文件名，並用1.2.3.4或12：34或12：34：34：56：56：78：90或此類代替它們。

然後，如果無法通過自動診斷過程解決問題，這些過程基於眾所周知，磨損和戰鬥測試的簡單解決方案來識別問題，那麼客戶將在第二層中完全按照ReportBug的操作進行操作，並查找錯誤報告（和/或FOUM/WIKI帖子），並從我們已經擁有的現有知識數據庫中顯示給它們。

If the issue remains unsolved it will then in the 3rd tier facilitate forwarding the issue to the issue tracker and giving it an ID number, then forwarding it to our support tools (IRC/Mailing lists) that we already have, from within the client itself, and if IRC is used this will be facilitated by the bot issuing a " Issue #98153: no sound in pianobar" in the channel notifying our supporters of an open issue, and if用戶沒有收到解決方案或決定離開的解決方案，因此問題可以保持打開狀態和/或轉發到郵件列表，可以通過訪問帶有ID號的跟踪器網站或通過從跟踪器收回有關此問題的電子郵件通知來跟進。

如果該問題仍未解決，則可以將其轉發到第四層，就像BTS一樣（在BTS上提交報告，因為它被確定為支持者是軟件問題），也可能是上游。

診斷

The diagnostics tree files can possibly be some sort of XML or such, and will need to be signed and verified, the core diagnostic tree will be much like what reportbug does, it'll just gather some preliminary information about the system and verify that it's Debian, what version, arch, and what sources apt prefers, etc. The others which will be developed and maintained over time will be specific to the categories mentioned earlier, a sound issue diagnostic tree file for example will do諸如執行聲音測試之類的事情，詢問用戶是否聽到聲音，檢查混合器，要求他們檢查其連接等。

這些診斷樹文件還將通過運行命令來促進更多信息收集，從而收集有關問題類型的更多信息。這些命令將需要顯示和解釋並由用戶驗證，以及顯示的報告/日誌/輸出，並（（可選）解析/序列化/固定化以刪除任何個人信息。這些診斷將需要簽名和評估，並且問題跟踪器將以同樣的方式進行任何好的論壇評級系統的促進，只使用GPG簽名，而對解決方案進行評級不僅會導致客戶簽名診斷的信任，還會增加對診斷診斷的支持者的信任，這也會增加診斷的信任。

只要有可能，應採用諸如Chroots到基於內核的安全機制之類的所有安全機制，以鎖定診斷的事情，它們應該是簡單且不感知的。我們不想創建一個有知覺的診斷工具，只需進行一些簡單的檢查，以了解已知的配置問題，簡單的測試和編譯數據以進行進一步支持。

機器人

The IRC bot should be not only a conduit/proxy for the user to the IRC support channels (up for much debate) perhaps speaking on the user's behalf in the channel with a generated user ID or issue number, which will not only allow us to ensure the user only sees stuff related to their issue, but that the issue tracker knows what support responses belong to the issue for later documentation of the issue and solution back to our existing tools like the wiki, forums, mailinglists and 這樣的。可以做各種方法，並且可以編寫IRC客戶端腳本或用於將這些ID列入這些ID（例如普通划痕）的端功能，或者也許支持者可以將Bot的消息發送給Bot以“登錄”到問題上，以便與Bot交談將信息發送回您簽名的用戶。

該機器人還將促進訪問編譯報告的訪問，並提供診斷和用戶提交的信息，從而使所有關於運行非常常見的命令和使用粘貼等的chat不休。此外，該機器人可能會作為客戶界面作為客戶界面，以在正常獨立的IRC客戶端中的某人在跟踪器中打開新問題（即使認為有必要，只有已知和註冊的支持者）。

簡而言之，機器人是與IRC支持渠道粘合的膠水，並應注意確保根據用戶的首選語言，Debian的分支，甚至是什麼包裝或發行的餐飲服務，這些信息在正確的渠道中浮起，因為我們對不同的事物有特定的渠道（因此，我們需要將人們轉介給其他渠道並與其他渠道相處，因此可以使他們受到任何損害的感覺，或者是他們的損害，或者是對他們進行的，或者有任何損失的感覺，或者是對他們進行的，或者是對他們進行的，或者是對他們進行的，或者是對他們進行的，或者是對他們進行的，或者是對他們進行的，或者是對他們進行的，或者是對他們的損害。

伺服器

跟踪器將包含有關該問題的元數據，它將生成問題標識符，跟踪任何CC地址的任何CC地址，以及報告的何處（Paste.debian.net最有可能），並且問題的狀態以及任何論壇，郵件，BTS或其他可能鏈接到此問題的郵件，BTS或其他事項。它本身不應該是某種新的Wiki或論壇，只是將其與元數據一起鏈接和粘合的前端。它應該具有類似於BTS的Web接口。

問題和錯誤是不同的；錯誤是軟件中的實際問題，那裡的問題通常只是Pebcak等。這就是為什麼有必要創建一個新跟踪器的原因，因為此跟踪器僅用於短期跟踪問題並確保它到達正確的最終休息地點。跟踪器將為機器人和客戶端提供所需的信息，以在我們現有的信息機器人中進行事實，提交錯誤報告或向郵件列表發出電子郵件，並作為任何感興趣的方都可以找出這些事情發生的地方以及在哪裡找到它們的地方。它不是我們所有現有系統的替代者，而是包裝器。粘合了DISS的所有組件，包括我們已經擁有的所有組件。

進一步的考慮

有人建議我們只是改善現有系統，這就是其中的一部分，但這不是代替。這仍然存在問題2的問題，因為他們需要了解以及如何使用這些東西，因此疏遠用戶。這將是OS本身中的軟件，它以直觀的方式整合和促進了不需要一年或以上的學習政策和實踐的所有軟件。

在改善現有系統方面，該項目及其貢獻者將尋求在需要註冊的任何和所有Debian支持系統上統一註冊，並與當前系統的團隊合作，以協同的方式將它們集成在一起。

Furthermore, existing systems can be used/adapted at the descretion of the current developers working on other areas, for example the BTS and Tracker can be one and the same, and these "Issues" can just be a much lower class of bug that the maintainer is not bothered with, and the reportbug can just be extended to include these other features, and an existing IRC bot can be forked and modified to add the needed functionality.這不僅是一個旨在創建單個新軟件的項目，而且還可以適應我們現在為了更好地為我們服務的所有項目。

我們需要什麼

我們需要程序員。那些熟悉Python的人似乎非常適合這些任務，易於編碼以及強大而靈活的，以開發我們所需的東西，而基本系統之外的依賴性較少。那些擁有基於信任的系統和服務，GPG簽名等的人。具有GUI/前端編程經驗的人。那些熟悉Debian開發過程以及用戶和開發人員的所有關注者。那些可以使用插座，HTTP，電子郵件協議等編程客戶/服務器網絡堆棧的人。

我們需要圍繞現有系統，現有團隊的努力以及為他們納入統一的Debian登錄證書系統的投入和計劃，該系統將在所有Debian站點和服務中運行。

我們需要那些將在該項目的網絡存在上進行記錄並與之接觸的人，並保留狀態信息和項目的目標以及如此明確的定義。

路線圖

該項目剛剛在2017年10月13日（星期五）的清晨開始，大約在美國/EST時間凌晨2點。在撰寫本文時，我們甚至沒有24小時，我們已經有六個左右的人在頻道中閒逛，並在各種論壇上做出回應。在這一點上，我們都只是在努力，圍繞思想拋棄，並試圖仔細做出將塑造項目及其設計的初步決策。

這裡的第一個目標是用Wiki建立一個牢固的網絡形象，並將其繪製出該集成系統的解剖結構及其進度的繪製，以便人們可以理解我們來自哪裡，我們要去的地方以及我們走了多遠。

這裡的第二個目標是充實一個可以定義該系統的功能和通信的API，我不是一個經驗豐富的程序員，但我已經看到它已經完成了數十年，有時您必須製作某些東西（一種工具）才能做出其他事情，在這種情況下，我認為啟動在客戶端界面上，尤其是GUI界面會固有地脫穎而出。起初，沒有問題跟踪器，問題將不會持久，這將只是一個客戶與可能生活在我們開發渠道中的基本機器人交談。

應該強調的是，這不是我們要迅速推出和部署的東西，我們希望獲得一些工作框架並進行廣泛的α測試外部正常渠道，最初沒有對現有服務進行任何修改以幫助促進集成，因為API還不存在。一旦我們擁有維護者和已經在Debian開發人員圈子中的人員的興趣和興趣，我們只想開始一個僅在非生產測試/不穩定係統上使用的beta測試階段。一旦對實施診斷的安全信任機制有信心，該系統實際上可以打包以進行SID，並希望將其插入將來的Debian穩定版本。診斷文件很可能會使用某種存儲庫，這些存儲庫可以隨著時間的推移而開發並實現在客戶中，而無需等待新的Debian發行週期，基於單獨的剛性測試和簽名/驗證過程。

從長遠來看，我們希望看到Debian Installer具有更強大的技能確定為第一步，而不僅僅是普通/專家安裝模式，並且該支持客戶端由默認情況下自動安裝，而不是選擇高級或專家級別的系統。我們希望看到我們所有的支持者不僅參與自由范圍的支持，還可以註冊基於信任的系統並使用GPG簽名，以便我們的知識庫可以是更高的質量和更受信任的。