Tziporet Koren wrote:
2. Agree on OFED 1.3 schedule:
* Feature freeze - Sep 4
Must have general features:
* QoS: OSM, CM, CMA, ULPs (IPoIB, SDP, SRP)
Tziporet,
As was stated by Moni in the meetings, we want the QoS implementation to
first pass review on
Or Gerlitz wrote:
* QoS: OSM, CM, CMA, ULPs (IPoIB, SDP, SRP)
Must have general features:
Tziporet,
As was stated by Moni in the meetings, we want the QoS implementation
to first pass review on the general list (aka ofa) and be accepted
to upstream merge before it
[ snip ]
Let me copy and paste an email conversation I had with Or that
highlights why this is broken:
--- Begin cut-n-paste
On Mon, 2007-07-02 at 22:25 +0300, Or Gerlitz wrote:
[sorry for breaking the thread, I am working from home now and
unable
to use normal mailer.]
Let me
Quoting Doug Ledford [EMAIL PROTECTED]:
Subject: Re: RFC OFED-1.3 installation
On Tue, 2007-07-17 at 19:27 +0300, Michael S. Tsirkin wrote:
Quoting Doug Ledford [EMAIL PROTECTED]:
Subject: Re: RFC OFED-1.3 installation
On Tue, 2007-07-17 at 18:25 +0300, Michael S. Tsirkin wrote:
On Jul 17, 2007, at 1:06 PM, Doug Ledford wrote:
Look, rpms are just like versioned tarballs. Once they go out in the
wild, that particular name-version-release combination is FROZEN. It
NEVER changes.
I think that these 3 statements sum up the whole argument. I find it
hard to disagree
Quoting Doug Ledford [EMAIL PROTECTED]:
Subject: Re: RFC OFED-1.3 installation
On Tue, 2007-07-17 at 19:45 +0300, Michael S. Tsirkin wrote:
Quoting Doug Ledford [EMAIL PROTECTED]:
Subject: Re: RFC OFED-1.3 installation
On Tue, 2007-07-17 at 19:27 +0300, Michael S. Tsirkin wrote:
On Tue, 2007-07-17 at 20:12 +0300, Michael S. Tsirkin wrote:
Look, rpms are just like versioned tarballs. Once they go out in the
wild, that particular name-version-release combination is FROZEN.
It really looks like this is a work around for when you want to apply
a patch without going
There are lots of things that we as a distributor have to care about
that upstream generally does not. The spec file and patches are how we
solve our customer's problems. They are what make a stable
distribution, as opposed to a bleeding edge, must always update to
latest upstream version
It seems to me that this is all stemming from the same old fundamental
confusion between a release and a distribution. I think everyone
would be better served by a process where individual maintainers were
responsible for releasing tarballs of their packages, with schedules
coordinated toward an
On Tue, 2007-07-17 at 18:36 +0300, Vladimir Sokolovsky wrote:
[ snip ]
Let me copy and paste an email conversation I had with Or that
highlights why this is broken:
--- Begin cut-n-paste
On Mon, 2007-07-02 at 22:25 +0300, Or Gerlitz wrote:
[sorry for breaking the thread, I am
I think everyone
would be better served by a process where individual maintainers were
responsible for releasing tarballs of their packages, with schedules
coordinated toward an overall openfabrics release
For what it's worth, I agree with this approach.
- Sean
Sean Hefty wrote:
I do have a task item to add QoS to the kernel stack as part of my PathForward
work. I believe that we need a discussion on the list regarding the best
approach before starting work on this, however, because of IBTA rules, I haven't
started the discussion.
I understand
So you need to be able to
tell the difference between a customer running libibverbs-1.0.4 from
OFED-1.3-beta1 and libibverbs-1.0.4 from OFED-1.3 final.
I don't really think we want customers to run beta code, or intend to support
such configurations.
--
MST
So you need to be able to
tell the difference between a customer running libibverbs-1.0.4 from
OFED-1.3-beta1 and libibverbs-1.0.4 from OFED-1.3 final.
I don't really think we want customers to run beta code, or
intend to support
such configurations.
But we still need to tell the
I don't really think we want customers to run beta code
What's the point of a beta then??
Donnu.
In previous OFED releases, we had release candidates rather
than beta.
Openfabrics members were running RCs and reporting issues on
the list and in
bugzilla. Do you really ask your
Hi Tziporet,
On 7/16/07, Tziporet Koren [EMAIL PROTECTED] wrote:
Hi All,
We have our OFED synch meeting today at 9am PST.
Agenda:
1. Merge the OFED 1.2.1 release with OFED 1.2.c release in August.
2. Agree on OFED 1.3 schedule:
* Feature freeze - Sep 4
* Alpha release - Sep
I think it's easy enough to make the revision of the RPMS be something
like -0.1.2007-07-17.1 or something like that.
OK, so you say just ignore the content and stick a date in there?
Fine, that'll work, and we can cover the RCs this way too I think.
I just meant to add a revision
Hi Tziporet,
On 7/17/07, Tziporet Koren [EMAIL PROTECTED] wrote:
*OFED July 16 meeting summary*
*1. Merge the OFED 1.2.1 release with OFED 1.2.c release in August. *
There was a long discussion on pros cons regarding merging the two
releases.
Pros:
- Everybody will be focused on the same
On Wed, 2007-07-18 at 00:09 +0300, Michael S. Tsirkin wrote:
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [ofa-general] Re: RFC OFED-1.3 installation
I don't really think we want customers to run beta code
What's the point of a beta then??
Donnu.
In previous OFED
19 matches
Mail list logo
