[openib-general] userspace git trees

[Sasha Khapyorsky]

On 07:48 Mon 11 Dec     , Michael S. Tsirkin wrote:
> > > > > > Recently I found this OFA 'Userspace Git Trees' downloading howto:
> > > > > > 
> > > > > > https://openib.org/tiki/tiki-index.php?page=Downloading+Code+From+the+OFA+git+Repositories
> > > > > > 
> > > > > > and thought that we could make it simpler for end-user to choose the
> > > > > > "right" git tree just by adding one more series of symbolic links under
> > > > > > /pub/scm. This links will point to the maintainer's "official" trees, and
> > > > > > we will have only one such link per project.
> > > > > > 
> > > > > > So typical downloading howto for end-users will looks like:
> > > > > > 
> > > > > >   git clone git://staging.openfabrics.org/dapl
> > > > > >   git clone git://staging.openfabrics.org/ibutils
> > > > > >   git clone git://staging.openfabrics.org/imgen
> > > > > >   ...
> > > > > > 
> > > > > > instead of
> > > > > > 
> > > > > >   git clone git://staging.openfabrics.org/~ardavis/dapl
> > > > > >   git clone git://staging.openfabrics.org/~eitan/ibutils
> > > > > >   git clone git://staging.openfabrics.org/~mst/imgen
> > > > > >   ...
> > > > > > 
> > > > > > as it is now.
> > > > > 
> > > > > NACK, please remove this. These soft links are messy, and
> > > > > the fact that one needs root just to add a tree shows just how the approach
> > > > > is broken.
> > > > 
> > > > No, it is not instead, but in addition to ~user/ links, so root is _not_
> > > > required to add tree.
> > > 
> > > right but suddenly root is needed to make it "official".
> > > Let's avoid the whole policy-setting-by-softlinks.
> > > "I have root" should not equal, or be required for "I say what's official".
> > 
> > What are you trying to avoid? That only sysadmin will decide which git
> > tree will be "official" for OFED and which will not?
> 
> Yes. Another point is that I should not need sysadmin priviledges to create
> a new project and declare my tree the official source.

Nothing prevents from you to do it. No?

In "worst" case we could make /pub/scm writable for dedicated group (like
'git') and add all git users to this group. I think this should be safe -
currently we have only symbolic links in this directory.

> But not only that - staging is used to develop more than just OFED.  Read
> the rant part in the original mail if you like for more detail - development
> trees should all be equal. Only releases should be official.  And release has an
> immutable name, so it does not *matter* which tree you get it from.

I don't understand how it is related. Currently we have the list of
"official" trees anyway in Wiki (as above):

https://openib.org/tiki/tiki-index.php?page=Downloading+Code+From+the+OFA+git+Repositories

, and the goal is just to make it easier for end-users to find this.

> > > These should be branches, not separate trees.
> > 
> > Why not?
> 
> You seem to have a fear of branches :).

Of course not :). I like branches and I like trees, both can be useful.

> Many trees do not buy you anything,
> I tried this with ofed 1.1 in the beginning.

Your bad experience doesn't mean that multiple trees are bad idea -
you may find many good experiences as well (look at kernel.org for
example).

> You can have many trees. But a single project maintained by a single person
> belongs in a single public tree, scattering it around between multiple trees
> just makes it messy for people to track, and messy to figure out the delta
> between branches.

In the "rant" above you talked about equal development trees, I guess
"multiple"? What about multiple projects maintained by single person,
and single project maintained by multiple persons, and experimental
features of some existing project maintained but yet another person...

> Finally, it wastes space.

'git-clone -s' helps to save space.


Anyway I don't think that my proposition is so "Great Idea" (and
requires such fundamental discussion as branch against tree :)), but just
small helpful thing, mainly end-user oriented. And since there is no
strong support for this, I'm removing this now.

Sasha