Lustre devel - Dec 2009 - Fwd: The Lustre community and GIT

Brian Reitz sent an email about GIT, that raises some questions, and I would
like to initiate some discussion here how we can reach the best
organization.

1. We need a public repository, where non Sun community members can commit.

a.  There are Lustre users than have their own branches.  LLNL has probably
the best tested branch among all users.  DDN''s customers have a version
of
Lustre that includes patches not yet in Sun''s releases.  It would be
very
valuable if these kind of releases could be collected in a publicly
accessible GIT repository.

I doubt that Sun will give commit rights to external entities (this is not
unreasonable, Sun needs to control what code enters its repositories).
 Hence I think that the community would be better served with a GIT
repository in a public place, like github, that can give such access.

My group at ClusterStor has reserved the "lustre" project at Github
and we
will give keys to any and all organizations that wish to make serious
contributions to Lustre.  I was in particular hoping that LLNL would be
willing to commit their releases to that public place.

b.  Everyone is uncertain about what Sun will do with Lustre (proprietary
Solaris / ZFS server releases and discontinued support for Linux servers
have been mentioned to me several times now).  A public repository with the
open code will be valuable for the community and promote continued
development and access.


2. We need MUCH more in the repository than Sun is putting into it.

There are many development branches and sometimes abandoned projects that
still have a lot of value.  For example, there is a nearly complete OS X
client port - what if someone wanted to pick that up?  Similarly, there are
projects like size on MDS or the network request scheduler that may need
help from the community to get finished or re-prioritized.

It is unclear to me if these kind of branches can be found in the publicly
available CVS.  If they can, a collection of relevant branches, broadly
along the lines of what I mention above, should be placed in the public GIT
repository.

3. Brian''s email message seems to indicate that Sun''s git
repository will be
used for Sun development.  In the past there were two CVS repositories - a
read-only one that was publicly accessible and when I last controlled the
group it was updated very frequently with all open source code (presently,
it seems to only contain releases, not the development stream of commits).
It is unclear how Sun can manage development with this git repository given
that parts of its work are proprietary (like the Windows port) or unreleased
(like the ZFS work).  Can we get more insight in what Brian is alluding to?


I am sure other community members have further suggestions, and I hope we
can discuss these here.  If there is support for github as a good location,
please let me know and we will give participants the keys.  In particular I
would like to publicly request that community members like LLNL that have
quite possibly the highest quality releases, place them in github or publish
another location where these can be found.

Thank you very much for your thoughts.

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.lustre.org/pipermail/lustre-devel/attachments/20091213/e10f165a/attachment.html

Peter Braam wrote:
> My group at ClusterStor has reserved the "lustre" project at
Github and we
> will give keys to any and all organizations that wish to make serious
> contributions to Lustre.  I was in particular hoping that LLNL would be
> willing to commit their releases to that public place.
First, I''d like to say thanks to Sun.  We are thrilled that they went 
through the effort of switching the repository over to git.

Yes, we at LLNL are happy to make our tree more public.  We have wanted 
to do this for a while, but hadn''t spent the time to figure out a 
reasonable method of distribution.  Even with the move to git, it is not 
immediately clear how we should share our branch of Lustre given our 
current work flow.

For a long time, we used a script to create a tarball from Sun''s CVS 
repo, and then imported that tree into a branch of our local Subversion 
repo.  All of our changes and maintained a quilt stack of patches.

For a number of reasons, when we started planning our 1.8.2-based 
release a couple of months ago, I transitioned us from Subversion to 
git.  We currently maintain all of our patches using topgit, which 
maintains each "patch" as a separate real "topic" branch in
git.

topgit is nice in some ways, but one of its down sides is that it makes 
the git history pretty ugly, with dozens and dozens of merges.  topgit 
allows a DAG of topic branch dependencies, but I decided to keep it 
simple with a stack-like arrangement of patches.

But to make a long story short, I doubt that anyone wants to see our 
topgit noise in a public repo.  So how would we handle an llnl branch in 
a repo on github?

We are willing to change our workflow, and even give up using topgit, if 
someone can suggest a better way.  To some extent, we can try to improve 
our patch development process.  Instead of creating a new quilt 
patch/topgit branch, we could just:

  1) Create git temporary branch
  2) Develop fix, commit, commit, commit...
  3) Condense development branch into one clean commit on the llnl branch.

One issue will be that in parallel, we are going to be submitting this 
patch to Sun via bugzilla.  It is often a month or more before this 
patch is revised and landed upstream.  And if a different version IS 
landed upstream, merging later could be problematic.  At the very least, 
there will be conflicts, but those are easily dealt with.

More worrying is when Sun comes up with a better fix that touches other 
code that our fix.  When we merge from Sun, there is no obvious clue 
that we now have two fixes for the same bug, and while it may not have 
conflicted from git''s point of view, the code is now probably broken.

So what is the best way for us to carry our long-term patches in git? 
Any suggestions?

Chris

Hello Peter,

As previously announced, we have already made the initial Lustre  
repository available to everyone this week at git.lustre.org.  This  
repository contains all of the main development and release branches  
and their history.  It''s where all of the Sun developers and  
maintaners will get their sources from, and it will continue to be  
available under the GPL v2 license as it always has been.

Sun''s policy of prioritizing stability, not just for releases but also
to underpin development, makes safeguarding the quality of this
repository paramount.  Everyone contributing to the Lustre sources -
not just internal Sun engineers but also external contributors like
LLNL, CEA, ORNL and DDN - is therefore subject to the same gatekeeping
procedures and must follow the same patch submission, testing and
landing processes.  These are further detailed in the wiki pages that
were in the original announcement:

http://wiki.lustre.org/index.php/Accessing_Lustre_Code
http://wiki.lustre.org/index.php/Submitting_Patches


For people not familiar with Git, it should be clarified that limiting  
commits to the Sun Prime repository does not in any way restrict  
access to the Lustre code, or the ability of non-Sun developers to  
share their own Git clone with the Lustre community.  Developers will  
be able to host their own Lustre clones (essentially full  
repositories) as and where they wish.  The major advantage of Git is  
that anyone can pull from any repository, or in fact from a number of  
different repositories at the same time - this choice is left to the  
user.

This is the same model used by the Linux kernel, and has proven to  
work well with Git.  Each kernel developer hosts their own clone(s) at  
git.kernel.org, or at some other site like repo.or.cz, or github.com,  
and when they have changes to submit upstream they send an email  
(usually containing both the patch, and the git URL to pull from) to  
the subsystem maintainer, or to Linus directly, requesting that he  
pull their changes.  This pull request is normally only sent after the  
patch has been reviewed, possibly multiple times,  by the appropriate  
subsystem maintainers.  Each developer has full control over their own  
clone, and in fact it is rare that more than one person has push  
access to a clone.

The fact that there are many different clones (some more important,  
and others less so) in no way implies that the kernel is being forked,  
but rather that this is the standard way in which to use Git to  
exchange changes.  The location at which a clone is hosted also has no  
bearing on its usefulness.



To answer your specific concerns in more detail,

On 2009-12-13, at 11:47, Peter Braam wrote:
> 1. We need a public repository, where non Sun community members can  
> commit.
>
> a.  There are Lustre users than have their own branches.  LLNL has  
> probably the best tested branch among all users.  DDN''s customers
> have a version of Lustre that includes patches not yet in Sun''s  
> releases.  It would be very valuable if these kind of releases could  
> be collected in a publicly accessible GIT repository.
That is true even today - most of the patches that are in the DDN  
branches were initially developed by Sun and are already in the  
publicly-available Lustre CVS, and many of the LLNL patches have or  
are being landed for the 1.8.2 release.

As you know, there will always be a delta of patches that are not in  
an official release, and will be available in the next one.  With the  
increase in testing to improve the quality of new releases compared to  
the past, releases are by necessity less frequent.  Should anyone have  
a desire for more bleeding-edge code, they have always been able fetch  
the current branch before its release, regardless of whether this is  
Git or CVS.  We maintain a number of different branches (b1_8 for  
incremental development, b_release_1_8_1 for critical fixes on the  
1.8.1 release, etc) these are already available to the public.
> I doubt that Sun will give commit rights to external entities (this  
> is not unreasonable, Sun needs to control what code enters its  
> repositories).  Hence I think that the community would be better  
> served with a GIT repository in a public place, like github, that  
> can give such access.
While CVS was very restrictive in terms of managing external commit  
permissions due to its monolithic repository, some external  
contributors have had commit access to CVS prior our migration to Git,  
based on need.  With the migration to Git there is no need to manage  
such access ourselves, as developers are able to host their clones  
wherever they want.  The git.lustre.org repository will remain the  
canonical source for Sun releases, and we will be happy to pull fixes  
into this repository that meet the quality guidelines stated above.  I  
for one would welcome external inspectors on patches, and we continue  
to work with external sites to do scale testing of Lustre.
> My group at ClusterStor has reserved the "lustre" project at
Github
> and we will give keys to any and all organizations that wish to make  
> serious contributions to Lustre.  I was in particular hoping that  
> LLNL would be willing to commit their releases to that public place.

Note that with Git and github.com there is no need to give keys to  
anyone, and in fact that would seem to be detrimental to ClusterStor,  
because the "lustre" clone you have reserved is within your
company''s
private hosting space (i.e. http://github.com/clusterstor/lustre).   
With Github (or Git in general) it is possible for anyone to make  
their own clone or mirror of a repository at any time, no keys or  
permission required, and it will appear ashttp://github.com/{user}/ 
lustre or whatever they want to call it.
> b.  Everyone is uncertain about what Sun will do with Lustre  
> (proprietary Solaris / ZFS server releases and discontinued support  
> for Linux servers have been mentioned to me several times now).  A  
> public repository with the open code will be valuable for the  
> community and promote continued development and access.
I agree that a public repository is important, and we will continue to  
host one at git.lustre.org as we have in the past for CVS, and it can  
and should be cloned as needed.  As you are hopefully aware, with Git  
every checkout has a full copy of the repository, including all  
history, so the code is already very "open" and "public". 
Lustre is,
and will continue to be, available as GPL software.

We definitely welcome external contributions to Lustre, which have in  
the past been done by a small number of people outside of Sun.  I  
don''t think the choice of CVS or Git or hosting site has ever been a  
limiting factor in this regard.  We look forward to contributions of  
fixes, designs, and features, from ClusterStor, as we would with any  
Lustre contributor.
> 2. We need MUCH more in the repository than Sun is putting into it.
>
> There are many development branches and sometimes abandoned projects  
> that still have a lot of value.  For example, there is a nearly  
> complete OS X client port - what if someone wanted to pick that up?   
> Similarly, there are projects like size on MDS or the network  
> request scheduler that may need help from the community to get  
> finished or re-prioritized.
All of the Lustre history is still available in CVS, as it has always  
been.  As far as I know (I''ve never checked it out myself) even the OS/
X client port is publicly available today, which was not true a few  
years ago.

Due to the convoluted branch, repository, and tag abuse that was used  
to manage the Lustre code in CVS, there is a non-zero effort required  
to migrate any of the branches in CVS to Git.  Rather than bring all  
of the old detritus along into Git, only the main development/ 
production branches are being automatically migrated initially.

Now that the Git migration is complete, the Sun maintainers of non- 
release features (HSM, SOM, CMD, NRS, etc) will be creating Git clones  
and landing their work into them as time permits.

If anyone wants to import one of the other CVS branches (e.g. OS/X),  
all they will need to do is create a patch from that branch and then  
commit this into their own Git clone.
> It is unclear to me if these kind of branches can be found in the  
> publicly available CVS.
Yes, they can, as they always have been.  The CVS repository will  
remain available indefinitely for spelunking expeditions should the  
need arise.  Note that the full history that leads to the current  
release branches (b1_6, b1_8, HEAD) is available in Git, so there is  
at least a trail of breadcrumbs leading to where we are today.
> If they can, a collection of relevant branches, broadly along the  
> lines of what I mention above, should be placed in the public GIT  
> repository.
For currently-active branches this was already our plan.  For  
historical and inactive branches, and we welcome any contributions  
that bring these ancient CVS branches back to life.  Nikita is  
probably best positioned to know what needs to be imported from the OS/ 
X branch in CVS, and if there are other particular branches that  
contain important work we''ll be happy to discuss them with you.  It  
will of course be possible to create Git clones for these old branches  
as needed.
> 3. Brian''s email message seems to indicate that Sun''s git
repository
> will be used for Sun development.  In the past there were two CVS  
> repositories - a read-only one that was publicly accessible and when  
> I last controlled the group it was updated very frequently with all  
> open source code (presently, it seems to only contain releases, not  
> the development stream of commits).
That''s not correct.  The public cvs.lustre.org repository in fact  
contains all of the Lustre commits and all of the history.  I just did  
a checkout and there are in fact tags and branches for the pre-release  
1.8.2 builds, lprocfs rewrite, CMD, etc. that are very much works in  
progress.

One of the very last commits on CVS HEAD was on Thursday before CVS  
went read-only, from a patch submitted by LLNL:

revision 1.593
date: 2009/12/10 13:52:51;  author: dzogin;  state: Exp;  lines: +5 -0
Branch HEAD
b=21259
i=andrew.perepechko
i=alexey.lyashkov
----------------------------------------------------------------------
Description: Allow non-root access for "lfs check".
Details    : Added a check in obd_class_ioctl() for OBD_IOC_PING_TARGET.

> It is unclear how Sun can manage development with this git  
> repository given that parts of its work are proprietary (like the  
> Windows port) or unreleased (like the ZFS work).  Can we get more  
> insight in what Brian is alluding to?
I''m not sure what "alluding" you are alluding to?

Of course, if there is any proprietary code developed it will just not  
be pushed to the public git.lustre.org repository.  I expect that any  
proprietary or unreleased code that ClusterStor is already or will  
develop will similarly not be posted publicly until you are ready to  
do so.

Sun''s current in-progress code will very likely reside in separate  
clones at git.lustre.org, but will not be merged into the Sun Prime  
repository for an official release until it is inspected, tested, and  
has permission to land.  Pulls into the Sun Prime repository will be  
done by the release manager for each branch, as previously stated.   
The Lustre engineers at ClusterStor are already familiar with this  
process and have already had their first patch pass inspections and it  
is ready for landing.

That is one of the major benefits of Git over CVS - that there ISN''T a
single repository, and in fact every clone has a full copy of the  
history and can be used by anyone.  There is no need to have all of  
the development done in branches on a single repository, but rather to  
keep projects in their own clones.

That allows developers to do local commits on their machines, to push  
it to their public clone if they want to share their work and/or make  
an offsite backup, and people are free to choose which clone one they  
use.  Sun''s Prime repository used for releases will only contain  
stable Lustre code.  This is the Git usage model for the Linux kernel,  
and think it is a good one to follow for Lustre as well.  You are free  
to manage your clones in some other way.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

Andreas Dilger wrote:
> For people not familiar with Git, it should be clarified that limiting  
> commits to the Sun Prime repository does not in any way restrict  
> access to the Lustre code, or the ability of non-Sun developers to  
> share their own Git clone with the Lustre community.  Developers will  
> be able to host their own Lustre clones (essentially full  
> repositories) as and where they wish.
Ah, right, good point.  We would probably just have an llnl lustre repo 
on github (if not one for each developer...), once we figure out how to 
make our branch more presentable.
> This is the same model used by the Linux kernel, and has proven to  
> work well with Git.  Each kernel developer hosts their own clone(s) at  
> git.kernel.org, or at some other site like repo.or.cz, or github.com,  
> and when they have changes to submit upstream they send an email  
> (usually containing both the patch, and the git URL to pull from) to  
> the subsystem maintainer, or to Linus directly, requesting that he  
> pull their changes.  This pull request is normally only sent after the  
> patch has been reviewed, possibly multiple times,  by the appropriate  
> subsystem maintainers.  Each developer has full control over their own  
> clone, and in fact it is rare that more than one person has push  
> access to a clone.
Has Sun given any thought to how git might be more integrated into the 
Bugzilla patch review process?  In particular, for external developers? 
  I see there is an internal "Lustre GIT page" that I can''t
access, and
external contributors are just told to follow the "submitting patches"
guidelines.

We would love to be able to tell Sun to pull from a branch to get our 
unreviewed patches, and vice versa.

Chris

On 2009-12-15, at 15:19, Christopher J. Morrone wrote:
> Andreas Dilger wrote:
>> For people not familiar with Git, it should be clarified that  
>> limiting
>> commits to the Sun Prime repository does not in any way restrict
>> access to the Lustre code, or the ability of non-Sun developers to
>> share their own Git clone with the Lustre community.  Developers will
>> be able to host their own Lustre clones (essentially full
>> repositories) as and where they wish.
>
> Ah, right, good point.  We would probably just have an llnl lustre  
> repo
> on github (if not one for each developer...), once we figure out how  
> to
> make our branch more presentable.
You would should rebase your repository against the Lustre git repo,  
but that should be fairly straight forward since topgit keeps each  
patch in a separate branch.  In general, users can use git rebase for  
keeping their patches updated against a remote tree, but since you  
started with a completely different git repo it probably will fail  
horribly.
>> This is the same model used by the Linux kernel, and has proven to
>> work well with Git.  Each kernel developer hosts their own clone(s)  
>> at
>> git.kernel.org, or at some other site like repo.or.cz, or github.com,
>> and when they have changes to submit upstream they send an email
>> (usually containing both the patch, and the git URL to pull from) to
>> the subsystem maintainer, or to Linus directly, requesting that he
>> pull their changes.  This pull request is normally only sent after  
>> the
>> patch has been reviewed, possibly multiple times,  by the appropriate
>> subsystem maintainers.  Each developer has full control over their  
>> own
>> clone, and in fact it is rare that more than one person has push
>> access to a clone.
>
> Has Sun given any thought to how git might be more integrated into the
> Bugzilla patch review process?  In particular, for external  
> developers?
Actually, Robert found a few tools that allow attaching patches to  
bugzilla directly from git that seem very useful.  I don''t have the  
names offhand, but it was very simple, like "git bz send-patch  
[bugno]" or similar.  Ideally, the gatekeeper would also be able to  
automatically mark the patch as landed on the appropriate release  
branch, but I suspect that would need a bit more scripting.  There has  
also been some investigation of "Review Board", but I don''t
know where
that is today.
>  I see there is an internal "Lustre GIT page" that I
can''t access, and
> external contributors are just told to follow the "submitting
patches"
> guidelines.
>
> We would love to be able to tell Sun to pull from a branch to get our
> unreviewed patches, and vice versa.

I agree that doing git pulls instead of patch submission is cleaner,  
but it definitely isn''t a good way to do patch review.  For the kernel
all of the patch review is done via email, but that has the drawback  
that the discussion about a given patch isn''t kept in a single place,  
and it isn''t clear who has agreed with or objected to a patch without  
trolling the whole thread each time.

We''re still investigating how to improve the patch workflow, and  
welcome input.  The first priority was to make a Git repository  
available, and then we can look at improving how patches are handled  
(tracking, inspections, testing, landing).  I didn''t want to entangle  
those two major process changes, as it would have delayed the Git  
transition even further.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

Andreas Dilger wrote:
> On 2009-12-15, at 15:19, Christopher J. Morrone wrote:
>> Andreas Dilger wrote:
>>> For people not familiar with Git, it should be clarified that
limiting
>>> commits to the Sun Prime repository does not in any way restrict
>>> access to the Lustre code, or the ability of non-Sun developers to
>>> share their own Git clone with the Lustre community.  Developers
will
>>> be able to host their own Lustre clones (essentially full
>>> repositories) as and where they wish.
>>
>> Ah, right, good point.  We would probably just have an llnl lustre repo
>> on github (if not one for each developer...), once we figure out how to
>> make our branch more presentable.
> 
> You would should rebase your repository against the Lustre git repo, but 
> that should be fairly straight forward since topgit keeps each patch in 
> a separate branch.  In general, users can use git rebase for keeping 
> their patches updated against a remote tree, but since you started with 
> a completely different git repo it probably will fail horribly.
I''m not really clear what you mean here.  I am not worried about
merging
in the latest from Sun''s repo, that can be done a number of ways easily
enough.

Lets say that I DON''T use topgit, because it is just going to be 
confusing for anyone else who tries to look at our repo.  And lets say 
that I have a branch of lustre that has 50 "patches" against the 
upstream code (our 1.6.6 branch had 175 patches! lets hope we don''t 
diverge that much again...)

How do I keep track of the logical set of patches?  I am not worried 
that I will lose them, I''m worried that cruft will accumulate, and that
their will be hidden conflicts.  I am worried that llnl will fix the 
problem one way, and then Sun will fix it another, and now we have two 
fixes that don''t get along in our tree.  Its entirely possible that 
there will be no contextual conflicts, even thought the fixes don''t
work
together.

Also, if we commit all of our work to one tree, how do we keep track of 
which commits belong to the same "bug"?

Maybe I am just overthinking the problem.  I''m hoping that I am.

Sun is never going to perform a full "pull" from the "llnl"
branch.  And
rightly so, that would just be too many disparate fixes to digest.  So 
(at llnl) have two somewhat conflicting goals:

1) Keep every logical change separate (so we can interact with Sun sanely)
2) Keep all changes together (so we can tag and install it :))

Previously we solved the problem with quilt, and now we solve this with 
topgit.  As long as we do not publish our repo, using topgit is probably 
going to be fine.  But I am worried that if we publish our repo, the 
history will just look like nonsense to other (because of topgit), and 
not be terribly useful beyond those folks that just want to blindly use 
our latest tag.

Chris

On 2009-12-15, at 18:18, Christopher J. Morrone wrote:
> Lets say that I DON''T use topgit, because it is just going to be  
> confusing for anyone else who tries to look at our repo.  And lets  
> say that I have a branch of lustre that has 50 "patches" against
the
> upstream code (our 1.6.6 branch had 175 patches! lets hope we
don''t
> diverge that much again...)
>
> How do I keep track of the logical set of patches?  I am not worried  
> that I will lose them, I''m worried that cruft will accumulate, and
> that their will be hidden conflicts.  I am worried that llnl will  
> fix the problem one way, and then Sun will fix it another, and now  
> we have two fixes that don''t get along in our tree.  Its entirely
> possible that there will be no contextual conflicts, even thought  
> the fixes don''t work together.
I know that Brian Behlendorf and Ricardo investigated a number of  
different tools for managing patches, and topgit was the one they  
chose.  Another tool in this vein is "guilt", which manages a patch  
series in a way similar to "quilt".

For developers that aren''t keeping a huge number of patches, and  
especially not a large number of dependent patches, "git rebase" is  
probably sufficient. That will refresh the patches against changes in  
the upstream repository.

As for tracking hidden semantic conflicts that do not have contextual  
conflicts, that is of course more difficult.  I think one important  
way to track this is that our own commit message policy will be to  
include the bug number into the "short" (one line) patch description,
and if you do a "git rebase" against the updated repo and your patch  
for that bug does not disappear due to the upstream commit for that  
bug, the patch should be reviewed.

I believe there are scripts that can automatically generate "shortlog"
summaries of git commits, and if LLNL''s commit policy is also to  
include our bug number along with some LLNL-specific marker into the  
short description then a simple "sort" should make it fairly simple to
detect automatically where there are LLNL-applied and Sun patches in  
your repo for the same bug.
> Also, if we commit all of our work to one tree, how do we keep track  
> of which commits belong to the same "bug"?
Via the commit message, as we are doing, is probably the easiest.
> Sun is never going to perform a full "pull" from the
"llnl" branch.
> And rightly so, that would just be too many disparate fixes to  
> digest.  So (at llnl) have two somewhat conflicting goals:
>
> 1) Keep every logical change separate (so we can interact with Sun  
> sanely)
> 2) Keep all changes together (so we can tag and install it :))
>
> Previously we solved the problem with quilt, and now we solve this  
> with topgit.  As long as we do not publish our repo, using topgit is  
> probably going to be fine.  But I am worried that if we publish our  
> repo, the history will just look like nonsense to other (because of  
> topgit), and not be terribly useful beyond those folks that just  
> want to blindly use our latest tag.
I think that depends on how topgit is doing the updates against the  
upstream repository.  If it is doing a "rebase" each time, then there
should only be a single git branch (each with a single commit) for  
each patch that you have applied.  If it does this via a "merge" then
there will be new commits for each pull that you do from upstream that  
is resolving conflicts, and the repo will become a mess.

Topgit is actually reasonably well suited to this, because it keeps  
every patch in a separate branch, and it would be possible (I think)  
to pull from just that branch, or possibly to make a clone and then  
delete all of the other branches, and then pull from that.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

hi Andreas,

On Tue, Dec 15, 2009 at 11:05 PM, Andreas Dilger <adilger at sun.com>
wrote:
> Hello Peter,
>
>
> > 2. We need MUCH more in the repository than Sun is putting into it.
> >
> > There are many development branches and sometimes abandoned projects
> > that still have a lot of value.  For example, there is a nearly
> > complete OS X client port - what if someone wanted to pick that up?
> > Similarly, there are projects like size on MDS or the network
> > request scheduler that may need help from the community to get
> > finished or re-prioritized.
>
> All of the Lustre history is still available in CVS, as it has always
> been.  As far as I know (I''ve never checked it out myself) even
the OS/
> X client port is publicly available today, which was not true a few
> years ago.
>
I would say, some time ago publicly available cvs repository "did not feel
well". I could not find cmd2 (seems to be not available todays too), gns or
even cmd3 code and any attempt to convert it to git or do anything that
requires "cvs rlog" resulted in this:

:pserver:anonymous at cvs.lustre.org:/lustre lustre-core
password file:
cvsroot: :pserver:anonymous at cvs.lustre.org:2401/lustre
pass: A
I LOVE YOU
cvs rlog: Logging lustre-core
cvs rlog: Logging lustre-core/asobd
cvs rlog: Logging lustre-core/autoconf
cvs rlog: Logging lustre-core/cmm
cvs rlog: Logging lustre-core/cmobd
cvs rlog: Logging lustre-core/cobd
cvs rlog: Logging lustre-core/conf
cvs rlog: Logging lustre-core/contrib
cvs rlog: Logging lustre-core/demos
cvs [rlog aborted]: unexpected ''\x0'' reading revision number
in RCS
file /lustre/lustre-core/demos/Attic/snaprest.sh,v
exit: 1

Obviously demos/snaprest.sh,v contained garbage. Now it seems to be fixed.

I think this is why Peter said it is "not clear" if all valuable
branches
are available in public cvs.

Thanks.

-- 
umka
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.lustre.org/pipermail/lustre-devel/attachments/20091216/1119305f/attachment.html

On 2009-12-16, at 10:24, Yuriy Umanets wrote:
> Andreas Dilger wrote:
>> Peter Braam wrote:
>> > 2. We need MUCH more in the repository than Sun is putting into
it.
>> >
>> > There are many development branches and sometimes abandoned  
>> projects
>> > that still have a lot of value.  For example, there is a nearly
>> > complete OS X client port - what if someone wanted to pick that
up?
>> > Similarly, there are projects like size on MDS or the network
>> > request scheduler that may need help from the community to get
>> > finished or re-prioritized.
>>
>> All of the Lustre history is still available in CVS, as it has always
>> been.  As far as I know (I''ve never checked it out myself)
even the
>> OS/
>> X client port is publicly available today, which was not true a few
>> years ago.
>
> I would say, some time ago publicly available cvs repository "did  
> not feel well".
Was this from a checkout, or only via CVS scraping tools like cvs2git?
> I could not find cmd2 (seems to be not available todays too), gns or  
> even cmd3 code
Doing a "cvs log lustre/ChangeLog" shows that tags for all of those  
projects exist on that file.  I haven''t tried to do a checkout of one  
of those tags, but I''d expect them to be there.  I know that ages ago  
some branches were deleted (in particular b_devel), but I don''t think  
there is anything of interest there.
> and any attempt to convert it to git or do anything that requires  
> "cvs rlog" resulted in this:
>
> cvs [rlog aborted]: unexpected ''\x0'' reading revision
number in RCS
> file /lustre/lustre-core/demos/Attic/snaprest.sh,v
> exit: 1
>
> Obviously demos/snaprest.sh,v contained garbage. Now it seems to be  
> fixed.
This file was corrupted at some point in the past (binary zeros  
appended to the file), as was documented in bugs 17080 and 18564.   
That was fixed this past summer when we started our own Git conversion  
process and noticed the same problem.

That was never a problem for checking out useful branches either  
internally or externally, because I don''t think snaprest.sh was used  
since early 2000 when Peter and I were working on snapfs, and it was  
deleted several years ago due to being completely obsolete.  It only  
was noticeable when trying to scrape the entire repository, including  
all of the history.
> I think this is why Peter said it is "not clear" if all valuable
> branches are available in public cvs.

It''s unfortunate that incorrect conclusions were reached with  
incomplete data.

The problem isn''t whether all of the valuable branches are available  
in CVS, but rather which branches are the valuable ones?  I just  
checked, and there are 7638 tags in CVS, including 453 branches and  
490 release tags.  If there are some useful bits in there that you are  
aware of, I''d be happy to see them extracted from the rest and brought
back to life.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

Andreas Dilger wrote:
> I know that Brian Behlendorf and Ricardo investigated a number of 
> different tools for managing patches, and topgit was the one they 
> chose.  Another tool in this vein is "guilt", which manages a
patch
> series in a way similar to "quilt".
Yes, I have discussed this at length with Brian.

The main problem with guilt is that seems to be designed with the single 
developer in mind, and not really well suited for sharing.  The major 
problem being that the patches and series information are not stored in 
git.  You need to come up with your own method of storing and keeping 
track of the patch set.

With topgit, anyone can simply clone our repo and checkout the
"t18/top"
branch of lustre, and have a tree that contains all of our patches. 
They don''t really even need to use topgit.  And, in fact, I think Brian
is the only person using topgit directly on the project that you are 
referring to.  The others usually just branch off one of his topgit 
branches and pass patches back to Brian.
> For developers that aren''t keeping a huge number of patches, and 
> especially not a large number of dependent patches, "git rebase"
is
> probably sufficient. That will refresh the patches against changes in 
> the upstream repository.
Except that "git rebase" is a destructive operation, right?  It is
fine
for the single developer to do that, but you basically can''t rebase a 
branch that you have published.  Here is the kind of comment that I see 
associate with git rebase over and over on the web:

"You should only use git rebase on your local-only branches. Its purpose 
is to keep your local, invisible changes up-to-date so that when you 
publish them they''ll be more relevant and easy to understand for
others."

So rebase is off limits to us when managing our published "llnl"
branch.
  (This is also why topgit uses "git merge" internally, not "git
rebase".)
> As for tracking hidden semantic conflicts that do not have contextual 
> conflicts, that is of course more difficult.  I think one important way 
> to track this is that our own commit message policy will be to include 
> the bug number into the "short" (one line) patch description, and
if you
> do a "git rebase" against the updated repo and your patch for
that bug
> does not disappear due to the upstream commit for that bug, the patch 
> should be reviewed.
Yes, that might work.  I am hoping that it will work, but I am not 
entirely convinced yet.  If we were using git rebase, our history would 
be shorter and easer to follow.  But we can''t use rebase.  So
I''m not
sure how easy it will be to track things using the log with repeated merges.

Maybe we just need to try it and see how it goes.
> I think that depends on how topgit is doing the updates against the 
> upstream repository.  If it is doing a "rebase" each time, then
there
> should only be a single git branch (each with a single commit) for each 
> patch that you have applied.  If it does this via a "merge" then
there
> will be new commits for each pull that you do from upstream that is 
> resolving conflicts, and the repo will become a mess.
It uses "git merge", because "git rebase" would basically
make the whole
thing unsharable.  Many of the merges turn into fast-forwards, but not 
all of them.

Chris

On Wed, 2009-12-16 at 15:01 -0800, Christopher J. Morrone
wrote:
> Andreas Dilger wrote:
> > For developers that aren''t keeping a huge number of patches,
and
> > especially not a large number of dependent patches, "git
rebase" is
> > probably sufficient. That will refresh the patches against changes in 
> > the upstream repository.
> 
> Except that "git rebase" is a destructive operation, right?  It
is fine
> for the single developer to do that, but you basically can''t
rebase a
> branch that you have published.  Here is the kind of comment that I see 
> associate with git rebase over and over on the web:
> 
> "You should only use git rebase on your local-only branches. Its
purpose
> is to keep your local, invisible changes up-to-date so that when you 
> publish them they''ll be more relevant and easy to understand for
others."
> 
> So rebase is off limits to us when managing our published "llnl"
branch.
>   (This is also why topgit uses "git merge" internally, not
"git rebase".)
It''s not a rule written in stone. If you have branches on which you
expect others to base their work, rebasing is painful for them as they
have to keep rebasing their work on top of the ones you do. But, this
can be OK if this is communicated to those that would follow your work.
Dave Miller used to rebase often with the net-2.6 tree, but stopped due
to the pain it was causing people working with him; it does occasionally
get rebased (and an email sent to netdev) if there is a problem that
would result in intolerable ugliness in the history.

linux-next is essentially rebased every day, but keeps tags to the
previous heads so that they don''t get lost. Ie, if one wants to develop
against linux-next, they should use a tag such as next-20091216 to get a
stable base as master gets rewound daily. Similarly, the "pu" branch
of
git is often rewound, and this fact is well advertised.

Certainly, if your changes are to go upstream via git pull and not via
an email patch series, then I think rebasing -- at least before the send
-- is a good idea, just to keep the history clean of distracting commits
like "Oops, forgot to add this file."

-- 
Dave Dillow
National Center for Computational Science
Oak Ridge National Laboratory
(865) 241-6602 office

On Thu, Dec 17, 2009 at 12:47 AM, Andreas Dilger <adilger at sun.com>
wrote:
> On 2009-12-16, at 10:24, Yuriy Umanets wrote:
>
>> Andreas Dilger wrote:
>>
>>  Peter Braam wrote:
>>> > 2. We need MUCH more in the repository than Sun is putting
into it.
>>> >
>>> > There are many development branches and sometimes abandoned
projects
>>> > that still have a lot of value.  For example, there is a
nearly
>>> > complete OS X client port - what if someone wanted to pick
that up?
>>> > Similarly, there are projects like size on MDS or the network
>>> > request scheduler that may need help from the community to get
>>> > finished or re-prioritized.
>>>
>>> All of the Lustre history is still available in CVS, as it has
always
>>> been.  As far as I know (I''ve never checked it out myself)
even the OS/
>>> X client port is publicly available today, which was not true a few
>>> years ago.
>>>
>>
>> I would say, some time ago publicly available cvs repository "did
not feel
>> well".
>>
>
> Was this from a checkout, or only via CVS scraping tools like cvs2git?

For example, git cvsimport. Additionally, cvs contained *.*,v files in wrong
format
>
>
>  I could not find cmd2 (seems to be not available todays too), gns or even
>> cmd3 code
>>
>
> Doing a "cvs log lustre/ChangeLog" shows that tags for all of
those
> projects exist on that file.  I haven''t tried to do a checkout of
one of
> those tags, but I''d expect them to be there.  I know that ages ago
some
> branches were deleted (in particular b_devel), but I don''t think
there is
> anything of interest there.
>
Cannot recall exactly, seems that I could not checkout specific
tags/branches while tags them selves were existing. Is it possible that I
happen to do that in the middle of some cvs migration process? I know there
were couple of them lastly.
>
>  and any attempt to convert it to git or do anything that requires
"cvs
>> rlog" resulted in this:
>>
>> cvs [rlog aborted]: unexpected ''\x0'' reading revision
number in RCS
>> file /lustre/lustre-core/demos/Attic/snaprest.sh,v
>> exit: 1
>>
>> Obviously demos/snaprest.sh,v contained garbage. Now it seems to be
fixed.
>>
>
> This file was corrupted at some point in the past (binary zeros appended to
> the file), as was documented in bugs 17080 and 18564.  That was fixed this
> past summer when we started our own Git conversion process and noticed the
> same problem.
>
Sorry to contradict but it was not fixed at Sep 21, the date I tried it last
time.

>
> That was never a problem for checking out useful branches either internally
> or externally, because I don''t think snaprest.sh was used since
early 2000
> when Peter and I were working on snapfs, and it was deleted several years
> ago due to being completely obsolete.  It only was noticeable when trying
to
> scrape the entire repository, including all of the history.
Yeah, unfortunately it was in "demos" directory which is one of first,
so
that, it failed very quickly.
>
>
>  I think this is why Peter said it is "not clear" if all valuable
branches
>> are available in public cvs.
>>
>
>
> It''s unfortunate that incorrect conclusions were reached with
incomplete
> data.
>
> The problem isn''t whether all of the valuable branches are
available in
> CVS, but rather which branches are the valuable ones?  I just checked, and
> there are 7638 tags in CVS, including 453 branches and 490 release tags. 
If
> there are some useful bits in there that you are aware of, I''d be
happy to
> see them extracted from the rest and brought back to life.
Sure I can name some of them but only those I participated or aware of.
Little % of those thousands tags:

mac os client, cobd + cmobd + mds on tmpfs, gns, cmd2, cmd3 branches, som,
crow (may be), hendrix project tests for cmd2 and cmd3

Thanks.

>
>
> Cheers, Andreas
> --
> Andreas Dilger
> Sr. Staff Engineer, Lustre Group
> Sun Microsystems of Canada, Inc.
>
>

-- 
umka
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.lustre.org/pipermail/lustre-devel/attachments/20091217/d9bb45f8/attachment.html

Sent from my iPhone

On Dec 15, 2009, at 14:05, Andreas Dilger <adilger at sun.com> wrote:
> Hello Peter,
>
> As previously announced, we have already made the initial Lustre  
> repository available to everyone this week at git.lustre.org.  This  
> repository contains all of the main development and release branches  
> and their history.  It''s where all of the Sun developers and  
> maintaners will get their sources from, and it will continue to be  
> available under the GPL v2 license as it always has been.
>
> Sun''s policy of prioritizing stability, not just for releases but
also
> to underpin development, makes safeguarding the quality of this
> repository paramount.  Everyone contributing to the Lustre sources -
> not just internal Sun engineers but also external contributors like
> LLNL, CEA, ORNL and DDN - is therefore subject to the same gatekeeping
> procedures and must follow the same patch submission, testing and
> landing processes.  These are further detailed in the wiki pages that
> were in the original announcement:
>
> http://wiki.lustre.org/index.php/Accessing_Lustre_Code
> http://wiki.lustre.org/index.php/Submitting_Patches
>
>
Sun is no longer supporting the Lustre community (storage OEMs and  
others have been refused further support).  The model you describe  
won''t apply much longer I think.  People will be looking for different
arrangements.

Peter


> For people not familiar with Git, it should be clarified that  
> limiting commits to the Sun Prime repository does not in any way  
> restrict access to the Lustre code, or the ability of non-Sun  
> developers to share their own Git clone with the Lustre community.   
> Developers will be able to host their own Lustre clones (essentially  
> full repositories) as and where they wish.  The major advantage of  
> Git is that anyone can pull from any repository, or in fact from a  
> number of different repositories at the same time - this choice is  
> left to the user.
>
> This is the same model used by the Linux kernel, and has proven to  
> work well with Git.  Each kernel developer hosts their own clone(s)  
> at git.kernel.org, or at some other site like repo.or.cz, or github.com 
> , and when they have changes to submit upstream they send an email  
> (usually containing both the patch, and the git URL to pull from) to  
> the subsystem maintainer, or to Linus directly, requesting that he  
> pull their changes.  This pull request is normally only sent after  
> the patch has been reviewed, possibly multiple times,  by the  
> appropriate subsystem maintainers.  Each developer has full control  
> over their own clone, and in fact it is rare that more than one  
> person has push access to a clone.
>
> The fact that there are many different clones (some more important,  
> and others less so) in no way implies that the kernel is being  
> forked, but rather that this is the standard way in which to use Git  
> to exchange changes.  The location at which a clone is hosted also  
> has no bearing on its usefulness.
>
>
>
> To answer your specific concerns in more detail,
>
> On 2009-12-13, at 11:47, Peter Braam wrote:
>> 1. We need a public repository, where non Sun community members can  
>> commit.
>>
>> a.  There are Lustre users than have their own branches.  LLNL has  
>> probably the best tested branch among all users.  DDN''s
customers
>> have a version of Lustre that includes patches not yet in
Sun''s
>> releases.  It would be very valuable if these kind of releases  
>> could be collected in a publicly accessible GIT repository.
>
> That is true even today - most of the patches that are in the DDN  
> branches were initially developed by Sun and are already in the  
> publicly-available Lustre CVS, and many of the LLNL patches have or  
> are being landed for the 1.8.2 release.
>
> As you know, there will always be a delta of patches that are not in  
> an official release, and will be available in the next one.  With  
> the increase in testing to improve the quality of new releases  
> compared to the past, releases are by necessity less frequent.   
> Should anyone have a desire for more bleeding-edge code, they have  
> always been able fetch the current branch before its release,  
> regardless of whether this is Git or CVS.  We maintain a number of  
> different branches (b1_8 for incremental development,  
> b_release_1_8_1 for critical fixes on the 1.8.1 release, etc) these  
> are already available to the public.
>
>> I doubt that Sun will give commit rights to external entities (this  
>> is not unreasonable, Sun needs to control what code enters its  
>> repositories).  Hence I think that the community would be better  
>> served with a GIT repository in a public place, like github, that  
>> can give such access.
>
> While CVS was very restrictive in terms of managing external commit  
> permissions due to its monolithic repository, some external  
> contributors have had commit access to CVS prior our migration to  
> Git, based on need.  With the migration to Git there is no need to  
> manage such access ourselves, as developers are able to host their  
> clones wherever they want.  The git.lustre.org repository will  
> remain the canonical source for Sun releases, and we will be happy  
> to pull fixes into this repository that meet the quality guidelines  
> stated above.  I for one would welcome external inspectors on  
> patches, and we continue to work with external sites to do scale  
> testing of Lustre.
>
>> My group at ClusterStor has reserved the "lustre" project at
Github
>> and we will give keys to any and all organizations that wish to  
>> make serious contributions to Lustre.  I was in particular hoping  
>> that LLNL would be willing to commit their releases to that public  
>> place.
>
>
> Note that with Git and github.com there is no need to give keys to  
> anyone, and in fact that would seem to be detrimental to  
> ClusterStor, because the "lustre" clone you have reserved is
within
> your company''s private hosting space (i.e.
http://github.com/clusterstor/lustre
> ).  With Github (or Git in general) it is possible for anyone to  
> make their own clone or mirror of a repository at any time, no keys  
> or permission required, and it will appear ashttp://github.com/ 
> {user}/lustre or whatever they want to call it.
>
>> b.  Everyone is uncertain about what Sun will do with Lustre  
>> (proprietary Solaris / ZFS server releases and discontinued support  
>> for Linux servers have been mentioned to me several times now).  A  
>> public repository with the open code will be valuable for the  
>> community and promote continued development and access.
>
> I agree that a public repository is important, and we will continue  
> to host one at git.lustre.org as we have in the past for CVS, and it  
> can and should be cloned as needed.  As you are hopefully aware,  
> with Git every checkout has a full copy of the repository, including  
> all history, so the code is already very "open" and
"public".
> Lustre is, and will continue to be, available as GPL software.
>
> We definitely welcome external contributions to Lustre, which have  
> in the past been done by a small number of people outside of Sun.  I  
> don''t think the choice of CVS or Git or hosting site has ever been
a
> limiting factor in this regard.  We look forward to contributions of  
> fixes, designs, and features, from ClusterStor, as we would with any  
> Lustre contributor.
>
>> 2. We need MUCH more in the repository than Sun is putting into it.
>>
>> There are many development branches and sometimes abandoned  
>> projects that still have a lot of value.  For example, there is a  
>> nearly complete OS X client port - what if someone wanted to pick  
>> that up?  Similarly, there are projects like size on MDS or the  
>> network request scheduler that may need help from the community to  
>> get finished or re-prioritized.
>
> All of the Lustre history is still available in CVS, as it has  
> always been.  As far as I know (I''ve never checked it out myself)
> even the OS/X client port is publicly available today, which was not  
> true a few years ago.
>
> Due to the convoluted branch, repository, and tag abuse that was  
> used to manage the Lustre code in CVS, there is a non-zero effort  
> required to migrate any of the branches in CVS to Git.  Rather than  
> bring all of the old detritus along into Git, only the main  
> development/production branches are being automatically migrated  
> initially.
>
> Now that the Git migration is complete, the Sun maintainers of non- 
> release features (HSM, SOM, CMD, NRS, etc) will be creating Git  
> clones and landing their work into them as time permits.
>
> If anyone wants to import one of the other CVS branches (e.g. OS/X),  
> all they will need to do is create a patch from that branch and then  
> commit this into their own Git clone.
>
>> It is unclear to me if these kind of branches can be found in the  
>> publicly available CVS.
>
> Yes, they can, as they always have been.  The CVS repository will  
> remain available indefinitely for spelunking expeditions should the  
> need arise.  Note that the full history that leads to the current  
> release branches (b1_6, b1_8, HEAD) is available in Git, so there is  
> at least a trail of breadcrumbs leading to where we are today.
>
>> If they can, a collection of relevant branches, broadly along the  
>> lines of what I mention above, should be placed in the public GIT  
>> repository.
>
> For currently-active branches this was already our plan.  For  
> historical and inactive branches, and we welcome any contributions  
> that bring these ancient CVS branches back to life.  Nikita is  
> probably best positioned to know what needs to be imported from the  
> OS/X branch in CVS, and if there are other particular branches that  
> contain important work we''ll be happy to discuss them with you. 
It
> will of course be possible to create Git clones for these old  
> branches as needed.
>
>> 3. Brian''s email message seems to indicate that Sun''s
git
>> repository will be used for Sun development.  In the past there  
>> were two CVS repositories - a read-only one that was publicly  
>> accessible and when I last controlled the group it was updated very  
>> frequently with all open source code (presently, it seems to only  
>> contain releases, not the development stream of commits).
>
> That''s not correct.  The public cvs.lustre.org repository in fact
> contains all of the Lustre commits and all of the history.  I just  
> did a checkout and there are in fact tags and branches for the pre- 
> release 1.8.2 builds, lprocfs rewrite, CMD, etc. that are very much  
> works in progress.
>
> One of the very last commits on CVS HEAD was on Thursday before CVS  
> went read-only, from a patch submitted by LLNL:
>
> revision 1.593
> date: 2009/12/10 13:52:51;  author: dzogin;  state: Exp;  lines: +5 -0
> Branch HEAD
> b=21259
> i=andrew.perepechko
> i=alexey.lyashkov
> ----------------------------------------------------------------------
> Description: Allow non-root access for "lfs check".
> Details    : Added a check in obd_class_ioctl() for  
> OBD_IOC_PING_TARGET.
>
>
>> It is unclear how Sun can manage development with this git  
>> repository given that parts of its work are proprietary (like the  
>> Windows port) or unreleased (like the ZFS work).  Can we get more  
>> insight in what Brian is alluding to?
>
> I''m not sure what "alluding" you are alluding to?
>
> Of course, if there is any proprietary code developed it will just  
> not be pushed to the public git.lustre.org repository.  I expect  
> that any proprietary or unreleased code that ClusterStor is already  
> or will develop will similarly not be posted publicly until you are  
> ready to do so.
>
> Sun''s current in-progress code will very likely reside in separate
> clones at git.lustre.org, but will not be merged into the Sun Prime  
> repository for an official release until it is inspected, tested,  
> and has permission to land.  Pulls into the Sun Prime repository  
> will be done by the release manager for each branch, as previously  
> stated.  The Lustre engineers at ClusterStor are already familiar  
> with this process and have already had their first patch pass  
> inspections and it is ready for landing.
>
> That is one of the major benefits of Git over CVS - that there
ISN''T
> a single repository, and in fact every clone has a full copy of the  
> history and can be used by anyone.  There is no need to have all of  
> the development done in branches on a single repository, but rather  
> to keep projects in their own clones.
>
> That allows developers to do local commits on their machines, to  
> push it to their public clone if they want to share their work and/ 
> or make an offsite backup, and people are free to choose which clone  
> one they use.  Sun''s Prime repository used for releases will only
> contain stable Lustre code.  This is the Git usage model for the  
> Linux kernel, and think it is a good one to follow for Lustre as  
> well.  You are free to manage your clones in some other way.
>
> Cheers, Andreas
> --
> Andreas Dilger
> Sr. Staff Engineer, Lustre Group
> Sun Microsystems of Canada, Inc.

I though majority of the lustre development and support was from Sun.
This is news to us.

Nevertheless I am glad Sun did this conversion.

Couple of questions:

1) What will happen to the Wiki? It still has a lot of Sun stuff on it (logo)
2) Will we still keep bugzilla.lustre.org?
3) Will there ever be a git over http? This is important for people
who are behind firewalls.

Also, it would be nice to have the RPMs on the Wiki instead of
registering with Sun.




On Sat, Dec 26, 2009 at 10:01 AM, Peter Braam
<peter.braam at clusterstor.com> wrote:
>
>
> Sent from my iPhone
>
> On Dec 15, 2009, at 14:05, Andreas Dilger <adilger at sun.com> wrote:
>
>> Hello Peter,
>>
>> As previously announced, we have already made the initial Lustre
>> repository available to everyone this week at git.lustre.org. ?This
>> repository contains all of the main development and release branches
>> and their history. ?It''s where all of the Sun developers and
>> maintaners will get their sources from, and it will continue to be
>> available under the GPL v2 license as it always has been.
>>
>> Sun''s policy of prioritizing stability, not just for releases
but also
>> to underpin development, makes safeguarding the quality of this
>> repository paramount. ?Everyone contributing to the Lustre sources -
>> not just internal Sun engineers but also external contributors like
>> LLNL, CEA, ORNL and DDN - is therefore subject to the same gatekeeping
>> procedures and must follow the same patch submission, testing and
>> landing processes. ?These are further detailed in the wiki pages that
>> were in the original announcement:
>>
>> http://wiki.lustre.org/index.php/Accessing_Lustre_Code
>> http://wiki.lustre.org/index.php/Submitting_Patches
>>
>>
>
> Sun is no longer supporting the Lustre community (storage OEMs and
> others have been refused further support). ?The model you describe
> won''t apply much longer I think. ?People will be looking for
different
> arrangements.
>
> Peter
>
>
>
>> For people not familiar with Git, it should be clarified that
>> limiting commits to the Sun Prime repository does not in any way
>> restrict access to the Lustre code, or the ability of non-Sun
>> developers to share their own Git clone with the Lustre community.
>> Developers will be able to host their own Lustre clones (essentially
>> full repositories) as and where they wish. ?The major advantage of
>> Git is that anyone can pull from any repository, or in fact from a
>> number of different repositories at the same time - this choice is
>> left to the user.
>>
>> This is the same model used by the Linux kernel, and has proven to
>> work well with Git. ?Each kernel developer hosts their own clone(s)
>> at git.kernel.org, or at some other site like repo.or.cz, or github.com
>> , and when they have changes to submit upstream they send an email
>> (usually containing both the patch, and the git URL to pull from) to
>> the subsystem maintainer, or to Linus directly, requesting that he
>> pull their changes. ?This pull request is normally only sent after
>> the patch has been reviewed, possibly multiple times, ?by the
>> appropriate subsystem maintainers. ?Each developer has full control
>> over their own clone, and in fact it is rare that more than one
>> person has push access to a clone.
>>
>> The fact that there are many different clones (some more important,
>> and others less so) in no way implies that the kernel is being
>> forked, but rather that this is the standard way in which to use Git
>> to exchange changes. ?The location at which a clone is hosted also
>> has no bearing on its usefulness.
>>
>>
>>
>> To answer your specific concerns in more detail,
>>
>> On 2009-12-13, at 11:47, Peter Braam wrote:
>>> 1. We need a public repository, where non Sun community members can
>>> commit.
>>>
>>> a. ?There are Lustre users than have their own branches. ?LLNL has
>>> probably the best tested branch among all users. ?DDN''s
customers
>>> have a version of Lustre that includes patches not yet in
Sun''s
>>> releases. ?It would be very valuable if these kind of releases
>>> could be collected in a publicly accessible GIT repository.
>>
>> That is true even today - most of the patches that are in the DDN
>> branches were initially developed by Sun and are already in the
>> publicly-available Lustre CVS, and many of the LLNL patches have or
>> are being landed for the 1.8.2 release.
>>
>> As you know, there will always be a delta of patches that are not in
>> an official release, and will be available in the next one. ?With
>> the increase in testing to improve the quality of new releases
>> compared to the past, releases are by necessity less frequent.
>> Should anyone have a desire for more bleeding-edge code, they have
>> always been able fetch the current branch before its release,
>> regardless of whether this is Git or CVS. ?We maintain a number of
>> different branches (b1_8 for incremental development,
>> b_release_1_8_1 for critical fixes on the 1.8.1 release, etc) these
>> are already available to the public.
>>
>>> I doubt that Sun will give commit rights to external entities (this
>>> is not unreasonable, Sun needs to control what code enters its
>>> repositories). ?Hence I think that the community would be better
>>> served with a GIT repository in a public place, like github, that
>>> can give such access.
>>
>> While CVS was very restrictive in terms of managing external commit
>> permissions due to its monolithic repository, some external
>> contributors have had commit access to CVS prior our migration to
>> Git, based on need. ?With the migration to Git there is no need to
>> manage such access ourselves, as developers are able to host their
>> clones wherever they want. ?The git.lustre.org repository will
>> remain the canonical source for Sun releases, and we will be happy
>> to pull fixes into this repository that meet the quality guidelines
>> stated above. ?I for one would welcome external inspectors on
>> patches, and we continue to work with external sites to do scale
>> testing of Lustre.
>>
>>> My group at ClusterStor has reserved the "lustre" project
at Github
>>> and we will give keys to any and all organizations that wish to
>>> make serious contributions to Lustre. ?I was in particular hoping
>>> that LLNL would be willing to commit their releases to that public
>>> place.
>>
>>
>> Note that with Git and github.com there is no need to give keys to
>> anyone, and in fact that would seem to be detrimental to
>> ClusterStor, because the "lustre" clone you have reserved is
within
>> your company''s private hosting space (i.e.
http://github.com/clusterstor/lustre
>> ). ?With Github (or Git in general) it is possible for anyone to
>> make their own clone or mirror of a repository at any time, no keys
>> or permission required, and it will appear ashttp://github.com/
>> {user}/lustre or whatever they want to call it.
>>
>>> b. ?Everyone is uncertain about what Sun will do with Lustre
>>> (proprietary Solaris / ZFS server releases and discontinued support
>>> for Linux servers have been mentioned to me several times now). ?A
>>> public repository with the open code will be valuable for the
>>> community and promote continued development and access.
>>
>> I agree that a public repository is important, and we will continue
>> to host one at git.lustre.org as we have in the past for CVS, and it
>> can and should be cloned as needed. ?As you are hopefully aware,
>> with Git every checkout has a full copy of the repository, including
>> all history, so the code is already very "open" and
"public".
>> Lustre is, and will continue to be, available as GPL software.
>>
>> We definitely welcome external contributions to Lustre, which have
>> in the past been done by a small number of people outside of Sun. ?I
>> don''t think the choice of CVS or Git or hosting site has ever
been a
>> limiting factor in this regard. ?We look forward to contributions of
>> fixes, designs, and features, from ClusterStor, as we would with any
>> Lustre contributor.
>>
>>> 2. We need MUCH more in the repository than Sun is putting into it.
>>>
>>> There are many development branches and sometimes abandoned
>>> projects that still have a lot of value. ?For example, there is a
>>> nearly complete OS X client port - what if someone wanted to pick
>>> that up? ?Similarly, there are projects like size on MDS or the
>>> network request scheduler that may need help from the community to
>>> get finished or re-prioritized.
>>
>> All of the Lustre history is still available in CVS, as it has
>> always been. ?As far as I know (I''ve never checked it out
myself)
>> even the OS/X client port is publicly available today, which was not
>> true a few years ago.
>>
>> Due to the convoluted branch, repository, and tag abuse that was
>> used to manage the Lustre code in CVS, there is a non-zero effort
>> required to migrate any of the branches in CVS to Git. ?Rather than
>> bring all of the old detritus along into Git, only the main
>> development/production branches are being automatically migrated
>> initially.
>>
>> Now that the Git migration is complete, the Sun maintainers of non-
>> release features (HSM, SOM, CMD, NRS, etc) will be creating Git
>> clones and landing their work into them as time permits.
>>
>> If anyone wants to import one of the other CVS branches (e.g. OS/X),
>> all they will need to do is create a patch from that branch and then
>> commit this into their own Git clone.
>>
>>> It is unclear to me if these kind of branches can be found in the
>>> publicly available CVS.
>>
>> Yes, they can, as they always have been. ?The CVS repository will
>> remain available indefinitely for spelunking expeditions should the
>> need arise. ?Note that the full history that leads to the current
>> release branches (b1_6, b1_8, HEAD) is available in Git, so there is
>> at least a trail of breadcrumbs leading to where we are today.
>>
>>> If they can, a collection of relevant branches, broadly along the
>>> lines of what I mention above, should be placed in the public GIT
>>> repository.
>>
>> For currently-active branches this was already our plan. ?For
>> historical and inactive branches, and we welcome any contributions
>> that bring these ancient CVS branches back to life. ?Nikita is
>> probably best positioned to know what needs to be imported from the
>> OS/X branch in CVS, and if there are other particular branches that
>> contain important work we''ll be happy to discuss them with
you. ?It
>> will of course be possible to create Git clones for these old
>> branches as needed.
>>
>>> 3. Brian''s email message seems to indicate that
Sun''s git
>>> repository will be used for Sun development. ?In the past there
>>> were two CVS repositories - a read-only one that was publicly
>>> accessible and when I last controlled the group it was updated very
>>> frequently with all open source code (presently, it seems to only
>>> contain releases, not the development stream of commits).
>>
>> That''s not correct. ?The public cvs.lustre.org repository in
fact
>> contains all of the Lustre commits and all of the history. ?I just
>> did a checkout and there are in fact tags and branches for the pre-
>> release 1.8.2 builds, lprocfs rewrite, CMD, etc. that are very much
>> works in progress.
>>
>> One of the very last commits on CVS HEAD was on Thursday before CVS
>> went read-only, from a patch submitted by LLNL:
>>
>> revision 1.593
>> date: 2009/12/10 13:52:51; ?author: dzogin; ?state: Exp; ?lines: +5 -0
>> Branch HEAD
>> b=21259
>> i=andrew.perepechko
>> i=alexey.lyashkov
>> ----------------------------------------------------------------------
>> Description: Allow non-root access for "lfs check".
>> Details ? ?: Added a check in obd_class_ioctl() for
>> OBD_IOC_PING_TARGET.
>>
>>
>>> It is unclear how Sun can manage development with this git
>>> repository given that parts of its work are proprietary (like the
>>> Windows port) or unreleased (like the ZFS work). ?Can we get more
>>> insight in what Brian is alluding to?
>>
>> I''m not sure what "alluding" you are alluding to?
>>
>> Of course, if there is any proprietary code developed it will just
>> not be pushed to the public git.lustre.org repository. ?I expect
>> that any proprietary or unreleased code that ClusterStor is already
>> or will develop will similarly not be posted publicly until you are
>> ready to do so.
>>
>> Sun''s current in-progress code will very likely reside in
separate
>> clones at git.lustre.org, but will not be merged into the Sun Prime
>> repository for an official release until it is inspected, tested,
>> and has permission to land. ?Pulls into the Sun Prime repository
>> will be done by the release manager for each branch, as previously
>> stated. ?The Lustre engineers at ClusterStor are already familiar
>> with this process and have already had their first patch pass
>> inspections and it is ready for landing.
>>
>> That is one of the major benefits of Git over CVS - that there
ISN''T
>> a single repository, and in fact every clone has a full copy of the
>> history and can be used by anyone. ?There is no need to have all of
>> the development done in branches on a single repository, but rather
>> to keep projects in their own clones.
>>
>> That allows developers to do local commits on their machines, to
>> push it to their public clone if they want to share their work and/
>> or make an offsite backup, and people are free to choose which clone
>> one they use. ?Sun''s Prime repository used for releases will
only
>> contain stable Lustre code. ?This is the Git usage model for the
>> Linux kernel, and think it is a good one to follow for Lustre as
>> well. ?You are free to manage your clones in some other way.
>>
>> Cheers, Andreas
>> --
>> Andreas Dilger
>> Sr. Staff Engineer, Lustre Group
>> Sun Microsystems of Canada, Inc.
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel
>

On 2009-12-27, at 17:49, Mag Gam wrote:
> I though majority of the lustre development and support was from Sun.
> This is news to us.
Peter has his own opinions and motivations, and does not in any way  
speak for Sun.  His comments should in no way be confused with any  
statement of direction for Lustre.  Sun will continue Lustre  
development and support in the future.
> Nevertheless I am glad Sun did this conversion.
Thanks.  We worked hard to make sure the transition to Git was  
successful.
> Couple of questions:
>
> 1) What will happen to the Wiki? It still has a lot of Sun stuff on  
> it (logo)
The wiki is continuing to be improved by our documentation team.
> 2) Will we still keep bugzilla.lustre.org?
Yes.
> 3) Will there ever be a git over http? This is important for people
> who are behind firewalls.
I''ll pass that question on to our Git administration folks.
> Also, it would be nice to have the RPMs on the Wiki instead of
> registering with Sun.
I don''t think that will be changing in the near future, but our  
management is aware of this issue.
> On Sat, Dec 26, 2009 at 10:01 AM, Peter Braam
> <peter.braam at clusterstor.com> wrote:
>> Sent from my iPhone
>>
>> On Dec 15, 2009, at 14:05, Andreas Dilger <adilger at sun.com>
wrote:
>>
>>> Hello Peter,
>>>
>>> As previously announced, we have already made the initial Lustre
>>> repository available to everyone this week at git.lustre.org.  This
>>> repository contains all of the main development and release
branches
>>> and their history.  It''s where all of the Sun developers
and
>>> maintaners will get their sources from, and it will continue to be
>>> available under the GPL v2 license as it always has been.
>>>
>>> Sun''s policy of prioritizing stability, not just for
releases but
>>> also
>>> to underpin development, makes safeguarding the quality of this
>>> repository paramount.  Everyone contributing to the Lustre sources
-
>>> not just internal Sun engineers but also external contributors like
>>> LLNL, CEA, ORNL and DDN - is therefore subject to the same  
>>> gatekeeping
>>> procedures and must follow the same patch submission, testing and
>>> landing processes.  These are further detailed in the wiki pages  
>>> that
>>> were in the original announcement:
>>>
>>> http://wiki.lustre.org/index.php/Accessing_Lustre_Code
>>> http://wiki.lustre.org/index.php/Submitting_Patches
>>>
>>>
>>
>> Sun is no longer supporting the Lustre community (storage OEMs and
>> others have been refused further support).  The model you describe
>> won''t apply much longer I think.  People will be looking for  
>> different
>> arrangements.
>>
>> Peter
>>
>>
>>
>>> For people not familiar with Git, it should be clarified that
>>> limiting commits to the Sun Prime repository does not in any way
>>> restrict access to the Lustre code, or the ability of non-Sun
>>> developers to share their own Git clone with the Lustre community.
>>> Developers will be able to host their own Lustre clones
(essentially
>>> full repositories) as and where they wish.  The major advantage of
>>> Git is that anyone can pull from any repository, or in fact from a
>>> number of different repositories at the same time - this choice is
>>> left to the user.
>>>
>>> This is the same model used by the Linux kernel, and has proven to
>>> work well with Git.  Each kernel developer hosts their own clone(s)
>>> at git.kernel.org, or at some other site like repo.or.cz, or  
>>> github.com
>>> , and when they have changes to submit upstream they send an email
>>> (usually containing both the patch, and the git URL to pull from)
to
>>> the subsystem maintainer, or to Linus directly, requesting that he
>>> pull their changes.  This pull request is normally only sent after
>>> the patch has been reviewed, possibly multiple times,  by the
>>> appropriate subsystem maintainers.  Each developer has full control
>>> over their own clone, and in fact it is rare that more than one
>>> person has push access to a clone.
>>>
>>> The fact that there are many different clones (some more important,
>>> and others less so) in no way implies that the kernel is being
>>> forked, but rather that this is the standard way in which to use
Git
>>> to exchange changes.  The location at which a clone is hosted also
>>> has no bearing on its usefulness.
>>>
>>>
>>>
>>> To answer your specific concerns in more detail,
>>>
>>> On 2009-12-13, at 11:47, Peter Braam wrote:
>>>> 1. We need a public repository, where non Sun community members
can
>>>> commit.
>>>>
>>>> a.  There are Lustre users than have their own branches.  LLNL
has
>>>> probably the best tested branch among all users. 
DDN''s customers
>>>> have a version of Lustre that includes patches not yet in
Sun''s
>>>> releases.  It would be very valuable if these kind of releases
>>>> could be collected in a publicly accessible GIT repository.
>>>
>>> That is true even today - most of the patches that are in the DDN
>>> branches were initially developed by Sun and are already in the
>>> publicly-available Lustre CVS, and many of the LLNL patches have or
>>> are being landed for the 1.8.2 release.
>>>
>>> As you know, there will always be a delta of patches that are not
in
>>> an official release, and will be available in the next one.  With
>>> the increase in testing to improve the quality of new releases
>>> compared to the past, releases are by necessity less frequent.
>>> Should anyone have a desire for more bleeding-edge code, they have
>>> always been able fetch the current branch before its release,
>>> regardless of whether this is Git or CVS.  We maintain a number of
>>> different branches (b1_8 for incremental development,
>>> b_release_1_8_1 for critical fixes on the 1.8.1 release, etc) these
>>> are already available to the public.
>>>
>>>> I doubt that Sun will give commit rights to external entities
(this
>>>> is not unreasonable, Sun needs to control what code enters its
>>>> repositories).  Hence I think that the community would be
better
>>>> served with a GIT repository in a public place, like github,
that
>>>> can give such access.
>>>
>>> While CVS was very restrictive in terms of managing external commit
>>> permissions due to its monolithic repository, some external
>>> contributors have had commit access to CVS prior our migration to
>>> Git, based on need.  With the migration to Git there is no need to
>>> manage such access ourselves, as developers are able to host their
>>> clones wherever they want.  The git.lustre.org repository will
>>> remain the canonical source for Sun releases, and we will be happy
>>> to pull fixes into this repository that meet the quality guidelines
>>> stated above.  I for one would welcome external inspectors on
>>> patches, and we continue to work with external sites to do scale
>>> testing of Lustre.
>>>
>>>> My group at ClusterStor has reserved the "lustre"
project at Github
>>>> and we will give keys to any and all organizations that wish to
>>>> make serious contributions to Lustre.  I was in particular
hoping
>>>> that LLNL would be willing to commit their releases to that
public
>>>> place.
>>>
>>>
>>> Note that with Git and github.com there is no need to give keys to
>>> anyone, and in fact that would seem to be detrimental to
>>> ClusterStor, because the "lustre" clone you have reserved
is within
>>> your company''s private hosting space (i.e.
http://github.com/clusterstor/lustre
>>> ).  With Github (or Git in general) it is possible for anyone to
>>> make their own clone or mirror of a repository at any time, no keys
>>> or permission required, and it will appear ashttp://github.com/
>>> {user}/lustre or whatever they want to call it.
>>>
>>>> b.  Everyone is uncertain about what Sun will do with Lustre
>>>> (proprietary Solaris / ZFS server releases and discontinued
support
>>>> for Linux servers have been mentioned to me several times now).
A
>>>> public repository with the open code will be valuable for the
>>>> community and promote continued development and access.
>>>
>>> I agree that a public repository is important, and we will continue
>>> to host one at git.lustre.org as we have in the past for CVS, and
it
>>> can and should be cloned as needed.  As you are hopefully aware,
>>> with Git every checkout has a full copy of the repository,
including
>>> all history, so the code is already very "open" and
"public".
>>> Lustre is, and will continue to be, available as GPL software.
>>>
>>> We definitely welcome external contributions to Lustre, which have
>>> in the past been done by a small number of people outside of Sun. 
I
>>> don''t think the choice of CVS or Git or hosting site has
ever been a
>>> limiting factor in this regard.  We look forward to contributions
of
>>> fixes, designs, and features, from ClusterStor, as we would with
any
>>> Lustre contributor.
>>>
>>>> 2. We need MUCH more in the repository than Sun is putting into
it.
>>>>
>>>> There are many development branches and sometimes abandoned
>>>> projects that still have a lot of value.  For example, there is
a
>>>> nearly complete OS X client port - what if someone wanted to
pick
>>>> that up?  Similarly, there are projects like size on MDS or the
>>>> network request scheduler that may need help from the community
to
>>>> get finished or re-prioritized.
>>>
>>> All of the Lustre history is still available in CVS, as it has
>>> always been.  As far as I know (I''ve never checked it out
myself)
>>> even the OS/X client port is publicly available today, which was
not
>>> true a few years ago.
>>>
>>> Due to the convoluted branch, repository, and tag abuse that was
>>> used to manage the Lustre code in CVS, there is a non-zero effort
>>> required to migrate any of the branches in CVS to Git.  Rather than
>>> bring all of the old detritus along into Git, only the main
>>> development/production branches are being automatically migrated
>>> initially.
>>>
>>> Now that the Git migration is complete, the Sun maintainers of non-
>>> release features (HSM, SOM, CMD, NRS, etc) will be creating Git
>>> clones and landing their work into them as time permits.
>>>
>>> If anyone wants to import one of the other CVS branches (e.g.
OS/X),
>>> all they will need to do is create a patch from that branch and
then
>>> commit this into their own Git clone.
>>>
>>>> It is unclear to me if these kind of branches can be found in
the
>>>> publicly available CVS.
>>>
>>> Yes, they can, as they always have been.  The CVS repository will
>>> remain available indefinitely for spelunking expeditions should the
>>> need arise.  Note that the full history that leads to the current
>>> release branches (b1_6, b1_8, HEAD) is available in Git, so there
is
>>> at least a trail of breadcrumbs leading to where we are today.
>>>
>>>> If they can, a collection of relevant branches, broadly along
the
>>>> lines of what I mention above, should be placed in the public
GIT
>>>> repository.
>>>
>>> For currently-active branches this was already our plan.  For
>>> historical and inactive branches, and we welcome any contributions
>>> that bring these ancient CVS branches back to life.  Nikita is
>>> probably best positioned to know what needs to be imported from the
>>> OS/X branch in CVS, and if there are other particular branches that
>>> contain important work we''ll be happy to discuss them with
you.  It
>>> will of course be possible to create Git clones for these old
>>> branches as needed.
>>>
>>>> 3. Brian''s email message seems to indicate that
Sun''s git
>>>> repository will be used for Sun development.  In the past there
>>>> were two CVS repositories - a read-only one that was publicly
>>>> accessible and when I last controlled the group it was updated
very
>>>> frequently with all open source code (presently, it seems to
only
>>>> contain releases, not the development stream of commits).
>>>
>>> That''s not correct.  The public cvs.lustre.org repository
in fact
>>> contains all of the Lustre commits and all of the history.  I just
>>> did a checkout and there are in fact tags and branches for the pre-
>>> release 1.8.2 builds, lprocfs rewrite, CMD, etc. that are very much
>>> works in progress.
>>>
>>> One of the very last commits on CVS HEAD was on Thursday before CVS
>>> went read-only, from a patch submitted by LLNL:
>>>
>>> revision 1.593
>>> date: 2009/12/10 13:52:51;  author: dzogin;  state: Exp;  lines:  
>>> +5 -0
>>> Branch HEAD
>>> b=21259
>>> i=andrew.perepechko
>>> i=alexey.lyashkov
>>>
----------------------------------------------------------------------
>>> Description: Allow non-root access for "lfs check".
>>> Details    : Added a check in obd_class_ioctl() for
>>> OBD_IOC_PING_TARGET.
>>>
>>>
>>>> It is unclear how Sun can manage development with this git
>>>> repository given that parts of its work are proprietary (like
the
>>>> Windows port) or unreleased (like the ZFS work).  Can we get
more
>>>> insight in what Brian is alluding to?
>>>
>>> I''m not sure what "alluding" you are alluding
to?
>>>
>>> Of course, if there is any proprietary code developed it will just
>>> not be pushed to the public git.lustre.org repository.  I expect
>>> that any proprietary or unreleased code that ClusterStor is already
>>> or will develop will similarly not be posted publicly until you are
>>> ready to do so.
>>>
>>> Sun''s current in-progress code will very likely reside in
separate
>>> clones at git.lustre.org, but will not be merged into the Sun Prime
>>> repository for an official release until it is inspected, tested,
>>> and has permission to land.  Pulls into the Sun Prime repository
>>> will be done by the release manager for each branch, as previously
>>> stated.  The Lustre engineers at ClusterStor are already familiar
>>> with this process and have already had their first patch pass
>>> inspections and it is ready for landing.
>>>
>>> That is one of the major benefits of Git over CVS - that there
ISN''T
>>> a single repository, and in fact every clone has a full copy of the
>>> history and can be used by anyone.  There is no need to have all of
>>> the development done in branches on a single repository, but rather
>>> to keep projects in their own clones.
>>>
>>> That allows developers to do local commits on their machines, to
>>> push it to their public clone if they want to share their work and/
>>> or make an offsite backup, and people are free to choose which
clone
>>> one they use.  Sun''s Prime repository used for releases
will only
>>> contain stable Lustre code.  This is the Git usage model for the
>>> Linux kernel, and think it is a good one to follow for Lustre as
>>> well.  You are free to manage your clones in some other way.
>>>
>>> Cheers, Andreas
>>> --
>>> Andreas Dilger
>>> Sr. Staff Engineer, Lustre Group
>>> Sun Microsystems of Canada, Inc.
>> _______________________________________________
>> Lustre-devel mailing list
>> Lustre-devel at lists.lustre.org
>> http://lists.lustre.org/mailman/listinfo/lustre-devel
>>

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

On Wed, Dec 30, 2009 at 11:12 PM, Andreas Dilger <adilger at sun.com>
wrote:
> On 2009-12-27, at 17:49, Mag Gam wrote:
> > I though majority of the lustre development and support was from Sun.
> > This is news to us.
>
> Peter has his own opinions and motivations, and does not in any way
> speak for Sun.  His comments should in no way be confused with any
> statement of direction for Lustre.  Sun will continue Lustre
> development and support in the future.
>
>
Indeed.  Let''s see if Sun''s VP of HPC Marc Hamilton can
clarify what he told
someone who works for me.  Hopefully the plans have changed.  I haven''t
met
anybody who is informed about the facts, and doesn''t share my concerns,
including many senior staff in the Lustre team.

As for my own motivations, I would like the Lustre community to continue to
aid high-end HPC.

Peter
> > Nevertheless I am glad Sun did this conversion.
>
> Thanks.  We worked hard to make sure the transition to Git was
> successful.
>
> > Couple of questions:
> >
> > 1) What will happen to the Wiki? It still has a lot of Sun stuff on
> > it (logo)
>
> The wiki is continuing to be improved by our documentation team.
>
> > 2) Will we still keep bugzilla.lustre.org?
>
> Yes.
>
> > 3) Will there ever be a git over http? This is important for people
> > who are behind firewalls.
>
> I''ll pass that question on to our Git administration folks.
>
> > Also, it would be nice to have the RPMs on the Wiki instead of
> > registering with Sun.
>
> I don''t think that will be changing in the near future, but our
> management is aware of this issue.
>
> > On Sat, Dec 26, 2009 at 10:01 AM, Peter Braam
> > <peter.braam at clusterstor.com> wrote:
> >> Sent from my iPhone
> >>
> >> On Dec 15, 2009, at 14:05, Andreas Dilger <adilger at
sun.com> wrote:
> >>
> >>> Hello Peter,
> >>>
> >>> As previously announced, we have already made the initial
Lustre
> >>> repository available to everyone this week at git.lustre.org. 
This
> >>> repository contains all of the main development and release
branches
> >>> and their history.  It''s where all of the Sun
developers and
> >>> maintaners will get their sources from, and it will continue
to be
> >>> available under the GPL v2 license as it always has been.
> >>>
> >>> Sun''s policy of prioritizing stability, not just for
releases but
> >>> also
> >>> to underpin development, makes safeguarding the quality of
this
> >>> repository paramount.  Everyone contributing to the Lustre
sources -
> >>> not just internal Sun engineers but also external contributors
like
> >>> LLNL, CEA, ORNL and DDN - is therefore subject to the same
> >>> gatekeeping
> >>> procedures and must follow the same patch submission, testing
and
> >>> landing processes.  These are further detailed in the wiki
pages
> >>> that
> >>> were in the original announcement:
> >>>
> >>> http://wiki.lustre.org/index.php/Accessing_Lustre_Code
> >>> http://wiki.lustre.org/index.php/Submitting_Patches
> >>>
> >>>
> >>
> >> Sun is no longer supporting the Lustre community (storage OEMs and
> >> others have been refused further support).  The model you describe
> >> won''t apply much longer I think.  People will be looking
for
> >> different
> >> arrangements.
> >>
> >> Peter
> >>
> >>
> >>
> >>> For people not familiar with Git, it should be clarified that
> >>> limiting commits to the Sun Prime repository does not in any
way
> >>> restrict access to the Lustre code, or the ability of non-Sun
> >>> developers to share their own Git clone with the Lustre
community.
> >>> Developers will be able to host their own Lustre clones
(essentially
> >>> full repositories) as and where they wish.  The major
advantage of
> >>> Git is that anyone can pull from any repository, or in fact
from a
> >>> number of different repositories at the same time - this
choice is
> >>> left to the user.
> >>>
> >>> This is the same model used by the Linux kernel, and has
proven to
> >>> work well with Git.  Each kernel developer hosts their own
clone(s)
> >>> at git.kernel.org, or at some other site like repo.or.cz, or
> >>> github.com
> >>> , and when they have changes to submit upstream they send an
email
> >>> (usually containing both the patch, and the git URL to pull
from) to
> >>> the subsystem maintainer, or to Linus directly, requesting
that he
> >>> pull their changes.  This pull request is normally only sent
after
> >>> the patch has been reviewed, possibly multiple times,  by the
> >>> appropriate subsystem maintainers.  Each developer has full
control
> >>> over their own clone, and in fact it is rare that more than
one
> >>> person has push access to a clone.
> >>>
> >>> The fact that there are many different clones (some more
important,
> >>> and others less so) in no way implies that the kernel is being
> >>> forked, but rather that this is the standard way in which to
use Git
> >>> to exchange changes.  The location at which a clone is hosted
also
> >>> has no bearing on its usefulness.
> >>>
> >>>
> >>>
> >>> To answer your specific concerns in more detail,
> >>>
> >>> On 2009-12-13, at 11:47, Peter Braam wrote:
> >>>> 1. We need a public repository, where non Sun community
members can
> >>>> commit.
> >>>>
> >>>> a.  There are Lustre users than have their own branches. 
LLNL has
> >>>> probably the best tested branch among all users. 
DDN''s customers
> >>>> have a version of Lustre that includes patches not yet in
Sun''s
> >>>> releases.  It would be very valuable if these kind of
releases
> >>>> could be collected in a publicly accessible GIT
repository.
> >>>
> >>> That is true even today - most of the patches that are in the
DDN
> >>> branches were initially developed by Sun and are already in
the
> >>> publicly-available Lustre CVS, and many of the LLNL patches
have or
> >>> are being landed for the 1.8.2 release.
> >>>
> >>> As you know, there will always be a delta of patches that are
not in
> >>> an official release, and will be available in the next one. 
With
> >>> the increase in testing to improve the quality of new releases
> >>> compared to the past, releases are by necessity less frequent.
> >>> Should anyone have a desire for more bleeding-edge code, they
have
> >>> always been able fetch the current branch before its release,
> >>> regardless of whether this is Git or CVS.  We maintain a
number of
> >>> different branches (b1_8 for incremental development,
> >>> b_release_1_8_1 for critical fixes on the 1.8.1 release, etc)
these
> >>> are already available to the public.
> >>>
> >>>> I doubt that Sun will give commit rights to external
entities (this
> >>>> is not unreasonable, Sun needs to control what code enters
its
> >>>> repositories).  Hence I think that the community would be
better
> >>>> served with a GIT repository in a public place, like
github, that
> >>>> can give such access.
> >>>
> >>> While CVS was very restrictive in terms of managing external
commit
> >>> permissions due to its monolithic repository, some external
> >>> contributors have had commit access to CVS prior our migration
to
> >>> Git, based on need.  With the migration to Git there is no
need to
> >>> manage such access ourselves, as developers are able to host
their
> >>> clones wherever they want.  The git.lustre.org repository will
> >>> remain the canonical source for Sun releases, and we will be
happy
> >>> to pull fixes into this repository that meet the quality
guidelines
> >>> stated above.  I for one would welcome external inspectors on
> >>> patches, and we continue to work with external sites to do
scale
> >>> testing of Lustre.
> >>>
> >>>> My group at ClusterStor has reserved the
"lustre" project at Github
> >>>> and we will give keys to any and all organizations that
wish to
> >>>> make serious contributions to Lustre.  I was in particular
hoping
> >>>> that LLNL would be willing to commit their releases to
that public
> >>>> place.
> >>>
> >>>
> >>> Note that with Git and github.com there is no need to give
keys to
> >>> anyone, and in fact that would seem to be detrimental to
> >>> ClusterStor, because the "lustre" clone you have
reserved is within
> >>> your company''s private hosting space (i.e.
> http://github.com/clusterstor/lustre
> >>> ).  With Github (or Git in general) it is possible for anyone
to
> >>> make their own clone or mirror of a repository at any time, no
keys
> >>> or permission required, and it will appear
ashttp://github.com/
> >>> {user}/lustre or whatever they want to call it.
> >>>
> >>>> b.  Everyone is uncertain about what Sun will do with
Lustre
> >>>> (proprietary Solaris / ZFS server releases and
discontinued support
> >>>> for Linux servers have been mentioned to me several times
now).  A
> >>>> public repository with the open code will be valuable for
the
> >>>> community and promote continued development and access.
> >>>
> >>> I agree that a public repository is important, and we will
continue
> >>> to host one at git.lustre.org as we have in the past for CVS,
and it
> >>> can and should be cloned as needed.  As you are hopefully
aware,
> >>> with Git every checkout has a full copy of the repository,
including
> >>> all history, so the code is already very "open" and
"public".
> >>> Lustre is, and will continue to be, available as GPL software.
> >>>
> >>> We definitely welcome external contributions to Lustre, which
have
> >>> in the past been done by a small number of people outside of
Sun.  I
> >>> don''t think the choice of CVS or Git or hosting site
has ever been a
> >>> limiting factor in this regard.  We look forward to
contributions of
> >>> fixes, designs, and features, from ClusterStor, as we would
with any
> >>> Lustre contributor.
> >>>
> >>>> 2. We need MUCH more in the repository than Sun is putting
into it.
> >>>>
> >>>> There are many development branches and sometimes
abandoned
> >>>> projects that still have a lot of value.  For example,
there is a
> >>>> nearly complete OS X client port - what if someone wanted
to pick
> >>>> that up?  Similarly, there are projects like size on MDS
or the
> >>>> network request scheduler that may need help from the
community to
> >>>> get finished or re-prioritized.
> >>>
> >>> All of the Lustre history is still available in CVS, as it has
> >>> always been.  As far as I know (I''ve never checked it
out myself)
> >>> even the OS/X client port is publicly available today, which
was not
> >>> true a few years ago.
> >>>
> >>> Due to the convoluted branch, repository, and tag abuse that
was
> >>> used to manage the Lustre code in CVS, there is a non-zero
effort
> >>> required to migrate any of the branches in CVS to Git.  Rather
than
> >>> bring all of the old detritus along into Git, only the main
> >>> development/production branches are being automatically
migrated
> >>> initially.
> >>>
> >>> Now that the Git migration is complete, the Sun maintainers of
non-
> >>> release features (HSM, SOM, CMD, NRS, etc) will be creating
Git
> >>> clones and landing their work into them as time permits.
> >>>
> >>> If anyone wants to import one of the other CVS branches (e.g.
OS/X),
> >>> all they will need to do is create a patch from that branch
and then
> >>> commit this into their own Git clone.
> >>>
> >>>> It is unclear to me if these kind of branches can be found
in the
> >>>> publicly available CVS.
> >>>
> >>> Yes, they can, as they always have been.  The CVS repository
will
> >>> remain available indefinitely for spelunking expeditions
should the
> >>> need arise.  Note that the full history that leads to the
current
> >>> release branches (b1_6, b1_8, HEAD) is available in Git, so
there is
> >>> at least a trail of breadcrumbs leading to where we are today.
> >>>
> >>>> If they can, a collection of relevant branches, broadly
along the
> >>>> lines of what I mention above, should be placed in the
public GIT
> >>>> repository.
> >>>
> >>> For currently-active branches this was already our plan.  For
> >>> historical and inactive branches, and we welcome any
contributions
> >>> that bring these ancient CVS branches back to life.  Nikita is
> >>> probably best positioned to know what needs to be imported
from the
> >>> OS/X branch in CVS, and if there are other particular branches
that
> >>> contain important work we''ll be happy to discuss them
with you.  It
> >>> will of course be possible to create Git clones for these old
> >>> branches as needed.
> >>>
> >>>> 3. Brian''s email message seems to indicate that
Sun''s git
> >>>> repository will be used for Sun development.  In the past
there
> >>>> were two CVS repositories - a read-only one that was
publicly
> >>>> accessible and when I last controlled the group it was
updated very
> >>>> frequently with all open source code (presently, it seems
to only
> >>>> contain releases, not the development stream of commits).
> >>>
> >>> That''s not correct.  The public cvs.lustre.org
repository in fact
> >>> contains all of the Lustre commits and all of the history.  I
just
> >>> did a checkout and there are in fact tags and branches for the
pre-
> >>> release 1.8.2 builds, lprocfs rewrite, CMD, etc. that are very
much
> >>> works in progress.
> >>>
> >>> One of the very last commits on CVS HEAD was on Thursday
before CVS
> >>> went read-only, from a patch submitted by LLNL:
> >>>
> >>> revision 1.593
> >>> date: 2009/12/10 13:52:51;  author: dzogin;  state: Exp; 
lines:
> >>> +5 -0
> >>> Branch HEAD
> >>> b=21259
> >>> i=andrew.perepechko
> >>> i=alexey.lyashkov
> >>>
----------------------------------------------------------------------
> >>> Description: Allow non-root access for "lfs check".
> >>> Details    : Added a check in obd_class_ioctl() for
> >>> OBD_IOC_PING_TARGET.
> >>>
> >>>
> >>>> It is unclear how Sun can manage development with this git
> >>>> repository given that parts of its work are proprietary
(like the
> >>>> Windows port) or unreleased (like the ZFS work).  Can we
get more
> >>>> insight in what Brian is alluding to?
> >>>
> >>> I''m not sure what "alluding" you are
alluding to?
> >>>
> >>> Of course, if there is any proprietary code developed it will
just
> >>> not be pushed to the public git.lustre.org repository.  I
expect
> >>> that any proprietary or unreleased code that ClusterStor is
already
> >>> or will develop will similarly not be posted publicly until
you are
> >>> ready to do so.
> >>>
> >>> Sun''s current in-progress code will very likely
reside in separate
> >>> clones at git.lustre.org, but will not be merged into the Sun
Prime
> >>> repository for an official release until it is inspected,
tested,
> >>> and has permission to land.  Pulls into the Sun Prime
repository
> >>> will be done by the release manager for each branch, as
previously
> >>> stated.  The Lustre engineers at ClusterStor are already
familiar
> >>> with this process and have already had their first patch pass
> >>> inspections and it is ready for landing.
> >>>
> >>> That is one of the major benefits of Git over CVS - that there
ISN''T
> >>> a single repository, and in fact every clone has a full copy
of the
> >>> history and can be used by anyone.  There is no need to have
all of
> >>> the development done in branches on a single repository, but
rather
> >>> to keep projects in their own clones.
> >>>
> >>> That allows developers to do local commits on their machines,
to
> >>> push it to their public clone if they want to share their work
and/
> >>> or make an offsite backup, and people are free to choose which
clone
> >>> one they use.  Sun''s Prime repository used for
releases will only
> >>> contain stable Lustre code.  This is the Git usage model for
the
> >>> Linux kernel, and think it is a good one to follow for Lustre
as
> >>> well.  You are free to manage your clones in some other way.
> >>>
> >>> Cheers, Andreas
> >>> --
> >>> Andreas Dilger
> >>> Sr. Staff Engineer, Lustre Group
> >>> Sun Microsystems of Canada, Inc.
> >> _______________________________________________
> >> Lustre-devel mailing list
> >> Lustre-devel at lists.lustre.org
> >> http://lists.lustre.org/mailman/listinfo/lustre-devel
> >>
>
>
> Cheers, Andreas
> --
> Andreas Dilger
> Sr. Staff Engineer, Lustre Group
> Sun Microsystems of Canada, Inc.
>
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.lustre.org/pipermail/lustre-devel/attachments/20091231/a0c7ef8d/attachment-0001.html

There was a lot of steam about the GIT conversion but it seems there
haven''t been any commits since Dec 14 2009. Or is there another site I
can see for the updates?

TIA


On Wed, Dec 30, 2009 at 9:20 PM, Peter Braam
<peter.braam at clusterstor.com> wrote:
>
>
> On Wed, Dec 30, 2009 at 11:12 PM, Andreas Dilger <adilger at sun.com>
wrote:
>>
>> On 2009-12-27, at 17:49, Mag Gam wrote:
>> > I though majority of the lustre development and support was from
Sun.
>> > This is news to us.
>>
>> Peter has his own opinions and motivations, and does not in any way
>> speak for Sun. ?His comments should in no way be confused with any
>> statement of direction for Lustre. ?Sun will continue Lustre
>> development and support in the future.
>>
>
> Indeed. ?Let''s see if Sun''s VP of HPC Marc Hamilton can
clarify what he told
> someone who works for me. ?Hopefully the plans have changed. ?I
haven''t met
> anybody who is informed about the facts, and doesn''t share my
concerns,
> including many senior staff in the Lustre team.
> As for my own motivations, I would like the Lustre community to continue to
> aid high-end HPC.
> Peter
>>
>> > Nevertheless I am glad Sun did this conversion.
>>
>> Thanks. ?We worked hard to make sure the transition to Git was
>> successful.
>>
>> > Couple of questions:
>> >
>> > 1) What will happen to the Wiki? It still has a lot of Sun stuff
on
>> > it (logo)
>>
>> The wiki is continuing to be improved by our documentation team.
>>
>> > 2) Will we still keep bugzilla.lustre.org?
>>
>> Yes.
>>
>> > 3) Will there ever be a git over http? This is important for
people
>> > who are behind firewalls.
>>
>> I''ll pass that question on to our Git administration folks.
>>
>> > Also, it would be nice to have the RPMs on the Wiki instead of
>> > registering with Sun.
>>
>> I don''t think that will be changing in the near future, but
our
>> management is aware of this issue.
>>
>> > On Sat, Dec 26, 2009 at 10:01 AM, Peter Braam
>> > <peter.braam at clusterstor.com> wrote:
>> >> Sent from my iPhone
>> >>
>> >> On Dec 15, 2009, at 14:05, Andreas Dilger <adilger at
sun.com> wrote:
>> >>
>> >>> Hello Peter,
>> >>>
>> >>> As previously announced, we have already made the initial
Lustre
>> >>> repository available to everyone this week at
git.lustre.org. ?This
>> >>> repository contains all of the main development and
release branches
>> >>> and their history. ?It''s where all of the Sun
developers and
>> >>> maintaners will get their sources from, and it will
continue to be
>> >>> available under the GPL v2 license as it always has been.
>> >>>
>> >>> Sun''s policy of prioritizing stability, not just
for releases but
>> >>> also
>> >>> to underpin development, makes safeguarding the quality of
this
>> >>> repository paramount. ?Everyone contributing to the Lustre
sources -
>> >>> not just internal Sun engineers but also external
contributors like
>> >>> LLNL, CEA, ORNL and DDN - is therefore subject to the same
>> >>> gatekeeping
>> >>> procedures and must follow the same patch submission,
testing and
>> >>> landing processes. ?These are further detailed in the wiki
pages
>> >>> that
>> >>> were in the original announcement:
>> >>>
>> >>> http://wiki.lustre.org/index.php/Accessing_Lustre_Code
>> >>> http://wiki.lustre.org/index.php/Submitting_Patches
>> >>>
>> >>>
>> >>
>> >> Sun is no longer supporting the Lustre community (storage OEMs
and
>> >> others have been refused further support). ?The model you
describe
>> >> won''t apply much longer I think. ?People will be
looking for
>> >> different
>> >> arrangements.
>> >>
>> >> Peter
>> >>
>> >>
>> >>
>> >>> For people not familiar with Git, it should be clarified
that
>> >>> limiting commits to the Sun Prime repository does not in
any way
>> >>> restrict access to the Lustre code, or the ability of
non-Sun
>> >>> developers to share their own Git clone with the Lustre
community.
>> >>> Developers will be able to host their own Lustre clones
(essentially
>> >>> full repositories) as and where they wish. ?The major
advantage of
>> >>> Git is that anyone can pull from any repository, or in
fact from a
>> >>> number of different repositories at the same time - this
choice is
>> >>> left to the user.
>> >>>
>> >>> This is the same model used by the Linux kernel, and has
proven to
>> >>> work well with Git. ?Each kernel developer hosts their own
clone(s)
>> >>> at git.kernel.org, or at some other site like repo.or.cz,
or
>> >>> github.com
>> >>> , and when they have changes to submit upstream they send
an email
>> >>> (usually containing both the patch, and the git URL to
pull from) to
>> >>> the subsystem maintainer, or to Linus directly, requesting
that he
>> >>> pull their changes. ?This pull request is normally only
sent after
>> >>> the patch has been reviewed, possibly multiple times, ?by
the
>> >>> appropriate subsystem maintainers. ?Each developer has
full control
>> >>> over their own clone, and in fact it is rare that more
than one
>> >>> person has push access to a clone.
>> >>>
>> >>> The fact that there are many different clones (some more
important,
>> >>> and others less so) in no way implies that the kernel is
being
>> >>> forked, but rather that this is the standard way in which
to use Git
>> >>> to exchange changes. ?The location at which a clone is
hosted also
>> >>> has no bearing on its usefulness.
>> >>>
>> >>>
>> >>>
>> >>> To answer your specific concerns in more detail,
>> >>>
>> >>> On 2009-12-13, at 11:47, Peter Braam wrote:
>> >>>> 1. We need a public repository, where non Sun
community members can
>> >>>> commit.
>> >>>>
>> >>>> a. ?There are Lustre users than have their own
branches. ?LLNL has
>> >>>> probably the best tested branch among all users.
?DDN''s customers
>> >>>> have a version of Lustre that includes patches not yet
in Sun''s
>> >>>> releases. ?It would be very valuable if these kind of
releases
>> >>>> could be collected in a publicly accessible GIT
repository.
>> >>>
>> >>> That is true even today - most of the patches that are in
the DDN
>> >>> branches were initially developed by Sun and are already
in the
>> >>> publicly-available Lustre CVS, and many of the LLNL
patches have or
>> >>> are being landed for the 1.8.2 release.
>> >>>
>> >>> As you know, there will always be a delta of patches that
are not in
>> >>> an official release, and will be available in the next
one. ?With
>> >>> the increase in testing to improve the quality of new
releases
>> >>> compared to the past, releases are by necessity less
frequent.
>> >>> Should anyone have a desire for more bleeding-edge code,
they have
>> >>> always been able fetch the current branch before its
release,
>> >>> regardless of whether this is Git or CVS. ?We maintain a
number of
>> >>> different branches (b1_8 for incremental development,
>> >>> b_release_1_8_1 for critical fixes on the 1.8.1 release,
etc) these
>> >>> are already available to the public.
>> >>>
>> >>>> I doubt that Sun will give commit rights to external
entities (this
>> >>>> is not unreasonable, Sun needs to control what code
enters its
>> >>>> repositories). ?Hence I think that the community would
be better
>> >>>> served with a GIT repository in a public place, like
github, that
>> >>>> can give such access.
>> >>>
>> >>> While CVS was very restrictive in terms of managing
external commit
>> >>> permissions due to its monolithic repository, some
external
>> >>> contributors have had commit access to CVS prior our
migration to
>> >>> Git, based on need. ?With the migration to Git there is no
need to
>> >>> manage such access ourselves, as developers are able to
host their
>> >>> clones wherever they want. ?The git.lustre.org repository
will
>> >>> remain the canonical source for Sun releases, and we will
be happy
>> >>> to pull fixes into this repository that meet the quality
guidelines
>> >>> stated above. ?I for one would welcome external inspectors
on
>> >>> patches, and we continue to work with external sites to do
scale
>> >>> testing of Lustre.
>> >>>
>> >>>> My group at ClusterStor has reserved the
"lustre" project at Github
>> >>>> and we will give keys to any and all organizations
that wish to
>> >>>> make serious contributions to Lustre. ?I was in
particular hoping
>> >>>> that LLNL would be willing to commit their releases to
that public
>> >>>> place.
>> >>>
>> >>>
>> >>> Note that with Git and github.com there is no need to give
keys to
>> >>> anyone, and in fact that would seem to be detrimental to
>> >>> ClusterStor, because the "lustre" clone you have
reserved is within
>> >>> your company''s private hosting space (i.e.
>> >>> http://github.com/clusterstor/lustre
>> >>> ). ?With Github (or Git in general) it is possible for
anyone to
>> >>> make their own clone or mirror of a repository at any
time, no keys
>> >>> or permission required, and it will appear
ashttp://github.com/
>> >>> {user}/lustre or whatever they want to call it.
>> >>>
>> >>>> b. ?Everyone is uncertain about what Sun will do with
Lustre
>> >>>> (proprietary Solaris / ZFS server releases and
discontinued support
>> >>>> for Linux servers have been mentioned to me several
times now). ?A
>> >>>> public repository with the open code will be valuable
for the
>> >>>> community and promote continued development and
access.
>> >>>
>> >>> I agree that a public repository is important, and we will
continue
>> >>> to host one at git.lustre.org as we have in the past for
CVS, and it
>> >>> can and should be cloned as needed. ?As you are hopefully
aware,
>> >>> with Git every checkout has a full copy of the repository,
including
>> >>> all history, so the code is already very "open"
and "public".
>> >>> Lustre is, and will continue to be, available as GPL
software.
>> >>>
>> >>> We definitely welcome external contributions to Lustre,
which have
>> >>> in the past been done by a small number of people outside
of Sun. ?I
>> >>> don''t think the choice of CVS or Git or hosting
site has ever been a
>> >>> limiting factor in this regard. ?We look forward to
contributions of
>> >>> fixes, designs, and features, from ClusterStor, as we
would with any
>> >>> Lustre contributor.
>> >>>
>> >>>> 2. We need MUCH more in the repository than Sun is
putting into it.
>> >>>>
>> >>>> There are many development branches and sometimes
abandoned
>> >>>> projects that still have a lot of value. ?For example,
there is a
>> >>>> nearly complete OS X client port - what if someone
wanted to pick
>> >>>> that up? ?Similarly, there are projects like size on
MDS or the
>> >>>> network request scheduler that may need help from the
community to
>> >>>> get finished or re-prioritized.
>> >>>
>> >>> All of the Lustre history is still available in CVS, as it
has
>> >>> always been. ?As far as I know (I''ve never
checked it out myself)
>> >>> even the OS/X client port is publicly available today,
which was not
>> >>> true a few years ago.
>> >>>
>> >>> Due to the convoluted branch, repository, and tag abuse
that was
>> >>> used to manage the Lustre code in CVS, there is a non-zero
effort
>> >>> required to migrate any of the branches in CVS to Git.
?Rather than
>> >>> bring all of the old detritus along into Git, only the
main
>> >>> development/production branches are being automatically
migrated
>> >>> initially.
>> >>>
>> >>> Now that the Git migration is complete, the Sun
maintainers of non-
>> >>> release features (HSM, SOM, CMD, NRS, etc) will be
creating Git
>> >>> clones and landing their work into them as time permits.
>> >>>
>> >>> If anyone wants to import one of the other CVS branches
(e.g. OS/X),
>> >>> all they will need to do is create a patch from that
branch and then
>> >>> commit this into their own Git clone.
>> >>>
>> >>>> It is unclear to me if these kind of branches can be
found in the
>> >>>> publicly available CVS.
>> >>>
>> >>> Yes, they can, as they always have been. ?The CVS
repository will
>> >>> remain available indefinitely for spelunking expeditions
should the
>> >>> need arise. ?Note that the full history that leads to the
current
>> >>> release branches (b1_6, b1_8, HEAD) is available in Git,
so there is
>> >>> at least a trail of breadcrumbs leading to where we are
today.
>> >>>
>> >>>> If they can, a collection of relevant branches,
broadly along the
>> >>>> lines of what I mention above, should be placed in the
public GIT
>> >>>> repository.
>> >>>
>> >>> For currently-active branches this was already our plan.
?For
>> >>> historical and inactive branches, and we welcome any
contributions
>> >>> that bring these ancient CVS branches back to life.
?Nikita is
>> >>> probably best positioned to know what needs to be imported
from the
>> >>> OS/X branch in CVS, and if there are other particular
branches that
>> >>> contain important work we''ll be happy to discuss
them with you. ?It
>> >>> will of course be possible to create Git clones for these
old
>> >>> branches as needed.
>> >>>
>> >>>> 3. Brian''s email message seems to indicate
that Sun''s git
>> >>>> repository will be used for Sun development. ?In the
past there
>> >>>> were two CVS repositories - a read-only one that was
publicly
>> >>>> accessible and when I last controlled the group it was
updated very
>> >>>> frequently with all open source code (presently, it
seems to only
>> >>>> contain releases, not the development stream of
commits).
>> >>>
>> >>> That''s not correct. ?The public cvs.lustre.org
repository in fact
>> >>> contains all of the Lustre commits and all of the history.
?I just
>> >>> did a checkout and there are in fact tags and branches for
the pre-
>> >>> release 1.8.2 builds, lprocfs rewrite, CMD, etc. that are
very much
>> >>> works in progress.
>> >>>
>> >>> One of the very last commits on CVS HEAD was on Thursday
before CVS
>> >>> went read-only, from a patch submitted by LLNL:
>> >>>
>> >>> revision 1.593
>> >>> date: 2009/12/10 13:52:51; ?author: dzogin; ?state: Exp;
?lines:
>> >>> +5 -0
>> >>> Branch HEAD
>> >>> b=21259
>> >>> i=andrew.perepechko
>> >>> i=alexey.lyashkov
>> >>>
----------------------------------------------------------------------
>> >>> Description: Allow non-root access for "lfs
check".
>> >>> Details ? ?: Added a check in obd_class_ioctl() for
>> >>> OBD_IOC_PING_TARGET.
>> >>>
>> >>>
>> >>>> It is unclear how Sun can manage development with this
git
>> >>>> repository given that parts of its work are
proprietary (like the
>> >>>> Windows port) or unreleased (like the ZFS work). ?Can
we get more
>> >>>> insight in what Brian is alluding to?
>> >>>
>> >>> I''m not sure what "alluding" you are
alluding to?
>> >>>
>> >>> Of course, if there is any proprietary code developed it
will just
>> >>> not be pushed to the public git.lustre.org repository. ?I
expect
>> >>> that any proprietary or unreleased code that ClusterStor
is already
>> >>> or will develop will similarly not be posted publicly
until you are
>> >>> ready to do so.
>> >>>
>> >>> Sun''s current in-progress code will very likely
reside in separate
>> >>> clones at git.lustre.org, but will not be merged into the
Sun Prime
>> >>> repository for an official release until it is inspected,
tested,
>> >>> and has permission to land. ?Pulls into the Sun Prime
repository
>> >>> will be done by the release manager for each branch, as
previously
>> >>> stated. ?The Lustre engineers at ClusterStor are already
familiar
>> >>> with this process and have already had their first patch
pass
>> >>> inspections and it is ready for landing.
>> >>>
>> >>> That is one of the major benefits of Git over CVS - that
there ISN''T
>> >>> a single repository, and in fact every clone has a full
copy of the
>> >>> history and can be used by anyone. ?There is no need to
have all of
>> >>> the development done in branches on a single repository,
but rather
>> >>> to keep projects in their own clones.
>> >>>
>> >>> That allows developers to do local commits on their
machines, to
>> >>> push it to their public clone if they want to share their
work and/
>> >>> or make an offsite backup, and people are free to choose
which clone
>> >>> one they use. ?Sun''s Prime repository used for
releases will only
>> >>> contain stable Lustre code. ?This is the Git usage model
for the
>> >>> Linux kernel, and think it is a good one to follow for
Lustre as
>> >>> well. ?You are free to manage your clones in some other
way.
>> >>>
>> >>> Cheers, Andreas
>> >>> --
>> >>> Andreas Dilger
>> >>> Sr. Staff Engineer, Lustre Group
>> >>> Sun Microsystems of Canada, Inc.
>> >> _______________________________________________
>> >> Lustre-devel mailing list
>> >> Lustre-devel at lists.lustre.org
>> >> http://lists.lustre.org/mailman/listinfo/lustre-devel
>> >>
>>
>>
>> Cheers, Andreas
>> --
>> Andreas Dilger
>> Sr. Staff Engineer, Lustre Group
>> Sun Microsystems of Canada, Inc.
>>
>> _______________________________________________
>> Lustre-devel mailing list
>> Lustre-devel at lists.lustre.org
>> http://lists.lustre.org/mailman/listinfo/lustre-devel
>
>

On Fri, 2010-02-05 at 08:16 -0500, Mag Gam wrote:
> There was a lot of steam about the GIT conversion but it seems there
> haven''t been any commits since Dec 14 2009. Or is there another
site I
> can see for the updates?
I don''t see the problem here -- I have been getting updates regularly.
Are you doing a "git pull" in your cloned repository prior to running
"git log" or "gitk"?

-- 
Dave Dillow
National Center for Computational Science
Oak Ridge National Laboratory
(865) 241-6602 office

On 2010-02-05, at 06:16, Mag Gam wrote:
> There was a lot of steam about the GIT conversion but it seems there
> haven''t been any commits since Dec 14 2009. Or is there another
site I
> can see for the updates?
The official git repository at git://git.lustre.org/prime/lustre.git  
is both the public repository and the same one that the Lustre  
developers use and is of course updated all the time.  It contains  
both the HEAD (2.0) and b1_8 branches.

If you are having trouble accessing this repo, please let us know.
> On Wed, Dec 30, 2009 at 9:20 PM, Peter Braam
> <peter.braam at clusterstor.com> wrote:
>>
>> On Wed, Dec 30, 2009 at 11:12 PM, Andreas Dilger <adilger at
sun.com>
>> wrote:
>>>
>>> On 2009-12-27, at 17:49, Mag Gam wrote:
>>>> I though majority of the lustre development and support was
from
>>>> Sun.
>>>> This is news to us.
>>>
>>> Peter has his own opinions and motivations, and does not in any way
>>> speak for Sun.  His comments should in no way be confused with any
>>> statement of direction for Lustre.  Sun will continue Lustre
>>> development and support in the future.
>>>
>>
>> Indeed.  Let''s see if Sun''s VP of HPC Marc Hamilton
can clarify
>> what he told
>> someone who works for me.  Hopefully the plans have changed.  I  
>> haven''t met
>> anybody who is informed about the facts, and doesn''t share my
>> concerns,
>> including many senior staff in the Lustre team.
>> As for my own motivations, I would like the Lustre community to  
>> continue to
>> aid high-end HPC.
>> Peter
>>>
>>>> Nevertheless I am glad Sun did this conversion.
>>>
>>> Thanks.  We worked hard to make sure the transition to Git was
>>> successful.
>>>
>>>> Couple of questions:
>>>>
>>>> 1) What will happen to the Wiki? It still has a lot of Sun
stuff on
>>>> it (logo)
>>>
>>> The wiki is continuing to be improved by our documentation team.
>>>
>>>> 2) Will we still keep bugzilla.lustre.org?
>>>
>>> Yes.
>>>
>>>> 3) Will there ever be a git over http? This is important for
people
>>>> who are behind firewalls.
>>>
>>> I''ll pass that question on to our Git administration
folks.
>>>
>>>> Also, it would be nice to have the RPMs on the Wiki instead of
>>>> registering with Sun.
>>>
>>> I don''t think that will be changing in the near future,
but our
>>> management is aware of this issue.
>>>
>>>> On Sat, Dec 26, 2009 at 10:01 AM, Peter Braam
>>>> <peter.braam at clusterstor.com> wrote:
>>>>> Sent from my iPhone
>>>>>
>>>>> On Dec 15, 2009, at 14:05, Andreas Dilger <adilger at
sun.com> wrote:
>>>>>
>>>>>> Hello Peter,
>>>>>>
>>>>>> As previously announced, we have already made the
initial Lustre
>>>>>> repository available to everyone this week at
git.lustre.org.
>>>>>> This
>>>>>> repository contains all of the main development and
release
>>>>>> branches
>>>>>> and their history.  It''s where all of the Sun
developers and
>>>>>> maintaners will get their sources from, and it will
continue to
>>>>>> be
>>>>>> available under the GPL v2 license as it always has
been.
>>>>>>
>>>>>> Sun''s policy of prioritizing stability, not
just for releases but
>>>>>> also
>>>>>> to underpin development, makes safeguarding the quality
of this
>>>>>> repository paramount.  Everyone contributing to the
Lustre
>>>>>> sources -
>>>>>> not just internal Sun engineers but also external
contributors
>>>>>> like
>>>>>> LLNL, CEA, ORNL and DDN - is therefore subject to the
same
>>>>>> gatekeeping
>>>>>> procedures and must follow the same patch submission,
testing and
>>>>>> landing processes.  These are further detailed in the
wiki pages
>>>>>> that
>>>>>> were in the original announcement:
>>>>>>
>>>>>> http://wiki.lustre.org/index.php/Accessing_Lustre_Code
>>>>>> http://wiki.lustre.org/index.php/Submitting_Patches
>>>>>>
>>>>>>
>>>>>
>>>>> Sun is no longer supporting the Lustre community (storage
OEMs and
>>>>> others have been refused further support).  The model you
describe
>>>>> won''t apply much longer I think.  People will be
looking for
>>>>> different
>>>>> arrangements.
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>>
>>>>>> For people not familiar with Git, it should be
clarified that
>>>>>> limiting commits to the Sun Prime repository does not
in any way
>>>>>> restrict access to the Lustre code, or the ability of
non-Sun
>>>>>> developers to share their own Git clone with the Lustre
>>>>>> community.
>>>>>> Developers will be able to host their own Lustre clones
>>>>>> (essentially
>>>>>> full repositories) as and where they wish.  The major
advantage
>>>>>> of
>>>>>> Git is that anyone can pull from any repository, or in
fact
>>>>>> from a
>>>>>> number of different repositories at the same time -
this choice
>>>>>> is
>>>>>> left to the user.
>>>>>>
>>>>>> This is the same model used by the Linux kernel, and
has proven
>>>>>> to
>>>>>> work well with Git.  Each kernel developer hosts their
own
>>>>>> clone(s)
>>>>>> at git.kernel.org, or at some other site like
repo.or.cz, or
>>>>>> github.com
>>>>>> , and when they have changes to submit upstream they
send an
>>>>>> email
>>>>>> (usually containing both the patch, and the git URL to
pull
>>>>>> from) to
>>>>>> the subsystem maintainer, or to Linus directly,
requesting that
>>>>>> he
>>>>>> pull their changes.  This pull request is normally only
sent
>>>>>> after
>>>>>> the patch has been reviewed, possibly multiple times, 
by the
>>>>>> appropriate subsystem maintainers.  Each developer has
full
>>>>>> control
>>>>>> over their own clone, and in fact it is rare that more
than one
>>>>>> person has push access to a clone.
>>>>>>
>>>>>> The fact that there are many different clones (some
more
>>>>>> important,
>>>>>> and others less so) in no way implies that the kernel
is being
>>>>>> forked, but rather that this is the standard way in
which to
>>>>>> use Git
>>>>>> to exchange changes.  The location at which a clone is
hosted
>>>>>> also
>>>>>> has no bearing on its usefulness.
>>>>>>
>>>>>>
>>>>>>
>>>>>> To answer your specific concerns in more detail,
>>>>>>
>>>>>> On 2009-12-13, at 11:47, Peter Braam wrote:
>>>>>>> 1. We need a public repository, where non Sun
community
>>>>>>> members can
>>>>>>> commit.
>>>>>>>
>>>>>>> a.  There are Lustre users than have their own
branches.  LLNL
>>>>>>> has
>>>>>>> probably the best tested branch among all users. 
DDN''s
>>>>>>> customers
>>>>>>> have a version of Lustre that includes patches not
yet in Sun''s
>>>>>>> releases.  It would be very valuable if these kind
of releases
>>>>>>> could be collected in a publicly accessible GIT
repository.
>>>>>>
>>>>>> That is true even today - most of the patches that are
in the DDN
>>>>>> branches were initially developed by Sun and are
already in the
>>>>>> publicly-available Lustre CVS, and many of the LLNL
patches
>>>>>> have or
>>>>>> are being landed for the 1.8.2 release.
>>>>>>
>>>>>> As you know, there will always be a delta of patches
that are
>>>>>> not in
>>>>>> an official release, and will be available in the next
one.  With
>>>>>> the increase in testing to improve the quality of new
releases
>>>>>> compared to the past, releases are by necessity less
frequent.
>>>>>> Should anyone have a desire for more bleeding-edge
code, they
>>>>>> have
>>>>>> always been able fetch the current branch before its
release,
>>>>>> regardless of whether this is Git or CVS.  We maintain
a number
>>>>>> of
>>>>>> different branches (b1_8 for incremental development,
>>>>>> b_release_1_8_1 for critical fixes on the 1.8.1
release, etc)
>>>>>> these
>>>>>> are already available to the public.
>>>>>>
>>>>>>> I doubt that Sun will give commit rights to
external entities
>>>>>>> (this
>>>>>>> is not unreasonable, Sun needs to control what code
enters its
>>>>>>> repositories).  Hence I think that the community
would be better
>>>>>>> served with a GIT repository in a public place,
like github,
>>>>>>> that
>>>>>>> can give such access.
>>>>>>
>>>>>> While CVS was very restrictive in terms of managing
external
>>>>>> commit
>>>>>> permissions due to its monolithic repository, some
external
>>>>>> contributors have had commit access to CVS prior our
migration to
>>>>>> Git, based on need.  With the migration to Git there is
no need
>>>>>> to
>>>>>> manage such access ourselves, as developers are able to
host
>>>>>> their
>>>>>> clones wherever they want.  The git.lustre.org
repository will
>>>>>> remain the canonical source for Sun releases, and we
will be
>>>>>> happy
>>>>>> to pull fixes into this repository that meet the
quality
>>>>>> guidelines
>>>>>> stated above.  I for one would welcome external
inspectors on
>>>>>> patches, and we continue to work with external sites to
do scale
>>>>>> testing of Lustre.
>>>>>>
>>>>>>> My group at ClusterStor has reserved the
"lustre" project at
>>>>>>> Github
>>>>>>> and we will give keys to any and all organizations
that wish to
>>>>>>> make serious contributions to Lustre.  I was in
particular
>>>>>>> hoping
>>>>>>> that LLNL would be willing to commit their releases
to that
>>>>>>> public
>>>>>>> place.
>>>>>>
>>>>>>
>>>>>> Note that with Git and github.com there is no need to
give keys
>>>>>> to
>>>>>> anyone, and in fact that would seem to be detrimental
to
>>>>>> ClusterStor, because the "lustre" clone you
have reserved is
>>>>>> within
>>>>>> your company''s private hosting space (i.e.
>>>>>> http://github.com/clusterstor/lustre
>>>>>> ).  With Github (or Git in general) it is possible for
anyone to
>>>>>> make their own clone or mirror of a repository at any
time, no
>>>>>> keys
>>>>>> or permission required, and it will appear
ashttp://github.com/
>>>>>> {user}/lustre or whatever they want to call it.
>>>>>>
>>>>>>> b.  Everyone is uncertain about what Sun will do
with Lustre
>>>>>>> (proprietary Solaris / ZFS server releases and
discontinued
>>>>>>> support
>>>>>>> for Linux servers have been mentioned to me several
times
>>>>>>> now).  A
>>>>>>> public repository with the open code will be
valuable for the
>>>>>>> community and promote continued development and
access.
>>>>>>
>>>>>> I agree that a public repository is important, and we
will
>>>>>> continue
>>>>>> to host one at git.lustre.org as we have in the past
for CVS,
>>>>>> and it
>>>>>> can and should be cloned as needed.  As you are
hopefully aware,
>>>>>> with Git every checkout has a full copy of the
repository,
>>>>>> including
>>>>>> all history, so the code is already very
"open" and "public".
>>>>>> Lustre is, and will continue to be, available as GPL
software.
>>>>>>
>>>>>> We definitely welcome external contributions to Lustre,
which
>>>>>> have
>>>>>> in the past been done by a small number of people
outside of
>>>>>> Sun.  I
>>>>>> don''t think the choice of CVS or Git or
hosting site has ever
>>>>>> been a
>>>>>> limiting factor in this regard.  We look forward to  
>>>>>> contributions of
>>>>>> fixes, designs, and features, from ClusterStor, as we
would
>>>>>> with any
>>>>>> Lustre contributor.
>>>>>>
>>>>>>> 2. We need MUCH more in the repository than Sun is
putting
>>>>>>> into it.
>>>>>>>
>>>>>>> There are many development branches and sometimes
abandoned
>>>>>>> projects that still have a lot of value.  For
example, there
>>>>>>> is a
>>>>>>> nearly complete OS X client port - what if someone
wanted to
>>>>>>> pick
>>>>>>> that up?  Similarly, there are projects like size
on MDS or the
>>>>>>> network request scheduler that may need help from
the
>>>>>>> community to
>>>>>>> get finished or re-prioritized.
>>>>>>
>>>>>> All of the Lustre history is still available in CVS, as
it has
>>>>>> always been.  As far as I know (I''ve never
checked it out myself)
>>>>>> even the OS/X client port is publicly available today,
which
>>>>>> was not
>>>>>> true a few years ago.
>>>>>>
>>>>>> Due to the convoluted branch, repository, and tag abuse
that was
>>>>>> used to manage the Lustre code in CVS, there is a
non-zero effort
>>>>>> required to migrate any of the branches in CVS to Git. 
Rather
>>>>>> than
>>>>>> bring all of the old detritus along into Git, only the
main
>>>>>> development/production branches are being automatically
migrated
>>>>>> initially.
>>>>>>
>>>>>> Now that the Git migration is complete, the Sun
maintainers of
>>>>>> non-
>>>>>> release features (HSM, SOM, CMD, NRS, etc) will be
creating Git
>>>>>> clones and landing their work into them as time
permits.
>>>>>>
>>>>>> If anyone wants to import one of the other CVS branches
(e.g.
>>>>>> OS/X),
>>>>>> all they will need to do is create a patch from that
branch and
>>>>>> then
>>>>>> commit this into their own Git clone.
>>>>>>
>>>>>>> It is unclear to me if these kind of branches can
be found in
>>>>>>> the
>>>>>>> publicly available CVS.
>>>>>>
>>>>>> Yes, they can, as they always have been.  The CVS
repository will
>>>>>> remain available indefinitely for spelunking
expeditions should
>>>>>> the
>>>>>> need arise.  Note that the full history that leads to
the current
>>>>>> release branches (b1_6, b1_8, HEAD) is available in
Git, so
>>>>>> there is
>>>>>> at least a trail of breadcrumbs leading to where we are
today.
>>>>>>
>>>>>>> If they can, a collection of relevant branches,
broadly along
>>>>>>> the
>>>>>>> lines of what I mention above, should be placed in
the public
>>>>>>> GIT
>>>>>>> repository.
>>>>>>
>>>>>> For currently-active branches this was already our
plan.  For
>>>>>> historical and inactive branches, and we welcome any  
>>>>>> contributions
>>>>>> that bring these ancient CVS branches back to life. 
Nikita is
>>>>>> probably best positioned to know what needs to be
imported from
>>>>>> the
>>>>>> OS/X branch in CVS, and if there are other particular
branches
>>>>>> that
>>>>>> contain important work we''ll be happy to
discuss them with
>>>>>> you.  It
>>>>>> will of course be possible to create Git clones for
these old
>>>>>> branches as needed.
>>>>>>
>>>>>>> 3. Brian''s email message seems to indicate
that Sun''s git
>>>>>>> repository will be used for Sun development.  In
the past there
>>>>>>> were two CVS repositories - a read-only one that
was publicly
>>>>>>> accessible and when I last controlled the group it
was updated
>>>>>>> very
>>>>>>> frequently with all open source code (presently, it
seems to
>>>>>>> only
>>>>>>> contain releases, not the development stream of
commits).
>>>>>>
>>>>>> That''s not correct.  The public cvs.lustre.org
repository in fact
>>>>>> contains all of the Lustre commits and all of the
history.  I
>>>>>> just
>>>>>> did a checkout and there are in fact tags and branches
for the
>>>>>> pre-
>>>>>> release 1.8.2 builds, lprocfs rewrite, CMD, etc. that
are very
>>>>>> much
>>>>>> works in progress.
>>>>>>
>>>>>> One of the very last commits on CVS HEAD was on
Thursday before
>>>>>> CVS
>>>>>> went read-only, from a patch submitted by LLNL:
>>>>>>
>>>>>> revision 1.593
>>>>>> date: 2009/12/10 13:52:51;  author: dzogin;  state:
Exp;  lines:
>>>>>> +5 -0
>>>>>> Branch HEAD
>>>>>> b=21259
>>>>>> i=andrew.perepechko
>>>>>> i=alexey.lyashkov
>>>>>>
----------------------------------------------------------------------
>>>>>> Description: Allow non-root access for "lfs
check".
>>>>>> Details    : Added a check in obd_class_ioctl() for
>>>>>> OBD_IOC_PING_TARGET.
>>>>>>
>>>>>>
>>>>>>> It is unclear how Sun can manage development with
this git
>>>>>>> repository given that parts of its work are
proprietary (like
>>>>>>> the
>>>>>>> Windows port) or unreleased (like the ZFS work). 
Can we get
>>>>>>> more
>>>>>>> insight in what Brian is alluding to?
>>>>>>
>>>>>> I''m not sure what "alluding" you are
alluding to?
>>>>>>
>>>>>> Of course, if there is any proprietary code developed
it will
>>>>>> just
>>>>>> not be pushed to the public git.lustre.org repository. 
I expect
>>>>>> that any proprietary or unreleased code that
ClusterStor is
>>>>>> already
>>>>>> or will develop will similarly not be posted publicly
until you
>>>>>> are
>>>>>> ready to do so.
>>>>>>
>>>>>> Sun''s current in-progress code will very
likely reside in
>>>>>> separate
>>>>>> clones at git.lustre.org, but will not be merged into
the Sun
>>>>>> Prime
>>>>>> repository for an official release until it is
inspected, tested,
>>>>>> and has permission to land.  Pulls into the Sun Prime
repository
>>>>>> will be done by the release manager for each branch, as
>>>>>> previously
>>>>>> stated.  The Lustre engineers at ClusterStor are
already familiar
>>>>>> with this process and have already had their first
patch pass
>>>>>> inspections and it is ready for landing.
>>>>>>
>>>>>> That is one of the major benefits of Git over CVS -
that there
>>>>>> ISN''T
>>>>>> a single repository, and in fact every clone has a full
copy of
>>>>>> the
>>>>>> history and can be used by anyone.  There is no need to
have
>>>>>> all of
>>>>>> the development done in branches on a single
repository, but
>>>>>> rather
>>>>>> to keep projects in their own clones.
>>>>>>
>>>>>> That allows developers to do local commits on their
machines, to
>>>>>> push it to their public clone if they want to share
their work
>>>>>> and/
>>>>>> or make an offsite backup, and people are free to
choose which
>>>>>> clone
>>>>>> one they use.  Sun''s Prime repository used for
releases will only
>>>>>> contain stable Lustre code.  This is the Git usage
model for the
>>>>>> Linux kernel, and think it is a good one to follow for
Lustre as
>>>>>> well.  You are free to manage your clones in some other
way.
>>>>>>
>>>>>> Cheers, Andreas
>>>>>> --
>>>>>> Andreas Dilger
>>>>>> Sr. Staff Engineer, Lustre Group
>>>>>> Sun Microsystems of Canada, Inc.
>>>>> _______________________________________________
>>>>> Lustre-devel mailing list
>>>>> Lustre-devel at lists.lustre.org
>>>>> http://lists.lustre.org/mailman/listinfo/lustre-devel
>>>>>
>>>
>>>
>>> Cheers, Andreas
>>> --
>>> Andreas Dilger
>>> Sr. Staff Engineer, Lustre Group
>>> Sun Microsystems of Canada, Inc.
>>>
>>> _______________________________________________
>>> Lustre-devel mailing list
>>> Lustre-devel at lists.lustre.org
>>> http://lists.lustre.org/mailman/listinfo/lustre-devel
>>
>>

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

Who is the git admin? We would really like to have http access it
makes a huge difference for people who are behind proxys


On Fri, Feb 5, 2010 at 12:42 PM, Andreas Dilger <adilger at sun.com>
wrote:
> On 2010-02-05, at 06:16, Mag Gam wrote:
>>
>> There was a lot of steam about the GIT conversion but it seems there
>> haven''t been any commits since Dec 14 2009. Or is there
another site I
>> can see for the updates?
>
> The official git repository at git://git.lustre.org/prime/lustre.git is
both
> the public repository and the same one that the Lustre developers use and
is
> of course updated all the time. ?It contains both the HEAD (2.0) and b1_8
> branches.
>
> If you are having trouble accessing this repo, please let us know.
>
>> On Wed, Dec 30, 2009 at 9:20 PM, Peter Braam
>> <peter.braam at clusterstor.com> wrote:
>>>
>>> On Wed, Dec 30, 2009 at 11:12 PM, Andreas Dilger <adilger at
sun.com> wrote:
>>>>
>>>> On 2009-12-27, at 17:49, Mag Gam wrote:
>>>>>
>>>>> I though majority of the lustre development and support was
from Sun.
>>>>> This is news to us.
>>>>
>>>> Peter has his own opinions and motivations, and does not in any
way
>>>> speak for Sun. ?His comments should in no way be confused with
any
>>>> statement of direction for Lustre. ?Sun will continue Lustre
>>>> development and support in the future.
>>>>
>>>
>>> Indeed. ?Let''s see if Sun''s VP of HPC Marc
Hamilton can clarify what he
>>> told
>>> someone who works for me. ?Hopefully the plans have changed. ?I
haven''t
>>> met
>>> anybody who is informed about the facts, and doesn''t share
my concerns,
>>> including many senior staff in the Lustre team.
>>> As for my own motivations, I would like the Lustre community to
continue
>>> to
>>> aid high-end HPC.
>>> Peter
>>>>
>>>>> Nevertheless I am glad Sun did this conversion.
>>>>
>>>> Thanks. ?We worked hard to make sure the transition to Git was
>>>> successful.
>>>>
>>>>> Couple of questions:
>>>>>
>>>>> 1) What will happen to the Wiki? It still has a lot of Sun
stuff on
>>>>> it (logo)
>>>>
>>>> The wiki is continuing to be improved by our documentation
team.
>>>>
>>>>> 2) Will we still keep bugzilla.lustre.org?
>>>>
>>>> Yes.
>>>>
>>>>> 3) Will there ever be a git over http? This is important
for people
>>>>> who are behind firewalls.
>>>>
>>>> I''ll pass that question on to our Git administration
folks.
>>>>
>>>>> Also, it would be nice to have the RPMs on the Wiki instead
of
>>>>> registering with Sun.
>>>>
>>>> I don''t think that will be changing in the near
future, but our
>>>> management is aware of this issue.
>>>>
>>>>> On Sat, Dec 26, 2009 at 10:01 AM, Peter Braam
>>>>> <peter.braam at clusterstor.com> wrote:
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Dec 15, 2009, at 14:05, Andreas Dilger <adilger
at sun.com> wrote:
>>>>>>
>>>>>>> Hello Peter,
>>>>>>>
>>>>>>> As previously announced, we have already made the
initial Lustre
>>>>>>> repository available to everyone this week at
git.lustre.org. ?This
>>>>>>> repository contains all of the main development and
release branches
>>>>>>> and their history. ?It''s where all of the
Sun developers and
>>>>>>> maintaners will get their sources from, and it will
continue to be
>>>>>>> available under the GPL v2 license as it always has
been.
>>>>>>>
>>>>>>> Sun''s policy of prioritizing stability,
not just for releases but
>>>>>>> also
>>>>>>> to underpin development, makes safeguarding the
quality of this
>>>>>>> repository paramount. ?Everyone contributing to the
Lustre sources -
>>>>>>> not just internal Sun engineers but also external
contributors like
>>>>>>> LLNL, CEA, ORNL and DDN - is therefore subject to
the same
>>>>>>> gatekeeping
>>>>>>> procedures and must follow the same patch
submission, testing and
>>>>>>> landing processes. ?These are further detailed in
the wiki pages
>>>>>>> that
>>>>>>> were in the original announcement:
>>>>>>>
>>>>>>>
http://wiki.lustre.org/index.php/Accessing_Lustre_Code
>>>>>>> http://wiki.lustre.org/index.php/Submitting_Patches
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Sun is no longer supporting the Lustre community
(storage OEMs and
>>>>>> others have been refused further support). ?The model
you describe
>>>>>> won''t apply much longer I think. ?People will
be looking for
>>>>>> different
>>>>>> arrangements.
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>>
>>>>>>> For people not familiar with Git, it should be
clarified that
>>>>>>> limiting commits to the Sun Prime repository does
not in any way
>>>>>>> restrict access to the Lustre code, or the ability
of non-Sun
>>>>>>> developers to share their own Git clone with the
Lustre community.
>>>>>>> Developers will be able to host their own Lustre
clones (essentially
>>>>>>> full repositories) as and where they wish. ?The
major advantage of
>>>>>>> Git is that anyone can pull from any repository, or
in fact from a
>>>>>>> number of different repositories at the same time -
this choice is
>>>>>>> left to the user.
>>>>>>>
>>>>>>> This is the same model used by the Linux kernel,
and has proven to
>>>>>>> work well with Git. ?Each kernel developer hosts
their own clone(s)
>>>>>>> at git.kernel.org, or at some other site like
repo.or.cz, or
>>>>>>> github.com
>>>>>>> , and when they have changes to submit upstream
they send an email
>>>>>>> (usually containing both the patch, and the git URL
to pull from) to
>>>>>>> the subsystem maintainer, or to Linus directly,
requesting that he
>>>>>>> pull their changes. ?This pull request is normally
only sent after
>>>>>>> the patch has been reviewed, possibly multiple
times, ?by the
>>>>>>> appropriate subsystem maintainers. ?Each developer
has full control
>>>>>>> over their own clone, and in fact it is rare that
more than one
>>>>>>> person has push access to a clone.
>>>>>>>
>>>>>>> The fact that there are many different clones (some
more important,
>>>>>>> and others less so) in no way implies that the
kernel is being
>>>>>>> forked, but rather that this is the standard way in
which to use Git
>>>>>>> to exchange changes. ?The location at which a clone
is hosted also
>>>>>>> has no bearing on its usefulness.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> To answer your specific concerns in more detail,
>>>>>>>
>>>>>>> On 2009-12-13, at 11:47, Peter Braam wrote:
>>>>>>>>
>>>>>>>> 1. We need a public repository, where non Sun
community members can
>>>>>>>> commit.
>>>>>>>>
>>>>>>>> a. ?There are Lustre users than have their own
branches. ?LLNL has
>>>>>>>> probably the best tested branch among all
users. ?DDN''s customers
>>>>>>>> have a version of Lustre that includes patches
not yet in Sun''s
>>>>>>>> releases. ?It would be very valuable if these
kind of releases
>>>>>>>> could be collected in a publicly accessible GIT
repository.
>>>>>>>
>>>>>>> That is true even today - most of the patches that
are in the DDN
>>>>>>> branches were initially developed by Sun and are
already in the
>>>>>>> publicly-available Lustre CVS, and many of the LLNL
patches have or
>>>>>>> are being landed for the 1.8.2 release.
>>>>>>>
>>>>>>> As you know, there will always be a delta of
patches that are not in
>>>>>>> an official release, and will be available in the
next one. ?With
>>>>>>> the increase in testing to improve the quality of
new releases
>>>>>>> compared to the past, releases are by necessity
less frequent.
>>>>>>> Should anyone have a desire for more bleeding-edge
code, they have
>>>>>>> always been able fetch the current branch before
its release,
>>>>>>> regardless of whether this is Git or CVS. ?We
maintain a number of
>>>>>>> different branches (b1_8 for incremental
development,
>>>>>>> b_release_1_8_1 for critical fixes on the 1.8.1
release, etc) these
>>>>>>> are already available to the public.
>>>>>>>
>>>>>>>> I doubt that Sun will give commit rights to
external entities (this
>>>>>>>> is not unreasonable, Sun needs to control what
code enters its
>>>>>>>> repositories). ?Hence I think that the
community would be better
>>>>>>>> served with a GIT repository in a public place,
like github, that
>>>>>>>> can give such access.
>>>>>>>
>>>>>>> While CVS was very restrictive in terms of managing
external commit
>>>>>>> permissions due to its monolithic repository, some
external
>>>>>>> contributors have had commit access to CVS prior
our migration to
>>>>>>> Git, based on need. ?With the migration to Git
there is no need to
>>>>>>> manage such access ourselves, as developers are
able to host their
>>>>>>> clones wherever they want. ?The git.lustre.org
repository will
>>>>>>> remain the canonical source for Sun releases, and
we will be happy
>>>>>>> to pull fixes into this repository that meet the
quality guidelines
>>>>>>> stated above. ?I for one would welcome external
inspectors on
>>>>>>> patches, and we continue to work with external
sites to do scale
>>>>>>> testing of Lustre.
>>>>>>>
>>>>>>>> My group at ClusterStor has reserved the
"lustre" project at Github
>>>>>>>> and we will give keys to any and all
organizations that wish to
>>>>>>>> make serious contributions to Lustre. ?I was in
particular hoping
>>>>>>>> that LLNL would be willing to commit their
releases to that public
>>>>>>>> place.
>>>>>>>
>>>>>>>
>>>>>>> Note that with Git and github.com there is no need
to give keys to
>>>>>>> anyone, and in fact that would seem to be
detrimental to
>>>>>>> ClusterStor, because the "lustre" clone
you have reserved is within
>>>>>>> your company''s private hosting space (i.e.
>>>>>>> http://github.com/clusterstor/lustre
>>>>>>> ). ?With Github (or Git in general) it is possible
for anyone to
>>>>>>> make their own clone or mirror of a repository at
any time, no keys
>>>>>>> or permission required, and it will appear
ashttp://github.com/
>>>>>>> {user}/lustre or whatever they want to call it.
>>>>>>>
>>>>>>>> b. ?Everyone is uncertain about what Sun will
do with Lustre
>>>>>>>> (proprietary Solaris / ZFS server releases and
discontinued support
>>>>>>>> for Linux servers have been mentioned to me
several times now). ?A
>>>>>>>> public repository with the open code will be
valuable for the
>>>>>>>> community and promote continued development and
access.
>>>>>>>
>>>>>>> I agree that a public repository is important, and
we will continue
>>>>>>> to host one at git.lustre.org as we have in the
past for CVS, and it
>>>>>>> can and should be cloned as needed. ?As you are
hopefully aware,
>>>>>>> with Git every checkout has a full copy of the
repository, including
>>>>>>> all history, so the code is already very
"open" and "public".
>>>>>>> Lustre is, and will continue to be, available as
GPL software.
>>>>>>>
>>>>>>> We definitely welcome external contributions to
Lustre, which have
>>>>>>> in the past been done by a small number of people
outside of Sun. ?I
>>>>>>> don''t think the choice of CVS or Git or
hosting site has ever been a
>>>>>>> limiting factor in this regard. ?We look forward to
contributions of
>>>>>>> fixes, designs, and features, from ClusterStor, as
we would with any
>>>>>>> Lustre contributor.
>>>>>>>
>>>>>>>> 2. We need MUCH more in the repository than Sun
is putting into it.
>>>>>>>>
>>>>>>>> There are many development branches and
sometimes abandoned
>>>>>>>> projects that still have a lot of value. ?For
example, there is a
>>>>>>>> nearly complete OS X client port - what if
someone wanted to pick
>>>>>>>> that up? ?Similarly, there are projects like
size on MDS or the
>>>>>>>> network request scheduler that may need help
from the community to
>>>>>>>> get finished or re-prioritized.
>>>>>>>
>>>>>>> All of the Lustre history is still available in
CVS, as it has
>>>>>>> always been. ?As far as I know (I''ve never
checked it out myself)
>>>>>>> even the OS/X client port is publicly available
today, which was not
>>>>>>> true a few years ago.
>>>>>>>
>>>>>>> Due to the convoluted branch, repository, and tag
abuse that was
>>>>>>> used to manage the Lustre code in CVS, there is a
non-zero effort
>>>>>>> required to migrate any of the branches in CVS to
Git. ?Rather than
>>>>>>> bring all of the old detritus along into Git, only
the main
>>>>>>> development/production branches are being
automatically migrated
>>>>>>> initially.
>>>>>>>
>>>>>>> Now that the Git migration is complete, the Sun
maintainers of non-
>>>>>>> release features (HSM, SOM, CMD, NRS, etc) will be
creating Git
>>>>>>> clones and landing their work into them as time
permits.
>>>>>>>
>>>>>>> If anyone wants to import one of the other CVS
branches (e.g. OS/X),
>>>>>>> all they will need to do is create a patch from
that branch and then
>>>>>>> commit this into their own Git clone.
>>>>>>>
>>>>>>>> It is unclear to me if these kind of branches
can be found in the
>>>>>>>> publicly available CVS.
>>>>>>>
>>>>>>> Yes, they can, as they always have been. ?The CVS
repository will
>>>>>>> remain available indefinitely for spelunking
expeditions should the
>>>>>>> need arise. ?Note that the full history that leads
to the current
>>>>>>> release branches (b1_6, b1_8, HEAD) is available in
Git, so there is
>>>>>>> at least a trail of breadcrumbs leading to where we
are today.
>>>>>>>
>>>>>>>> If they can, a collection of relevant branches,
broadly along the
>>>>>>>> lines of what I mention above, should be placed
in the public GIT
>>>>>>>> repository.
>>>>>>>
>>>>>>> For currently-active branches this was already our
plan. ?For
>>>>>>> historical and inactive branches, and we welcome
any contributions
>>>>>>> that bring these ancient CVS branches back to life.
?Nikita is
>>>>>>> probably best positioned to know what needs to be
imported from the
>>>>>>> OS/X branch in CVS, and if there are other
particular branches that
>>>>>>> contain important work we''ll be happy to
discuss them with you. ?It
>>>>>>> will of course be possible to create Git clones for
these old
>>>>>>> branches as needed.
>>>>>>>
>>>>>>>> 3. Brian''s email message seems to
indicate that Sun''s git
>>>>>>>> repository will be used for Sun development.
?In the past there
>>>>>>>> were two CVS repositories - a read-only one
that was publicly
>>>>>>>> accessible and when I last controlled the group
it was updated very
>>>>>>>> frequently with all open source code
(presently, it seems to only
>>>>>>>> contain releases, not the development stream of
commits).
>>>>>>>
>>>>>>> That''s not correct. ?The public
cvs.lustre.org repository in fact
>>>>>>> contains all of the Lustre commits and all of the
history. ?I just
>>>>>>> did a checkout and there are in fact tags and
branches for the pre-
>>>>>>> release 1.8.2 builds, lprocfs rewrite, CMD, etc.
that are very much
>>>>>>> works in progress.
>>>>>>>
>>>>>>> One of the very last commits on CVS HEAD was on
Thursday before CVS
>>>>>>> went read-only, from a patch submitted by LLNL:
>>>>>>>
>>>>>>> revision 1.593
>>>>>>> date: 2009/12/10 13:52:51; ?author: dzogin; ?state:
Exp; ?lines:
>>>>>>> +5 -0
>>>>>>> Branch HEAD
>>>>>>> b=21259
>>>>>>> i=andrew.perepechko
>>>>>>> i=alexey.lyashkov
>>>>>>>
>>>>>>>
----------------------------------------------------------------------
>>>>>>> Description: Allow non-root access for "lfs
check".
>>>>>>> Details ? ?: Added a check in obd_class_ioctl() for
>>>>>>> OBD_IOC_PING_TARGET.
>>>>>>>
>>>>>>>
>>>>>>>> It is unclear how Sun can manage development
with this git
>>>>>>>> repository given that parts of its work are
proprietary (like the
>>>>>>>> Windows port) or unreleased (like the ZFS
work). ?Can we get more
>>>>>>>> insight in what Brian is alluding to?
>>>>>>>
>>>>>>> I''m not sure what "alluding" you
are alluding to?
>>>>>>>
>>>>>>> Of course, if there is any proprietary code
developed it will just
>>>>>>> not be pushed to the public git.lustre.org
repository. ?I expect
>>>>>>> that any proprietary or unreleased code that
ClusterStor is already
>>>>>>> or will develop will similarly not be posted
publicly until you are
>>>>>>> ready to do so.
>>>>>>>
>>>>>>> Sun''s current in-progress code will very
likely reside in separate
>>>>>>> clones at git.lustre.org, but will not be merged
into the Sun Prime
>>>>>>> repository for an official release until it is
inspected, tested,
>>>>>>> and has permission to land. ?Pulls into the Sun
Prime repository
>>>>>>> will be done by the release manager for each
branch, as previously
>>>>>>> stated. ?The Lustre engineers at ClusterStor are
already familiar
>>>>>>> with this process and have already had their first
patch pass
>>>>>>> inspections and it is ready for landing.
>>>>>>>
>>>>>>> That is one of the major benefits of Git over CVS -
that there ISN''T
>>>>>>> a single repository, and in fact every clone has a
full copy of the
>>>>>>> history and can be used by anyone. ?There is no
need to have all of
>>>>>>> the development done in branches on a single
repository, but rather
>>>>>>> to keep projects in their own clones.
>>>>>>>
>>>>>>> That allows developers to do local commits on their
machines, to
>>>>>>> push it to their public clone if they want to share
their work and/
>>>>>>> or make an offsite backup, and people are free to
choose which clone
>>>>>>> one they use. ?Sun''s Prime repository used
for releases will only
>>>>>>> contain stable Lustre code. ?This is the Git usage
model for the
>>>>>>> Linux kernel, and think it is a good one to follow
for Lustre as
>>>>>>> well. ?You are free to manage your clones in some
other way.
>>>>>>>
>>>>>>> Cheers, Andreas
>>>>>>> --
>>>>>>> Andreas Dilger
>>>>>>> Sr. Staff Engineer, Lustre Group
>>>>>>> Sun Microsystems of Canada, Inc.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Lustre-devel mailing list
>>>>>> Lustre-devel at lists.lustre.org
>>>>>> http://lists.lustre.org/mailman/listinfo/lustre-devel
>>>>>>
>>>>
>>>>
>>>> Cheers, Andreas
>>>> --
>>>> Andreas Dilger
>>>> Sr. Staff Engineer, Lustre Group
>>>> Sun Microsystems of Canada, Inc.
>>>>
>>>> _______________________________________________
>>>> Lustre-devel mailing list
>>>> Lustre-devel at lists.lustre.org
>>>> http://lists.lustre.org/mailman/listinfo/lustre-devel
>>>
>>>
>
>
> Cheers, Andreas
> --
> Andreas Dilger
> Sr. Staff Engineer, Lustre Group
> Sun Microsystems of Canada, Inc.
>
>