From: Andy Whitcroft <apw@shadowen.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: linux-next@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: linux-next: first tree
Date: Thu, 14 Feb 2008 16:04:36 +0000 [thread overview]
Message-ID: <20080214160231.GC10713@shadowen.org> (raw)
In-Reply-To: <20080215003537.8911ce35.sfr@canb.auug.org.au>
On Fri, Feb 15, 2008 at 12:35:37AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> I have created the first cut of the linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git.
>
> Things to know about this tree:
>
> It has two branches - master and stable. Stable is currently just Linus'
> tree and will never rebase. Master will rebase on an almost daily basis
> (maybe slower at the start).
As devout believers in testing things early we test -mm and -git releases
as they drop. I am keen that we are able to continue this with the -next
tree once it gets going. Having just pulled this tree its not obvious how
I would communicate which tree I had tested. I guess we could use the
SHA1 of the actual head used, but that really is cumbersome for the poor
people who have to check the results and actually report things to lkml.
As I previously indicated (on my stupidly subjected "testing linux-next")
to make it simple for us to test these releases, and for the reporters to
have a clear way to refer to them, we need some kind of sensible handle
for each. It is also very desirable that it be trivial for a script to
detect releases. The -git series is pretty handily named, following that
example might make sense.
I was going to propose you name them in a similar way to the main -gitN
releases. But, I note that you are merging with what appears to be an up to
date Linus master tree. Which means there is no nice name for the real
base point for your merges anyhow.
I guess there are a couple of sensible names for these. Either a simple
date or using the nearest sane tag.
So either:
next-20080214
or:
v2.6.25-rc1-next1
Where the "base" version would be determinable from:
apw@pinky$ git describe --tags origin/stable
v2.6.25-rc1-120-ge760e71
I am guessing if a maintainer is coming back to look at a failure
reported by yourself, they are also going to want to know what the base
was for the merge which failed. So it may make sense to keep a tag for
that too?
Also will you be producing any tarballs for these releases? If so I
would say they would definatly need to be against some common base, like
against the nearest official tag "below".
-apw
next prev parent reply other threads:[~2008-02-14 16:04 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-14 13:35 linux-next: first tree Stephen Rothwell
2008-02-14 14:06 ` Jiri Kosina
2008-02-14 14:34 ` Stephen Rothwell
2008-02-14 14:45 ` Rafael J. Wysocki
2008-02-14 15:00 ` Stephen Rothwell
2008-02-14 15:25 ` Martin Schwidefsky
2008-02-14 21:48 ` Stephen Rothwell
2008-02-14 15:49 ` Paul Mundt
2008-02-14 21:58 ` Stephen Rothwell
2008-02-14 15:54 ` Dave Kleikamp
2008-02-14 22:01 ` Stephen Rothwell
2008-02-15 4:58 ` Len Brown
2008-02-15 6:19 ` Stephen Rothwell
2008-02-14 16:04 ` Andy Whitcroft [this message]
2008-02-20 14:23 ` Stephen Rothwell
2008-02-20 16:47 ` Randy Dunlap
2008-02-22 0:07 ` Frank Seidel
2008-02-22 0:12 ` Randy Dunlap
2008-02-22 0:22 ` Harvey Harrison
2008-02-22 5:31 ` Frank Seidel
2008-02-22 0:15 ` Greg KH
2008-02-22 5:33 ` Frank Seidel
2008-02-22 0:28 ` Stephen Rothwell
2008-02-22 5:41 ` Frank Seidel
2008-02-22 5:55 ` Stephen Rothwell
2008-02-14 17:38 ` Mauro Carvalho Chehab
2008-02-14 22:24 ` Stephen Rothwell
2008-02-18 16:07 ` Mauro Carvalho Chehab
2008-02-14 18:29 ` Yinghai Lu
2008-02-14 18:39 ` Benny Halevy
2008-02-14 20:20 ` Greg KH
2008-02-14 20:50 ` Sam Ravnborg
2008-02-14 23:52 ` Stephen Rothwell
2008-02-14 23:31 ` Stephen Rothwell
2008-02-14 20:23 ` Sam Ravnborg
2008-02-14 23:35 ` Stephen Rothwell
2008-02-14 21:03 ` Jeff Garzik
2008-02-14 21:05 ` Jeff Garzik
2008-02-14 21:26 ` James Bottomley
2008-02-14 21:45 ` Jeff Garzik
2008-02-14 23:58 ` Stephen Rothwell
2008-02-14 22:27 ` Trond Myklebust
2008-02-15 0:33 ` Stephen Rothwell
2008-02-15 21:00 ` J. Bruce Fields
2008-02-16 15:37 ` Stephen Rothwell
2008-02-14 23:17 ` David Chinner
2008-02-15 0:50 ` Stephen Rothwell
2008-02-15 1:10 ` David Chinner
2008-02-15 2:14 ` Stephen Rothwell
2008-02-15 8:33 ` Bryan Wu
2008-02-16 15:33 ` Stephen Rothwell
2008-02-17 2:23 ` Robin Getz
2008-02-17 5:33 ` Stephen Rothwell
2008-02-16 15:13 ` Stefan Richter
2008-02-16 15:40 ` Stephen Rothwell
2008-02-17 19:09 ` Mark M. Hoffman
2008-02-17 23:27 ` Stephen Rothwell
2008-02-18 8:04 ` Artem Bityutskiy
2008-02-18 8:29 ` Stephen Rothwell
2008-02-18 11:11 ` Paolo Ciarrocchi
2008-02-18 13:15 ` Stephen Rothwell
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=20080214160231.GC10713@shadowen.org \
--to=apw@shadowen.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--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