What
is a software patch?
By Ross Gardler,
Published: 07 January 2008, Reviewed: 09 July 2012
Bài được đưa lên
Internet ngày: 09/07/2012
Lời
người dịch: Bản vá là gì và vì sao bản vá là siêu
quan trọng trong một dự án phát triển mở. Bài viết
này phân tích chi tiết việc những người đóng góp cho
dự án tạo ra các bản vá như là một tính năng mới
hoặc một sửa lỗi rồi đóng góp lại cho cộng đồng
dự án thông qua những người duy trì kho mã nguồn của
dự án và mối quan hệ tương hỗ giữa họ, và cả những
khuyến cáo để sao cho các bản vá mà bạn đóng góp
vào dễ được áp dụng trong các phiên bản sẽ được
phát hành trong tương lai của phần mềm nguồn mở trong
dự án đó, đặc biệt là phương châm “Phát hành
sớm, phát hành thường xuyên” có liên quan thế nào
tới việc tạo ra và đề xuất các bản vá của dự án.
Một bản vá là một
hồ sơ những thay đổi được làm thành một tập hợp
các tài nguyên. Thường thì một bản vá sẽ bổ sung thêm
một tính năng mới, sửa một lỗi hoặc bổ sung thêm tài
liệu cho dự án. Ý nghĩa phổ biến của việc tạo ra một
bản vá là bằng việc sử dụng diff, một công cụ có
sẵn phổ biến trong các hệ thống Linux và Unix.
Các bản vá là cách
thức được ưu tiên để đệ trình những đóng góp cho
các dự án phát triển mở như phần mềm nguồn mở
(PMNM). Người đóng góp tạo ra một bản vá và đệ trình
nó cho dự án. Người duy trì dự án có thể sau đó kiểm
tra những thay đổi và áp dụng chúng cho kho mã chính nếu
họ chọn thế. Các công cụ khác nhau là sẵn sàng để
giúp với các bản vá. Những công cụ đó làm cho rất dễ
dàng để tạo và quản lý các bản vá cho các đầu ra
của dự án như mã nguồn và tài liệu. Các bản vá và
các công cụ quản lý bản vá là chìa khóa cho việc xây
dựng một cộng đồng tích cực những người đóng góp
cho một dự án phát triển mở.
Tài liệu này đưa ra
một tổng quan đơn giản về một bản vá phần mềm. Nó
không làm viecj với các cơ chế tạo ra và xử lý các bản
vá, những thứ sẽ được điều khiển tốt hơn bằng
tài liệu của công cụ quản lý bản vá được lựa
chọn. Trong phần tiếp theo, chúng tôi liệt kê vài công
cụ để giúp bạn làm quen với việc tạo ra các bản vá.
Tạo một bản vá
Khi một người đóng
góp thực hiện một thay đổi cho các đầu ra của một
dự án, họ làm thế bằng việc soạn sửa các tập có
sẵn trong một hệ
thống kiểm soát phiên bản (bản
dịch tiếng Việt). Hệ thống kiểm soát phiên bản
theo dõi các thay đổi đối với các tài liệu và mã
nguồn theo thời gian. Việc sử dụng một hệ thống kiểm
soát phiên bản để tiến hành tạo ra một bản vá là
đơn giản vì bạn luôn có thể tham chiếu tới phiên bản
của mã nguồn mà những thay đổi đó dựa vào. Tuy nhiên,
có một vài bước nên được thực hiện để tối đa
hóa những cơ hội để bản vá được những người duy
trì dự án chấp nhận.
Điều quan trọng là
người đóng góp đảm bảo rằng bản vá tuân thủ với
bất kỳ tài liệu và các tiêu chuẩn viết mã nào mà dự
án áp dụng. Cũng là sống còn để kiểm tra kỹ những
thay đổi đối với các bộ kiểm thử nào mà dự án
cung cấp. Cuối cùng, mỗi đóng góp nên được làm thành
tài liệu một cách rõ ràng, tối thiểu là với các chi
tiết về:
- nó định làm gì
- nó định triển khai như thế nào
- nó được sử dụng như thế nào
Một khi người đóng
góp thỏa mãn rằng bản vá đáng để những người duy
trì dự án xem xét, thì bản vá phải được tạo ra.
Việc người đóng
góp làm thế nào tạo ra được bản vá là phụ thuộc
vào môi trường phát triển nào họ đang sử dụng và
trong hệ thống kiểm soát phiên bản nào dự án đang sử
dụng. Hầu hết các môi trường phát triển tích hợp -
IDE (Integrated Development Environment) bao gồm một tính năng
để tạo một bản vá. Cũng có nhiều công cụ bạn có
thể cài đặt, cung cấp các giao diện dòng lệnh hoặc
GUI cho các công cụ tạo bản vá.
Sau khi chạy công cụ
được chọn, một hoặc nhiều tệp sẽ được tạo ra.
Nói chung, các tệp đó mô tả những thay đổi được
thực hiện trong đóng góp đó. Thường thì nhiều tệp sẽ
được đặt vào một tệp lưu trữ duy nhất để dễ
quản lý. Lưu trữ này được gọi là một bản vá. Đây
chính là bản vá mà một người đóng góp đệ trình cho
dự án.
Qui trình đệ trình
thực sự khác nhau đối với từng dự án, nhưng trong tất
cả các trường hợp sẽ có một yêu cầu đề cập tới
sự chỉ định bản quyền hoặc các quyền sử dụng sở
hữu trí tuệ (IP) nằm bên trong bản vá đó. Điều này
được thảo luận xa hơn trong Thỏa
thuận Giấy phép của Người đóng góp (bản
dịch tiếng Việt).
Áp dụng một bản
vá
Một khi một bản vá
đã được một người đóng góp đệ trình, thì sau đó
trách nhiệm của những người duy trì dự án để đánh
giá và, ở những nơi phù hợp, áp dụng bản vá đó. Các
dự án khác nhau có các tiếp cận về việc rà soát lại
và áp dụng các bản vá khác nhau. Tuy nhiên, chúng tất cả
có vài bước chung như sau:
- nhanh chóng đánh giá giá trị của bản vá
- chuẩn bị nhắc nhở và ý kiến phản hồi xác đáng cho người đóng góp (yêu cầu một đề xuất lại ở những nơi phù hợp)
- thử áp dụng bản vá
- chạy bất kỳ bộ kiểm thử nào đối với mã được thay đổi
- báo cáo bất kỳ vấn đề gì cho người đóng góp và yêu cầu đề xuất lại
- đệ trình bản vá cho hệ thống kiểm soát phiên bản
Các lập trình viên
có kỹ năng có thể đọc các tệp bản vá và hiểu những
tác động của chúng mà thực sự không cần áp dụng
chúng cho kho mã. Điều này làm cho dễ dàng để đưa ra ý
kiến phản hồi nhanh cho người đóng góp. Nếu người
duy trì dự án sẽ cảm thấy rằng bản vá trông giống
như một sự đóng góp cứng cáp, thì họ sẽ áp dụng nó
cho bản sao phát triển cục bộ của họ và kiểm thử
nó. Vì một đóng góp tốt sẽ luôn trải qua việc kiểm
thử mở rộng, điều này sẽ là một vấn đề đơn giản
cho người duy trì. Tuy nhiên, các sai sót có thể được
thực hiện và vì thế việc kiểm thử tiếp nên luôn
được triển khai.
Một khi một bản vá
sẵn sàng để được áp dụng cho cây kiểm soát phiên
bản, thì người duy trì sẽ 'đệ trình' (commit) nó. Đó
là, họ sẽ làm cho nó sẵn sàng trong hệ thống kiểm
soát phiên bản công khai. Hành động này thường sẽ tạo
ra một thông báo tự động cho cộng đồng các lập trình
viên thông qua một danh sách thư 'đệ trình'. Tại thời
điểm này, cộng đồng rộng lớn hơn được trao cơ hội
để rà soát lại sự đóng góp đó; nếu thay đổi đó
là trong câu trả lời cho một báo cáo lỗi hoặc một yêu
cầu tính năng, thì một phiếu (ticket) có liên quan trong
trình theo dõi vấn đề sẽ được cập nhật.
Liệu điều này có
thực sự là đơn giản?
Để mọi điều làm
việc được trơn tru như được mô tả ở trên, điều
quan trọng là những người đóng góp tạo ra các bản vá
đối với một phiên bản gần đây của các đầu ra của
dự án (thường là mã của phần mềm), ưu tiên phiên bản
gần đây nhất, từ 'đầu' của hệ thống kiểm soát
phiên bản. Điều này là vì, khi thời gian trôi đi, mã sẽ
tiến hóa. Nếu mã theo yêu cầu đã thay đổi kể từ khi
người đóng góp đã tải về bản sao của chúng, thì
việc áp dụng bản vá đó có thể không đơn giản như
được mô tả ở trên, vì có thể có những xung đột
đối với những thay đổi.
Vì những người sử
dụng thường muốn làm việc với một phiên bản mã ổn
định trong một môi trường sản xuất, có khả năng là
những thay đổi ban đầu còn chưa được thực hiện đối
với phiên bản phát triển phần mềm mới nhất. Điều
này tạo ra một sự khó xử cho người đóng góp: họ
đóng góp một bản vá đối với một phiên bản cũ của
mã, hay họ đầu tư thời gian vào việc tạo ra một bản
vá đối với phiên bản phát triển mới nhất?
Để
tối đa hóa những cơ hội của một bản vá được chấp
nhận, người đóng góp nên đệ trình bản vá đối với
phiên bản phát triển mới nhất. Vì thế người đóng
góp nên có một bản sao của sự phát triển của dự án
được triển khai và sẵn sàng để kiểm thử. Tất cả
những đóng góp trước hết nên được áp dụng cho phiên
bản phát triển này, và bất kỳ sự thay đổi nào tiếp
sau cần thiết phải đảm bảo nó làm việc được như
mong đợi sẽ được thực hiện.
Việc có một môi
trường phát triển được triển khai như thế này đã bổ
sung thêm lợi ích của việc cho phép tổ chức kiểm thử
phiên bản phát triển hiện hành trong một môi trường
không sống còn. Điều này tới lượt nó sẽ giúp cho
quyết định để nâng cấp hay không khi một phát hành
mới là sẵn sàng.
Sự
thất bại của những người đóng góp để tạo ra các
bản vá đối với phiên bản phát triển mới nhất của
dự án sẽ làm gia tăng số lượng thời gian mà một
người duy trì cần phải đầu tư vào trong việc rà soát
lại và áp dụng bản vá. Hệ quả là, những cơ hội
được chấp nhận của nó bị giảm thiểu đáng kể. sự
từ chối sẽ không ngăn cản được tổ chức của người
đóng góp khỏi việc sử dụng bản vá, nhưng nó sẽ có
nghĩa là một nâng cấp tới các phiên bản trong tương
lai sẽ được thực hiện phức tạp hơn, vì những sửa
đổi cục bộ của họ sẽ phải được áp dụng lại
cho các phiên bản mới. Hệ quả là, việc đặt nỗ lực
vào ở một giai đoạn sớm sẽ làm giảm nỗ lực để
nâng cấp và vì thế làm cho có nhiều khả năng hơn là
một bản nâng cấp sẽ chạy được trơn tru.
Thậm
chí dù được khuyến caó cho những người đóng góp để
làm việc đối với các nguồn phát triển mới nhất, các
dự án vẫn nên có thiện chí cân nhắc các bản vá đối
với các phiên bản cũ. Một bản vá đối với một phiên
bản cũ là tốt hơn so với không có bản vá nào cả.
Liệu một bản vá như vậy có được áp dụng hay không,
phụ thuộc vào cộng đồng và vào giá trị được thừa
nhận của bản vá đó. Một sự bổ sung thêm tính
năng hoặc một sửa lỗi quan trọng có khả năng sẽ được
áp dụng, trong khi một tính năng phù hợp có thể bị bỏ
qua khi mà có thể không có các lập trình viên tích cực
nào với một nhu cầu cho tính năng đó.
Phát hành sớm,
phát hành thường xuyên
Để
giảm thiểu những cơ hội của người sử dụng đệ
trình các bản vá đối với một phiên bản đã lỗi
thời, các dự án phát triển mở nên phát hành sớm và
phát hành thường xuyên. Trong các giai đoạn sớm của một
dự án, các phiên bản của dự án càng thường xuyên bao
nhiều, thì con đường nâng cấp càng dễ dàng hơn bấy
nhiêu, người sử dụng có khả năng sẽ chuyển sang một
phiên bản mới nhiều hơn. Hệ quả là, họ có khả năng
nhiều hơn cung cấp các bản vá đối với một kho mã gần
đây hơn. Việc chăm sóc những người sử dụng theo cách
này đảm bảo rằng dự án giúp cho những người sử
dụng trở thành những người đóng góp có giá trị với
nỗ lực nhỏ nhất.
Một dự án có càng
nhiều người đóng góp, thì có khả năng nhiều hơn là
nó sẽ sống sót. Đối với các dự án nguồn mở, việc
xây dựng và duy trì một cộng đồng tích cực (bản
dịch tiếng Việt) là sống còn cho sự bền vững.
Vì sao tôi nên đóng
góp một bản vá?
Một
số người hoài nghi vì sao họ nên đặt nỗ lực vào
việc cung cấp một bản vá. Họ có thể
coi nó là công việc bổ sung hơn và trên các nỗ lực
phát triển của việc tạo ra những sửa đổi trước
tiên. Tuy nhiên, thuần túy có lợi ích ích kỷ trong việc
tạo ra và đệ trình một bản vá có chất lượng: nó
làm cho dễ dàng hơn để duy trì sự sử dụng của bạn
đối với các đầu ra của dự án.
Tại
một số thời điểm trong tương lai, một tổ chức có
khả năng muốn sử dụng phiên bản mới nhất và tốt
nhất các đầu ra của dự án. Nếu nhân viên của tổ
chức đó thất bại để làm việc với cộng đồng để
có những sửa đổi cục bộ của họ được chấp nhận,
chì họ sẽ cần phải áp dụng lại tất cả các thay
đổi, hoặc đánh mất chúng. Đó là, tổ chức sẽ trả
tiền cho nhân viên của mình để thực hiện mỗi sự
thay đổi 2 lần.
Dễ dàng để bỏ qua
thực tế này. Sau tất cả, mỗi thay đổi dường như là
đáng kể và dễ dàng để áp dụng lại. tuy nhiên, mỗi
thay đổi là tích cóp dồn lại, và vì dự án từng đã
và đang có tiến bộ một cách độc lập với những thay
đổi của bạn, hoàn toàn có thể rằng ứng dụng các
sửa đổi của bạn sẽ không còn là một hoạt động
đơn giản nữa.
Việc
đệ trình một bản vá cho một dự án không đảm bảo
rằng nó sẽ được đưa vào, mà nó chắc chắn làm gia
tăng các cơ hội, đặc biệt nếu nhân viên được khuyến
khích để làm việc với những người duy trì dự án để
đảm bảo bản vá là tương thích với các mục tiêu của
dự án. Là hiếm đối với các dự án để từ chối
hoàn toàn các bản vá; bất kỳ sự từ chối nào cũng
thường đi với những khuyến cáo cho các cách thức để
làm cho nó áp dụng được đối với cộng đồng.
Cuối
cùng, hành động cung cấp các bản vá cho các dự án đảm
bảo rằng một tổ chức có một con đường nâng cấp rẻ
hơn và nó làm cho dễ dàng hơn để tạo ra các phiên bản.
Cùng lúc, chúng giúp để đảm bảo rằng phần mềm mà
họ phụ thuộc vào vẫn giữ được trong sự phát triển
tích cực. Mark Johnson đã chỉ
ra trong bài
trình bày của ông tại TransferSummit/UK
2010 cách mà nó có thể đáng làm để cung cấp các bản
vá và trở nên tích cực trong một dự án phát triển mở.
Vì thế, đây là một cách tuyệt vời để giúp xây
dựng cộng đồng (bản
dịch tiếng Việt) xung quanh dự án của
bạn.
A
patch is a record of changes made to a set of resources. Typically a
patch will add a new feature, fix a bug, or add documentation to the
project. A popular means of creating a patch is by using diff, a tool
that is commonly available on Linux and Unix systems.
Patches
are the preferred way to submit contributions to open development
projects such as open source software. The contributor creates a
patch and submits it to the project. The project maintainer can then
inspect the changes and apply them to the main code base if they so
choose. Various tools are available to help with patches. These tools
make it very easy to create and manage patches for project outputs
such as source code and documentation. Patches and patch management
tools are the key to building an active community of contributors to
an open development project.
This
document provides a simple overview of a software patch. It does not
deal with the mechanics of creating and processing patches, which are
better handled by the documentation of the patch management tool
chosen. In the further reading section, we list a few tools to help
you get started with creating patches.
When
a contributor makes a change to the outputs of a project they do so
by editing files available in a version
control system. A version control system tracks changes to
documents and source code over time. Using one makes creating a patch
simple because you can always refer to the version of the source code
the changes are based upon. However, there are a few steps that
should be taken to maximise the chances of the patch being accepted
by the maintainers of a project.
It
is important that the contributor ensures that the patch complies
with any documentation and coding standards adopted by the project.
It is also critical to thoroughly test changes against any test
suites the project provides. Finally, each contribution should be
clearly documented with, at a minimum, details on:
- what it is intended to do
- how it is implemented
- how it is used
Once
the contributor is satisfied that the patch is worthy of
consideration by the project maintainers, a patch must be created.
How
the contributor creates the patch depends on which development
environment they are using and on which version control system the
project is using. Most Integrated Development Environments (IDEs)
include a feature to generate a patch. There are also many tools you
can install, providing command line or GUI interfaces to patch
generation tools.
After
running the chosen tool, one or more files will be produced.
Collectively, these files describe the changes made in the
contribution. Often multiple files will be placed into a single
archive file for ease of management. This archive is called a patch.
It is this patch that a contributor submits to the project.
The
actual submission process varies from project to project, but in all
cases there will be a requirement to address the assignment of
copyright or rights to use the IP contained within the patch. This is
discussed further in Contributor
Licence Agreements.
Once
a patch has been submitted by a contributor, it is then the
responsibility of the project maintainers to evaluate and, where
appropriate, apply the patch. Different projects have different
approaches to reviewing and applying patches. However, they all have
some common steps:
- quickly evaluate the value of the patch
- prepare prompt and accurate feedback to the contributor (requesting a resubmission where appropriate)
- experimentally apply the patch
- run any test suites against changed code
- report any problems to the contributor and request a resubmission
- commit the patch to the version control system
Skilled
developers can read patch files and understand their implications
without actually applying them to the code base. This makes it easy
to provide rapid feedback to the contributor. Should the project
maintainer feel that the patch looks like a solid contribution, they
will apply it to their local development copy and test it. Since a
good contribution will already have undergone extensive testing, this
should be a simple matter for the maintainer. However, mistakes can
be made and so further testing should always be carried out.
Once
a patch is ready to be applied to the version control tree, the
maintainer will ‘commit’ it. That is, they will make it available
in the public version control system. This action will usually result
in an automated notification to the developer community via a
‘commit’ email list. At this point, the wider community is given
the opportunity to review the contribution; if the change is in
response to a bug report or a feature request, the associated ticket
in the issue tracker should be updated.
For
things to work as smoothly as described above, it is important that
contributors create patches against a recent version of the project
outputs (usually software code), preferably the most recent version,
from the ‘head’ of the version control system. This is because,
as time passes, code will evolve. If the code in question has changed
since the contributor downloaded their copy, applying the patch may
not be as simple as described above, since there may be conflicting
changes.
Since
users often want to work with a stable version of the code in a
production environment, it is possible that the initial changes were
not made against the latest development version of software. This
creates a dilemma for the contributor: do they contribute a patch
against an old version of the code, or do they invest the time in
creating a patch against the latest development version?
In
order to maximise the chances of a patch being accepted, the
contributor should submit the patch against the latest development
version. Therefore the contributor should have a development copy of
the project deployed and ready to test against. All contributions
should first be applied to this development version, and any further
changes necessary to ensure it works as expected should be made.
Having
a development environment deployed like this has the added benefit of
allowing the organisation to test current development versions in a
non-critical environment. This, in turn, helps with the decision to
upgrade or not when a new release is available.
Failure
of contributors to create patches against the latest development
version of a project will increase the amount of time a maintainer
needs to invest in reviewing and applying the patch. Consequently,
the chances of its being accepted are significantly reduced.
Rejection will not prevent the contributor’s organisation from
using the patch, but it will mean that an upgrade to future releases
is made more complicated, since their local modifications will have
to be reapplied to new releases. Consequently, putting the effort in
at an early stage will reduce the effort to upgrade and thus make it
more likely that an upgrade will go smoothly.
Even
though it is advisable for contributors to work against the latest
development resources, projects should still be willing to consider
patches against older versions. A patch against an old version is
better than no patch at all. Whether such a patch is applied or not
depends on the community and on the perceived value of the patch. An
important feature addition or a bug fix is likely to be applied,
whereas a niche feature may be ignored as there may be no active
developers with a need for that feature.
To
minimise the chances of users submitting patches against an outdated
release, open development projects should release early and release
often. In teh early stages of a project, the more frequent the
project releases are, and the easier the upgrade path, the more
likely users are to move to a new version. Consequently, they are
more likely to provide patches against a more recent code base.
Looking after users in this way ensures that the project enables
users to become valuable contributors with minimal effort.
The
more contributors a project has, the more likely it is to survive.
For open source projects, building
and maintaining an active community are vital for sustainability.
Some
people wonder why they should put the effort into providing a patch.
They may consider it additional work over and above the development
effort of making the modifications in the first place. However, there
is purely selfish benefit in creating and submitting a quality patch:
it makes it easier to maintain your use of the project outputs.
At
some point in the future an organisation is likely to want to use the
latest and greatest release of the project outputs. If that
organisation’s staff has failed to work with the community in order
to have their local modifications accepted, they will need to reapply
all changes, or lose them. That is, the organisation will be paying
its staff to make each change twice.
It
is easy to ignore this fact. After all, each change seems
insignificant and easy to reapply. However, each change is
cumulative, and since the project has been progressing independently
of your changes, it is quite possible that the application of your
modifications will no longer be a simple activity.
Submitting
a patch to a project does not guarantee that it will be included, but
it certainly increases the chances, especially if staff are
encouraged to work with project maintainers to ensure the patch is
compatible with the objectives of the project. It is rare for
projects to refuse patches outright; any refusal is usually
accompanied by recommendations for ways to make it acceptable to the
community.
Ultimately,
the act of providing patches to projects ensures that an organisation
has a cheaper upgrade path and it makes it easier to create releases.
At the same time, they help to ensure that the software they depend
on remains in active development. Mark Johnson showed in his
presentation
at TransferSummit/UK 2010 how rewarding it can be to provide patches
and become active in an open development project. As such, it is a
great way of helping build
community around your project.
Dịch: Lê Trung Nghĩa
Không có nhận xét nào:
Đăng nhận xét
Lưu ý: Chỉ thành viên của blog này mới được đăng nhận xét.