เหตุใดบางโครงการขนาดใหญ่เช่น Git และ Debian ให้ใช้รายการส่งเมลเท่านั้นไม่ใช่ตัวติดตามปัญหา

65

ตัวติดตามบั๊กสำหรับโปรเจคที่มีขนาดเหมาะสมดูเหมือนจะเป็นเรื่องง่ายสำหรับฉัน - มันทำให้การจัดระเบียบปัญหานับแสนเป็นเรื่องง่ายโดยไม่เกิดปัญหาการชนหรือการมั่วสุมกัน

ดังนั้นเมื่อฉันเห็นโครงการขนาดใหญ่จริง ๆ เช่น Git โดยใช้รายชื่อผู้รับจดหมายเป็นวิธีหลักในการประสานงานการบำรุงรักษาและการพัฒนาฉันก็รู้สึกปลิวไปนิดหน่อย ตัวอย่าง:

Git -หน้าชุมชน :

... รายงานข้อผิดพลาดควรถูกส่งไปยังรายการจดหมายนี้
ระบบติดตามบั๊ก Debianตาม Wikipedia:

... คุณสมบัติที่เป็นเอกลักษณ์คือมันไม่มีรูปแบบของเว็บอินเตอร์เฟสเพื่อแก้ไขรายงานบั๊ก - การแก้ไขทั้งหมดจะกระทำผ่านอีเมล

เครื่องมือติดตามบั๊กสมัยใหม่หลายรุ่นมีการรวมที่ดีมากกับอีเมล (คุณสามารถรับความคิดเห็นหรือการแจ้งเตือนเกี่ยวกับข้อผิดพลาดที่คุณกำลังรับชมหรือที่ได้รับมอบหมายให้คุณ) รวมถึงระบบควบคุมเวอร์ชัน (คอมมิชชัน .) สิ่งนี้จะต้องทำด้วยตนเองพร้อมกับรายชื่อผู้รับจดหมายและคุณจะได้รับอีเมลจำนวนมากเกี่ยวกับข้อบกพร่องที่คุณไม่สนใจ

ดังนั้นอะไรคือข้อดีหลักของรายชื่อผู้รับจดหมายผ่านตัวติดตามบั๊กบนเว็บ เหตุใดบางโครงการขนาดใหญ่จึงใช้รายการส่งจดหมายเท่านั้น

— naught101
แหล่งที่มา

2

ใช่ไม่ฉันเห็นด้วยกับคุณ Git ใช้รายชื่อผู้รับจดหมาย :) สิ่งที่ฉันพูดคือคุณกำลังจับมันด้วย "บางโครงการที่ยิ่งใหญ่จริงๆ" และฉันแค่คิดว่าถ้าคุณทำเช่นนั้นคุณควรให้มากกว่านี้ ตัวอย่างสำหรับโครงการที่ยิ่งใหญ่จริงๆ มิฉะนั้นคำถามจะเกิดขึ้นที่ "Git ใช้รายชื่อรับเมลทำไมจึงเป็นเช่นนั้น" ซึ่งในกรณีนี้คำตอบJörg W Mittag เป็นดีเหมาะ ...

— Shivan มังกร

1

อืมฉันอยู่ภายใต้ความรู้สึกว่ามีอีกมาก ... Debian ใช้ระบบอีเมลพื้นฐานแม้ว่าจะซับซ้อนกว่ารายการส่งเมล ตกลง แต่ประเด็นหลักคือ 'อะไรคือข้อดีของการใช้รายชื่อผู้รับจดหมายผ่านเครื่องติดตามบั๊ก' หากไม่มีคำตอบคือ "ไม่มีเลยนักพัฒนาคอมไพล์ก็เป็นแค่ luddites"

— naught101

@ naught101: ทำไมคุณถึงปลิวไปเมื่อคุณเห็นมัน? เดเบียนไม่เสถียรสามารถติดตั้งและใช้งานได้โดยไม่ต้องเห็นช่องโหว่ของรูทระยะไกลที่ต้องการการแพตช์และไม่จำเป็นต้องรีบูตเครื่องเป็นเวลาหกเดือนได้อย่างง่ายดาย นั่นสำหรับDebian เวอร์ชันที่ไม่เสถียร ฉันมีเซิร์ฟเวอร์ Debian ถูกล็อคผู้ที่มีเวลาถึง 4 หลักของเวลา (ไม่ใช่การเจาะรูทเครื่องจากระยะไกลเดียวที่ต้องรีบูตเพื่อส่งผลต่อการตั้งค่าของฉันในช่วงเวลานั้น) พวกเหล่านี้อาจไม่ได้ใช้เทคโนโลยีล่าสุด แต่ก็เห็นได้ชัดว่าพวกเขากำลังทำสิ่งที่ถูกต้อง ฉันจะทิ้งเครื่องมือติดตามบั๊กเพื่อความเสถียรของเดเบียนทุกที่ทุกเวลา

— Cedric Martin

2

@CedricMartin: ฉันรู้ว่าฉันเห็นด้วย การติดตามบั๊กของรายการส่งเมลทำงานอย่างชัดเจนเพียงพอสำหรับบางทีม แต่มันก็ดูง่ายกว่าฉันสำหรับตัวติดตามบั๊ก ฉันคิดอยู่เสมอว่าสำหรับผู้พัฒนาโครงการหลักความแตกต่างอาจดูเล็กมากพวกเขาติดตามเกือบทุกอย่างที่เกิดขึ้น แต่สำหรับผู้มาใหม่รายชื่อผู้รับจดหมายนั้นแทบจะเป็นไปไม่ได้เลยดังนั้นจึงไม่มีภาพรวมที่ง่ายของโครงการออกกำลังกาย ตัวติดตามบั๊กช่วยให้ผู้ใช้ใหม่ / ผู้พัฒนาได้อย่างรวดเร็วหาวิธีการย้ายโครงการและรับทราบว่าการปรับปรุงประเภทใดที่ทีมงานหลักถือว่าสำคัญ

— naught101

Greg Kroah-Hartman มีส่วนร่วมในเรื่องนี้เนื่องจากเกี่ยวข้องกับเคอร์เนล Linux เป็นส่วนหนึ่งของการสนทนานี้ โดยเฉพาะอย่างยิ่ง: "ไม่มีทางที่รูปแบบ github / gerrit / gitorious จะใช้งานได้กับเคอร์เนลสเกลที่เราทำงานนั้นแตกต่างอย่างสิ้นเชิงกับที่เครื่องมือเหล่านั้นจัดการได้ ... ไม่มีอีกแล้ว วิธีที่รู้จักกันในการจัดการกับ 10,000 แพตช์ทุก 2 เดือนในการวางจำหน่ายที่เสถียรพร้อมการตรวจสอบจากเพื่อน ๆ ด้วยนักพัฒนามากกว่า 3,000 รายนอกเหนือจากที่เราทำในวันนี้ "

— naught101

45

การตั้งค่าคุณสังเกตดูเหมือนว่าเป็นผลมาจากธรรมชาติของคำแนะนำที่ระบุไว้อย่างชัดเจนในมาตรฐานการเข้ารหัส GNU มันแนะนำให้รายงานข้อผิดพลาดทางอีเมลตามที่คุณเห็นในใบเสนอราคาด้านล่าง (ฉันทำเครื่องหมายตัวหนาส่วนที่ตรงกับการสังเกตของคุณ):

4.7.2 --help

--helpตัวเลือกมาตรฐานควรแสดงเอกสารสรุปเกี่ยวกับวิธีการเรียกใช้โปรแกรมบนเอาต์พุตมาตรฐานจากนั้นออกจากโปรแกรมสำเร็จ ตัวเลือกและข้อโต้แย้งอื่น ๆ ควรถูกละเว้นเมื่อพบสิ่งนี้และโปรแกรมไม่ควรทำหน้าที่ตามปกติ

ใกล้ถึงจุดสิ้นสุดของ‘--help’ตัวเลือกโปรดวางบรรทัดที่ให้ที่อยู่อีเมลสำหรับรายงานข้อผิดพลาดหน้าแรกของแพ็คเกจ (ปกติ‘http://www.gnu.org/software/pkg’และหน้าทั่วไปเพื่อขอความช่วยเหลือในการใช้โปรแกรม GNU รูปแบบควรเป็นดังนี้:
    Report bugs to: mailing-address
    pkg home page: <http://www.gnu.org/software/pkg/>
    General help using GNU software: <http://www.gnu.org/gethelp/>
มันก็โอเคที่จะพูดถึงรายชื่อผู้รับจดหมายและหน้าเว็บที่เหมาะสมอื่น ๆ

ในทางกลับกันการตั้งค่าดังกล่าวสะท้อนให้เห็นถึงการยอมรับอีเมลสากลในรูปแบบของการสื่อสารทางอิเล็กทรอนิกส์ ผู้ใช้ที่อ่าน--helpข้อความเช่นแนะนำข้างต้นควรเข้าใจได้ง่ายว่าจะทำอย่างไรถ้าพวกเขาเห็นข้อผิดพลาด - เมลเป็นเรื่องง่าย

ตัวติดตามปัญหาอาจจะ (และฉันคิดว่าเป็น ) ที่ดีกว่าสำหรับนักพัฒนาที่ทำงานในโครงการ แต่สำหรับผู้ชมที่กว้างขึ้นมันจะยากที่จะนำเสนอและอธิบายวิธีการใช้งานโดยเฉพาะอย่างยิ่งคำนึงถึงความหลากหลายและความแตกต่างระหว่างระบบติดตามปัญหาต่างๆ .

โครงการหนึ่งสามารถใช้ Bugzilla อีกโครงการหนึ่งจะยึดกับ JIRA โครงการที่สามกับ ... GNATSฯลฯ ฯลฯ ไม่มีวิธีใดที่จะนำเสนอ "สวนสัตว์" ทั้งหมดนี้ในแบบที่จะเป็นมาตรฐานและเหมือนกัน

Report bugs to: mailing-address

หมายเหตุข้างต้นไม่ได้หมายความว่าโครงการที่ไม่ควรจะใช้ติดตามปัญหาภายใน ตามที่อธิบายไว้ในคำตอบที่ดีที่จะคำถามที่เกี่ยวข้อง ,

ติดตามข้อผิดพลาดของคุณเป็นของคุณสะดวกสบายไม่ได้ของลูกค้า หากคุณไม่สามารถรับปัญหาทางโทรศัพท์หรืออีเมลและป้อนข้อมูลด้วยตนเองคุณคิดว่าพวกเขารู้สึกอย่างไร

คุณต้องสามารถป้อนปัญหาและกำหนดด้วยตนเองให้กับลูกค้า ...

— ริ้น
แหล่งที่มา

3

คำตอบที่ดี! อีเมลรู้จักกันดีกว่าตัวติดตามปัญหาและง่ายต่อการเข้าใจ (ซึ่งไม่ได้บอกว่าทุกคน "รับ" อีเมล: P)

— Andres F.

21

นอกจากนี้ว่าคำแนะนำคือ GNU โบราณวิธีที่เก่ากว่าเว็บและ Web-based ติดตามปัญหา

— Ross Patterson

@ RossPatterson ฉันคิดว่า แต่ดูเหมือนไม่น่าเป็นไปได้ว่ามันเก่ากว่าเว็บโดยพิจารณาว่ามี URL จำนวนมาก ...

— naught101

6

@gnat: ส่วนหนึ่งที่สำคัญของการเชื่อมโยงว่าคำตอบเป็นที่ดีเพื่อให้เป็น"ถ้ามันเป็นเรื่องง่ายสำหรับคุณคุณสามารถป้อนเรียงลำดับของสิ่งที่มีสิทธิ"เป็นส่วนหนึ่ง นั่นเป็นกุญแจสำคัญสำหรับโครงการโอเพนซอร์สหลายแห่งเนื่องจากไม่มีเงินทุนสนับสนุนทางโทรศัพท์ รายชื่อผู้รับจดหมายเป็นบริการปิดสำหรับฉันในฐานะผู้ใช้รายงานข้อผิดพลาดเนื่องจากฉันไม่ต้องการลงชื่อสมัครใช้เพื่อตอบกลับ ด้วยตัวติดตามบั๊กฉันสามารถเห็นว่าปัญหาที่ฉันมีอยู่ในระบบและสามารถกลับมาและค้นหาในภายหลังและดูว่ามีการอัปเดตหรือไม่ นี่เป็นเรื่องยากสำหรับรายชื่อผู้รับจดหมายเว้นแต่ว่าจะมีตัวติดตามรายการทางเว็บที่ดีมากซึ่งมักไม่เป็นเช่นนั้น

— naught101

1

@ naught101 มันอาจจะไม่แก่กว่าบนเว็บ แต่แน่นอนว่าเก่ากว่าตัวติดตามบนเว็บ

— sakisk

30

โดยเฉพาะอย่างยิ่ง Git นั้นมีเหตุผลทางประวัติศาสตร์ที่เรียบง่าย: Git เริ่มต้นโดยแฮกเกอร์ Linux สำหรับแฮกเกอร์ Linux และใช้รูปแบบการพัฒนาและเครื่องมือแบบเดียวกับที่ Linux ทำ อย่างไรก็ตามลีนุกซ์มีอายุมากกว่า WWW ดังนั้นเมื่อเริ่มต้นลีนุกซ์ก็ไม่มีตัวติดตามปัญหาบนเว็บเพราะไม่มีเว็บ!

ชุมชน Linux ได้พัฒนาเครื่องมือและเวิร์กโฟลว์ที่มีประสิทธิภาพสูงสำหรับการจัดการรายงานข้อผิดพลาดและการตรวจสอบโค้ดผ่านอีเมลและไม่มีเหตุผลที่พวกเขาจะทิ้งงานเหล่านั้นทั้งหมดและเริ่มจากศูนย์เมื่อเริ่มโครงการ Git

— Jörg W Mittag
แหล่งที่มา

3

ฉันคิดว่า WWW นำหน้า Linux เล็กน้อย. พวกเขาทั้งคู่ทำกันมากในเวลาเดียวกันและโดยคนกลุ่มต่าง ๆ มันไม่ได้จริงๆจนกระทั่งช่วงกลางยุค 90 ที่ทั้งสองออกไป

— Donal Fellows

6

ok แต่เคอร์เนลลินุกซ์ตอนนี้มีบั๊ก: bugzilla.kernel.org เห็นได้ชัดว่าไม่ใช่อุปสรรคใหญ่

— naught101

7

-1 Git อายุน้อยกว่าเว็บอย่างจริงจัง Vintage 2005 มีตัวติดตามปัญหามากมายในขณะนั้นรวมถึง Bugzilla ด้วย ไลนัสไม่ชอบตัวติดตามปัญหาและคำพูดของเขาคือกฎหมายในสภาพแวดล้อมนั้น

— Ross Patterson

6

@RossPatterson - เขากล่าวว่า Linux มีอายุมากกว่าเว็บไม่ใช่ Git ฉันไม่คิดว่าความคิดเห็นของคุณแสดงให้เห็นถึงการลงคะแนนเสียงเนื่องจากคุณพูดซ้ำสิ่งที่เขาพูด

— beatgammit

2

@tjameson เมื่อเข้าใจย้อนหลังคุณพูดถูก กลับไปเป็นกลาง

— Ross Patterson

17

สำหรับ Git:

มีการสนทนาหลายรายการในรายชื่อผู้รับจดหมายที่ผู้คนเสนอให้ใช้ตัวติดตามบั๊กบางประเภท ความคิดริเริ่มเหล่านี้ดูเหมือนจะทำให้มึนงงดังนั้นเหตุผลที่ Git ไม่ได้ใช้ตัวติดตามบั๊กอาจเป็นเพียงว่าผู้ให้ข้อมูลส่วนใหญ่ไม่พบว่ามีประโยชน์

ในโพสต์ไปยังรายชื่อผู้รับจดหมาย Junio C Hamano (ผู้ดูแล Git) สรุปว่าทำไมเขาถึงรู้สึกว่าตัวติดตามบั๊กนั้นไม่มีประโยชน์มาก ฉันไม่ต้องการรวมการโพสต์ทั้งหมด (มันค่อนข้างยาว) แต่มันก็ลดลงไปที่:

หากคุณกำลังมองหาข้อมูลเกี่ยวกับปัญหาที่แก้ไขแล้วการค้นหารายการที่เก็บถาวรจะทำงานได้ดีเท่ากับการค้นหาตัวติดตามบั๊ก
หากคุณรายงานข้อผิดพลาดของแท้และผู้คนต้องการที่จะดูแลมันรายการนี้ก็ใช้ได้ดีเช่นกัน
หากไม่มีใครสนใจทำงานเกี่ยวกับปัญหามันจะตกอยู่ในรอยแตกแม้ในเครื่องติดตามบั๊ก
ตัวติดตามบั๊กจะเป็นอีกระบบหนึ่งที่ต้องได้รับการดูแลตรวจสอบข้อผิดพลาดใหม่ ๆ อย่างสม่ำเสมอปิดตัวแก้ไขบั๊ก ฯลฯ สั้น ๆ ทำงานพิเศษเพื่อผลประโยชน์เล็ก ๆ น้อย ๆ

— sleske
แหล่งที่มา

5

คำตอบที่ดี แต่ฉันจะยืนยันว่าจุดที่ 3 ของคุณเป็นข้อเสียที่สำคัญของอีเมล: หากบั๊กยากต่อการแก้ไขและ devs ปัจจุบันขี้เกียจมันจะถูกฝังอย่างมีนัยสำคัญมากกว่ารายการในตัวติดตามปัญหา นี่อาจหมายถึงข้อผิดพลาดบางอย่างไม่เคยได้รับการแก้ไขเพียงเพราะผู้คนไม่รู้จักที่นั่น

— TheLQ

1

@TheLQ: จริง อย่างไรก็ตามเห็นได้ชัดว่าเป็นความเสี่ยงที่บางโครงการยินดีที่จะรับ และเพื่อความยุติธรรม git เป็นซอฟต์แวร์ที่ค่อนข้างแข็งแกร่งแม้ไม่มีตัวติดตามบั๊ก

— sleske

1

@TheLQ: หน้าเว็บที่เรียบง่ายจะไม่พูดถึงข้อบกพร่องที่รู้จักทั้งหมด (และกระทู้ที่เกี่ยวข้อง) แก้ไขได้หรือไม่ สิ่งที่คล้ายกับสิ่งนี้ยกเว้นว่าลิงก์ชี้ไปยังไฟล์เก็บถาวรเธรด

— สวัสดีชาวโลก

1

@HelloWorld: นั่นก็จะเป็นตัวติดตามปัญหา (ง่าย) และเช่นเดียวกับติดตามปัญหาคนที่จะต้องจัดการกับมัน ...

— sleske

มีวิธีที่ดีในการรับสำเนาออฟไลน์ของอีเมลที่ส่งออกไปในขณะที่ฉันไม่ได้เป็นสมาชิกใช่ไหม

— PSkocik

6

Debian ใช้ตัวติดตามบั๊กส่วนต่อประสานเริ่มต้นคืออีเมล และมันก็สะดวก Lucas Nussbaum หัวหน้าโครงการ Debian ปัจจุบันได้โพสต์เมื่อวานนี้ :

debbugs เป็นชิ้นส่วนของซอฟต์แวร์ที่อยู่เบื้องหลัง Debian Bugs Tracking System (BTS) มันถูกใช้โดยโครงการ GNU แม้มักจะถูกมองว่าเป็นแบบเก่า แต่ก็มีคุณสมบัติที่เป็นเอกลักษณ์หลายอย่างเช่นการติดตามสถานะของข้อบกพร่องในแต่ละรุ่นและสาขาของแพ็คเกจ) หรือความสามารถในการโต้ตอบทั้งหมดผ่านอีเมลทำให้ง่ายต่อการทำงาน ออฟไลน์หรือในสภาพแวดล้อมที่เชื่อมต่อไม่ดี

ส่วนสุดท้ายคือคุณสมบัตินักฆ่าที่นี่ - เพียงแค่จัดคิวรายงานเหล่านั้นในคิวเมลท้องถิ่นของคุณจนกว่าคุณจะออกจากเครื่องบิน!

— Dominik George
แหล่งที่มา

4

ป้องกันเด็กอายุ 9 ปีออกไป
ไม่จำเป็นต้องสร้างบัญชีแยกต่างหากสำหรับแต่ละฟอรัม
[รายย่อย] ประสบการณ์ของผู้ใช้ที่สอดคล้องกันในรายชื่อรับเมลที่แตกต่างกันและเส้นโค้งการเรียนรู้ที่ไม่เป็นศูนย์เมื่อสมัครรับรายการใหม่
ทำงานแบบออฟไลน์ คุณสามารถเชื่อมต่ออินเทอร์เน็ตและดาวน์โหลดชุดของอีเมลจากนั้นไปปีนเขาเขียนคำตอบของคุณในขณะที่เพลิดเพลินกับธรรมชาติของแม่และส่งพวกเขาในภายหลัง
อนุญาตให้เข้ารหัสอีเมลและ / หรือเซ็นชื่อผ่าน GPG
กระจายอำนาจ - หากฟอรัมเกิดปัญหาคุณยังคงมีสำเนาอยู่ แต่ก็ยังไม่สามารถต้านทานได้ moderator / แฮ็กเกอร์ชั่วร้ายไม่สามารถเข้าไปยุ่งเกี่ยวกับสิ่งที่คุณพูดได้อย่างง่ายดาย ไม่มีใครสามารถยกเลิกประวัติได้
อนุญาตให้ฟิลเตอร์, โฟลเดอร์และฟีเจอร์การจัดการขั้นสูงทั้งหมดของไคลเอนต์อีเมล
"การแจ้งเตือนแบบพุช" - คุณสามารถเปิดไคลเอนต์อีเมลของคุณและรับการแจ้งเตือนเมื่อมีคำตอบใหม่
ที่เดียวที่จะปกครองได้ทั้งหมดไม่จำเป็นต้องข้ามไปมาระหว่างไซต์
ภูมิคุ้มกันต่อช่องโหว่ความปลอดภัยทั้งหมดที่เกี่ยวข้องกับเว็บ (html / javascript / injections ฯลฯ )
ไม่มีการขยายตัว - ไม่มีตราสัญลักษณ์ลายเซ็นแฟนซีโฆษณาเว็บบีคอน javascript bloat มันง่ายและตรงประเด็น - การสนทนา
ภาระเซิร์ฟเวอร์น้อยกว่าการตั้งค่า LAMP

ข้อเสียอย่างหนึ่งของรายชื่อผู้รับจดหมายที่คำนึงถึงคือฟอรัมแบ่งออกเป็นหมวดหมู่และหมวดหมู่ย่อยในขณะที่รายชื่อรับเมลไม่ได้ สิ่งนี้สามารถเลียนแบบได้โดยการแบ่งรายชื่อผู้รับจดหมายออกเป็นหลายรายการจดหมายจากนั้นผู้ใช้สามารถใช้ตัวกรองที่เหมาะสมเพื่อใส่แต่ละข้อความด้วยโฟลเดอร์ที่เกี่ยวข้อง (แต่ละโฟลเดอร์เป็นหมวดหมู่) ในเว็บบอร์ดนี้เป็นไปโดยอัตโนมัติ

— สวัสดีชาวโลก
แหล่งที่มา

เหตุใดผู้คนจึงยืนยันในการสร้างเวอร์ชันบนเว็บเพื่อติดตามปัญหา (BTW คำถามนี้ไม่เกี่ยวกับทุกสิ่ง ) ถูกกล่าวถึงในคำถามอื่น: การให้ผู้ใช้เขียนรายงานบั๊กที่เหมาะสมและมีประโยชน์ "รายงานข้อผิดพลาดออนไลน์ที่ผู้ใช้แก้ไขได้ ผู้ใช้ปรับปรุง ..."

— ริ้น

ขอขอบคุณ. แต่สิ่งนี้แสดงให้เห็นถึง downvote หรือไม่? หัวข้อหลักของคำตอบนี้คือข้อดีของ ML และตอบคำถามดั้งเดิมได้ค่อนข้างดี ฉันได้ลบคำพูด "เว็บฟอรัม"

— สวัสดีชาวโลก

2

ข้อเสียที่กล่าวถึงในคำตอบนี้จริง ๆ แล้วขัดขวางฉันจากการติดกับรายชื่ออีเมล dev ส่วนใหญ่ พวกเขาส่งผ่านทุกอย่างดังนั้นหลังจากรายงานข้อผิดพลาดฉันมักจะยกเลิกการสมัครสมาชิกเพียงสองสัปดาห์ต่อมา Bugtrackers แก้ปัญหานี้ได้เป็นอย่างดีโดยให้ฉันสมัครรับรายงานข้อผิดพลาดเฉพาะ

— Roman Starkov

6

การแก้ไข: ป้องกันไม่ให้เด็กอายุ25ปีออกไป เมื่อไม่นานมานี้ฉันได้เรียนรู้ว่าการส่งจดหมายเหล่านั้นแสดงรายการสิ่งต่าง ๆ เพื่อสนับสนุนโครงการจริง และฉันเกลียดมัน !!

— Ciro Santilli 新疆改造中心法轮功六四事件

2

"ไม่จำเป็นต้องสร้างบัญชีแยกต่างหากสำหรับแต่ละฟอรัม" - บ่อยครั้งเพื่อป้องกันสแปมที่คุณต้องสมัครใช้งานรายการ แต่นั่นสมัครรับอีเมลทั้งหมด ดังนั้นคุณต้องสมัครสมาชิกและเลือกไม่ใช้ 'สแปม' และเพิ่มคำขอเพื่อให้คุณอยู่ใน CC หรือ TO เมื่อเทียบกับ bugzilla มันมีอะไรให้ทำมากกว่านี้

— Maciej Piechotka