> I think we just need to come up with rules for considering a > platform to have voting ability before merging the patch. I totally agree, except for the "just" part. ;) IMO a platform is much like a feature in terms of requiring commitment/accountability, community agreement on cost/benefit, and so on. You can see a lot of that in the feature-page template. https://github.com/gluster/glusterfs-specs/blob/master/in_progress/template.md That might provide a good starting point, even though some items won't apply to a platform and others are surely missing. It's new territory, after all. Also, I believe the bar for platforms should be higher than for features, because a new platform multiplies our test load (and associated burdens) instead of merely adding to it. Also, new features rarely impact all developers the way that new platforms do. Nobody should be making assumptions or unilateral decisions about something as important as when it is or is not OK to block all merges throughout the project. That needs to be the subject of an explicit and carefully considered community decision. That, in turn, requires some clearly defined cost/benefit analysis and resource commitment. If we don't get the process right this time, we'll end up having this same conversation yet again, and I'm sure nobody wants that. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
