* linux-next: rebase of the jdelvare-hwmon quilt series @ 2013-09-05 0:19 Stephen Rothwell 2013-09-05 7:25 ` Jean Delvare 0 siblings, 1 reply; 9+ messages in thread From: Stephen Rothwell @ 2013-09-05 0:19 UTC (permalink / raw) To: Jean Delvare; +Cc: linux-next, linux-kernel [-- Attachment #1: Type: text/plain, Size: 208 bytes --] Hi Jean, Why did you bother rebasing the jdelvare-hwmon quilt series? None of the patches changed (not that that even matters). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: rebase of the jdelvare-hwmon quilt series 2013-09-05 0:19 linux-next: rebase of the jdelvare-hwmon quilt series Stephen Rothwell @ 2013-09-05 7:25 ` Jean Delvare 0 siblings, 0 replies; 9+ messages in thread From: Jean Delvare @ 2013-09-05 7:25 UTC (permalink / raw) To: Stephen Rothwell; +Cc: linux-next, linux-kernel Hi Stephen, On Thu, 5 Sep 2013 10:19:03 +1000, Stephen Rothwell wrote: > Why did you bother rebasing the jdelvare-hwmon quilt series? None of the > patches changed (not that that even matters). I'm not "rebasing". Rebasing is a git thing, and I'm using quilt, not git, to feed linux-next. Until the patches hit Linus' tree, I am not maintaining a tree, I am maintaining a patch set on top of a moving tree. I only use git to send my pull request to Linus to make things easier for him. What you see is just how quilt works. That's nothing to worry about. I've been working that way for over 6 years. I am curious why you started yelling at me about this 3 months ago when it has proven to work just fine for 6 years. You asked me to tag what my quilt series was based on, and I did. You asked me to get my patches in linux-next ASAP so that they get more testing, and I do. Last time, you mentioned a problem with testing results being lost when I "rebase" my quilt series". I don't quite think it's true for hwmon patches as the subsystem is pretty much self-contained (the things I am working on at least) plus I do built-test and to some extent run-test the patches continuously, so I am confident my approach isn't breaking bisectability. But I have heard you nevertheless and already slightly changed my process. I will no longer be "rebasing" during the merge window, i.e. the first pull request I send during the merge window, which contains the patches that have been waiting or have been added since the previous merge window, will now be based on the just-released .0 kernel, rather than the current pre-rc1 state of Linus' tree at the time I issue the pull request. Hopefully this should address your "test results are lost" concern. I don't think there's much more I can offer. I have to work with a relatively recent tree so I have to "rebase" from times to times anyway. At least once per development cycle, right? And I don't think it would be very reasonable to stay on -rc1 all the time. That's why I follow upstream development between -rc1 and final, and will only stop doing so between final and -rc1. Staying with .0 wouldn't be reasonable either, there's a reason why we maintain stable kernels trees. I don't think you want developers to base their work on the previous stable kernel, right? You see, I don't want to make your life harder or anything. It's just that your request doesn't make sense to me. "Don't rebase" is not something I can do much with, as I do have to follow upstream development and rebase at some point in time anyway. If you propose a complete workflow which is better than what I do today, I'll be happy to consider switching to it. But just telling me to skip one mandatory step in my current workflow is simply not helping, sorry. -- Jean Delvare ^ permalink raw reply [flat|nested] 9+ messages in thread
* linux-next: rebase of the jdelvare-hwmon quilt series @ 2013-07-11 0:27 Stephen Rothwell 2013-07-11 5:57 ` Jean Delvare 0 siblings, 1 reply; 9+ messages in thread From: Stephen Rothwell @ 2013-07-11 0:27 UTC (permalink / raw) To: Jean Delvare; +Cc: linux-next, linux-kernel [-- Attachment #1: Type: text/plain, Size: 454 bytes --] Hi Jean, Why have you just rebased the jdelvare-hwmon series (http://khali.linux-fr.org/devel/linux-3/jdelvare-hwmon/)? You have just invalidated your testing and made it likely that Linus will blast you if you ask him to pull your patches. Your whole series was already based after v3.10 (i.e. released or rebased after the merge window opened), so why move it again? -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: rebase of the jdelvare-hwmon quilt series 2013-07-11 0:27 Stephen Rothwell @ 2013-07-11 5:57 ` Jean Delvare 2013-07-11 6:53 ` Stephen Rothwell 0 siblings, 1 reply; 9+ messages in thread From: Jean Delvare @ 2013-07-11 5:57 UTC (permalink / raw) To: Stephen Rothwell; +Cc: linux-next, linux-kernel Hi Stephen, On Thu, 11 Jul 2013 10:27:24 +1000, Stephen Rothwell wrote: > Why have you just rebased the jdelvare-hwmon series > (http://khali.linux-fr.org/devel/linux-3/jdelvare-hwmon/)? You have > just invalidated your testing and made it likely that Linus will blast > you if you ask him to pull your patches. Your whole series was already > based after v3.10 (i.e. released or rebased after the merge window > opened), so why move it again? I'm quite confused by this complaint of yours. I do not have the feeling that I rebased anything or invalidated any testing. And I don't think I did anything different this time from the way I have been proceeding for years. I had only 2 hwmon patches for Linus for this merge window: hwmon-lm63-drop-redundant-safety.patch hwmon-lm90-drop-redundant-safety.patch They have been in http://khali.linux-fr.org/devel/linux-3/jdelvare-hwmon/ (and thus in linux-next) continuously since May 19th so I'd say they received pretty good testing. I did not touch them, I did not even have to refresh them. 3 days ago I added these 2 patches to the hwmon-for-linus branch of my staging tree: http://git.kernel.org/cgit/linux/kernel/git/jdelvare/staging.git/log/?h=hwmon-for-linus and asked Linux to pull from it. Yesterday I reviewed a new (trivial) hwmon patch, and I accepted it, so it was added to http://khali.linux-fr.org/devel/linux-3/jdelvare-hwmon/ as hwmon-w83792d-update-module-author.patch (and thus went to linux-next.) Last night Linus pulled from http://git.kernel.org/cgit/linux/kernel/git/jdelvare/staging.git/log/?h=hwmon-for-linus so the 2 "old" patches are now merged upstream. The one "new" patch is not, it will get upstream next time I ask Linus to pull from my staging tree. This is how things have happened, and I just can't see anything wrong. If you do, please explain what you thing shouldn't have happened, and let me know what I should have done instead. Thanks, -- Jean Delvare ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: rebase of the jdelvare-hwmon quilt series 2013-07-11 5:57 ` Jean Delvare @ 2013-07-11 6:53 ` Stephen Rothwell 2013-07-11 7:39 ` Jean Delvare 0 siblings, 1 reply; 9+ messages in thread From: Stephen Rothwell @ 2013-07-11 6:53 UTC (permalink / raw) To: Jean Delvare; +Cc: linux-next, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2541 bytes --] Hi Jean, On Thu, 11 Jul 2013 07:57:00 +0200 Jean Delvare <khali@linux-fr.org> wrote: > > On Thu, 11 Jul 2013 10:27:24 +1000, Stephen Rothwell wrote: > > Why have you just rebased the jdelvare-hwmon series > > (http://khali.linux-fr.org/devel/linux-3/jdelvare-hwmon/)? You have > > just invalidated your testing and made it likely that Linus will blast > > you if you ask him to pull your patches. Your whole series was already > > based after v3.10 (i.e. released or rebased after the merge window > > opened), so why move it again? > > I'm quite confused by this complaint of yours. I do not have the > feeling that I rebased anything or invalidated any testing. And I don't > think I did anything different this time from the way I have been > proceeding for years. Probably not, I guess I have been getting more sensitive lately. However, you have changed the base of your quilt series. This means that you have included more changes from Linus' tree into your tree, thus any testing you have done previously may be invalidated by those changes. > I had only 2 hwmon patches for Linus for this merge window: > hwmon-lm63-drop-redundant-safety.patch > hwmon-lm90-drop-redundant-safety.patch Yeah, sorry, but I was complaining to several people today. > They have been in > http://khali.linux-fr.org/devel/linux-3/jdelvare-hwmon/ (and thus in > linux-next) continuously since May 19th so I'd say they received pretty > good testing. I did not touch them, I did not even have to refresh them. Actually, those patches only hit linux-next on July 9 (my time), when the were based on v3.10-6005-gd2b4a64. Then today you changed the base of your series to v3.10-8587-g496322b and added another patch. > 3 days ago I added these 2 patches to the hwmon-for-linus branch of my > staging tree: > http://git.kernel.org/cgit/linux/kernel/git/jdelvare/staging.git/log/?h=hwmon-for-linus > and asked Linux to pull from it. Which is probably when they hit linux-next. > Yesterday I reviewed a new (trivial) hwmon patch, and I accepted it, so > it was added to http://khali.linux-fr.org/devel/linux-3/jdelvare-hwmon/ as > hwmon-w83792d-update-module-author.patch (and thus went to linux-next.) And I have no problem with maintainers making judgement calls about simple patches during the merge window. It all seems a bit trivial when we are talking about 2 patches, but it is the process that is important. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: rebase of the jdelvare-hwmon quilt series 2013-07-11 6:53 ` Stephen Rothwell @ 2013-07-11 7:39 ` Jean Delvare 2013-07-11 23:17 ` Paul Gortmaker 0 siblings, 1 reply; 9+ messages in thread From: Jean Delvare @ 2013-07-11 7:39 UTC (permalink / raw) To: Stephen Rothwell; +Cc: linux-next, linux-kernel On Thu, 11 Jul 2013 16:53:43 +1000, Stephen Rothwell wrote: > On Thu, 11 Jul 2013 07:57:00 +0200 Jean Delvare <khali@linux-fr.org> wrote: > > On Thu, 11 Jul 2013 10:27:24 +1000, Stephen Rothwell wrote: > > > Why have you just rebased the jdelvare-hwmon series > > > (http://khali.linux-fr.org/devel/linux-3/jdelvare-hwmon/)? You have > > > just invalidated your testing and made it likely that Linus will blast > > > you if you ask him to pull your patches. Your whole series was already > > > based after v3.10 (i.e. released or rebased after the merge window > > > opened), so why move it again? > > > > I'm quite confused by this complaint of yours. I do not have the > > feeling that I rebased anything or invalidated any testing. And I don't > > think I did anything different this time from the way I have been > > proceeding for years. > > Probably not, I guess I have been getting more sensitive lately. > However, you have changed the base of your quilt series. This means that > you have included more changes from Linus' tree into your tree, thus any > testing you have done previously may be invalidated by those changes. And then what? Linus will end up merging these patches into his up-to-date tree anyway. Me staying on an old tree is not going to help anything. I am precisely trying to stick to Linus' tree as much as possible, precisely to me sure that 1* merging my patches will be a trivial operation for Linus and 2* I can detect and fix any build or run-time issue before Linus merges my patches. Isn't linux-next itself rebased on Linus's latest tree every day for exactly that reason? > > I had only 2 hwmon patches for Linus for this merge window: > > hwmon-lm63-drop-redundant-safety.patch > > hwmon-lm90-drop-redundant-safety.patch > > Yeah, sorry, but I was complaining to several people today. > > > They have been in > > http://khali.linux-fr.org/devel/linux-3/jdelvare-hwmon/ (and thus in > > linux-next) continuously since May 19th so I'd say they received pretty > > good testing. I did not touch them, I did not even have to refresh them. > > Actually, those patches only hit linux-next on July 9 (my time), when the > were based on v3.10-6005-gd2b4a64. Hmm, that would mean I forgot to update my public series when I accepted them. That's embarrassing and I apologize for that, this should not happen. My tree is seeing so little change these days, it can stay for weeks without a change, so if I forget to export once, it can take long before the omission is repaired. > Then today you changed the base of > your series to v3.10-8587-g496322b and added another patch. Yes I did. I always do that. > > 3 days ago I added these 2 patches to the hwmon-for-linus branch of my > > staging tree: > > http://git.kernel.org/cgit/linux/kernel/git/jdelvare/staging.git/log/?h=hwmon-for-linus > > and asked Linux to pull from it. > > Which is probably when they hit linux-next. I suppose so, yes. Updating my public patch series is a preliminary step to preparing my staging tree for Linus to pull from. > > Yesterday I reviewed a new (trivial) hwmon patch, and I accepted it, so > > it was added to http://khali.linux-fr.org/devel/linux-3/jdelvare-hwmon/ as > > hwmon-w83792d-update-module-author.patch (and thus went to linux-next.) > > And I have no problem with maintainers making judgement calls about > simple patches during the merge window. FWIW I would have accepted the patch even if it was not trivial and it would have gone in linux-next just the same. The only difference is whether I consider the patch for this merge window or only for the next. Is there a policy to not include new patches in linux-next during a merge window if the patch is for the next merge window? If so I wasn't aware of it. I always considered that the earlier a patch gets in linux-next, the better. > It all seems a bit trivial when we are talking about 2 patches, but it is > the process that is important. I'm fine respecting any process in place, but at this point I still do not understand how what I did is supposed to be wrong or problematic. I can't believe you are asking me to not rebase my quilt series on Linus's latest kernel tree every now and then, to make sure it still applies cleanly. This is exactly what quilt is good for. So please tell me exactly what you expect from me. Was I supposed to base my patches on v3.10 rather than following Linus's v3.11 development tree until I sent my pull request? This would put the merging burden on his (and your) shoulders instead of mine, which seems wrong. And if so, what am I supposed to do after Linus has actually pulled my changes? What if I need to send a second round of patches during the merge window? Confused, -- Jean Delvare ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: rebase of the jdelvare-hwmon quilt series 2013-07-11 7:39 ` Jean Delvare @ 2013-07-11 23:17 ` Paul Gortmaker 2013-07-12 0:27 ` Stephen Rothwell 0 siblings, 1 reply; 9+ messages in thread From: Paul Gortmaker @ 2013-07-11 23:17 UTC (permalink / raw) To: Jean Delvare; +Cc: Stephen Rothwell, linux-next, linux-kernel On Thu, Jul 11, 2013 at 3:39 AM, Jean Delvare <khali@linux-fr.org> wrote: > On Thu, 11 Jul 2013 16:53:43 +1000, Stephen Rothwell wrote: >> On Thu, 11 Jul 2013 07:57:00 +0200 Jean Delvare <khali@linux-fr.org> wrote: >> > On Thu, 11 Jul 2013 10:27:24 +1000, Stephen Rothwell wrote: >> > > Why have you just rebased the jdelvare-hwmon series >> > > (http://khali.linux-fr.org/devel/linux-3/jdelvare-hwmon/)? You have >> > > just invalidated your testing and made it likely that Linus will blast >> > > you if you ask him to pull your patches. Your whole series was already >> > > based after v3.10 (i.e. released or rebased after the merge window >> > > opened), so why move it again? >> > >> > I'm quite confused by this complaint of yours. I do not have the >> > feeling that I rebased anything or invalidated any testing. And I don't >> > think I did anything different this time from the way I have been >> > proceeding for years. >> >> Probably not, I guess I have been getting more sensitive lately. >> However, you have changed the base of your quilt series. This means that >> you have included more changes from Linus' tree into your tree, thus any >> testing you have done previously may be invalidated by those changes. > > And then what? Linus will end up merging these patches into his > up-to-date tree anyway. Me staying on an old tree is not going to help > anything. I am precisely trying to stick to Linus' tree as much as Actually, the above is not quite true. It isn't about staying on an _old_ tree, but staying on a baseline that matches where your testing took place. This matters when people are trying to track down problems with git bisect -- since the merge will also record what your baseline was, and assumes your patches work and were tested on that baseline. If you rebase to a new baseline, and don't fully re-test there, then the bisect will most likely point at one of your patches as broken. Yet, if you didn't rebase, then all your patches will "pass" bisect test, and the _merge_ commit will be called the failure -- which tells us that something new in the tree since your baseline has caused breakage in your subsystem. That can be a critical bit of information. In this merge window, there has already been several examples where Linus has been annoyed by people changing their baseline last minute. https://lkml.org/lkml/2013/7/7/86 > possible, precisely to me sure that 1* merging my patches will be a > trivial operation for Linus and 2* I can detect and fix any build or > run-time issue before Linus merges my patches. > > Isn't linux-next itself rebased on Linus's latest tree every day for > exactly that reason? > >> > I had only 2 hwmon patches for Linus for this merge window: >> > hwmon-lm63-drop-redundant-safety.patch >> > hwmon-lm90-drop-redundant-safety.patch >> >> Yeah, sorry, but I was complaining to several people today. >> >> > They have been in >> > http://khali.linux-fr.org/devel/linux-3/jdelvare-hwmon/ (and thus in >> > linux-next) continuously since May 19th so I'd say they received pretty >> > good testing. I did not touch them, I did not even have to refresh them. >> >> Actually, those patches only hit linux-next on July 9 (my time), when the >> were based on v3.10-6005-gd2b4a64. > > Hmm, that would mean I forgot to update my public series when I > accepted them. That's embarrassing and I apologize for that, this > should not happen. My tree is seeing so little change these days, it > can stay for weeks without a change, so if I forget to export once, it > can take long before the omission is repaired. > >> Then today you changed the base of >> your series to v3.10-8587-g496322b and added another patch. > > Yes I did. I always do that. This is the crux of what Stephen is complaining about here. You do not want to always be doing this. > >> > 3 days ago I added these 2 patches to the hwmon-for-linus branch of my >> > staging tree: >> > http://git.kernel.org/cgit/linux/kernel/git/jdelvare/staging.git/log/?h=hwmon-for-linus >> > and asked Linux to pull from it. >> >> Which is probably when they hit linux-next. > > I suppose so, yes. Updating my public patch series is a preliminary > step to preparing my staging tree for Linus to pull from. > >> > Yesterday I reviewed a new (trivial) hwmon patch, and I accepted it, so >> > it was added to http://khali.linux-fr.org/devel/linux-3/jdelvare-hwmon/ as >> > hwmon-w83792d-update-module-author.patch (and thus went to linux-next.) >> >> And I have no problem with maintainers making judgement calls about >> simple patches during the merge window. > > FWIW I would have accepted the patch even if it was not trivial and it > would have gone in linux-next just the same. The only difference is > whether I consider the patch for this merge window or only for the next. The linux-next tree should not see "new" commits during the two week window of the merge window -- only content for the active merge window should be in linux-next during the merge window. Once the rc1 tag has been completed, then you can add new content. This has been something that Stephen broadcasts regularly for each merge window start. So there is nothing wrong with accepting the patch, but if it isn't destined for this merge window, then it should not be forwarded to linux-next until after rc1 gets tagged. > > Is there a policy to not include new patches in linux-next during a > merge window if the patch is for the next merge window? If so I wasn't > aware of it. I always considered that the earlier a patch gets in > linux-next, the better. Yes, see above. > >> It all seems a bit trivial when we are talking about 2 patches, but it is >> the process that is important. > > I'm fine respecting any process in place, but at this point I still do > not understand how what I did is supposed to be wrong or problematic. I > can't believe you are asking me to not rebase my quilt series on > Linus's latest kernel tree every now and then, to make sure it still > applies cleanly. This is exactly what quilt is good for. This is what you'll get in trouble for. Here is another example. http://marc.info/?l=linux-kernel&m=137331580204926&w=2 Unless you have a concrete reason for changing your baseline, and then retest it there, you shouldn't be changing it. > > So please tell me exactly what you expect from me. Was I supposed to > base my patches on v3.10 rather than following Linus's v3.11 > development tree until I sent my pull request? This would put the > merging burden on his (and your) shoulders instead of mine, which seems Yes, if you did the above, you would be fine. Many times Linus has said that people should not worry about "protecting" him from merges. And if you are really concerned, you can do a local "test-merge" yourself, and give hints about what he might run into, and even a sample merge on a separate branch, that he can look at if required. Hope that helps clarify things, Paul. -- > wrong. And if so, what am I supposed to do after Linus has actually > pulled my changes? What if I need to send a second round of patches > during the merge window? > > Confused, > -- > Jean Delvare > -- > To unsubscribe from this list: send the line "unsubscribe linux-next" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: rebase of the jdelvare-hwmon quilt series 2013-07-11 23:17 ` Paul Gortmaker @ 2013-07-12 0:27 ` Stephen Rothwell 2013-07-12 0:36 ` Stephen Rothwell 0 siblings, 1 reply; 9+ messages in thread From: Stephen Rothwell @ 2013-07-12 0:27 UTC (permalink / raw) To: Paul Gortmaker; +Cc: Jean Delvare, linux-next, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1863 bytes --] Hi Jean, On Thu, 11 Jul 2013 19:17:52 -0400 Paul Gortmaker <paul.gortmaker@gmail.com> wrote: > > On Thu, Jul 11, 2013 at 3:39 AM, Jean Delvare <khali@linux-fr.org> wrote: > > > > FWIW I would have accepted the patch even if it was not trivial and it > > would have gone in linux-next just the same. The only difference is > > whether I consider the patch for this merge window or only for the next. > > The linux-next tree should not see "new" commits during the two week > window of the merge window -- only content for the active merge window > should be in linux-next during the merge window. Once the rc1 tag has > been completed, then you can add new content. This has been something > that Stephen broadcasts regularly for each merge window start. > > So there is nothing wrong with accepting the patch, but if it isn't destined > for this merge window, then it should not be forwarded to linux-next until > after rc1 gets tagged. > > > Is there a policy to not include new patches in linux-next during a > > merge window if the patch is for the next merge window? If so I wasn't > > aware of it. I always considered that the earlier a patch gets in > > linux-next, the better. > > Yes, see above. As Paul said, new material should not enter linux-next until after -rc1 is released. In fact, every time Linus opens a merge window, I send an email to lkml and the linux-next list saying just that. I also often add that message to the top of my daily release announcements (though I forgot during this merge window). This restriction is imposed so that maintainers still getting their code into the current merge window are not distracted by reports of problems in linux-next to do with code that will not be merged in this merge window. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: rebase of the jdelvare-hwmon quilt series 2013-07-12 0:27 ` Stephen Rothwell @ 2013-07-12 0:36 ` Stephen Rothwell 0 siblings, 0 replies; 9+ messages in thread From: Stephen Rothwell @ 2013-07-12 0:36 UTC (permalink / raw) To: Paul Gortmaker; +Cc: Jean Delvare, linux-next, linux-kernel [-- Attachment #1: Type: text/plain, Size: 782 bytes --] On Fri, 12 Jul 2013 10:27:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > As Paul said, new material should not enter linux-next until after -rc1 > is released. In fact, every time Linus opens a merge window, I send an > email to lkml and the linux-next list saying just that. I also often add > that message to the top of my daily release announcements (though I > forgot during this merge window). > > This restriction is imposed so that maintainers still getting their code > into the current merge window are not distracted by reports of problems > in linux-next to do with code that will not be merged in this merge > window. Of course, this does not apply to bug fixes etc. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-09-05 7:25 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-09-05 0:19 linux-next: rebase of the jdelvare-hwmon quilt series Stephen Rothwell 2013-09-05 7:25 ` Jean Delvare -- strict thread matches above, loose matches on Subject: below -- 2013-07-11 0:27 Stephen Rothwell 2013-07-11 5:57 ` Jean Delvare 2013-07-11 6:53 ` Stephen Rothwell 2013-07-11 7:39 ` Jean Delvare 2013-07-11 23:17 ` Paul Gortmaker 2013-07-12 0:27 ` Stephen Rothwell 2013-07-12 0:36 ` Stephen Rothwell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).