[ewg] Re: [ofa-general] Re: RFC OFED-1.3 installation
On Wed, 2007-07-18 at 07:31 +0300, Michael S. Tsirkin wrote:
> Thanks for the script.
> In OFED, since we control the upstream, I think we'll try to do
> as much as possible at the package level, for example make sure
> that each package has a reasonable spec file.
> Some ideas on how we might want to do this below.
>
> > #!/bin/bash
> >
> > usage() {
> > echo "$0 repo daily | release [ signed | ]"
> > echo
> > echo " You must specify the repo to make a distribution tarball in.
> > This"
> > echo "script will not work with complex repos like the management repo that"
> > echo "builds more than one package. It expects a repo to be a single
> > package"
> > echo "repo where the directory name and the package name are the same, and"
> > echo "where a properly formatted reponame.spec.in file exists."
> > echo
> > echo " You must specify either release or daily in order for this
> > script"
> > echo "to make tarballs. If this is a daily release, the tarballs will"
> > echo "be named -git.tgz and will overwrite existing tarballs."
> > echo "If this is a release build, then the tarball will be named"
> > echo "-.tgz and must be a new file. In addition,"
> > echo "the script will add a new set of symbolic tags to the git repo"
> > echo "that correspond to the - of each tarball."
> > echo
> > echo " If the script detects that the tag on any component already
> > exists,"
> > echo "it will abort the release and prompt you to update the version on"
> > echo "the already tagged component. This enforces the proper behavior of"
> > echo "treating any released tarball as set in stone so that in the future"
> > echo "you will always be able to get to any given release tarball by"
> > echo "checking out the git tag and know with certainty that it is the same"
> > echo "code as released before even if you no longer have the same tarball"
> > echo "around."
> > echo
> > echo " As part of this process, the script will parse the
> > .spec.in"
> > echo "file and output a .spec file. Since this script isn't smart"
> > echo "enough to deal with other random changes that should have their own"
> > echo "checkin the script will refuse to run if the current repo state is
> > not"
> > echo "clean."
> > echo
> > echo " NOTE: the script has no clue if you are tagging on the right
> > branch,"
> > echo "it will however show you the git branch output so you can confirm it"
> > echo "is on the right branch before proceeding with the release."
> > echo
> > echo " In addition to just tagging the git repo, whenever creating a
> > release"
> > echo "there is an optional argument of either signed or a hex gpg key-id."
> > echo "If you do not pass an argument to release, then the tag will be a"
> > echo "simple git annotated tag. If you pass signed as the argument, the"
> > echo "git tag operation will use your default signing key to sign the tag."
> > echo "Or you can pass an actual gpg key id in hex format and git will sign"
> > echo "the tag with that key."
> > echo
> > }
> >
> > if [ -z "$1" -o -z "$2" ]; then usage; exit 1; fi
> >
> > if [ ! -d "$1" ]; then usage; exit 1; fi
> >
> > TMPDIR=dist
> > if [ ! -d $TMPDIR ]; then mkdir $TMPDIR; fi
> >
> > if [ "$2" = "daily" -o "$2" = "release" ]; then
> > if [ ! -f $TMPDIR/$1-$2.HEAD ]; then
> > touch $TMPDIR/$1-$2.HEAD
> > fi
> > NEWHEAD=`cat $TMPDIR/$1-$2.HEAD`
> > else
> > usage
> > exit 1
> > fi
> >
> > cd "$1"
> > echo "Updating git repo..."
> > git pull
> > RESULT=$?
> > HEAD=`git log --pretty=oneline -1`
> >
> > if [ "$RESULT" -ne 0 ]; then
> > echo "Failed to update the git repo cleanly, manual intervention
> > required"
> > exit 1
> > fi
>
> pull really will merge your local modifications with upstream.
> In OFED we really want just git clone, and use upstream code unmodified.
That depends on how you have your repos set up. I keep separate repos
for tracking upstream and for doing local work. You can run this on
either repo, and it will either give you a clean upstream copy or your
local copy merged up to date (assuming you are on a branch that merges
from upstream, otherwise if you are on a local branch, the pull will
update the repo, but not your checked out files).
This script is a little schitzophrenic at the moment because it acts
like it's both a customer of the git repo and a master of the git repo.
In truth, the release part of the script was only ever intended to be
used by a maintainer in a clean master repo. The daily part of the
script can be used by anyone who wants to spit out quick daily builds.
But, if you are a consumer of the repo instead of the maintainer, then
for the daily builds you need to update the repo.
So, in short, the daily part is usable by anyone tracking development of
any repo and will pull from the upstream repo to keep up to date. The
release functionality should only be used by maintainers, and then only
in their master repo. Make more sense tha
[ewg] Re: [ofa-general] Re: RFC OFED-1.3 installation
> Quoting Doug Ledford <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] Re: RFC OFED-1.3 installation
>
> On Wed, 2007-07-18 at 05:18 +0300, Michael S. Tsirkin wrote:
> > > Quoting Doug Ledford <[EMAIL PROTECTED]>:
> > > Subject: Re: [ofa-general] Re: RFC OFED-1.3 installation
> > >
> > > 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 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 customers to do this for you?
> > >
> > > Sure, as much as possible. I generally don't recommend using it in
> > > production, but just as close as they can get to production is fine with
> > > me. The more issues they find while I'm still actually working on it
> > > and making new revisions, the less issues they'll find after I stupidly
> > > think I'm done.
> >
> > So,Roland's idea of sticking a date in RPM revision willwork, won't it?
>
> As long as you don't do two package builds on the same day. That's why
> my script encodes both an increasing number and the date into the
> revision.
>
> For reference, I'll attach the updated script I made for spitting out a
> buildable tarball.
>
> Hehehe...resending because the ofa list server ate my message due to the
> script attachment :-D I'll inline it instead.
>
> I guess I'll also mention that this script exists in my ~/repos/upstream
> directory, and also in that directory are all the git repos that I have
> cloned from ofa (as well as other places). So, it's one level above all
> the various git clones and spits everything out into dist/. The easiest
> way to use this script for any given package you want to create a daily
> snapshot of is to run ./make.dist repodir daily; scp
> dist/repodir-git.tgz dist/repodir-daily.HEAD ofaserver:downloads. That
> simple action would (assuming you create a reasonable reponame.spec.in
> file in the repos that are missing one) spit out a tarball that can be
> passed directly to rpmbuild --rebuild reponame-git.tgz and rpm will spit
> out the packages, and the repodir-daily.HEAD file shows the HEAD of the
> git repo so you know exactly what state the tarball represents and you
> can always get to it in another more recent repo by just updating to
> that commit as head of tree.
Thanks for the script.
In OFED, since we control the upstream, I think we'll try to do
as much as possible at the package level, for example make sure
that each package has a reasonable spec file.
Some ideas on how we might want to do this below.
> #!/bin/bash
>
> usage() {
> echo "$0 repo daily | release [ signed | ]"
> echo
> echo "You must specify the repo to make a distribution tarball in.
> This"
> echo "script will not work with complex repos like the management repo that"
> echo "builds more than one package. It expects a repo to be a single package"
> echo "repo where the directory name and the package name are the same, and"
> echo "where a properly formatted reponame.spec.in file exists."
> echo
> echo "You must specify either release or daily in order for this
> script"
> echo "to make tarballs. If this is a daily release, the tarballs will"
> echo "be named -git.tgz and will overwrite existing tarballs."
> echo "If this is a release build, then the tarball will be named"
> echo "-.tgz and must be a new file. In addition,"
> echo "the script will add a new set of symbolic tags to the git repo"
> echo "that correspond to the - of each tarball."
> echo
> echo "If the script detects that the tag on any component already
> exists,"
> echo "it will abort the release and prompt you to update the version on"
> echo "the already tagged component. This enforces the proper behavior of"
> echo "treating any released tarball as set in stone so that in the future"
> echo "you will always be able to get to any given release tarball by"
> echo "checking out the git tag and know with certainty that it is the same"
> echo "code as released before even if you no longer have the same tarball"
> echo "around."
> echo
> echo "As part of this process, the script will parse the
> .spec.in"
> echo "file and output a .spec file. Since this script isn't smart"
> echo "enough to deal with other random changes that should have their own"
> echo "checkin the script will refuse to run if the current repo state is not"
> echo "clean."
> echo
> echo "NOTE: the script has no clue if you are tagging on the right
> branch,"
> echo "it will however show you the git branch output so you can confirm it"
> echo "is on the right branch before proceeding with the relea
[ewg] Re: [ofa-general] Re: RFC OFED-1.3 installation
On Wed, 2007-07-18 at 05:18 +0300, Michael S. Tsirkin wrote:
> > Quoting Doug Ledford <[EMAIL PROTECTED]>:
> > Subject: Re: [ofa-general] Re: RFC OFED-1.3 installation
> >
> > 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 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 customers to do this for you?
> >
> > Sure, as much as possible. I generally don't recommend using it in
> > production, but just as close as they can get to production is fine with
> > me. The more issues they find while I'm still actually working on it
> > and making new revisions, the less issues they'll find after I stupidly
> > think I'm done.
>
> So,Roland's idea of sticking a date in RPM revision willwork, won't it?
As long as you don't do two package builds on the same day. That's why
my script encodes both an increasing number and the date into the
revision.
For reference, I'll attach the updated script I made for spitting out a
buildable tarball.
Hehehe...resending because the ofa list server ate my message due to the
script attachment :-D I'll inline it instead.
I guess I'll also mention that this script exists in my ~/repos/upstream
directory, and also in that directory are all the git repos that I have
cloned from ofa (as well as other places). So, it's one level above all
the various git clones and spits everything out into dist/. The easiest
way to use this script for any given package you want to create a daily
snapshot of is to run ./make.dist repodir daily; scp
dist/repodir-git.tgz dist/repodir-daily.HEAD ofaserver:downloads. That
simple action would (assuming you create a reasonable reponame.spec.in
file in the repos that are missing one) spit out a tarball that can be
passed directly to rpmbuild --rebuild reponame-git.tgz and rpm will spit
out the packages, and the repodir-daily.HEAD file shows the HEAD of the
git repo so you know exactly what state the tarball represents and you
can always get to it in another more recent repo by just updating to
that commit as head of tree.
#!/bin/bash
usage() {
echo "$0 repo daily | release [ signed | ]"
echo
echo " You must specify the repo to make a distribution tarball in. This"
echo "script will not work with complex repos like the management repo that"
echo "builds more than one package. It expects a repo to be a single package"
echo "repo where the directory name and the package name are the same, and"
echo "where a properly formatted reponame.spec.in file exists."
echo
echo " You must specify either release or daily in order for this script"
echo "to make tarballs. If this is a daily release, the tarballs will"
echo "be named -git.tgz and will overwrite existing tarballs."
echo "If this is a release build, then the tarball will be named"
echo "-.tgz and must be a new file. In addition,"
echo "the script will add a new set of symbolic tags to the git repo"
echo "that correspond to the - of each tarball."
echo
echo " If the script detects that the tag on any component already exists,"
echo "it will abort the release and prompt you to update the version on"
echo "the already tagged component. This enforces the proper behavior of"
echo "treating any released tarball as set in stone so that in the future"
echo "you will always be able to get to any given release tarball by"
echo "checking out the git tag and know with certainty that it is the same"
echo "code as released before even if you no longer have the same tarball"
echo "around."
echo
echo " As part of this process, the script will parse the .spec.in"
echo "file and output a .spec file. Since this script isn't smart"
echo "enough to deal with other random changes that should have their own"
echo "checkin the script will refuse to run if the current repo state is not"
echo "clean."
echo
echo " NOTE: the script has no clue if you are tagging on the right branch,"
echo "it will however show you the git branch output so you can confirm it"
echo "is on the right branch before proceeding with the release."
echo
echo " In addition to just tagging the git repo, whenever creating a release"
echo "there is an optional argument of either signed or a hex gpg key-id."
echo "If you do not pass an argument to release, then the tag will be a"
echo "simple git annotated tag. If you pass signed as the argument, the"
echo "git tag operation will use your default signing key to sign the tag."
echo "Or you can pass an actual gpg key id in hex format and git will sign"
echo "the tag with that key."
echo
}
if [ -z "$1" -o -z "$2" ]; then usage; exit 1; fi
if [ ! -d "$1" ]; then usage;
[ewg] Re: [ofa-general] Re: RFC OFED-1.3 installation
On Wed, 2007-07-18 at 05:18 +0300, Michael S. Tsirkin wrote: > > Quoting Doug Ledford <[EMAIL PROTECTED]>: > > Subject: Re: [ofa-general] Re: RFC OFED-1.3 installation > > > > 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 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 customers to do this for you? > > > > Sure, as much as possible. I generally don't recommend using it in > > production, but just as close as they can get to production is fine with > > me. The more issues they find while I'm still actually working on it > > and making new revisions, the less issues they'll find after I stupidly > > think I'm done. > > So,Roland's idea of sticking a date in RPM revision willwork, won't it? As long as you don't do two package builds on the same day. That's why my script encodes both an increasing number and the date into the revision. For reference, I'll attach the updated script I made for spitting out a buildable tarball. -- Doug Ledford <[EMAIL PROTECTED]> GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband make.dist Description: application/shellscript 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
[ewg] Re: [ofa-general] Re: RFC OFED-1.3 installation
> Quoting Doug Ledford <[EMAIL PROTECTED]>: > Subject: Re: [ofa-general] Re: RFC OFED-1.3 installation > > 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 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 customers to do this for you? > > Sure, as much as possible. I generally don't recommend using it in > production, but just as close as they can get to production is fine with > me. The more issues they find while I'm still actually working on it > and making new revisions, the less issues they'll find after I stupidly > think I'm done. So,Roland's idea of sticking a date in RPM revision willwork, won't it? -- MST ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] Re: RFC OFED-1.3 installation
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 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 customers to do this for you? Sure, as much as possible. I generally don't recommend using it in production, but just as close as they can get to production is fine with me. The more issues they find while I'm still actually working on it and making new revisions, the less issues they'll find after I stupidly think I'm done. -- 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
[ewg] Re: RFC OFED-1.3 installation
On Tue, 2007-07-17 at 23:27 +0300, Michael S. Tsirkin wrote: > > 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. It's not so much whether you want them to or not. If you make it available, some of them *will* run it. Not necessarily in production, but still run it none the less. You need to be able to tell the difference. And they need to be able to tell the difference. What if they installed it to test and provide feedback to you, but then because the version numbers weren't distinct, and they forgot just which machines they put it in, *they* no longer knew which was the beta/rc code or the final release? -- 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] OFED July 16 meeting summary
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 release - All user space libs (except for the new libmlx4) are the same - Reduce QA efforts Cons: - The kernel was changed to 2.6.22 based and this can cause instability. - Harder to distinguish what are the differences between 1.2 to 1.2.c. (since its not only few patches) - 1.2.c release was aimed for ConnectX support only. If we lump the two releases together it may slow the convergence of this release. In addition there is a need to check with IBM and Chelsio, who actually asked for the 1.2.1 release, if this suites them. Steve agreed to test 1.2.c to see if its OK with his fixes. Need a respond from IBM too. (BTW - no patches from IBM were sent so far.) Decision: No decision was taken. I suggest we stay with two different branches for now. After more people will test 1.2.c and see if its stable enough we can decide not to do 1.2.1 *2. Agree on OFED 1.3 schedule: *The suggested schedule:* ** Feature freeze - Sep 4 * Alpha release - Sep 10 * Beta release - Sep 25 * RC1 - Oct 16 * RC2 - Oct 30 * RC3 - Nov 8 (assuming many of us are at SC07 on the week of Nov 11) * RC4 - Nov 20 * GA release - Nov 30 (or first week of Dec) Discussion: - Due to the 1.2.c release the schedule seems very tight. - Since 1.2.c progress only the kernel, many user level features that are already done are not exposed to customers in OFED release. Decision: Revisit the schedule on September according to the "must have" features readiness. *3. Review OFED 1.3 features list: * There was an agreement on the must have features, except QoS that should be defined after IBTA SPEC is published We have not reviewed the list of features thoroughly. Each company should review the features and send comments to the list. Must have general features: - Kernel base on 2.6.23 (all new features that will be part of this kernel will be included in OFED 1.3) - Install: - Break the packages RPMs (work with Novell and Redhat) to minimize integration effort into OS distribution - Package: - Sources arrangement for the end user (for the labs) - New HCAs & RNICs: - ConnectX support - Neteffect support - QoS: OSM, CM, CMA, ULPs (IPoIB, SDP, SRP) Other features (must have marked with *) == - libibverbs: New verbs: - Scalable Reliable Connected Transport (with Mellanox ConnectX)* - Reliable Multicast? ULPs: - IPoIB: - Performance improvements (those that will be stable on time) - NAPI - done - SDP: - * Keepalive - * AIO - uDAPL: - DAT 2.0 support with IB extensions for immediate data, atomics; - Add extensions for new verbs (SRCT,RM) - VNIC: - GA quality. Not a technology preview version anymore. - Added support for QLogic EVIC (10 Gbps Infiniband-to-Ethernet gateway) - in GA - RDS: RDMA API (using FMRs); GA quality with Oracle 11 - NFSoRDMA integration - pending we have a maintainer - Management: - * Multiple partitions via libibumad - OpenSM - More routing performance improvements - done - Even more speedups - done - Better packaging/installation - done - "Native" daemon mode - done - * Performance management - * Quality of Service manager: Based on IBTA annex - Enhancements for fat tree routing (non pure tree support) - done - More console commands and telnet access to console - done - More diagnostics - ibidsverify.pl: validate LIDs and GUIDs in subnet - done - Updated ibnetdiscover format with link width and speed, and GUIDs - done - ibnetdiscover grouping support for new Voltaire chassis - done - diag updates for IB router support - done - iblinkinfo.pl: Support peer port link width and speed validation - done - ibdatacounters: Add script and man page for subnet wide data counters saquery enhancements - done What happened to ibsim ? It was on the list I sent. Is there any reason it can't be included ? Thanks. -- Hal iWARP: - - * Chelsio: Get to GA level - NetEffect: Get the drivers into OFED ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] Re: RFC OFED-1.3 installation
> > 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 that encodes the daily build if you want to do daily builds. So you could have libibverbs RPMs with version 1.1.2-0.1.2007-07-17.1 or whatever, and then do 1.1.2-0.2.beta1 and 1.1.2-1 final. - R. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] Re: RFC OFED-1.3 installation
> But daily ... we don't want to increment a revision on each change, do we? 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. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Agenda for OFED meeting today
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 10 * Beta release - Sep 25 * RC1 - Oct 16 * RC2 - Oct 30 * RC3 - Nov 8 (assuming many of us are at SC07 on the week of Nov 11) * RC4 - Nov 20 * GA release - Nov 30 (or first week of Dec) 3. Review OFED 1.3 features list: In last meeting we decided that the schedule is one of the most important parameters in OFED 1.3. Thus I divided the features for two categories: - "must have" features - features that must be ready for the release (marked with *) - "optional" features - features that can be included in the release in case they are ready according to the schedule Must have general features: - Kernel base on 2.6.23 (all new features that will be part of this kernel will be included in OFED 1.3) - Install: - Break the packages RPMs (work with Novell and Redhat) to minimize integration effort into OS distribution - Package: - Sources arrangement for the end user (for the labs) - New HCAs & RNICs: - ConnectX support - Any other new HW? - QoS: OSM, CM, CMA, ULPs (IPoIB, SDP, SRP) Other features (must have marked with *) == - libibverbs: New verbs: - Scalable Reliable Connected Transport (with Mellanox ConnectX)* - Reliable Multicast? ULPs: - IPoIB: - Performance improvements (those that will be stable on time) - NAPI - done - SDP: - * Keepalive - * AIO - uDAPL: - DAT 2.0 support with IB extensions for immediate data, atomics; - Add extensions for new verbs (SRCT,RM) - VNIC: - GA quality. Not a technology preview version anymore. - Added support for QLogic EVIC (10 Gbps Infiniband-to-Ethernet gateway) - in GA - RDS: RDMA API (using FMRs); GA quality with Oracle 11 - NFSoRDMA integration - pending we have a maintainer - Management: - * Multiple partitions via libibumad - OpenSM - More routing performance improvements - done - Even more speedups - done - Better packaging/installation - done - "Native" daemon mode - done - * Performance management - * Quality of Service manager: Based on IBTA annex - Enhancements for fat tree routing (non pure tree support) - done - More console commands and telnet access to console - done - More diagnostics - ibidsverify.pl: validate LIDs and GUIDs in subnet - done - Updated ibnetdiscover format with link width and speed, and GUIDs - done - ibnetdiscover grouping support for new Voltaire chassis - done - diag updates for IB router support - done - iblinkinfo.pl: Support peer port link width and speed validation - done - ibdatacounters: Add script and man page for subnet wide data counters saquery enhancements - done What happened to ibsim ? I thought that was on the list I originally sent. -- Hal - iWARP: - * Chelsio: Get to GA level - NetEffect: Get the drivers into OFED Tziporet Koren Software Director Mellanox Technologies mailto: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Tel +972-4-9097200, ext 380 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] Re: RFC OFED-1.3 installation
> Quoting Roland Dreier <[EMAIL PROTECTED]>: > Subject: Re: [ofa-general] Re: RFC OFED-1.3 installation > > > But daily ... we don't want to increment a revision on each change, do we? > > 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. -- MST ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] Re: RFC OFED-1.3 installation
> Quoting Scott Weitzenkamp (sweitzen) <[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 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 customers to do this for you? > > You say toMAYto, I say toMAHto. > > We had many customers running various OFED 1.2 pre-GA builds for > testing, sometimes we had to use a daily build because of certain bug > fixes. OK then, I guess we could try to make it easy to switch between RCs. But daily ... we don't want to increment a revision on each change, do we? Maybe a nonstandard way like ofedinfo is enough for these testing setups? -- MST ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] 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 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 customers to do this for you? You say toMAYto, I say toMAHto. We had many customers running various OFED 1.2 pre-GA builds for testing, sometimes we had to use a daily build because of certain bug fixes. Scott ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] Re: RFC OFED-1.3 installation
> Quoting Scott Weitzenkamp (sweitzen) <[EMAIL PROTECTED]>: > Subject: RE: [ofa-general] Re: RFC OFED-1.3 installation > > > > 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 difference, so we can tell the customer > they are running beta code and should upgrade. Sure, this makes sense. Non-release code such as nightly builds must be marked as suchas clearly as possible. Installing such a version will always have an element of risk in it, though, and I don't think we want to encourage such use in production environment. -- MST ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] Re: RFC OFED-1.3 installation
> 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 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 customers to do this for you? -- MST ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] 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?? - R. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] RE: [ofa-general] Re: RFC OFED-1.3 installation
> > 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 difference, so we can tell the customer they are running beta code and should upgrade. Scott ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: RFC OFED-1.3 installation
> 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 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] OFED July 16 meeting summary
*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 release - All user space libs (except for the new libmlx4) are the same - Reduce QA efforts Cons: - The kernel was changed to 2.6.22 based and this can cause instability. - Harder to distinguish what are the differences between 1.2 to 1.2.c. (since its not only few patches) - 1.2.c release was aimed for ConnectX support only. If we lump the two releases together it may slow the convergence of this release. In addition there is a need to check with IBM and Chelsio, who actually asked for the 1.2.1 release, if this suites them. Steve agreed to test 1.2.c to see if its OK with his fixes. Need a respond from IBM too. (BTW - no patches from IBM were sent so far.) Decision: No decision was taken. I suggest we stay with two different branches for now. After more people will test 1.2.c and see if its stable enough we can decide not to do 1.2.1 *2. Agree on OFED 1.3 schedule: *The suggested schedule:* ** Feature freeze - Sep 4 * Alpha release - Sep 10 * Beta release - Sep 25 * RC1 - Oct 16 * RC2 - Oct 30 * RC3 - Nov 8 (assuming many of us are at SC07 on the week of Nov 11) * RC4 - Nov 20 * GA release - Nov 30 (or first week of Dec) Discussion: - Due to the 1.2.c release the schedule seems very tight. - Since 1.2.c progress only the kernel, many user level features that are already done are not exposed to customers in OFED release. Decision: Revisit the schedule on September according to the "must have" features readiness. *3. Review OFED 1.3 features list: * There was an agreement on the must have features, except QoS that should be defined after IBTA SPEC is published We have not reviewed the list of features thoroughly. Each company should review the features and send comments to the list. Must have general features: * Kernel base on 2.6.23 (all new features that will be part of this kernel will be included in OFED 1.3) * Install: o Break the packages RPMs (work with Novell and Redhat) to minimize integration effort into OS distribution * Package: o Sources arrangement for the end user (for the labs) * New HCAs & RNICs: o ConnectX support o Neteffect support * QoS: OSM, CM, CMA, ULPs (IPoIB, SDP, SRP) Other features (must have marked with *) == * libibverbs: New verbs: o Scalable Reliable Connected Transport (with Mellanox ConnectX)* o Reliable Multicast? ULPs: * IPoIB: o Performance improvements (those that will be stable on time) o NAPI - done * SDP: o * Keepalive o * AIO * uDAPL: o DAT 2.0 support with IB extensions for immediate data, atomics; o Add extensions for new verbs (SRCT,RM) * VNIC: o GA quality. Not a technology preview version anymore. o Added support for QLogic EVIC (10 Gbps Infiniband-to-Ethernet gateway) - in GA * RDS: RDMA API (using FMRs); GA quality with Oracle 11 * NFSoRDMA integration - pending we have a maintainer * Management: o * Multiple partitions via libibumad o OpenSM + More routing performance improvements - done + Even more speedups - done + Better packaging/installation - done + "Native" daemon mode - done + * Performance management + * Quality of Service manager: Based on IBTA annex + Enhancements for fat tree routing (non pure tree support) - done + More console commands and telnet access to console - done o More diagnostics + ibidsverify.pl: validate LIDs and GUIDs in subnet - done + Updated ibnetdiscover format with link width and speed, and GUIDs - done + ibnetdiscover grouping support for new Voltaire chassis - done + diag updates for IB router support - done + iblinkinfo.pl: Support peer port link width and speed validation - done + ibdatacounters: Add script and man page for subnet wide data counters saquery enhancements - done * iWARP: o * Chelsio: Get to GA level o NetEffect: Get the drivers into OFED ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] Agenda for OFED meeting today
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 that the SPEC should be ready next week (our tech writer is working on it these days). Once its out I hope we can have the public discussions. Additional work is needed in opensm, and those patches were posted on the list a couple of months ago. If someone has kernel patches to support QoS, I'd be interested in seeing them. (Feel free to send them to me directly if they cannot be shared publicly.) Yevgeny is working on opensm QoS now. He updating the changes to the latest OSM code and will resend the patches when they are done. Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] Agenda for OFED meeting today
On 7/17/07, Sean Hefty <[EMAIL PROTECTED]> wrote: >I remember that there was some last minute submission by Michael to be >included as technology-preview-for-demo-purposes-etc, are you referring >to this code? > >My understanding is the that Qos code of the Linux kernel IB stack QoS >code is going to be implemented through the path forward project by Sean >Hefty and that this work has not started yet. 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. Additional work is needed in opensm, and those patches were posted on the list a couple of months ago. There was a subsequent thread on these with questions which are still pending. -- Hal If someone has kernel patches to support QoS, I'd be interested in seeing them. (Feel free to send them to me directly if they cannot be shared publicly.) - Sean ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: RFC OFED-1.3 installation
On Tue, 2007-07-17 at 20:45 +0300, Michael S. Tsirkin wrote: > > 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 to fix any problem" system, a reality. It's the > > difference between RHEL and Fedora. > > I think I am getting it - you want to release a patched version of some OFED > library without going through openfabrics? OK. > So I imagine that's when you would increment the rpm-specific version number. > But I can't see why would an OFED release want to play with these. You don't want to, you *have* to. It's because you are distributing source software packages that build RPMs. And you aren't waiting until OFED is final, you release pre-releases too. 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. In order to do so, they need a different release number because the version number is the same. The only way this changes is if every component of OFED 1.3 releases their final tar.gz file in concert with OFED 1.3. Otherwise, at least *some* items in there will need a bumped release number. Unless of course you are just relying on ofed_info, which as I pointed out in my last email, is a workaround for not doing this. We *won't* use that workaround because having two means to tell the same thing increases our support personnel training costs and makes things more confusing for the customer. We have one tool already, that's good enough. Additionally, once you step into the "create rpms" space, there are only two ways things can go. You can adhere to RPM packaging standards, and your custom built RPMs will peacefully coexist on a system were there are similar RPMs coming from the OS distributor, aka Red Hat. Or, you can do what you've been doing, where RPMs you build don't maintain consistent numbering, and the customer can end up getting screwed when your RPMs and our RPMs collide. It would be careless and reckless to risk customer systems going belly up because your RPM and mine collide in a way that renders the machine dysfunctional. So don't think of it as playing games with bumping release numbers, think of it as finally making OFED RPMs standard compliant so you no longer need the workaround of ofed_info. -- 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
[ewg] RE: [ofa-general] Re: RFC OFED-1.3 installation
On Tue, 2007-07-17 at 11:34 -0700, Sean Hefty wrote: > >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. Ditto. -- 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
[ewg] RE: [ofa-general] Re: RFC OFED-1.3 installation
>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 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] RE: RFC OFED-1.3 installation
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 working from home now and > unable > > to use normal mailer.] > > > > > > > Let me give an example. In OFED 1.0, you shipped dapl version 1.2. > In > > OFED 1.1, you also shipped dapl version 1.2. However, code inspection > > shows that between OFED 1.0 and OFED 1.1, dapl did in fact change (not > > a lot, but anything is enough). > > I am not suppose to support correct versioning for every package in > OFED. > It should be done by the maintainer of the package. This may be true going forward when you've split all the packages up, but it definitely was *not* true when all the packages where thrown into one huge tarball and built out of one spec file. Since the versioning information was lost when that tarball was recreated over and over again, versioning responsibility necessarily fell back upon the spec file. > > The only reason that the OFED distribution has *ever* reliably > > installed the rpms you wanted installed is because you compile things > > locally and then *force* the upgrade of rpms over the top of older > rpms > > that have the same version number. And even then, you yourselves > can't > > tell the difference between a customer with the OFED 1.0 or OFED 1.1 > > dapl installed by checking the RPM version, you just have to go off > > what the end user *tells* you he installed and hope he's right. > > > > OFED does not force an upgrade, it simply removes the previous version > and then installs the new one. From the viewpoint of proper upgrades, there is no difference. Removing and then installing is just a work around for broken upgrades. > This is why package versioning does not affect OFED installation. Right, you guys did things in a way that allowed you to not care about something that any distributor *must* care about. > I agree that it is different for Linux Distributions Open Fabrics Enterprise Distribution > and should be fixed > for OFED-1.3 but it should > be under responsibility of package maintainer. The maintainer of any given software is responsible for their tarballs. The maintainer of any given rpm is responsible for their spec file and rpms. If a person takes on both roles, like Roland does, then they handle both roles and the roles mostly merge into one. But whenever someone other than the project maintainer decides to be the package maintainer, they are different roles and each is responsible for their own versioning requirements. > So, all RPM spec files should be fixed for OFED-1.3 and properly > maintained. > We should discuss the kernel-ib package structure and its spec file. > > > And I have to *know* what software my customer is running in order to > > support them. Because you guys have done things the way you have, I > > can't know that. I might be able to know if I could also guarantee > > they didn't download and locally compile your packages, but if they > > did, then the same version number of RPM can mean two different things > > entirely depending on whether it's your RPM or mine. > > > > You can easily check if there OFED installation by running 'ofed_info'. No, you can't. At least not on any system running our packages. We don't, and won't, include anything like ofed_info in our distribution. We have one tool, and only one, that we use to tell what software a system is running: rpm. We will not include things like ofed_info just to find out what rpm should, if used properly, already tell us. That would be unnecessary duplication and results in all sorts of support problems when you start needing to be able to tell customers to use multiple different tools to try and figure out what one tool should be able to tell them. > > > I posted links to a wealth of valuable information on the topic of > > making a proper spec file and creating *good* packages during my talk > > at Sonoma. I gather you haven't read those or you never would have > > suggested the above for creating the RPMs. > > > > I just looked into your presentation from Sonoma. You providing there an > example > of management package and your make.dist script for creating daily > builds and releases. > > I have a some questions about this script: > ... > 59 VERSION=`grep "AC_INIT.*$target" $target/configure.in | cut > -f 2 -d ',' | sed -e 's/ //g'` > ... > 97 DATE=`date +%Y%m%d` > 98 if [ -f $TMPDIR/$target.release ]; then > 99 RELEASE=`cat $TMPDIR/$target.release` > 100 RELEASE=`expr $RELEASE + 1` > 101 else > 102 RELEASE=1 > 103 fi > 104 echo $RELEASE > $TMPDIR/$target.release > 105
RE: [ewg] Re: [ofa-general] Agenda for OFED meeting today
>I remember that there was some last minute submission by Michael to be >included as technology-preview-for-demo-purposes-etc, are you referring >to this code? > >My understanding is the that Qos code of the Linux kernel IB stack QoS >code is going to be implemented through the path forward project by Sean >Hefty and that this work has not started yet. 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. Additional work is needed in opensm, and those patches were posted on the list a couple of months ago. If someone has kernel patches to support QoS, I'd be interested in seeing them. (Feel free to send them to me directly if they cannot be shared publicly.) - Sean ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] Re: RFC OFED-1.3 installation
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 overall "openfabrics release" (see http://live.gnome.org/TwoPointNineteen for hints about a process that might work), and then an OFED team handled spec files and kernel module packaging for various distros. In this world I would expect Doug could just take tarballs from the openfabrics world and not be bothered by the OFED RPM spec files (unless he wants to use them as a reference). To summarize, there would be two separate "products": - openfabrics release: format: .tar.gz files customers: OFED, Red Hat/Novell/Debian/etc packagers - OFED release: format: .srpm and binary .rpm files customers: end users who need newer drivers than their distribution includes - R. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: RFC OFED-1.3 installation
> 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 to fix any problem" system, a reality. It's the > difference between RHEL and Fedora. I think I am getting it - you want to release a patched version of some OFED library without going through openfabrics? OK. So I imagine that's when you would increment the rpm-specific version number. But I can't see why would an OFED release want to play with these. -- MST ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: RFC OFED-1.3 installation
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 through maintainer. Not really. When you have a customer with a sev 1 issue, you don't wait for upstream to release a new version of gcc before you get them their fix. There are also those times when you have an older, long released product that isn't up to date with upstream, for instance RHEL4 mdadm is 1.12.0 and will not be updated to the 2.6.2 version that's in Fedora. If I find a bug in that 1.12.0 version of mdadm, then I'll fix it using a patch in the spec file. If the bug also exists in upstream then it will get sent upstream to be included in the latest upstream release. But, upstream won't care about version 1.12.0, and they won't release a new version 1 mdadm just for our bugfix, so we carry those targeted fixes around as long as we have that version 1 mdadm on systems. There are other reasons to do this as well, for instance when you need to make a change as part of package integration that simply isn't needed or wanted upstream. For example, many times upstream couldn't care less about patches that implement our particular file system layout for a package. 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 to fix any problem" system, a reality. It's the difference between RHEL and Fedora. > The way OFED release process works, we really don't > do releases all that often, and when we do, we can coordinate with > the maintainer. -- 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
[ewg] Re: RFC OFED-1.3 installation
> 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: > > > > > 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: > > > > > > > Let me give an example. In OFED 1.0, you shipped dapl version > > > > > > > 1.2. In > > > > > > > OFED 1.1, you also shipped dapl version 1.2. However, code > > > > > > > inspection > > > > > > > shows that between OFED 1.0 and OFED 1.1, dapl did in fact change > > > > > > > (not a > > > > > > > lot, but anything is enough). So, between OFED 1.0 and OFED 1.1, > > > > > > > you > > > > > > > have two different versions of dapl, but with exactly the same > > > > > > > version > > > > > > > number. A person can't tell them apart. > > > > > > > > > > > > Yes, this sure looks like a problem. I think that versioning needs > > > > > > to be addressed > > > > > > at the package level, not at OFED level though. Right? > > > > > > > > > > Versioning needs to be addressed at both levels. You need versions of > > > > > software to start with, but then you still need releases of packages > > > > > to > > > > > differentiate between different builds of a specific version of > > > > > software. > > > > > > > > Why would we want to have different builds of a specific version of > > > > software > > > > for a specific OS? Could you give an example pls? > > > > > > It's how you integrate needed patches immediately while waiting on the > > > next release of the software. > > > > OK. > > > > > ... > > > You also bump the release number of the package any time you make > > > changes to the spec file and rebuild. > > > > Since we have spec files as part of package, this will be really > > the same as the previous case, right? > > Depends. Right now the spec file gets its version out of the configure > stuff. That version only updates when you update the version of the > software itself. It doesn't increment on each change to the source > repo, only on the major updates when you would release a new tarball > anyway. Package versioning is, by necessity, finer grained than source > repo versioning. You don't release a new dapl tarball just because you > updated some comments to remove a typo. But you *do* update rpm > versions on every single change, at least if you are going to distribute > the rpm. > > 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 through maintainer. The way OFED release process works, we really don't do releases all that often, and when we do, we can coordinate with the maintainer. -- MST ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: RFC OFED-1.3 installation
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 with them. :-) -- Jeff Squyres Cisco Systems ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] 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:
> > > > 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:
> > > > > > Let me give an example. In OFED 1.0, you shipped dapl version 1.2.
> > > > > > In
> > > > > > OFED 1.1, you also shipped dapl version 1.2. However, code
> > > > > > inspection
> > > > > > shows that between OFED 1.0 and OFED 1.1, dapl did in fact change
> > > > > > (not a
> > > > > > lot, but anything is enough). So, between OFED 1.0 and OFED 1.1,
> > > > > > you
> > > > > > have two different versions of dapl, but with exactly the same
> > > > > > version
> > > > > > number. A person can't tell them apart.
> > > > >
> > > > > Yes, this sure looks like a problem. I think that versioning needs to
> > > > > be addressed
> > > > > at the package level, not at OFED level though. Right?
> > > >
> > > > Versioning needs to be addressed at both levels. You need versions of
> > > > software to start with, but then you still need releases of packages to
> > > > differentiate between different builds of a specific version of
> > > > software.
> > >
> > > Why would we want to have different builds of a specific version of
> > > software
> > > for a specific OS? Could you give an example pls?
> >
> > It's how you integrate needed patches immediately while waiting on the
> > next release of the software.
>
> OK.
>
> > ...
> > You also bump the release number of the package any time you make
> > changes to the spec file and rebuild.
>
> Since we have spec files as part of package, this will be really
> the same as the previous case, right?
Depends. Right now the spec file gets its version out of the configure
stuff. That version only updates when you update the version of the
software itself. It doesn't increment on each change to the source
repo, only on the major updates when you would release a new tarball
anyway. Package versioning is, by necessity, finer grained than source
repo versioning. You don't release a new dapl tarball just because you
updated some comments to remove a typo. But you *do* update rpm
versions on every single change, at least if you are going to distribute
the rpm.
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. Changing the code underlying that particular
name-version-release is just as bad as the whole Linus scenario I
described. We couldn't stay in business if we let that happen, period.
That's why we have the guidelines that we do for package versioning.
If you need daily builds, there is a way to make that happen that
preserves the upgrade process and preserves unique name-version-release
combinations. In that case, you would use the daily feature of that
script I wrote. It spits out a tarball named package-git.tar.gz. The
-git nomenclature clearly identifies that this is *not* a versioned
tarball and it is *not* required to stay the same. You could put a date
or head tag on the name as well if you want to make it unique. I didn't
do that because then the daily git tarballs take up *way* too much space
in our SCM repo. Then, you name the package
name-version-0.release.git${DATE}
This way, each daily build has a unique name. You increment the release
number with each daily build, and the date tag allows you to see at a
glance what date of pull the release goes with. Once the software has
reached maturity, you simply pull the final name-version.tar.gz tarball
and update the spec to be name-version-1 and it automatically compares
as newer than the daily builds and upgrades. Then subsequent rpm builds
from that official release version start incrementing the release number
like normal.
--
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
[ewg] Re: RFC OFED-1.3 installation
> 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: > > > > > Let me give an example. In OFED 1.0, you shipped dapl version 1.2. > > > > > In > > > > > OFED 1.1, you also shipped dapl version 1.2. However, code inspection > > > > > shows that between OFED 1.0 and OFED 1.1, dapl did in fact change > > > > > (not a > > > > > lot, but anything is enough). So, between OFED 1.0 and OFED 1.1, you > > > > > have two different versions of dapl, but with exactly the same version > > > > > number. A person can't tell them apart. > > > > > > > > Yes, this sure looks like a problem. I think that versioning needs to > > > > be addressed > > > > at the package level, not at OFED level though. Right? > > > > > > Versioning needs to be addressed at both levels. You need versions of > > > software to start with, but then you still need releases of packages to > > > differentiate between different builds of a specific version of > > > software. > > > > Why would we want to have different builds of a specific version of software > > for a specific OS? Could you give an example pls? > > It's how you integrate needed patches immediately while waiting on the > next release of the software. OK. > ... > You also bump the release number of the package any time you make > changes to the spec file and rebuild. Since we have spec files as part of package, this will be really the same as the previous case, right? -- MST ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] 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:
> > > > Let me give an example. In OFED 1.0, you shipped dapl version 1.2. In
> > > > OFED 1.1, you also shipped dapl version 1.2. However, code inspection
> > > > shows that between OFED 1.0 and OFED 1.1, dapl did in fact change (not a
> > > > lot, but anything is enough). So, between OFED 1.0 and OFED 1.1, you
> > > > have two different versions of dapl, but with exactly the same version
> > > > number. A person can't tell them apart.
> > >
> > > Yes, this sure looks like a problem. I think that versioning needs to be
> > > addressed
> > > at the package level, not at OFED level though. Right?
> >
> > Versioning needs to be addressed at both levels. You need versions of
> > software to start with, but then you still need releases of packages to
> > differentiate between different builds of a specific version of
> > software.
>
> Why would we want to have different builds of a specific version of software
> for a specific OS? Could you give an example pls?
It's how you integrate needed patches immediately while waiting on the
next release of the software. For example, when mdadm-2.6.2.tar.gz was
released, I built an mdadm-2.6.2-1 package (the 1 being the release
number). I then went to work on some mdadm bug reports I had, and I
wrote a number of patches that squashed about 10 bug reports. During
that time, I had three intervening builds as I integrated those patches
into the spec file and applied them to the 2.6.2 base source code during
the build process. Those builds were 2.6.2-{2,3,4}. I also forwarded
those patches upstream, they've been integrated into the upstream code
base, but a 2.6.3 has not yet been released, the upstream maintainer is
waiting until everything he's putting into it settles down. When 2.6.3
is released, then I'll integrate 2.6.3 into our source SCM system, drop
all of the patches that have been integrated into the base 2.6.3 source
code, and build mdadm-2.6.3-1.
The point of all this being that most software maintainers don't release
new versions of their software on a daily or even weekly basis, so when
you are busy fixing up bugs in the software between releases, the
patches go in the spec file and you bump the release number so that each
subsequent build has a unique number that can positively identify both
the base source code used and all patches applied to that source code.
You also bump the release number of the package any time you make
changes to the spec file and rebuild. So, for instance, if the only
change I made to a package was to change the %doc macro in the %files
section, I would still bump the release number and rebuild so that the
new rpm name-version-release combination would uniquely identify the
change.
--
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
[ewg] Re: RFC OFED-1.3 installation
> 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: > > > Let me give an example. In OFED 1.0, you shipped dapl version 1.2. In > > > OFED 1.1, you also shipped dapl version 1.2. However, code inspection > > > shows that between OFED 1.0 and OFED 1.1, dapl did in fact change (not a > > > lot, but anything is enough). So, between OFED 1.0 and OFED 1.1, you > > > have two different versions of dapl, but with exactly the same version > > > number. A person can't tell them apart. > > > > Yes, this sure looks like a problem. I think that versioning needs to be > > addressed > > at the package level, not at OFED level though. Right? > > Versioning needs to be addressed at both levels. You need versions of > software to start with, but then you still need releases of packages to > differentiate between different builds of a specific version of > software. Why would we want to have different builds of a specific version of software for a specific OS? Could you give an example pls? -- MST ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: RFC OFED-1.3 installation
On Tue, 2007-07-17 at 18:25 +0300, Michael S. Tsirkin wrote: > > Let me give an example. In OFED 1.0, you shipped dapl version 1.2. In > > OFED 1.1, you also shipped dapl version 1.2. However, code inspection > > shows that between OFED 1.0 and OFED 1.1, dapl did in fact change (not a > > lot, but anything is enough). So, between OFED 1.0 and OFED 1.1, you > > have two different versions of dapl, but with exactly the same version > > number. A person can't tell them apart. > > Yes, this sure looks like a problem. I think that versioning needs to be > addressed > at the package level, not at OFED level though. Right? Versioning needs to be addressed at both levels. You need versions of software to start with, but then you still need releases of packages to differentiate between different builds of a specific version of software. -- 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
[ewg] RE: RFC OFED-1.3 installation
[ 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 give an example. In OFED 1.0, you shipped dapl version 1.2.
In
> OFED 1.1, you also shipped dapl version 1.2. However, code inspection
> shows that between OFED 1.0 and OFED 1.1, dapl did in fact change (not
> a lot, but anything is enough).
I am not suppose to support correct versioning for every package in
OFED.
It should be done by the maintainer of the package.
> The only reason that the OFED distribution has *ever* reliably
> installed the rpms you wanted installed is because you compile things
> locally and then *force* the upgrade of rpms over the top of older
rpms
> that have the same version number. And even then, you yourselves
can't
> tell the difference between a customer with the OFED 1.0 or OFED 1.1
> dapl installed by checking the RPM version, you just have to go off
> what the end user *tells* you he installed and hope he's right.
>
OFED does not force an upgrade, it simply removes the previous version
and then installs the new one.
This is why package versioning does not affect OFED installation.
I agree that it is different for Linux Distributions and should be fixed
for OFED-1.3 but it should
be under responsibility of package maintainer.
So, all RPM spec files should be fixed for OFED-1.3 and properly
maintained.
We should discuss the kernel-ib package structure and its spec file.
> And I have to *know* what software my customer is running in order to
> support them. Because you guys have done things the way you have, I
> can't know that. I might be able to know if I could also guarantee
> they didn't download and locally compile your packages, but if they
> did, then the same version number of RPM can mean two different things
> entirely depending on whether it's your RPM or mine.
>
You can easily check if there OFED installation by running 'ofed_info'.
> I posted links to a wealth of valuable information on the topic of
> making a proper spec file and creating *good* packages during my talk
> at Sonoma. I gather you haven't read those or you never would have
> suggested the above for creating the RPMs.
>
I just looked into your presentation from Sonoma. You providing there an
example
of management package and your make.dist script for creating daily
builds and releases.
I have a some questions about this script:
...
59 VERSION=`grep "AC_INIT.*$target" $target/configure.in | cut
-f 2 -d ',' | sed -e 's/ //g'`
...
97 DATE=`date +%Y%m%d`
98 if [ -f $TMPDIR/$target.release ]; then
99 RELEASE=`cat $TMPDIR/$target.release`
100 RELEASE=`expr $RELEASE + 1`
101 else
102 RELEASE=1
103 fi
104 echo $RELEASE > $TMPDIR/$target.release
105 RELEASE=0.${RELEASE}.${DATE}git
106 TARBALL=$target-git.tgz
107 fi
...
109 cp -a $target $target-$VERSION
110 sed -e
's/@VERSION@/'$VERSION'/;s/@RELEASE@/'$RELEASE'/;s/@TARBALL@/'$TARBALL'/
' < $target/$target.spec.in > $target-$VERSION/$target.spec
111 cd $target-$VERSION
112 ./autogen.sh
113 cd ..
114 echo "Creating $TMPDIR/$TARBALL"
115 tar -czf $TMPDIR/$TARBALL --exclude=.git $target-$VERSION
I thought that the standard way to get tar.gz file is using autotools (3
commands) like I wrote before:
autogen.sh, configure, make dist.
Can you explain why your way is better?
Do you have a proposal for daily builds? We need OFED daily builds for
verification.
We can't wait for RedHat updates to get the updated OFED packages.
What OFED-1.3 structure do you propose? Should it consist of source RPMs
or tgz files?
What features install script should support?
Regards,
Vladimir
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: RFC OFED-1.3 installation
> Let me give an example. In OFED 1.0, you shipped dapl version 1.2. In > OFED 1.1, you also shipped dapl version 1.2. However, code inspection > shows that between OFED 1.0 and OFED 1.1, dapl did in fact change (not a > lot, but anything is enough). So, between OFED 1.0 and OFED 1.1, you > have two different versions of dapl, but with exactly the same version > number. A person can't tell them apart. Yes, this sure looks like a problem. I think that versioning needs to be addressed at the package level, not at OFED level though. Right? -- MST ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] Agenda for OFED meeting today
Tziporet Koren wrote: 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 goes to OFED. Sp far I have not seen a single email on the list, how you think to meet the Sep 4 FF date? As always all code will be send for review to the public list Regarding schedule: Most of the code is already done for OFED 1.2, but we decided not to push QoS to OFED 1.2 since the SPEC was not complete. code which was not sent to the list is kind of not existing so it can't be "done". I remember that there was some last minute submission by Michael to be included as technology-preview-for-demo-purposes-etc, are you referring to this code? My understanding is the that Qos code of the Linux kernel IB stack QoS code is going to be implemented through the path forward project by Sean Hefty and that this work has not started yet. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] Agenda for OFED meeting today
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 goes to OFED. Sp far I have not seen a single email on the list, how you think to meet the Sep 4 FF date? As always all code will be send for review to the public list Regarding schedule: Most of the code is already done for OFED 1.2, but we decided not to push QoS to OFED 1.2 since the SPEC was not complete. Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: RFC OFED-1.3 installation
All: You may have skipped this mail because of its length. Please read it; Doug lists specific guidelines in here that SRPMs will need to adhere to for RH to include OFED v1.3 (many of the OFED RPMs -- including the OMPI RPM -- do not adhere to these guidelines; we all have work to do). On Jul 16, 2007, at 11:29 PM, Doug Ledford wrote: On Mon, 2007-07-16 at 15:24 +0300, Vladimir Sokolovsky wrote: [ snip ] Most of this proposal was just about splitting the packages up. That's good, but it doesn't warrant much comment. It's not the existence of different packages that will draw my comments, it's the *content* of the packages that will, the actual spec files themselves. However, there is this one tidbit: Source RPMs will be created for each userspace package in the following way: git clone ... autogen.sh configure --disable-libcheck make dist This is so fundamentally broken as to be brain dead. Yet it's what has been done since OFED 1.0. Can you imagine how screwed the open source world would be if one day Linus released kernel-2.6.24.tar.gz on kernel.org, only to silently update the file kernel-2.6.24.tar.gz to something else the next? This is the *ONLY* open source software group I know of that creates new tar.gz files any time they make a change but keeps the version of the file the same. 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.] Does this means that the OFED 1.3 effort is useless from your point of view? Yes and no. The effort to get a complete set of working libraries and stacks pulled together and debugged is good and worthwhile. The packaging has been done all wrong though. Because the ewg has concentrated on supporting local compile installations, they don't really have the faintest clue about several important issues that crop up specifically when you are attempting to support binary distribution instead of source distribution. That in turn has led them to make decisions that have proved to be very counterproductive to my end goal of a supportable environment for my customers. Let me give an example. In OFED 1.0, you shipped dapl version 1.2. In OFED 1.1, you also shipped dapl version 1.2. However, code inspection shows that between OFED 1.0 and OFED 1.1, dapl did in fact change (not a lot, but anything is enough). So, between OFED 1.0 and OFED 1.1, you have two different versions of dapl, but with exactly the same version number. A person can't tell them apart. Furthermore, unless the person is compiling locally, they'll never get the OFED 1.1 dapl installed because RPM/up2date will see that they already have the current version even when they have the OFED 1.0 version. So, in our RPMs, I updated the OFED 1.1 dapl version we built to be 1.2.1. Without doing that, the binary upgrade process that we use would have never worked. Then, in OFED 1.2, you guys update the dapl code again, and this time you decide to use...wait for it...that's right, 1.2.1. Great. Now we have a conflict between your 1.2.1 and our 1.2.1. How do people know which is which? They don't. And, of course, in order for binary upgrades to work, I once again had to bump our number. Our OFED 1.2 package now builds dapl 1.2.1.1 just because I had to do *something* in order to make upgrades work. The only reason that the OFED distribution has *ever* reliably installed the rpms you wanted installed is because you compile things locally and then *force* the upgrade of rpms over the top of older rpms that have the same version number. And even then, you yourselves can't tell the difference between a customer with the OFED 1.0 or OFED 1.1 dapl installed by checking the RPM version, you just have to go off what the end user *tells* you he installed and hope he's right. So, quite simply, the EWG has *chosen* to support source distribution and local compiles. That's fine really. But they've also chosen to bury their head in the sand about basic, non-flexible rules associated with any successful binary distribution and update process, even when I've brought those rules up multiple times. It should be no wonder then why I get all up in arms about packaging issues. Everything I give my customers has to automatically and correctly install, upgrade, downgrade, delete, verify, etc using RPM/up2date/yum. It can't require any --force options. And I don't have a choice about that. And I have to *know* what software my customer is running in order to support them. Because you guys have done things the way you have, I can't know that. I might be able to know if I could also guarantee they didn't download and locally compile your packages, but if they did, then the same version number of RPM can
[ewg] Re: [ofa-general] Agenda for OFED meeting today
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 the general list (aka "ofa") and be accepted to upstream merge before it goes to OFED. Sp far I have not seen a single email on the list, how you think to meet the Sep 4 FF date? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
