This is an automated email from the git hooks/post-receive script.
dod pushed a commit to branch master
in repository libconfig-model-dpkg-perl.
commit 1759f16cc5a4f9e0dd4aa9c782f24554addd7452
Author: Dominique Dumont <d...@debian.org>
Date: Sun Jun 15 18:50:36 2014 +0200
Dpkg::Path: added missing inline documentation
---
lib/Config/Model/models/Dpkg/Patch.pl | 33 ++++++++++++++++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/lib/Config/Model/models/Dpkg/Patch.pl
b/lib/Config/Model/models/Dpkg/Patch.pl
index 07c0b95..689a384 100644
--- a/lib/Config/Model/models/Dpkg/Patch.pl
+++ b/lib/Config/Model/models/Dpkg/Patch.pl
@@ -14,6 +14,8 @@
'element' => [
'Synopsis',
{
+ 'description' => 'This line is stored in the first line of DEP-3
description
+field',
'summary' => 'short description of the patch',
'type' => 'leaf',
'value_type' => 'uniline',
@@ -49,10 +51,21 @@ s/-/ /g;
'type' => 'leaf',
'value_type' => 'uniline'
},
+ 'description' => 'This field contains one URL pointing to the related
bug (possibly fixed by the patch). The Bug field is reserved for the bug URL in
the upstream bug tracker. Those fields can be used multiple times if several
bugs are concerned.
+
+The vendor name is explicitely encoded in the field name so that vendors can
share patches among them without having to update the meta-information in most
cases. The upstream bug URL is special cased because it\'s the central point of
cooperation and it must be easily distinguishable among all the bug URLs.
+
+To get a vendor bug (like Bug-Foo) in the graphical editor, right-click on the
patch name, enter "C<Bug-Foo>" (or any other value) in the "C<accept:>" entry
and hit "Return". A new element will be created that
+you can fill like the C<Bug> field.',
'type' => 'list'
},
'Forwarded',
{
+ 'description' => 'Any value other than "no" or "not-needed" means that
the patch has been forwarded upstream. Ideally the value is an URL proving that
it has been forwarded and where one can find more information about its
inclusion status.
+
+If the field is missing, its implicit value is "yes" if the "Bug" field is
present, otherwise it\'s "no". The field is really required only if the patch
is vendor specific, in that case its value should be "not-needed" to indicate
that the patch must not be forwarded upstream (whereas "no" simply means that
it has not yet been done).
+
+',
'type' => 'leaf',
'value_type' => 'uniline'
},
@@ -60,9 +73,17 @@ s/-/ /g;
{
'type' => 'leaf',
'value_type' => 'uniline'
+ 'description' => 'This field can be used to record the name and email
of the patch author (ex: "John Bear <f...@example.com>"). Its usage is
recommended when the patch author did not add copyright notices for his work in
the patch itself. It\'s also a good idea to add this contact information when
the patch needs to be maintained over time because it has very little chance of
being integrated upstream. This field can be used multiple times if several
people authored the patch.',
},
'Origin',
{
+ 'description' => 'This field should document the origin of the patch.
In most cases, it should be a simple URL. For patches backported/taken from
upstream, it should point into the upstream VCS web interface when possible,
otherwise it can simply list the relevant commit identifier (it should be
prefixed with "commit:" in that case). For other cases, one should simply
indicate the URL where the patch was taken from (mailing list archives,
distribution bugtrackers, etc.) when possible.
+
+The field can be optionaly prefixed with a single keyword followed by a comma
and a space to categorize the origin. The allowed keywords are "upstream" (in
the case of a patch cherry-picked from the upstream VCS), "backport" (in the
case of an upstream patch that had to be modified to apply on the current
version), "vendor" for a patch created by Debian or another distribution
vendor, or "other" for all other kind of patches.
+
+In general, a user-created patch grabbed in a BTS should be categorized as
"other". When copying a patch from another vendor, the meta-information (and
hence this field) should be kept if present, or created if necessary with a
"vendor" origin.
+
+If the Author field is present, the Origin field can be omitted and it\'s
assumed that the patch comes from its author.',
'type' => 'leaf',
'value_type' => 'string'
},
@@ -70,30 +91,40 @@ s/-/ /g;
{
'type' => 'leaf',
'value_type' => 'uniline'
+ 'description' => 'Like Author field, this field can be used to record
the name and email of the patch author (ex: "John Bear <f...@example.com>").
Its usage is recommended when the patch author did not add copyright notices
for his work in the patch itself. It\'s also a good idea to add this contact
information when the patch needs to be maintained over time because it has very
little chance of being integrated upstream. This field can be used multiple
times if several people auth [...]
},
'Reviewed-by',
{
'type' => 'leaf',
'value_type' => 'uniline'
+ 'description' => 'This field can be used to document the fact that the
patch has been reviewed and approved by someone. It should list her name and
email in the standard format (similar to the example given for the Author
field). This field can be used multiple times if several people reviewed the
patch.
+
+',
},
'Acked-by',
{
'type' => 'leaf',
'value_type' => 'uniline'
+ 'description' => 'Synonym to Reviewd-by. This field can be used to
document the fact that the patch has been reviewed and approved by someone. It
should list her name and email in the standard format (similar to the example
given for the Author field). This field can be used multiple times if several
people reviewed the patch.
+
+',
},
'Last-Update',
{
+ 'description' => 'This field can be used to record the date when the
meta-information was last updated. It should use the ISO date format
YYYY-MM-DD.',
'type' => 'leaf',
'value_type' => 'uniline'
},
'Applied-Upstream',
{
+ 'description' => 'This field can be used to document the fact that the
patch has been applied upstream. It may contain the upstream version expected
to contain this patch, or the URL or commit identifier of the upstream commit
(with commit identifiers prefixed with "commit:", as in the Origin field), or
both separated by a comma and a space.',
'type' => 'leaf',
'value_type' => 'uniline'
},
'diff',
{
- 'description' => 'This element contains the diff that will be used to
patch the source. Do not modify.',
+ 'description' => 'This element contains the diff that will be used to
patch the source. Do not modify unless you really know
+what you\'re doing.',
'summary' => 'actual patch',
'type' => 'leaf',
'value_type' => 'string'
--
Alioth's /usr/local/bin/git-commit-notice on
/srv/git.debian.org/git/pkg-perl/packages/libconfig-model-dpkg-perl.git
_______________________________________________
Pkg-perl-cvs-commits mailing list
Pkg-perl-cvs-commits@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-perl-cvs-commits
