[ewg] EWG/OFED meeting minutes for today (Dec 13, 2011)

[Edward Mascarenhas]

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.