On 8/16/13 9:08 AM, Geoffrey Wehrman wrote: > 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] Honestly, shipping it for years was SGI's first mistake. At that point you can't respond to upstream reviews, because you are committed to the patch as-is - it's already in the field. You can't argue from technical points; you need it merged because you shipped it. So all you can ask for is thumbs up or thumbs down; you got thumbs down. Not going upstream first will almost always burn you; now you have extra maintenance burden forever. Which takes time away from your upstream presence, etc, etc. > 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 The response, IIRC, was that we shouldn't reserve fields for unreviewed designs from the future. That's sound practice, IMHO, and I agree. extN has weird, old, unused structure fields, because this principle wasn't followed. I've seen the counterexample, and it sucks. TBH, if I went to btrfs or ext4, and said hey, please add these fields because I have a plan, they'd have told me no as well, and to come back with a patch which implements the plan, for review. > , 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. That really is unfortunate. See above about how that is only going to hurt you, I'm afraid. > 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. Sure, but their mere existence in your tree doesn't mean that it's the best solution. Upstream review & discussion can be arduous, but it finds & fixes things. Code written & shipped w/o 3rd party review tends to have more rough edges than if it had been wrung through 8 versions. "Note: The ibound mount option is not compatible with the inode64 mount option. If you specify both options, the mount(8) command will ignore the first option specified. " Review might have cleaned up that behavior. :) > 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. Asking for justification, testing, adherence to best practices, patch modification cycles, hard questioning, design review, etc is the standard to which everyone should be held. It's how xfs has been developed upstream for years, and what has made it the premier Linux filesystem. We owe each other courtesy during the process, but hard questions and a high bar should not be perceived as discourtesy. If it really does get personal, and sometimes it does despite all our efforts, then point it out, and people should reset the discussion to the technical side. Look, I'm trying to be master of 3 or more different Linux filesystems - and probably doing a poor job of it. But the one thing that has impressed me about XFS apart from the others is that for the most part, bad code doesn't get through. On-list review is rigorous, and code is held to very high standards. You have to be willing to get behind your proposal and make good technical arguments, and see it through to the end - or sometimes, lose the argument and regroup. -Eric _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
