|
sed -i 's/gregkh@suse.de/gregkh@linuxfoundation.org/g' .addressbook posted Tue, 31 Jan 2012 in [/diary]
I thought it would be easier to do a round of stable kernel releases in the middle of the larger kernel merge window, to prevent the next round from being so big (given that there are a lot of patches usually applying during the -rc1 merge window cycle). So, I've now done:
Please go test and let me know if there are any problems with any of these kernels. If I've missed any patches that you feel should be in them, also please let me know. Note, this is most likely going to be the LAST 3.1.y kernel release, so please move off to the 3.2 kernel at this point in time. Maintaining so many different kernel branches all at once is not trivial, and I want to minimize it if at all possible. posted Tue, 10 Jan 2012 in [/linux]
As 3.2 is now out, here's a note as to the current status of the different stable/longterm kernel trees. First off, please everyone remember to mark any patch that you want to have applied to the stable kernel trees with a simple: marking in the Signed-off-by: area. Once the patch hits Linus's tree, I will automatically be notified of it and it will be applied if possible. If it does not applied, you will be notified of that. Note that the address is stable@vger.kernel.org, not the older address that used to be used before October of 2011. At this time, all stable and longterm kernel trees are being maintained in one big git tree, located at: There are different branches for every different major kernel version. Here's the different active kernel versions that I am maintaining at the moment:
All other longterm kernels are being maintained in various forms (usually quite sporadically, if at all), by other people, and I can not speak for their lifetime at all, that is up to those individuals. If anyone has any questions about any of this, please let me know. posted Mon, 09 Jan 2012 in [/linux]
tl;dr;
History:2.6.16 became a "longterm" kernel because my day job (at SUSE) picked the 2.6.16 kernel for its "enterprise" release and it made things a lot easier for me to keep working at applying bugfixes and other stable patches to it to make my job simpler (applying a known-good bunch of patches in one stable update was easier than a set of smaller patches that were only tested by a smaller group of people.) Seeing that this worked well, a cabal of developers got together at a few different Linux conferences and determined that based on their future distro release cycles, we could all aim for standardizing on the 2.6.32 kernel, saving us all time and energy in the long run. We turned around and planted the proper seeds within the different organizations and low-and-behold, project managers figured that this was their idea and sold it to the rest of the groups and made it happen. Right now all of the major "enterprise" and "stable" distro releases are based on the 2.6.32 kernel, making this trial a huge success. Last year, two different community members (Andi and Paul) asked me if they could maintain the 2.6.34 and 2.6.35 kernels as -longterm kernel releases as their companies needed this type of support. I agreed, and they have done a great job at this. Andi reports that the 2.6.35 kernel is being used by a number of different distros, but they will be phased out as their support lifetime expires. There are also a number of embedded users of the kernel as well as some individual ones. So that -longterm kernel is having a lot of benefit for a wide range of users. Today:Now that 2.6.32 is over a year and a half, and the enterprise distros are off doing their thing with their multi-year upgrade cycles, there's no real need from the distros for a new longterm kernel release. But it turns out that the distros are not the only user of the kernel, other groups and companies have been approaching me over the past year, asking how they could pick the next longterm kernel, or what the process is in determining this. To keep this all out in the open, let's figure out what to do here. Consumer devices have a 1-2 year lifespan, and want and need the experience of the kernel community maintaining their "base" kernel for them. There is no real "enterprise" embedded distro out there from what I can see. montaVista and WindRiver have some offerings in this area, but they are not that widely used and are usually more "deep embedded". There's also talk that the CELF group and Linaro are wanting to do something on a "longterm" basis, and are fishing around for how to properly handle this with the community to share the workload. Android also is another huge player here, upgrading their kernel every major release, and they could use the support of a longterm kernel as well. Proposal:Here's a first cut at a proposal, let me know if you like it, hate it, would work for you and your company, or not at all:
This means that there are 2 -longterm kernels being maintained at the same time, and one -stable kernel. I'm volunteering to do this work, as it's pretty much what I'm doing today anyway, and I have all of the scripts and workflow down. Public Notifications:The current kernel.org site doesn't properly show what is and is not being maintained as a -stable and -longterm kernel. I have a proposal for how to fix this involving 'git notes', I just need to sit down and do the work with the kernel.org admins to get this running properly. Thoughts? Feel free to comment on the google+ thread about this, or on the lkml thread. posted Sun, 14 Aug 2011 in [/linux]
Sixth in a long series of complaints... See part 1 and part 2 and part 3 and part 4 and part 5 for previous atrocities. There's nothing like waking up and receiving in your inbox, a few scant hours after the merge window has opened up again, a plea for why you haven't already reviewed and applied all 117+ patches that the author sent to you a few weeks ago, back when they well knew you could not apply them due to the merge window being closed. Oh, and to top it all off, as the message was sent in HTML format, it didn't hit the mailing lists, I was the only one who received it. Because of that, I figured it was better if I just ignored it as well, just like the vger.kernel.org filters did. I think I'll just ignore this whole set of patches until after LinuxCon Vancouver which should give me enough time to cool off. This message brought to you by your favorite convicted monopolist. posted Mon, 08 Aug 2011 in [/linux] I have a python script that I run all the time as part of my process for emailing out "your patch has been accepted" messages when I accept a Linux kernel patch into one of the many different development trees I maintain. This script's goal is to merely determine the character encoding that the email needs to be sent in, either "UTF-8" or "ISO-8859-1" or "ANSI_X3.4-1968". It's really simple which is great, but it is slow when fed a file of any real length. For example, the Linux kernel Makefile takes almost 2 seconds to run through this file, even if the file is in the filesytem cache. The script was written for me by someone else who was tired of getting emails from me in the wrong encoding, and I greatly appreciate it, but they seem to have disappeared, and my python-foo is quite limited these days. So anyone wanting to speed this up for me, or rewrite it in perl so I can maintain it over time myself (while also speeding it up) would be greatly appreciated. I'm a Google Summer of Code mentor for a project to port Linux to a specific system on a chip that happens to be in a number of older game platforms. Here's one of these devices. I'm going to be in Taipei and Tokyo over the next few weeks, and it would be great if I could pick up one of these myself to help in the debugging effort of this project. Does anyone know of anywhere in either of those cities I might be able to get this device? And yes, I am pretty familiar with Akihabara in Tokyo and the electronic area in Taipei but I can't recall ever seeing anything like this before in the stores in those areas, but I probably just wasn't paying attention. Any help finding this would also be greatly appreciated. posted Tue, 24 May 2011 in [/linux]
My previous plea for help worked out very well. The resulting video of the talk can be seen here, with one of the highlights being the phrase, "It is cheaper to work upstream in the kernel" from Dirk Hohndel who works at Intel. There's a summary of the talk on lwn.net over here if you don't want to sit through the whole video. Since I received so many good questions that I worked into the talk last time, I figured I would try it again. In a few weeks, I'll be interviewing Linus Torvalds on stage at the LinuxCon Japan conference, with the topic naturally being "20 Years of Linux." But there's no reason we have to stick with that topic, right? Send me your ideas and questions and I'll do my best to pick through them and come up with something entertaining enough to fill up a 45 minute discussion between two boring Linux kernel developers. posted Thu, 19 May 2011 in [/linux]
Here's a short note as to the status of some recent activity in the openSUSE:Tumbleweed repo:
As always, if anyone knows of any packages they wish to see added to Tumbleweed, please let me know. Please read the wiki page for Tumbleweed if you have any basic questions about what it is or how to use it. Any other questions, please ask them on the opensuse-factory mailing list. posted Fri, 22 Apr 2011 in [/suse]
Here's a short note as to the status of some recent activity in the openSUSE:Tumbleweed repo:
Note, it seems that when any package is added or updated in the openSUSE:Tumbleweed repository, LibreOffice rebuilds itself. This can be annoying for those on bandwidth-challenged network connections, and seems to be due to the dependency chain that the LibreOffice developers have defined in their .spec files. Hopefully this will be resolved for the next major release, but in the meantime, I'll try to limit library updates in openSUSE:Tumbleweed to once a week at the most unless security issues require it. Please read the wiki page for Tumbleweed if you have any basic questions about what it is or how to use it. Any other questions, please ask them on the opensuse-factory mailing list. posted Sat, 09 Apr 2011 in [/suse]
In two separate email threads this week, I have been asked about the status of the Android wakelock issue that has been described in the past. It turns out that people don't realize that the Linux kernel now supports this type of locking, and has for a few releases now. Rafael J. Wysocki has merged a solution for this into the kernel and done the unthinkable, he documented everything! He wrote an here on lwn.net, and there is a pointer in that article to a 18 page paper describing in great detail the history, proposed solutions and eventual resolution of the problem. Astute readers will realize that now there are no barriers for merging any out-of-tree Android specific kernel drivers. Send them in, we will take them! posted Wed, 23 Mar 2011 in [/linux]
In a few weeks, I'm leading a panel discussion at the Linux Foundation Collaboration Summit about "Hardware Success Stories in the Linux Ecosystem". I'm lucky to have a great set of participants from a bunch of companies with a wide range of experience with Linux, so it should be a lot of fun. Participating are representatives from Intel, Qualcomm, and Texas Instruments. I'm working on coming up with some topics to cover, but, to keep things lively, what do you think would be good questions to ask these companies? Send them to me if you have any ideas. posted Tue, 22 Mar 2011 in [/linux] As noted before, I get a lot of email every day. A few years ago it got to the point that the number of individual queries coming in was making it so that I really didn't have much time to do much else than answer them. So after messing with some perl scripts I came up with an email bot that sits and watches my inbox for messages it can answer by pointing people at the proper place to ask the question in the first place. Every once in a while my email bot escapes to the wild. A number of years ago it hit the linux-usb mailing list so I tweaked it to hopefully never post a public location. But just the other day, a recipient decided to forward it on to a number of public mailing lists, which kind of showed that the recipient didn't actually read the message in the first place. A sad commentary on so many levels... posted Thu, 17 Mar 2011 in [/linux]
Fifth in a long series of complaints... See part 1 and part 2 and part 3 and part4 for previous atrocities. Heck, It's not like I haven't said all of this before, but it sure seems like no one learns from the past, or reads the documentation that we write for how to actually submit a patch for the kernel. Linux has one of the best documented procedures for how to do this, it's not like it's a secret or something... Anyway, here's a list of patches that people have sent me in this week alone that have caused me major problems:
Yeah, it's been a fun week... And if anyone ever wonders why code reviewers are grumpy, just look at the above list and understand. posted Thu, 10 Feb 2011 in [/linux] Finally, after many years of people asking for this, Linux can now properly support all known Samsung laptop devices. This means we can now handle backlight control, wifi button issues,and the weird "performance mode" keys as well as some of the other function keys. If you have a Samsung laptop, I suggest looking at the driver in this post on the linux-kernel mailing list, and letting me know if you have any problems with it or not. If your laptop is not listed in the DMI table, please feel free to send me a patch to add it so we can properly support it. Many thanks to Samsung oh so long ago for providing some of the needed information to get this to work, and to Ingmar Steen for putting all of the pieces together properly to handle the devices that were not being handled by the old in-kernel driver. posted Wed, 09 Feb 2011 in [/linux] Instead of the old boring "here's what drivers are being merged and deleted" and the like as I've posted in the past, I thought I'd just write about one specific project that has recently gone public that I think is a great indicator of how far the Linux Driver Project has come these days. From the very beginning, Novell has been extremely supportive of the Linux Driver Project, allowing me to work on it on company time, and has encouraged companies they partner with to participate in it, to get Linux drivers into the main kernel tree. One such company recently has been Ralink. Two weeks ago I visited Ralink in person for the second time, in Taiwan. The outcome of this meeting, and the previous ones, can be seen this past week on the rt2x00-users mailing list in these four posts, as well as a number of previous posts from Ralink developers. As you can see in these posts, Ralink is sending patches for the upstream rt2x00 driver for their new chipsets, and not just dumping a huge, stand-alone tarball driver on the community, as they have done in the past. This shows a huge willingness to learn how to deal with the kernel community, and they should be strongly encouraged and praised for this major change in attitude. I'd like to thank the developers and managers at Ralink for making this very public change, and for commiting the resources to see this through to have full Linux support for their chipsets in the main kernel tree. By no means is this something that I can claim full, if even partial credit for. There were numerous people at Ralink, Novell, and HP that helped in getting these meetings to happen, and the work done. I'm just happy to be a tiny part of this. On a personal note, I'd like to thank the Novell Taipei developer team who helped me on my visits, and whom have turned into wonderful kernel developers on their own accord, contributing many upstream patches, as well as becoming the maintainers for a few different drivers in the kernel tree. Without their help, none of this would have been possible. posted Wed, 09 Feb 2011 in [/linux] |
|
My Linux Stuff RSS |
|
||