2011-06-14 21:15:08

by Vinicius Costa Gomes

[permalink] [raw]
Subject: Per-project patch prefixes

Hi,

Now, this list receives patches for at least 3 different projects, so how
about using different subject prefixes for each priject? The first thing
that comes to mind is this:


1. kernel:
- bluetooth-next -> for patches against Gustavo's bluetooth-next
- bluetooth-current -> for patches against Gustavo's bluetooth-2.6

2. BlueZ:
- bluez

3. obexd:
- obexd

This is just an idea, what do you think?


Cheers,
--
Vinicius


2011-06-15 18:13:44

by Gustavo Padovan

[permalink] [raw]
Subject: Re: Per-project patch prefixes

* Johan Hedberg <[email protected]> [2011-06-15 15:04:43 +0300]:

> Hi,
>
> On Wed, Jun 15, 2011, Marcel Holtmann wrote:
> > > > Now, this list receives patches for at least 3 different projects, so how
> > > > about using different subject prefixes for each priject? The first thing
> > > > that comes to mind is this:
> > >
> > > This is a great idea. It can a lot when identifying patches, and you can do
> > > this to the project's .git/config:
> > >
> > > [format]
> > > subjectprefix = "bluetooth-next"
> >
> > as long as patches come in as [PATCH bluetooth-next v2] or something
> > similar I am fine with this. I want the [PATCH ...] prefix kept alive
> > since that is one thing that git did right from the beginning.
>
> The mandatory part then becomes "[PATCH bluetooth-next] Bluetooth: ".
> That doesn't leave much to the really valuable part, especially if
> you're on a 80-column wide terminal. Add Subject: to the beginning and
> you've got even less. Kernel patches already have the Bluetooth: prefix
> in the subject so they are pretty easy to spot IMHO. For obexd OTOH I'd
> be fine with a [PATCH obexd] convention.

So no modifications for the kernel patches. "Bluetooth:" prefix is enough to
me as well.

Gustavo

2011-06-15 12:05:18

by Luiz Augusto von Dentz

[permalink] [raw]
Subject: Re: Per-project patch prefixes

Hi Marcel,

On Wed, Jun 15, 2011 at 2:10 PM, Marcel Holtmann <[email protected]> wrot=
e:
> Hi Gustavo,
>
>> > Now, this list receives patches for at least 3 different projects, so =
how
>> > about using different subject prefixes for each priject? The first thi=
ng
>> > that comes to mind is this:
>>
>> This is a great idea. It can a lot when identifying patches, and you can=
do
>> this to the project's .git/config:
>>
>> [format]
>> =A0 =A0 =A0 =A0 subjectprefix =3D "bluetooth-next"
>
> as long as patches come in as [PATCH bluetooth-next v2] or something
> similar I am fine with this. I want the [PATCH ...] prefix kept alive
> since that is one thing that git did right from the beginning.

So an obexd patch would look like this:

[PATCH obexd 1/4] Add initial support for OBEX Action command

--=20
Luiz Augusto von Dentz
Computer Engineer

2011-06-15 12:04:43

by Johan Hedberg

[permalink] [raw]
Subject: Re: Per-project patch prefixes

Hi,

On Wed, Jun 15, 2011, Marcel Holtmann wrote:
> > > Now, this list receives patches for at least 3 different projects, so how
> > > about using different subject prefixes for each priject? The first thing
> > > that comes to mind is this:
> >
> > This is a great idea. It can a lot when identifying patches, and you can do
> > this to the project's .git/config:
> >
> > [format]
> > subjectprefix = "bluetooth-next"
>
> as long as patches come in as [PATCH bluetooth-next v2] or something
> similar I am fine with this. I want the [PATCH ...] prefix kept alive
> since that is one thing that git did right from the beginning.

The mandatory part then becomes "[PATCH bluetooth-next] Bluetooth: ".
That doesn't leave much to the really valuable part, especially if
you're on a 80-column wide terminal. Add Subject: to the beginning and
you've got even less. Kernel patches already have the Bluetooth: prefix
in the subject so they are pretty easy to spot IMHO. For obexd OTOH I'd
be fine with a [PATCH obexd] convention.

Johan

2011-06-15 11:10:28

by Marcel Holtmann

[permalink] [raw]
Subject: Re: Per-project patch prefixes

Hi Gustavo,

> > Now, this list receives patches for at least 3 different projects, so how
> > about using different subject prefixes for each priject? The first thing
> > that comes to mind is this:
>
> This is a great idea. It can a lot when identifying patches, and you can do
> this to the project's .git/config:
>
> [format]
> subjectprefix = "bluetooth-next"

as long as patches come in as [PATCH bluetooth-next v2] or something
similar I am fine with this. I want the [PATCH ...] prefix kept alive
since that is one thing that git did right from the beginning.

Regards

Marcel



2011-06-14 23:48:29

by Bastien Nocera

[permalink] [raw]
Subject: Re: Per-project patch prefixes

On Tue, 2011-06-14 at 18:15 -0300, Vinicius Costa Gomes wrote:
> Hi,
>
> Now, this list receives patches for at least 3 different projects, so how
> about using different subject prefixes for each priject? The first thing
> that comes to mind is this:
>
>
> 1. kernel:
> - bluetooth-next -> for patches against Gustavo's bluetooth-next
> - bluetooth-current -> for patches against Gustavo's bluetooth-2.6
>
> 2. BlueZ:
> - bluez
>
> 3. obexd:
> - obexd
>
> This is just an idea, what do you think?

Or we could stop playing with mailing-lists and use bugzillas for the
non-kernel bits...


2011-06-14 21:31:43

by Gustavo Padovan

[permalink] [raw]
Subject: Re: Per-project patch prefixes

* Vinicius Costa Gomes <[email protected]> [2011-06-14 18:15:08 -0300]:

> Hi,
>
> Now, this list receives patches for at least 3 different projects, so how
> about using different subject prefixes for each priject? The first thing
> that comes to mind is this:

This is a great idea. It can a lot when identifying patches, and you can do
this to the project's .git/config:

[format]
subjectprefix = "bluetooth-next"


You may also want this(if you never configured it :

[sendemail]
to = [email protected]

>
> 1. kernel:
> - bluetooth-next -> for patches against Gustavo's bluetooth-next
> - bluetooth-current -> for patches against Gustavo's bluetooth-2.6
>
> 2. BlueZ:
> - bluez
>
> 3. obexd:
> - obexd

There is hcidump missing here.

Gustavo