From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lukasz <el.es.cr@gmail.com>
Subject: Re: (Short?) merge window reminder
Date: Fri, 27 May 2011 09:20:06 +0000 (UTC)
Message-ID: <loom.20110527T101931-280@post.gmane.org>
References: <BANLkTi=PLuZhx1=rCfOtg=aOTuC1UbuPYg@mail.gmail.com>  <20110523192056.GC23629@elte.hu>  <BANLkTikdgM+kSvaEYuQkgCYJZELnvwfetg@mail.gmail.com>  <20110523231721.GM10009@thunk.org> <4DDAEC68.30803@zytor.com>  <BANLkTikGfVSAMY2a2yiXaNpvBVvF8YdMEA@mail.gmail.com>  <alpine.LNX.2.01.1105241409280.15351@frira.zrqbmnf.qr>  <BANLkTimCXVdVa6KLRG8GJR1gJY=7_5SkOA@mail.gmail.com>  <alpine.LNX.2.01.1105241500410.23085@frira.zrqbmnf.qr>  <BANLkTinNK+9XijCN0YGXyvLQ8_npPTG2cQ@mail.gmail.com>  <20110524154348.27ba649d@lxorguk.ukuu.org.uk>  <BANLkTi=Xuk4=Q43QV1pv33K=J2FFZBLLtQ@mail.gmail.com> <1306426437.6981.14.camel@segulix>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
To: linux-fsdevel@vger.kernel.org
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from lo.gmane.org ([80.91.229.12]:57059 "EHLO lo.gmane.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1757391Ab1E0JkF (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
	Fri, 27 May 2011 05:40:05 -0400
Received: from list by lo.gmane.org with local (Exim 4.69)
	(envelope-from <lnx-linux-fsdevel@m.gmane.org>)
	id 1QPtWW-0001rA-Dq
	for linux-fsdevel@vger.kernel.org; Fri, 27 May 2011 11:40:04 +0200
Received: from host81-139-112-239.in-addr.btopenworld.com ([81.139.112.239])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <linux-fsdevel@vger.kernel.org>; Fri, 27 May 2011 11:40:04 +0200
Received: from el.es.cr by host81-139-112-239.in-addr.btopenworld.com with local (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <linux-fsdevel@vger.kernel.org>; Fri, 27 May 2011 11:40:04 +0200
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

S=C3=A9rgio Basto <sergio <at> serjux.com> writes:

>=20
> Here it go my opinion,
> Many people ask for beginning of 2.7 kernel series which will end on
> 2.8, by old numeration.=20
> Kernel 2.8 will mainly a major clean up, of support of the very old
> hardware, like "math co-processor" at only exist in 386 and before
> Pentium. If some one want put Linux on this very old hardware should =
use
> kernel 2.2.

On the contrary, I hope this never happens.
Whatever the next 'step' will be, it should just keep going into the ri=
ght=20
direction, as usual, no revolution please :) Release early, release oft=
en
and no 'numerology' or 'walling off'...=20

As per Linus' own words, the release schedule is not about features
and it wasn't about features [since] forever... [at least since this
workflow was adopted - 2.6.8 and the introduction of git ? ;) ]

I like the d.r[.s][.lt] scheme (decade, release, stable, long-term),
 so basically, to convert 2.6 to 3 and leave the rest as is - no=20
big shock to existing infrastructure ;)

But I also like the yy.mm[.ss][.lt] (year, month, stable, long-term)

Or maybe a hybrid of these ?
ly.mm[.ss][.lt] (linux_year, month, stable, long term,
where linux_year =3D linux_decade + year-2000
and month in both of these =3D month_in_year of release

So that :

the 2.6.39-rcX process continues for now, and in time to
cut off, it gets renamed to

3.0 or 3.1 and then stable and lt adds their part,=20
or
11.07 (provided the release happened in July) (and then stable, lt part=
s add)
or
14.07 (11+3).(july)[.stable][.longterm]

but in all 3 cases there is a merge window ending with
3.0-rc1
or
11.07-rc1
or
14.07-rc1
and in case of months used in here, say next cycle has 7 weeks, so
the next major release will be
11.09 or 14.09 and so on;

Because the release cycle probably never had less than 4 weeks, using
the month is imho reasonable.


> However a new numeration of kernel is independent of this, and I agre=
e
> with new numeration of kernel on drop a number.=20

> Last but not least, I would like to see marked a hiper stable kernel =
,
> which will be used by Debian guys. Debian guys tend to stop in a kern=
el
> which is not the best one, so let we choose for them what is the stab=
le
> of stables .

That as well is probably never gonna happen ;) the kernel is more stabl=
e
with each release anyway, _because_ of the 'no thresholds' approach.
And Debian probably have their own reasons for ending up with old kerne=
ls,
like out-of-tree patches that don't get merged but need to be ported wh=
ich
is no easy job... and so on.

>=20
> Best regards,=20

u 2,
Kind Regards,
L.



--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel=
" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html