Hi Charles:
On Tue, Aug 18, 2009 at 3:06 AM, Charles Plessy wrote:
> Le Mon, Aug 10, 2009 at 10:58:04AM -0400, Jonathan Yu a écrit :
>> On Mon, Aug 10, 2009 at 1:13 AM, Charles Plessy wrote:
>> >
>> > we just had a case in the Debian Med packaging team where the upstream
>> > author
>> > of softw
Le Mon, Aug 10, 2009 at 10:58:04AM -0400, Jonathan Yu a écrit :
> On Mon, Aug 10, 2009 at 1:13 AM, Charles Plessy wrote:
> >
> > we just had a case in the Debian Med packaging team where the upstream
> > author
> > of software licensed under terms similar to the BSD license got upset to see
> > th
On Tue, Aug 11, 2009 at 9:56 PM, Romain Beauxis wrote:
> Le lundi 10 août 2009 09:58:04, Jonathan Yu a écrit :
>> On Mon, Aug 10, 2009 at 1:13 AM, Charles Plessy wrote:
>> > Le Tue, Jun 16, 2009 at 11:33:58AM +0800, Paul Wise a écrit :
>> >> On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessy wrote:
>>
Le lundi 10 août 2009 09:58:04, Jonathan Yu a écrit :
> On Mon, Aug 10, 2009 at 1:13 AM, Charles Plessy wrote:
> > Le Tue, Jun 16, 2009 at 11:33:58AM +0800, Paul Wise a écrit :
> >> On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessy wrote:
> >> > The dh_make template for debian/copyright induces many
On Mon, Aug 10, 2009 at 1:13 AM, Charles Plessy wrote:
> Le Tue, Jun 16, 2009 at 11:33:58AM +0800, Paul Wise a écrit :
>> On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessy wrote:
>>
>> > The dh_make template for debian/copyright induces many developers to put
>> > their
>> > packaging work under the
Le Tue, Jun 16, 2009 at 11:33:58AM +0800, Paul Wise a écrit :
> On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessy wrote:
>
> > The dh_make template for debian/copyright induces many developers to put
> > their
> > packaging work under the GPL, and I have already seen packages whose
> > license is
also sprach Guido Günther [2009.07.22.1523 +0200]:
> Sure. I think I do understand what James is talking about. It's
> basically a matter of taste if you rebase patch branches or use
> topgit - both have their up and downsides.
With reference to
http://lists.alioth.debian.org/pipermail/vcs-pkg-di
On Fri, Jul 17, 2009 at 06:48:22AM -0400, David Bremner wrote:
[..snip..]
> At least with topgit, patch branches are meant to be pushed and
> pulled, and use merge rather than rebase for just this reason. This
> makes the history ugly, but does facilitate the kind of collaboration
> James alluded
At Fri, 17 Jul 2009 09:00:50 +0200,
Guido Günther wrote:
> On Wed, Jul 08, 2009 at 07:24:20PM +0100, James Westby wrote:
> > Guido Günther wrote:
> > > Which isn't a problem on patch-queue branches since you either can
> > > recreate them anytime from what's in debian/patches or simply ammend the
On Wed, Jul 08, 2009 at 07:24:20PM +0100, James Westby wrote:
> Guido Günther wrote:
> > Which isn't a problem on patch-queue branches since you either can
> > recreate them anytime from what's in debian/patches or simply ammend the
> > commit. They're supposed to be rebased frequently anyway.
>
>
hi raphael,
On Wed, Jul 15, 2009 at 11:16:01PM +0200, Raphael Hertzog wrote:
> How do you expect to recognize the real starting point for the fields?
> The freetext might contain text that look like field names at the start
> of a line... I don't think that requesting fields to be first in the p
On Sat, 04 Jul 2009, sean finney wrote:
> > I believe it's important to be able to know where the patch came from.
>
> I do think that knowing where the patch came from is very important,
> and one of the main driving rationales behind this proposal.
>
> but more than a URL or a revision/commit i
Guido Günther wrote:
> Which isn't a problem on patch-queue branches since you either can
> recreate them anytime from what's in debian/patches or simply ammend the
> commit. They're supposed to be rebased frequently anyway.
"Supposed"?
That's not true in my opinion. It would tend to be hostile t
On Tue, Jul 07, 2009 at 12:56:26AM +0100, James Westby wrote:
> Guido Günther wrote:
> >> I am concerned that just allowing to use git-format-patch will result in
> >> people not making an effort to markup other metadata in DEP#3 format,
> >> like bug numbers or reviewers and leave those as free-fo
Guido Günther wrote:
>> I am concerned that just allowing to use git-format-patch will result in
>> people not making an effort to markup other metadata in DEP#3 format,
>> like bug numbers or reviewers and leave those as free-form in the body.
> We can have Forwarded:, Origin:, Received-by: in thi
On Sun, Jul 05, 2009 at 02:54:33PM +0200, Michael Banck wrote:
> On Sun, Jul 05, 2009 at 02:32:57PM +0200, Guido Günther wrote:
> > We can of course convert from and to a DEP#3 compatible format but why
> > not use something the rest of world uses for exchanging patches?
>
> It is not what the res
On Sun, Jul 05, 2009 at 02:32:57PM +0200, Guido Günther wrote:
> We can of course convert from and to a DEP#3 compatible format but why
> not use something the rest of world uses for exchanging patches?
It is not what the rest of the world uses; it is just what git uses.
I am concerned that just
On Sun, Jul 05, 2009 at 01:27:16PM +0200, Michael Banck wrote:
> On Thu, Jun 18, 2009 at 02:38:47PM +0200, Guido Günther wrote:
> > So 'Description' (Subject), 'Bug' (Closes), Signed-Of-By, Origin
> > (Author) are already there, some of them already being used by other
> > tools (git-dch). Wouldn't
On Thu, Jun 18, 2009 at 02:38:47PM +0200, Guido Günther wrote:
> So 'Description' (Subject), 'Bug' (Closes), Signed-Of-By, Origin
> (Author) are already there, some of them already being used by other
> tools (git-dch). Wouldn't it make sense to choose (or at least allow
> for) a format that's comp
On Sat, Jul 4, 2009 at 10:05 PM, Salvatore
Bonaccorso wrote:
> Having only the bugnumber should work too, but the URL is then:
> https://sourceforge.net/support/tracker.php?aid=1215086
That can be further shortened to this:
http://sf.net/support/tracker.php?aid=1215086
--
bye,
pabs
http://wik
Hi Charles
On Sat, Jul 04, 2009 at 10:55:13PM +0900, Charles Plessy wrote:
> Le Sat, Jul 04, 2009 at 02:58:28AM +0200, gregor herrmann a écrit :
> >
> > Maybe I'm too lazy but I'd rather use
> > Bug: #123456
> > Bug_CPAN: #12345
>
> Note that for Sourceforge, it seems that more than one
Hi all,
I take the opportunity of this discussion to make a few other questions and
comments…
Le Sat, Jul 04, 2009 at 12:35:16AM +0200, sean finney a écrit :
>
> Origin: Some User
>
> okay, maybe that should be Author, but then why have an additional and
> duplicate field "Origin: other, subm
here's a nice big group-reply with an assortment of comments :)
overall i think this looks pretty good, though i do have some concerns
that will kind of repeat themselves below about there being too much
emphasis on something machine friendly instead of human friendly...
On Sun, Jun 21, 2009 at 1
On Sun, 21 Jun 2009, Raphael Geissert wrote:
> > Description (required)
> Why not simply consider all the free-form text the description? that would
> make all the current patches with a comment insta DEP3-compliant.
Done, but that's a recommendatino for the parser. Note that it's not
DEP3-complia
Raphael Hertzog wrote:
> On Sat, 20 Jun 2009, Raphael Geissert wrote:
>> All I see here is that the tools should be able to extract the
>> information from the changelog, which often includes a bug number and
>> other bits of information.
>
> I would say the opposite. Once you have created your p
On Sat, 20 Jun 2009, Raphael Geissert wrote:
> All I see here is that the tools should be able to extract the information
> from the changelog, which often includes a bug number and other bits of
> information.
I would say the opposite. Once you have created your patch you should be
able to do ˝dc
On Sat, Jun 20, 2009 at 12:44:12PM -0500, Raphael Geissert wrote:
> Raphael Hertzog wrote:
> * debian/patches/fix_typo.patch:
> Fix typo in the main menu: s/setings/settings
> I would actually be duplicating the description (the patch name being the
> short description, and the changelog entry
Raphael Hertzog wrote:
>
> Have you tried to write the field for your cases? The spec is relatively
> light-weight even if it tries to support the more complicated case too.
Yes, and the examples I mentioned are/were real cases.
>
> Description: Fix typo
> Origin: vendor
> Forwarded: yes
The t
On Fri, 19 Jun 2009, Raphael Geissert wrote:
> I mean, often the patch name already says enough about it, at times patches
> are just trivial (a typo fix doesn't need four or five lines to be
> described), at times they are forwarded as soon as the new package is
> uploaded, at times they are $VCS
On Sat, 20 Jun 2009, Ben Finney wrote:
> Raphael Hertzog writes:
>
> > Merging all those ideas, I suggest we drop Status/Commit/Patch and use
> > the following format:
> >
> > Origin: :
>
> I'd still suggest having the extra information optional in the case of
> anything but “other”:
>
>
Joerg Jaspert wrote:
> On 11782 March 1977, Raphael Hertzog wrote:
>
>> This is a proposal to formalize a set of meta-information
>> to be embedded in patches applied to Debian packages. Most
>> patch systems allow for a free-from description preceeding
>> the content of the patch and the plan is
Raphael Hertzog writes:
> Merging all those ideas, I suggest we drop Status/Commit/Patch and use
> the following format:
>
> Origin: :
I'd still suggest having the extra information optional in the case of
anything but “other”:
"Origin: upstream" [ ": " ]
"Origin: backport" [ ": "
Raphael Hertzog wrote:
On Fri, 19 Jun 2009, Giacomo A. Catenazzi wrote:
In this case I think we should use DEP-3 without discussion every details:
we need a larger user base, then we will discuss details for standardization,
but not now.
I prefer we take the time to think it thoroughly so tha
On Fri, 19 Jun 2009, Sune Vuorela wrote:
> On 2009-06-19, Raphael Hertzog wrote:
> > +Scope and application
> > +-
> > +
> > +The usage of this format is highly recommended but as long as it's not
> > +endorsed by the Debian policy, it will not be required. It is however
>
> "
Josselin Mouette wrote:
Le vendredi 19 juin 2009 à 13:01 +0200, Giacomo Catenazzi a écrit :
What is the point of introducing this spec if it is not made mandatory
at some point in the future?
so, IMHO we need a complete guidelines and start to use
it widely. It should not be complete or 100% pr
Le vendredi 19 juin 2009 à 13:01 +0200, Giacomo Catenazzi a écrit :
> > What is the point of introducing this spec if it is not made mandatory
> > at some point in the future?
>
> so, IMHO we need a complete guidelines and start to use
> it widely. It should not be complete or 100% precise
> (so n
Josselin Mouette wrote:
> Le vendredi 19 juin 2009 à 10:05 +, Sune Vuorela a écrit :
>>> +The usage of this format is highly recommended but as long as it's not
>>> +endorsed by the Debian policy, it will not be required. It is however
>> "And there is no plan to make it required in the future"
Le Wed, Jun 17, 2009 at 12:40:01PM +0200, Raphael Hertzog a écrit :
> On Tue, 16 Jun 2009, Charles Plessy wrote:
> > The dh_make template for debian/copyright induces many developers to put
> > their
> > packaging work under the GPL, and I have already seen packages whose
> > license is
> > other
Le vendredi 19 juin 2009 à 10:05 +, Sune Vuorela a écrit :
> > +The usage of this format is highly recommended but as long as it's not
> > +endorsed by the Debian policy, it will not be required. It is however
>
> "And there is no plan to make it required in the future"
What is the point of i
Le vendredi 19 juin 2009 à 10:55 +0200, Raphael Hertzog a écrit :
> > It’s already better, but for more readability, would it be possible to
> > have a registered list of bug tracking aliases? For example:
> > Bug-Debian: #12345
> > Bug-Ubuntu: #2356
> > Bug-GNOME: #5671
>
On Wed, 17 Jun 2009 12:40:01 +0200
Raphael Hertzog wrote:
> > For the avoidance of confusion I would suggest that this be changed to
> > Reviewed-by - the normal Linux/git Signed-off-by has a specific meaning
> > that needn't include actually doing a code review.
>
> I started first with "Review
On 19/06/09 at 11:14 +0200, Josselin Mouette wrote:
> Le vendredi 19 juin 2009 à 11:03 +0200, Lucas Nussbaum a écrit :
> > > I did not contact them yet. I expect that they will follow the outcome of
> > > this DEP otherwise they would have to patch lintian to support the
> > > differing field and i
On 2009-06-19, Raphael Hertzog wrote:
> +Scope and application
> +-
> +
> +The usage of this format is highly recommended but as long as it's not
> +endorsed by the Debian policy, it will not be required. It is however
"And there is no plan to make it required in the future"
On Fri, 19 Jun 2009, Josselin Mouette wrote:
> > It should be possible. I see one problem here though. Bug-Gnome is really
> > "Bug" because it's the upstream bug. While we can have an URL mapping for
> > each vendor, it's not possible for the non-qualified entry used for the
> > upstream case.
>
Hi Raphaël,
On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote:
> Hello,
>
> please find below a first draft of DEP-3 that I called Patch Tagging
> Guidelines. The idea is to standardize a set of meta-information to embed
> in patches that we apply. Please review, share your comments
On Wed, Jun 17, 2009 at 12:40:01PM +0200, Raphael Hertzog wrote:
> On Mon, 15 Jun 2009, Mark Brown wrote:
> > On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote:
> > > * `Signed-off-by` (optional)
> > For the avoidance of confusion I would suggest that this be changed to
> > Review
Le vendredi 19 juin 2009 à 10:55 +0200, Raphael Hertzog a écrit :
> > It’s already better, but for more readability, would it be possible to
> > have a registered list of bug tracking aliases? For example:
> > Bug-Debian: #12345
> > Bug-Ubuntu: #2356
> > Bug-GNOME: #5671
>
Le vendredi 19 juin 2009 à 11:03 +0200, Lucas Nussbaum a écrit :
> > I did not contact them yet. I expect that they will follow the outcome of
> > this DEP otherwise they would have to patch lintian to support the
> > differing field and it seems counter-productive.
>
> That sounds like a pretty b
On 19/06/09 at 10:49 +0200, Raphael Hertzog wrote:
> > My concern is that Ubuntu already has a policy like this
> > (https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines). I
> > would really like ours to be compatible with theirs, so patches can
> > freely be copied between Ubuntu and D
On Fri, 19 Jun 2009, Josselin Mouette wrote:
> Le mercredi 17 juin 2009 à 12:40 +0200, Raphael Hertzog a écrit :
> >* `Bug-` or `Bug` (optional)
> >
> > -It contains one or more URLs (space separated) pointing to the related
> > bugs
> > -(possibly fixed by the patch). The `Bug` fiel
2009/6/19 Josselin Mouette :
> It’s already better, but for more readability, would it be possible to
> have a registered list of bug tracking aliases? For example:
> Bug-Debian: #12345
> Bug-Ubuntu: #2356
> Bug-GNOME: #5671
Personally I'd prefer URLs (for all bugs, including
On Fri, 19 Jun 2009, Lucas Nussbaum wrote:
> > distribution, so I don't mind if not all packages are converted, after
> > it's up to you to see if new lintian warnings annoy you enough or not to
> > live with it. :)
>
> See my comment above about this. It should be added to the introduction
> of t
Le mercredi 17 juin 2009 à 12:40 +0200, Raphael Hertzog a écrit :
>* `Bug-` or `Bug` (optional)
>
> -It contains one or more URLs (space separated) pointing to the related
> bugs
> -(possibly fixed by the patch). The `Bug` field is reserved
> -for the bug URL(s) in the upstream b
On 17/06/09 at 12:40 +0200, Raphael Hertzog wrote:
> Hello everybody,
>
> I'll try to do some new proposals based on your feedback. But first let
> me address the topic of the usefulness of the proposal. While there are
> currently no tools making use of this format, I can imagine many
> interesti
Raphael Hertzog wrote:
> Hello everybody,
>
> I'll try to do some new proposals based on your feedback. But first let
> me address the topic of the usefulness of the proposal. While there are
> currently no tools making use of this format, [...]
> In any case, it's a required step IMO if we want
Hello everybody,
I'll try to do some new proposals based on your feedback. But first let
me address the topic of the usefulness of the proposal. While there are
currently no tools making use of this format, I can imagine many
interesting usage for this information. It starts with the simple stats
On 17/06/09 at 09:04 +0200, Raphael Hertzog wrote:
> On Mon, 15 Jun 2009, Lucas Nussbaum wrote:
> > > * `Bug-` or `Bug` (optional)
> > >
> > > It contains one or more URLs (space separated) pointing to the
> > > related bugs
> > > (possibly fixed by the patch). The `Bug` field is reserv
On Tue, 16 Jun 2009, Felipe Sateler wrote:
> If the idea is to standarize metainformation, I would suggest standarizing
> filenaming scheme too. What I do in some packages is to name the patches as
> follows:
>
> 0xxx-name.patch -> Grabbed from upstream VCS
> 1xxx-name.patch -> Interesting for
On Mon, 15 Jun 2009, Lucas Nussbaum wrote:
> > * `Bug-` or `Bug` (optional)
> >
> > It contains one or more URLs (space separated) pointing to the related
> > bugs
> > (possibly fixed by the patch). The `Bug` field is reserved
> > for the bug URL(s) in the upstream bug tracker.
>
>
Raphael Hertzog writes:
> * `Origin` (required)
>
> This field should document the origin of the patch. It can have the
> following standard values: "upstream" (in the case of a patch
> cherry-picked
> from the upstream VCS), "backport" (in the case of an upstream patch
> that
On Tue, Jun 16, 2009 at 05:44:55PM +0200, Lucas Nussbaum wrote:
> > * `Debian-Specific` (optional)
> >
> >Is this patch a debian-specific patch that is not intended to be
> >shared with upstream? For example, changes to specify Debian-specific
> >application paths, configuration file
On 16/06/09 at 17:18 +0200, sean finney wrote:
> On Mon, Jun 15, 2009 at 06:27:45PM +0200, Lucas Nussbaum wrote:
> > > (possibly fixed by the patch). The `Bug` field is reserved
> > > for the bug URL(s) in the upstream bug tracker.
> >
> > What about using Debian: (like Ubuntu's Patch Tagg
hi,
(yay for group reply)
On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote:
> * `Description` (required)
>
> This obligatory field contains at least a short description on the
> first line. Supplementary lines can be used to provide a longer
> explanation of the patc
Carsten Hey wrote:
> On Tue, Jun 16, 2009 at 10:05:40AM +0100, Mark Brown wrote:
>> On Mon, Jun 15, 2009 at 11:31:51PM +0200, Carsten Hey wrote:
>> > If an integration of the information in the patch headers into UDD
>> > would be planned which could be used to query patches not applied
>> > upstr
"Thijs Kinkhorst" writes:
>> Possible benefits (partly mentioned in the spec)
>>
>> - tools can be adapted/crafted to maintain these fields
>> - streamline development practice to faciliate team communication
>> - (web)tools can analyse and produce statistics..
>
> This is still quite abstract: "
On Tue, June 16, 2009 11:23, Reinhard Tartler wrote:
> "Thijs Kinkhorst" writes:
>
>
>> Hi Raphaël,
>>
>>
>> On Mon, June 15, 2009 18:12, Raphael Hertzog wrote:
>>
>>> please find below a first draft of DEP-3 that I called Patch Tagging
>>> Guidelines. The idea is to standardize a set of meta-inf
On Tue, Jun 16, 2009 at 11:23:17AM +0200, Reinhard Tartler wrote:
> "Thijs Kinkhorst" writes:
> > above the patch? That works fine for me. Every formalisation has a cost
> > and I'm not sure here that it's offset by the (which?) benefits.
> Possible benefits (partly mentioned in the spec)
> -
"Thijs Kinkhorst" writes:
> Hi Raphaël,
>
> On Mon, June 15, 2009 18:12, Raphael Hertzog wrote:
>> please find below a first draft of DEP-3 that I called Patch Tagging
>> Guidelines. The idea is to standardize a set of meta-information to embed
>> in patches that we apply. Please review, share y
On Tue, Jun 16, 2009 at 10:05:40AM +0100, Mark Brown wrote:
> On Mon, Jun 15, 2009 at 11:31:51PM +0200, Carsten Hey wrote:
> > If an integration of the information in the patch headers into UDD would
> > be planned which could be used to query patches not applied upstream or
> > similar, I would at
On Mon, Jun 15, 2009 at 11:31:51PM +0200, Carsten Hey wrote:
> On Mon, Jun 15, 2009 at 10:15:16PM +0100, Mark Brown wrote:
> > On Mon, Jun 15, 2009 at 11:10:14PM +0200, Carsten Hey wrote:
> > > I currently don't see a relevant benefit in this above just using the
> > > changelog entry, which you n
Hi Raphaël,
On Mon, June 15, 2009 18:12, Raphael Hertzog wrote:
> please find below a first draft of DEP-3 that I called Patch Tagging
> Guidelines. The idea is to standardize a set of meta-information to embed
> in patches that we apply. Please review, share your comments and ideas
> of enhancem
On 2009-06-16, Paul Wise wrote:
> On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessy wrote:
>
>> The dh_make template for debian/copyright induces many developers to put
>> their
>> packaging work under the GPL, and I have already seen packages whose license
>> is
>> otherwise BSD-ish with such pat
On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessy wrote:
> The dh_make template for debian/copyright induces many developers to put their
> packaging work under the GPL, and I have already seen packages whose license
> is
> otherwise BSD-ish with such patches. If the maintainer suddenly goes MIA an
Raphael Hertzog wrote:
> Hello,
>
> please find below a first draft of DEP-3 that I called Patch Tagging
> Guidelines. The idea is to standardize a set of meta-information to embed
> in patches that we apply. Please review, share your comments and ideas of
> enhancements.
If the idea is to stand
Le Mon, Jun 15, i2009 at 06:12:49PM +0200, Raphael Hertzog a écrit :
>Title: Patch Tagging Guidelines
>DEP: 3
>State: DRAFT
>Date: 2009-06-12
>Drivers: Raphael Hertzog
>URL: http://dep.debian.net/deps/dep3
>Abstract:
> Meta-information embedded in patches applied to
On Mon, Jun 15, 2009 at 10:15:16PM +0100, Mark Brown wrote:
> On Mon, Jun 15, 2009 at 11:10:14PM +0200, Carsten Hey wrote:
>
> > I currently don't see a relevant benefit in this above just using the
> > changelog entry, which you need to write anyway. Additional information
>
> Putting the informa
On 2009-06-15, Raphael Hertzog wrote:
> Hello,
>
> please find below a first draft of DEP-3 that I called Patch Tagging
> Guidelines. The idea is to standardize a set of meta-information to embed
Wouldn't a better first goal be to have just a freeform text field ?
With the current amount of comme
On Mon, Jun 15, 2009 at 11:10:14PM +0200, Carsten Hey wrote:
> I currently don't see a relevant benefit in this above just using the
> changelog entry, which you need to write anyway. Additional information
Putting the information in the changelog makes it much harder to find
when looking at a p
On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote:
> please find below a first draft of DEP-3 that I called Patch Tagging
> Guidelines. The idea is to standardize a set of meta-information to embed
> in patches that we apply. Please review, share your comments and ideas of
> enhanceme
On Mon, 2009-06-15 at 21:37 +0200, Joerg Jaspert wrote:
> On 11782 March 1977, Raphael Hertzog wrote:
>
> > This is a proposal to formalize a set of meta-information
> > to be embedded in patches applied to Debian packages. Most
> > patch systems allow for a free-from description preceeding
> > th
On 11782 March 1977, Raphael Hertzog wrote:
> This is a proposal to formalize a set of meta-information
> to be embedded in patches applied to Debian packages. Most
> patch systems allow for a free-from description preceeding
> the content of the patch and the plan is to make use of that
> space t
Le lundi 15 juin 2009 à 18:12 +0200, Raphael Hertzog a écrit :
> * `Patch` (optional)
>
> URL pointing to the patch. It can be in a VCS web interface,
> a BTS attachment, etc. If the patch is available in the upstream VCS
> or BTS, those URLs take precedence.
Maintaining this inform
On 15/06/09 at 18:12 +0200, Raphael Hertzog wrote:
> Hello,
>
> please find below a first draft of DEP-3 that I called Patch Tagging
> Guidelines. The idea is to standardize a set of meta-information to embed
> in patches that we apply. Please review, share your comments and ideas of
> enhancement
On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote:
> * `Signed-off-by` (optional)
>
> This field can be used to document the fact that the patch has been
> reviewed by one or more persons. It should list their names and
> emails in the standard format (similar to the e
Hello,
please find below a first draft of DEP-3 that I called Patch Tagging
Guidelines. The idea is to standardize a set of meta-information to embed
in patches that we apply. Please review, share your comments and ideas of
enhancements.
If (and once) we have consensus that it is good idea to sta
85 matches
Mail list logo
