Hi Vladimir and Steve,
Thanks for your comments.
See below.
- Edward
--
Hi Edward,
The main disadvantage of this proposal is that it will require much more time
for the maintenance, which is a show stopper, IMHO:
Any update in the main tree will require to checkout every branch with
backports and make specific changes.
The proposed development method does have some additional steps which
will need to be performed by the individual developers prior to sending
in a pull request:
* if the change is applicable to all backport branches, the
developer will create a commit in the master (or fixes)
branch. This commit will contain actual code changes rather
then a patch file. Once the commit has been made in the
master (or fixes) branch, the developer will have to merge
the new commit to applicable backports. Effectively, this is
done with two commands (executed per backport branch) - "git
checkout <branch>" and "git merge master". This is easily
scriptable. The result of the above process can be one of
two possibilities:
1. The commit merges cleanly to all backport branches -
in this case, the developer is ready to send the pull
request.
2. The commit creates a merge conflict in one or more
of the backport branches - in this case, the developer
fixes the merge conflicts in all applicable backports
and then submits the pull request. This scenario does
involve a little bit more of manual maintenance work,
however, I don't consider this a show-stopper for the
following reasons:
* even with the current structure of the repo,
developers have to make sure that the patches
for the individual backports apply cleanly
and are correct (effectively, the same work
as fixing the merge conflict)
* the work is performed by the individual
developers and, thus distributed among all
members. It does not have to be performed by
a single individual/maintainer.
* in our experience, merge conflicts happen very
seldom. Almost all commits will merge cleanly and
will not require additional effort.
* if the change is only applicable to a few backport branches,
the developer will have to make the change into each of the
backport branches. This is effectively the same work that the
developer will have to do in the existing structure with some
simplification. The developer will not have to prepare the tree
for the particular backport (just checking out the particular
branch will do that). In addition, the developer will not have
to create a patch file to be checked in as changes are in the
form of actual code.
The goal of the newly proposed structure and development method is that
pull requests are only submitted on "clean" repositories. By the time
the pull request is submitted, all commits should have been applied to
the appropriate backport branches and all merge conflicts resolved in
the source repository ("source" as in "the repository to pull from").
There should be minimal to no maintenance work required by the person
pulling into the "master" OFED repository.
In addition, a lot of backports can be shared by the different kernels/Distros
and it is easily maintainable today. The suggested approach will lead to
spending more work on backports as they will be developed separately.
In general, we consider sharing backport directories/branches for
multiple kernels a bad idea. It creates confusion and as soon as
there is a difference, there will be the need to separate the two
in some way.
The newly proposed structure and development method will have just as
many backport branches as there are backport directories in the current
OFED repository. The checking out of the correct backport branch could
be done easily by using the 'ofed_scripts/get_backport_dir.sh' script
in conjunction with 'git checkout'.
Regarding the issues you bring in your proposal, there is a mechanism that
enables to check that all patches can be applied clearly
(ofed_scripts/ofed_makedist.sh) and a build script that checks the
compilation on the OFA server.
Also, ofed_makedist.sh creates a tarball per backport directory which make it
easier to test/develop for this specific kernel.
Each developer should check his code using these tools before sending a pull
request.
There is a way for developers to check their work but the fact that
broken patches have been checked into the repo on multiple occasions
indicates that the method isn't used for every patch that is submitted
or does not work as intended.
The newly proposed structure and development method will minimize the
potential of checking in broken changes by the virtue of requiring that
all commits are in the form of actual code, they are applied to all
appropriate backport branches, and pull requests are submitted only on
"clean" trees.
There will still be a need to do nightly builds to verify that commits
don't break the build but this is already done, so there will be no
change in this regard.
Also, there is something unclear to me with the suggested approach: How the
source tarball, included in the OFED, will look like?
The general discussion is about how the repository will be organized and
how developers will work within the new structure. The source tarball
can be packaged up as the community requires. For example, our process
already contains a script which creates a source RPM which matches the
content of the source RPM generated by the OFED scripts. It translates
the proposed repository structure into the same source RPM as OFED
generates. In this way, we can leverage the OFED spec and Makefiles.
Currently, I am investigating the "compat" backport project
(https://lkml.org/lkml/2011/9/9/327). Probably, we should go in this direction.
It makes sense to investigate this while we are looking at alternatives.
I would like to hear of your findings.
Regards,
Edward
Regards,
Vladimir
This message and any attached documents contain information from QLogic
Corporation or its wholly-owned subsidiaries that may be confidential. If you
are not the intended recipient, you may not read, copy, distribute, or use this
information. If you have received this transmission in error, please notify the
sender immediately by reply e-mail and then delete this message.
_______________________________________________
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
