Linux: 2.6.14 Merge Cycle Ending

Submitted by Jeremy
on September 8, 2005 - 11:01pm

Linux creator Linus Torvalds sent a reminder to the Linux Kernel Mailing List that the merge window for 2.6.14 is coming to and end. "As per the new merge policies that were discussed during LKS in Ottawa earlier during the summer," Linus explained, "I'm going to accept new stuff for 2.6.14 only during the first two weeks after 2.6.13 was released." The new development policy was first discussed on the lkml with the release of 2.6.13-rc4 [story], and further elaborated with the release of 2.6.13 [story].

The 2.6.13 stable kernel was released on August 28'th [story]. "That release was ten days ago," Linus said, "so you've got four more days before I don't want any big merges." He went on to note that following the merge cutoff 2.6.14-rc1 will be released. "We certainly already have enough for 2.6.14," Linus noted, "but I just wanted to remind people that if they expected me to merge your work, you're getting closer to the cut-off point."


From: Linus Torvalds [email blocked]
To: Linux Kernel Mailing List [email blocked]
Subject: Reminder: 2.6.14 merge window closing
Date:	Thu, 8 Sep 2005 12:25:59 -0700 (PDT)


As per the new merge policies that were discussed during LKS in Ottawa 
earlier during the summer, I'm going to accept new stuff for 2.6.14 only 
during the first two weeks after 2.6.13 was released.

That release was ten days ago, so you've got four more days before I don't 
want any big merges.

After that, I'll do a -rc1, and then we're supposed to just do fixes and
thus only work on any regressions and other immediate issues.

I've been merging a lot lately (happily, I got some work done during the
trip last week), so we certainly already have enough for 2.6.14. But I
just wanted to remind people that if they expected me to merge your work,
you're getting closer to the cut-off point..

(Of course, if you already sent me a pointer, and I haven't merged it yet, 
it might be because I missed something during travels, so please do 
re-send in that case)

			Linus

Related Links:

Deadlines

EricB (not verified)
on
September 9, 2005 - 1:29am

There is nothing quite like a deadline to make people rush and submit bad code.

Re:Deadlines

FreqMod (not verified)
on
September 9, 2005 - 1:37am

Then they may just submit it, and then submit a buch of fixes to the code afterwards. This may be bad for the rc's but not for the final version.

Re:Deadlines

priestjim (not verified)
on
September 9, 2005 - 2:52am

Well I believe the whole point of short deadlines is either to submit small quick changes that are most of the time bugless or wait for the next deadline and while waiting, further self-test the code so that there will be less victims in the next kernel (pre)release.

Exactly. If they didn't have

Anonymous_guy (not verified)
on
September 9, 2005 - 2:53am

Exactly. If they didn't have this rule then new crap would be submitted throughout RC releases... which would causes a lot of 2.6.14.x releases.

I've thought of different ways they could model the kernel development but there is no easy compromise. If they slow it down to the old style of 2.7.x development only releases then it would be longer (when development is speeding up) to see new features. However, the "Linux" platform is in such a state of flux right now that in only a matter of weeks something could completely change (gcc). I'd love for the Linux platform to become a mainstream competitor to Windows, but until there's one version of the kernel/gcc/glib that stays the same for a year or two that won't happen.

I don't quite understand your

r0b0 (not verified)
on
September 9, 2005 - 3:59am

I don't quite understand your last sentence. Each and every version of kenel or gcc stays the same forever.

consistency

consistency (not verified)
on
September 9, 2005 - 7:28am

consistency

Exactly consistency. Dependen

Anonymous_guy (not verified)
on
September 12, 2005 - 11:08pm

Exactly consistency. Dependencies change, or this and that changes. Functions or warnings become completely different things. It's just a developers dreamland that will never become reality. For crying out loud, copy Microsoft and do their "one version for 10 years" crap. At least on Windows you can run a Windows 3.1 app on Windows XP. Do you really think an app from Redhat 3.0 will run on Fedora Core 4? Not without 5 different compatibility libraries. Yes, Windows includes the compatibility libraries... but why doesn't any Linux distro? Is it because there are four or five different versions of this or that library? It could be! That's STUPID!

Consistancy

James Cornell (not verified)
on
September 13, 2005 - 12:56am

Thatś not exactly true. Because NT´s netstack is completely different from 9x/3x, Microsoft has broken much of the networked application that ran on Windows 3.x and the older versions of NT. If you have the source, it can be ran. Despite major changes to Glibc I still can compile old versions of say Xmms or Gimp from several years ago. On Windows it has the backwards compatibility, but thatś why it runs so slow and has so many memory leaks. Supporting applications from two decades ago is useless. Why does everyone think that Redhat is ¨Linux¨ by the way? It isn´t, and from experience it´s slower then even Windows XP with all the effects even on a 2.8GHz P4 with 1MB L2 and a boatload of ram. Get off the wagon and give the kernel team a break. Give the people programming Glibc and GCC a break too!

Then just go and use Winders

Anonümous (not verified)
on
September 13, 2005 - 2:01am

Then just go and use Winders if that is what you suits your needs. But leave us alone.

Well, I think that it'd be go

on
September 11, 2005 - 7:45am

Well, I think that it'd be good for everyone if the initial patch has good quality. Now, the new deadline-schema shouldn't affect that much to the quality of the initial patch. Firstly, because you are supposed to write your patch into good shape and then submit it in the next window. Secondly, because the bigger and more fundamental changes go anyway through -mm or some other more experimental tree.

The new deadline-schema enables rc's to be what rc's should be: release candidates. Release candidates should concentrate on improving the quality of the final release.

There is *NO* real deadline.

Anonymous (not verified)
on
September 9, 2005 - 1:23pm

There is *NO* real deadline. If you are to late, just submit to the next cycle. Cycles are supposed to become much shorter. So you will lose maximum 2-3 weeks.

Rushed code

on
September 9, 2005 - 3:04am

I don't think the review process is rushed. So rushed code will have to pass the same review criteria.
And code can be backed out. Perhaps easier to detect issues with things that have been introduced in rc1 than in rc6.

Merge ReiserV4! Alan Co

Alan Cox (not verified)
on
September 9, 2005 - 8:13pm

Merge ReiserV4!

Alan Cox

yes merge reiser v4

Britney Spears (not verified)
on
September 9, 2005 - 8:52pm

lol

love,
britney spears

No.

Linus Torvalds (not verified)
on
September 9, 2005 - 9:02pm

Not until it is ready.

you're never too old to visit

Michael Jackson (not verified)
on
September 10, 2005 - 5:29am

you're never too old to visit neverland, linus

M Jackson

Sometime, someone

Daniele (not verified)
on
September 13, 2005 - 5:38am

Sometime is good to have a long release cycle (and large patch, and code that do not work for a while and need test and twick) sometime not. This had to be lead to development plan, status of the code, marketing et all.

Someone have to lead. I remember Linus said he did not like posix thread, that clone() is enought ... etc. Now, in 2.6 there is the support for nptl. Someway, with aid of libc, now Linux has a good support for posix thread, something that should make happy (hopeful) Dave Butenhof.

I suppose the same will happen for reiser4 too. It is better to give a rationale, though... and elaborate, and enforce ...

ps.: here marketing is "people need this for work/home/anything", and sell and buy...

I think in this case a long

atari 2600 (not verified)
on
June 22, 2008 - 9:07am

I think in this case a long release circle has played in their favor.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.