linux-kernel - Re: linux-next: first tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080214160231.GC10713@shadowen.org>
Date:	Thu, 14 Feb 2008 16:04:36 +0000
From:	Andy Whitcroft <apw@...dowen.org>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: first tree

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@...ky$ 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/