From: David Miller <davem@davemloft.net>
To: mcarlson@broadcom.com
Cc: sfr@canb.auug.org.au, linux-next@vger.kernel.org, mchan@broadcom.com
Subject: Re: linux-next: net/net-current merge conflict
Date: Tue, 10 Jun 2008 12:44:47 -0700 (PDT) [thread overview]
Message-ID: <20080610.124447.94353426.davem@davemloft.net> (raw)
In-Reply-To: <20080610193826.GD5841@localdomain>
From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Tue, 10 Jun 2008 12:38:26 -0700
> The correct thing to do would be to increment the net-next version every
> time these conflicts appear. Right now and to the best of my knowledge,
> this policy would only apply to the tg3 driver. Do you feel this is an
> acceptable / sustainable way to deal with versioning between net and
> net-next?
I think there is no confusion, to be honest, consider:
1) The stable bug fix driver keeps incrementing the "N" in
x.y.N, so no problems.
2) The development driver keeps incrementing the "Y" in
x.Y and can be presumed to get the bug fixes when merges
happen from the stable branch. The inclusion of said bug
fixes is sort-of implicit in the higher "Y" value.
So really I don't see a reason to do anything special during
merges.
That's why, when I handled the merge tg3.c conflict yesterday
in net-next-2.6, I preserved the net-next-2.6 tg3.c driver
version value.
The driver version value has no meaning in the development
branch until Linus actually pulls it into his tree, for now
it just needs to have a larger "Y" than what is in the stable
series.
prev parent reply other threads:[~2008-06-10 19:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-10 7:28 linux-next: net/net-current merge conflict Stephen Rothwell
2008-06-10 19:38 ` Matt Carlson
2008-06-10 19:44 ` David Miller [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080610.124447.94353426.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=linux-next@vger.kernel.org \
--cc=mcarlson@broadcom.com \
--cc=mchan@broadcom.com \
--cc=sfr@canb.auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox