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