Trách nhiệm của ai là bản vá sửa lỗi?


12

Một tình huống đã phát sinh nhiều lần trong các dự án nguồn mở diễn ra như sau:

  1. Tôi nhận thấy một lỗi trong quá trình triển khai của chúng tôi và tìm ra bản vá hack nhanh. (Ví dụ: chỉ cần nhận xét mã mà chúng tôi không thực sự cần.)
  2. Tôi dành thêm một chút nỗ lực để tìm ra lỗi thực sự, đưa ra một bản vá và gửi nó thông qua yêu cầu kéo Git hoặc tương tự.
  3. Yêu cầu kéo của tôi bị từ chối. Có lẽ bản vá không hoàn hảo (ví dụ, bao gồm các dòng không nên có), có lẽ nó đã vi phạm phong cách mã hóa, có lẽ nó có các phân nhánh khác. Hoặc có lẽ tôi đã làm gì đó sai trong Git - yêu cầu kéo nên đã bị từ chối hoặc một cái gì đó. Một người bảo trì cung cấp thông tin phản hồi về cách cải thiện bản vá và yêu cầu tôi gửi lại.

Tại thời điểm này tôi bối rối về việc tôi nên tiến hành bao xa. Theo như tôi quan tâm, tôi không gặp vấn đề gì: Tôi đã sửa nó ở bước 1. Tôi đã báo cáo vấn đề, thậm chí tôi đã thực hiện các bước để khắc phục sự cố cho người khác. Nhưng tôi không cảm thấy rằng đó là "yêu cầu" của tôi, vì vậy tôi không cảm thấy trách nhiệm cải thiện bản vá sẽ đến với mình.

Một tình huống đặc biệt làm tôi khó chịu là sau khi thảo luận về sự thất bại của bản vá của mình, chúng tôi đạt được thỏa thuận về danh sách gửi thư về bản vá chính xác sẽ như thế nào (nghĩa là nó nên hoạt động như thế nào, đôi khi bao gồm mọi dòng mã được viết ra). Sau đó, nó vẫn được coi là trách nhiệm của tôi để thực sự tạo và gửi bản vá.

Có một nghi thức tiêu chuẩn trong những tình huống này? Họ giải quyết thế nào? Là phản ứng của tôi không bình thường? Bạn dự kiến ​​sẽ đi bao xa để sửa lỗi được chấp nhận?

(Lưu ý khi tôi nói "dự án nguồn mở", một số trong số này rất nhỏ, nhưng có thể không phải là sở thích - đơn giản là các dự án phần mềm nhỏ được sử dụng cho một số tổ chức, những người cam kết tài nguyên của nhà phát triển để làm việc với họ. là "sửa bản vá và gửi lại", hiểu rằng tôi có trách nhiệm với chủ nhân của mình để làm việc với những thứ có lợi cho họ. Dành thời gian để sửa một lỗi không ảnh hưởng đến chúng tôi sẽ là sai ...)

Câu trả lời:


12

Theo như tôi quan tâm, nếu bạn tìm thấy một lỗi hoặc có yêu cầu nâng cao, không phải là người đóng góp cho dự án và đã gửi báo cáo lỗi thông qua các kênh thích hợp, bạn đã hoàn thành. Về mặt trả lại cho cộng đồng, bất kỳ ai đang sử dụng một dự án nguồn mở và tìm thấy một khiếm khuyết đều phải báo cáo nó.

Cố gắng tìm một giải pháp, thiết kế và thực hiện nó là một phần thưởng cho dự án. Nếu bạn đã thực hiện điều này, có thể là một ý tưởng tốt để gửi nó, thông qua yêu cầu kéo hoặc có thể gửi deltas tệp cho nhóm phát triển cùng với báo cáo lỗi hoặc yêu cầu nâng cao để cung cấp cho họ một cái gì đó để làm việc. Tuy nhiên, họ không có nghĩa vụ phải chấp nhận đóng góp của bạn cho dự án.

Mong đợi một người dùng đóng góp các bản vá dường như sai, với tôi. Khá dễ dàng để tham gia vào một cuộc thảo luận về một vấn đề, nhưng đó là một khoản đầu tư thời gian lớn hơn nhiều để đưa ra giải pháp. Không có dự án nào nên mong đợi những người không đóng góp trở thành người đóng góp chỉ để khắc phục một vấn đề duy nhất.


Đồng ý 100%, người dùng cuối không có trách nhiệm gửi trực tiếp bản sửa lỗi vào kho lưu trữ nguồn, trừ khi bạn muốn trở thành người đóng góp thường xuyên cho dự án. Đó là những gì danh sách gửi thư và trình theo dõi lỗi dành cho. Spring, Maven, v.v. làm mô hình chính xác này, nơi mọi người sẽ tự tìm giải pháp và đăng nó lên mục trong Jira. Đó là tùy thuộc vào bất cứ ai đang làm việc với lỗi để chấp nhận và xử lý sự đóng góp.
Spencer Kormos

+1 để tìm lỗi và gửi báo cáo. Bạn có thể không gửi bản sửa lỗi nhưng tôi chắc chắn cảm thấy rằng chỉ bằng cách tìm ra lỗi, nghiên cứu và gửi thông tin liên quan trong báo cáo lỗi thì bạn chắc chắn đang đóng góp cho dự án.
maple_shaft

Giả sử tôi người đóng góp cho toàn bộ dự án. Điều đó thay đổi gì?
Steve Bennett

@SteveBennett Không biết cấu trúc của dự án, tôi không thể trả lời điều đó. Một số dự án được cấu trúc chặt chẽ hơn với các nhiệm vụ được giao, trong khi các dự án khác có nhiều luồng tự do hơn.
Thomas Owens

5

Tiếp tục khi bạn sẵn sàng với nó. Sẽ rất tốt nếu sửa bản vá của bạn và chia sẻ nó với thế giới trong cốp xe chính, nhưng nếu người bảo trì không muốn nó, hãy nhún vai. Bạn có thể đăng ở đâu đó vấn đề của bạn và bản vá để giải quyết vấn đề đó, để những người khác trong cùng một chiếc thuyền có thể tìm kiếm giải pháp.

Và bạn không phải không có vấn đề. Bản vá của bạn sẽ không được nâng cấp tiếp theo. Vì vậy, bạn sẽ phải repatch và hy vọng nó hoạt động hoặc xoa bóp nó vào vị trí, bất cứ khi nào bạn lấy một phiên bản mới. Vì vậy, đưa nó vào dự án chính sẽ giúp bạn tiết kiệm và công ty của bạn, về lâu dài.

Đó là một nỗi đau với bạn, nhưng bạn đang đóng góp cho cộng đồng. Tôi chắc chắn đánh giá cao tất cả những người đóng góp công việc đưa vào. Nó không giống như phần mềm chất lượng chỉ là nguồn gốc kỳ diệu từ quần chúng. Có người phải làm việc. (Vậy ai là người tuyệt vời? Bạn thật tuyệt vời). Nếu bạn không cảm thấy như vậy, hãy thông báo cho cộng đồng rằng trong khi bạn đánh giá cao cuộc thảo luận về việc nó nên như thế nào, thì đơn giản là bạn quá bận rộn để làm điều đó. Ý tôi là, họ sẽ làm gì? Cắt lương của bạn?


4

Có một nguyên lý làm cho văn hóa nguồn mở dễ hiểu hơn: người thực hiện công việc quyết định những gì cần làm. Đây là một trong những lời kêu gọi của nó so với công việc hàng ngày của các nhà phát triển. Ưu tiên số 1 của bạn có thể là # 50 trong hồ sơ tồn đọng của họ. Nếu bạn không khắc phục yêu cầu kéo của mình, cuối cùng nó có thể sẽ nhỏ giọt lên đầu và họ sẽ xử lý nó. Tuy nhiên, nếu bạn làm cho nó đủ dễ dàng với họ, họ sẽ chăm sóc nó ngay bây giờ.

Lý do khác họ yêu cầu bạn sửa yêu cầu kéo của bạn là hào hùng hơn. Họ muốn bạn nhận được tín dụng cho sự đóng góp của bạn, nhỏ như nó có thể. Nếu bạn thực hiện sửa lỗi, tên của bạn là tên trong trường tác giả của cam kết. Hầu hết mọi người đều tự hào về sự đóng góp của họ muốn xem qua nó, vì vậy modus operandi mặc định của người bảo trì là để cho họ.

Theo trách nhiệm của bạn đối với chủ lao động, nếu doanh nghiệp của bạn dựa vào mã này thì bạn không làm cho họ trở thành một kẻ bất đồng. Nhà tuyển dụng biết lợi ích của một công nhân dành thời gian để mài giũa các công cụ của mình.


2

AFAIK, cách mã nguồn mở là khả năng sửa lỗi sửa lỗi được dành cho người quan tâm đủ về lỗi để xử lý gánh nặng để đảm bảo sửa lỗi. Tùy thuộc vào hoàn cảnh, tôi đã làm mọi thứ, chỉ đơn giản là bỏ qua một vấn đề để chiến đấu (cung cấp các bản vá và tranh luận để chúng được chấp nhận) để đảm bảo rằng nó đã được sửa.

Mọi thứ đều đúng, chỉ cần đừng để mọi người quản lý dự án mong đợi điều sai từ bạn (tức là cho họ hy vọng rằng bạn sẽ khắc phục vấn đề đúng cách bằng các tùy chọn thảo luận và sau đó không làm gì cả), họ có thể nhận thức được nhiều vấn đề hơn họ có thể tự xử lý và sẽ cố gắng tạo ra một người đóng góp thường xuyên cho bạn nếu họ có thể.


1

Lỗi ban đầu chỉ có thể ảnh hưởng đến bạn, vì vậy bạn rất quan tâm đến việc gửi bài bằng cách làm bất cứ điều gì được yêu cầu để đưa bản vá của bạn tuân thủ. Nếu không, phiên bản tiếp theo bạn kéo (vì bạn cần các bản sửa lỗi khác) sẽ thiếu bản sửa lỗi của bạn.

Bạn không muốn duy trì một danh sách các bản vá bạn cần áp dụng mỗi khi bạn lấy một bản sao mới của dự án - thật quá rắc rối. Hãy dành thêm một chút thời gian và sửa nó vĩnh viễn để bạn không phải đối phó với nó một lần nữa.


1

Đối với một nhà phát triển nguồn mở, có hai loại vấn đề:

  • (a) các vấn đề không có bản vá
  • (b) các vấn đề gây ra bởi một bản vá

Tôi nghĩ rằng hầu hết các nhà bảo trì / nhà phát triển gói nguồn mở đều yêu thích ý tưởng giúp có được một người đóng góp không cốt lõi để tăng tốc với các bản vá của họ.

Tuy nhiên, mục tiêu chính của họ là giảm thiểu số lượng các vấn đề loại b. Đó là lý do tại sao thanh được đặt khá cao.

Một số người vượt qua nó. Họ trở thành những người đóng góp, hoặc thậm chí có thể là những người đóng góp cốt lõi. Những người khác bỏ cuộc. Có một bản chất Darwin nhất định đối với Nguồn mở - sự sống còn của kẻ mạnh nhất.

Tôi khuyến khích bạn tiếp tục và nhổ nước bọt đóng góp của bạn đến điểm mà nhóm chấp nhận nó. Khi bạn đã thực hiện một vài đóng góp, họ sẽ tin tưởng bạn hơn nữa, nhưng bạn vẫn nên đảm bảo rằng những đóng góp của mình là hoàn hảo.

Kết quả cuối cùng là hoàn toàn xứng đáng. Những thứ như có thể nói "Tôi có mã không? Có ... Bạn đang chạy thứ tôi viết mỗi ngày."


Ok, nhưng mức độ nhảy vòng hợp lý cần có là gì? Có lẽ có một sự khác biệt giữa một người bảo trì yêu cầu một chút nỗ lực để có được sự tin tưởng, và đơn giản là khó khăn và không hợp lý. Và một lần nữa, câu hỏi của tôi là: tôi đang cố gắng đạt được điều gì? Là nhận được lỗi của tôi vào codebase nhiều hơn trong lợi ích của họ hơn là của tôi?
Steve Bennett

Điều này đã được đề cập rằng bản phát hành tiếp theo sẽ không bao gồm bản vá cục bộ của bạn - vì vậy bạn nên sửa lỗi phần mềm. Công ty khôn ngoan - đó cũng là lợi ích tốt nhất của công ty - một ngày nào đó bạn có thể rời đi và không ai sẽ nhớ luôn vá lại ứng dụng XYZ với bản sửa lỗi cục bộ của bạn. Hãy thử điều này: làm lại bản vá, nhưng không gửi nó. Gửi cho người bảo trì qua email hoặc bằng cách khác - và HỎI về phản hồi của họ - như trong "Tôi nghĩ tôi đã nhận được mọi thứ bạn đã đề cập - bạn có thể giúp tôi đảm bảo điều này đúng không?"
pbr
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.