linux-kernel - Re: 2.6.19 -mm merge plans

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20060921220539.GL26683@redhat.com>
Date:	Thu, 21 Sep 2006 18:05:39 -0400
From:	Dave Jones <davej@...hat.com>
To:	David Miller <davem@...emloft.net>
Cc:	jeff@...zik.org, davidsen@....com, torvalds@...l.org,
	alan@...rguk.ukuu.org.uk, linux-kernel@...r.kernel.org
Subject: Re: 2.6.19 -mm merge plans

On Thu, Sep 21, 2006 at 02:52:08PM -0700, David Miller wrote:

 > But even on that note I would love to have a release cycle where I
 > didn't merge any new features and could work entirely on the bugs
 > that never get worked on.

Would certainly be nice, even if we didn't do it every-other, but
once every half dozen or so releases.  I've been looking over the
osdl bugzilla recently (Ironically in a form of escapism from
the Fedora bugzilla). There's a ton of really old reports in there
that could be mopped up with a targetted bugfixing release.
Right now, with so many open bugs, it's difficult to get a real
picture of where the problem areas are because there's so much
crap in there. (Fedora's bugzilla is actually going through the
same problem right now too sadly, at least in part because
the last few releases have taken so damned long to come out, and
the -stable releases whilst an improvement, haven't gone far
enough to fixing a lot of issues users are seeing[*]).

 > Sure, I'll still be merging new features into my "N + 1" tree.
 > But my pure interactions with Linus's tree can focus entirely
 > on bug fixing, and I really want an environment in which to
 > concentrate on that exclusively.

There's nothing actually stopping you from enforcing this rule
in the trees you maintain though. You could do this for networking
in .19 without having a mandate from Linus that the kernel as
a whole is going to do the same.

Not that networking is an area that sees that many regressions
compared to other subsystems IMO. What's your secret? :)

 > I think the even/odd idea is great, personally.  And if this
 > makes some people have to wait a little bit longer for their
 > favorite feature to get merged, that's tough. :-)

My concern is that people will 'sit out' the even stage, and
just accumulate stuff in a single tree they dump once when
every odd release opens up.

We already have some subsystems that do once-per-release merges,
and then let fixes build up in their out-of-tree SCM for months
until the next window. It won't necessarily get worse, but unless
everyone is participating in the odd/even rules, we won't get
the benefits that it would offer.

	Dave

[*] I'm not demeaning Greg & Chris' work here at all, they've
been doing a stellar job, but I think we could use more people
going through the changelogs looking for stuff that needs
backporting.
-
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/