Re: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3readiness
Woodruff, Robert J wrote: I hate to keep slipping this, but I think it is important to get what RedHat needs into OFED 1.3, so I am not apposed to this. I think however that perhaps after 1.3, we should discuss our process a bit to try to get a little better at making our original release dates. I think we are getting hit with feature creep, allowing some pretty major changes after the feature freeze date, late in the release cycle. I agree - we must do a better work in OFED 1.4 Main thing is that all companies will think in advance on the new features they want to drive and not come with features in the last minute. I also think that we do need to be a little more careful and selective about what features go into OFED, as it is suppose to be an enterprise release rather than an experimental code release. This is true but from first OFED version we decided that not all components must be in production level and that we allow components that are in experimental state as long as they do not harm the stability of the full package We may revisit this decision. I think we should have a session on OFED target and expectations in Sonoma For the kernel code, I think that this means keeping things a little closer to the kernel.org kernel features and if something is not upstream, then press for getting it upstream (or at least queued for upsteam) rather than allowing big patches into OFED that have not had a good review. The way we are working now, if it is getting into OFED, people are less aggressive at getting things upstream. Perhaps we can have a discussion about this at the Sonoma workshop. I agree we should have such a discussion at Sonoma Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3readiness
On Wed, 2008-01-30 at 17:10 -0800, Woodruff, Robert J wrote: Tziporet wrote, * Delay 1.3 release in a week * Do RC4 next week - Feb 6 * Add RC5 on Feb 18 - this will be the GOLD version * GA release on Feb 25 All - please reply if this is acceptable I hate to keep slipping this, but I think it is important to get what RedHat needs into OFED 1.3, so I am not apposed to this. I think however that perhaps after 1.3, we should discuss our process a bit to try to get a little better at making our original release dates. I think we are getting hit with feature creep, allowing some pretty major changes after the feature freeze date, late in the release cycle. I also think that we do need to be a little more careful and selective about what features go into OFED, as it is suppose to be an enterprise release rather than an experimental code release. For the kernel code, I think that this means keeping things a little closer to the kernel.org kernel features and if something is not upstream, then press for getting it upstream (or at least queued for upsteam) rather than allowing big patches into OFED that have not had a good review. The way we are working now, if it is getting into OFED, people are less aggressive at getting things upstream. Perhaps we can have a discussion about this at the Sonoma workshop. In addition, we should talk about how to integrate patches being queued in upper stream but not in OFED, like IPoIB noSRQ. There is always a window between OFED release and kernel release, a window between Distro release and OFED release. Some customers are targeted OFED release, some customers are targeted OFED release. Then how to handle these windows to meet different customers' requirements could be something t to be discussed at Sonoma workshop as well. Thanks Shirley ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3readiness
In addition, we should talk about how to integrate patches being queued in upper stream but not in OFED, like IPoIB noSRQ. There is always a window between OFED release and kernel release, a window between Distro release and OFED release. Some customers are targeted OFED release, some customers are targeted OFED release. Then how to handle these windows to meet different customers' requirements could be something t to be discussed at Sonoma workshop as well. Oops, a typo, I meant some customers are targeted Distro releases. From customer support point view, it's always better to have OFED releases in Distros. Thanks Shirley ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3readiness
Thanks for everyone here. I appreciate your comments and effort. The big challenge for us is how to sync features/blockers with OFED release Distros release. Most of our customers prefer Distros release so they can get same level of support as other pieces. If OFED could work with Distros release, then it will be less problems for both end users and Distros. That's just my personal opinion. We are here to support any issues being found in OFED release cycle on time regarding these patches. Thanks again! Shirley ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3readiness
The main reason is not the bugs but the features supported by IBM - CM support for non SRQ and 4K MTU These are entirely my opinions, but... OFED isn't even at RC1 if it's not at feature freeze... OFED has moved well beyond trying to provide an enterprise distribution to simply providing an experimental code base more concerned with including the latest and greatest features. It's become the staging area for getting the code into shape for merging upstream, which wasn't what I thought was the purpose of OFED. - Sean ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3readiness
On Wed, 2008-01-30 at 14:03 -0800, Sean Hefty wrote: The main reason is not the bugs but the features supported by IBM - CM support for non SRQ and 4K MTU These are entirely my opinions, but... OFED isn't even at RC1 if it's not at feature freeze... OFED has moved well beyond trying to provide an enterprise distribution to simply providing an experimental code base more concerned with including the latest and greatest features. It's become the staging area for getting the code into shape for merging upstream, which wasn't what I thought was the purpose of OFED. Well, that's not really a fair thing to say given that the CM support for non SRQ patch *is* upstream, it just isn't in OFED. As far as OFED not even being at RC1 if it isn't at feature freeze, that all depends on what's classified as a feature. I know the two patches above were called features by Tziporet, but if this were an internal Red Hat project, those would have been more correctly classified as blockers. Once we've passed our feature freeze deadline and started our testing and validation, if a bug or shortcoming is found in some new code we submitted, then that is classified as a blocker (unless it's actually unimportant enough that we can leave it, but there are very few of this sort of thing ever found). For us anyway, this will be our first release where we are turning on CM support in IPoIB. It would be a legitimate bug that the code as submitted doesn't work across all the hardware. So, that would be a blocker bug, with the fix being the non-SRQ support. Anyway, I got the impression that the real sentiment of your mail was less about those two bugs/features and more that OFED seems to be more of an experimental source repo than an enterprise distribution. In all fairness, the kernel portion of all of this, and the process of getting things into Linus' kernel, has *always* been a case of staging things in Roland's tree and then merging upstream. So, at least for the kernel, that's mostly true as OFED is pretty close to Roland's tree generally speaking. As for the user space packages though, you guys *are* the upstream. There's no one to merge upstream to and very little oversight by anyone. So, it's entirely up to all of you just how much your package seems to be a feature of the day change-athon versus a solid, stable program. -- Doug Ledford [EMAIL PROTECTED] GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: This is a digitally signed message part ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3readiness
Tziporet wrote, * Delay 1.3 release in a week * Do RC4 next week - Feb 6 * Add RC5 on Feb 18 - this will be the GOLD version * GA release on Feb 25 All - please reply if this is acceptable I hate to keep slipping this, but I think it is important to get what RedHat needs into OFED 1.3, so I am not apposed to this. I think however that perhaps after 1.3, we should discuss our process a bit to try to get a little better at making our original release dates. I think we are getting hit with feature creep, allowing some pretty major changes after the feature freeze date, late in the release cycle. I also think that we do need to be a little more careful and selective about what features go into OFED, as it is suppose to be an enterprise release rather than an experimental code release. For the kernel code, I think that this means keeping things a little closer to the kernel.org kernel features and if something is not upstream, then press for getting it upstream (or at least queued for upsteam) rather than allowing big patches into OFED that have not had a good review. The way we are working now, if it is getting into OFED, people are less aggressive at getting things upstream. Perhaps we can have a discussion about this at the Sonoma workshop. my 2 cents, woody ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
