On Fri, 2008-10-10 at 22:12 +0200, Papp Tamás wrote: > hi All, Hi,
> What patches should be applied for 1.6.5.1 to get it more stable (also > the same question for patchless clients)? Well, by definition, all of the patches that will be applied to release n are needed by release n-1. For 1.6.5.1 that would be all of the patches we have scheduled to land for 1.6.6. That may sound like a silly answer, but that really is the truth. It's not quite that simple however. Until a release (let's call it 1.6.6 for example) has gone through our QA process, there is no assurance that there are not inter-patch defects (more commonly referred to as ripple effects). Otherwise we could just apply a patch and make 1.6.5.2 and apply another and call it 1.6.5.3, etc. > I've found this in a bugzilla comment for clients: > > https://bugzilla.lustre.org/attachment.cgi?id=18103&action=edit Yes, that one can be an important one. > And this at the list: > > https://bugzilla.lustre.org/show_bug.cgi?id=16496 Not sure how important this one is, but as I will get to, it's all relative. > What else patches are proposed to use? We had recently advised one customer recently to apply the following attachments: attachment 18121 attachment 18293 attachment 19123 attachment 18103 In addition to a few others that were to fix problems particular to their installation. But this is the rub. Which patches any site should apply to a release depends on what their use patterns are like and which bugs they are running into as a result. Given the warning above about ripple effects, applying patches to a given release is a careful balance between minimizing risks of ripple effects and getting the fixes for the particular problems that are ailing you. Obviously the more testing you can do of your release +patches build before going live, the more patches you should be able to sustain without rude go-live incidents. > Is there any chance in the future to make these patches collected > somehow (for example more frequently source-only mini release , like > 1.6.5.x, or a website, or something like that)? As for more frequent releases, the problem we have with that is that our QA process is quite involved due to the complexity of Lustre and the array of kernels and architectures we have to test on to call any given release "fully QA certified". As can be witnessed by 1.6.5.1 (and the few 1.6.4.x releases) however, occasionally the need is justified. As for a website, I suppose you are looking for an enumeration of patches that will be applied to release n to get n+1. You can get information that from our bugzilla in the form of the release tracking bugs. For any given release there is a bug tracking all of the bugs that will be applied to release n-1 to get release n. We usually give those tracking bugs an alias of the form wxy[z]-tracking where w, x, y and possible z are the digits from the release. So for 1.6.6 you'd be interested in "166-tracking" which you can put into a "bug number" field in our BZ and you will get bug 14883. All of the bugs in the Depends on: field are the bugs with patches that have gone into 1.6.5 to get 1.6.6. If you wanted to be notified when a new bug has been identified as needing to go into a release you could simply subscribe yourself to the release tracker and you will get notified of updates to that Depends on: field. Hopefully this tells you all you need to know (and more) about our release process. _______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
