Linux-Next discussions
 help / color / mirror / Atom feed
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.

      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