On Thu, Aug 15, 2013 at 10:41:47PM +0100, Ric Wheeler wrote: | On 08/15/2013 07:04 PM, Geoffrey Wehrman wrote: | >On Thu, Aug 15, 2013 at 06:59:21AM +0100, Ric Wheeler wrote: | >| | >| As much as the community admires your brave willingness to protect us | >from | >| code that was entirely developed by Dave, that is not really how the | >| upstream kernel works. | >| | >| Dave is pretty much without equal in moving XFS along these days and this | >| is a key feature that we are depending on. | >| | >| Please don't try to create hurdles to other people getting work into | >| upstream, that kind of thing will lead to a fork of the XFS code base and | >| ultimately that will be harder for all of us. | >| | >| It sounds like what you really should look at doing is to work inside of | >| SGI to create a private, internal branch of the upstream code that you | >| deliver in your product. Upstream code is all about innovation and new | >| features, we don't let vendor specific, non-upstream branches become the | >| place for hardening our code. | > | >I agree Dave is a gifted, dedicated, passionate and prolific contributor | >to the XFS community. His contributions are greatly appreciated as are | >the contributions of all other members of the XFS community. Dave does | >stand out as the most significant code contributor to the project. He | >has played a significant role moving XFS forward both from within SGI | >and from outside SGI. This does not place his contributions beyond | >review or discussion however. | > | >My objection to the current readdir filetype field feature code is that | >the feature is not being made available to mainstream XFS users, only | >to those willing to run experimental code. Dave has clearly stated that | >he will not do the back-porting work. I am not expecting Dave to do the | >back-porting work. Mark has volunteered to fill the back-porting role. | >Th porting work cannot be completed as the feature is not yet complete. | >The associated user space code changes have not been submitted, | >and tests to validate the new feature have not been submitted. I do | >not consider this to be an unreasonable request, even if there were | >back-porting required. | > | >If Red Hat is depending on the readdir filetype field feature from Dave | >and do not wish to wait for the feature to be completed before pulling | >in the code, then perhaps Red Hat should create a internal branch of | >the upstream code that you can deliver in your products. The upstream | >code should be stable and fully functional, not a place for incomplete, | >partially tested, half finished work. | > | > | | I think that you are still unclear on what "mainstream" users are. | | People who pay for commercial support use vendor branches of the kernel | (from us, from SLES, from you, etc). | | Upstream users and community distros normally expect to see new features in | their kernels. | | For what it's worth, Red Hat has been the largest contributor to XFS for | quite a while now & XFS will be our RHEL7 default file system. | | We don't ship "untested" or "incomplete" code. Clearly we all have the interests of Linux users in mind whether they be those paying for commercial support, developers embedding Linux in other products, or technically savvy end users. Clearly we don't agree all the time on content, time lines, and process. We each have to be willing to engage in a civil conversation and be willing to compromise. I recognize that I tend to be a silent bystander until there is an issue where I disagree, and only then do I join the conversation. I do not get involved in the general conversations on the list. I have all kinds of excuses, but it comes down to the fact that I just don't make it a high enough priority. Likewise, I don't tell Dave, Christoph, Eric, and others how much I appreciate their contributions when I do not have an issue. That makes me nothing more than a whiner and complainer, and I apologize for as much. I think it is great that Red Hat has been the largest contributor of XFS code recently. I'm excited that XFS will be the default filesystem for RHEL 7. I am not trying to sabotage any of Red Hat's plans. Success for Red Hat and XFS translates into success for all Linux users. I would like to take this opportunity to point out that SGI's attempts to contribute code to XFS are frequently blocked by Red Hat without technical merit. Most recently we tried to submit code for the agskip mount option which SGI has been shipping for years. [http://oss.sgi.com/archives/xfs/2013-01/msg00561.html] We asked for fields to be reserved in the new v3 inodes for parent pointers and allocation policies. That request was soundly rejected despite the existence of unreserved padding in the new inode format. [http://oss.sgi.com/archives/xfs/2013-04/msg00214.html] The response to code submitted by SGI has been so negative, we don't even bother submitting most of our code to the list anymore as long as it does not affect the on-disk format. The list of features and capabilities that we carry in our internally maintained source trees is significant and long: DMAPI, behavior chains, agskip mount option, ibound mount option, etc. These are all features that have been rejected by the external community but are of value to SGI customers. A reiterate my appreciation of Red Hat's contributions to XFS. However, I hope that you and others at Red Hat recognize that Red Hat is not the sole source for innovation and contributions to XFS. The playing field must be kept level and everyone in the community must be allowed to participate. Geoffrey Wehrman _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
