John Casey wrote: >> * Whether it works and does what is intended. >> * Whether it fits the spirit of the project. > > This seems like it would be hard for a user to assess. Not sure how a > patch contributor is supposed to handle it.
The first one is obvious, so I assume just just mean #2. Not for them to determine. It's reasons a patch might be rejected that they should be prepared for and consider. If they aren't sure, they can ask before doing the work. > What I wind up doing in cases where I'm applying a patch is create tests > to go along with them if there are none. That's a good idea, but how often do you hesitate to apply a patch because you don't want to do the tests? I don't think we are any better off for it. > HOWERVER, I'd like to suggest > another guideline, for submitting a bug report: > > Steps to reproduce. Absolutely. > I agree that documentation is important, but making it a basis for > rejecting a patch isn't necessarily the way to go IMO. In many cases, > patches will be small enough that its documentation won't serve to > improve the lives of users. It's still a good idea to have doco in code > comments for developers to use, but if you're going to apply a patch, > you should be able to write a one- or two-line code comment describing a > particular change...otherwise, you probably shouldn't be applying the > patch. This was directed solely at user-facing docs, and only applies when that is deemed necessary. It's not that extreme. I agree, its rare for patch submitters to be affected by this, so its not that onerous. IT's much more to show what applies to the *developers*. >> * code that doesn't meet current metrics can and should be technically >> vetoed. Again, we should set these up to fail the build, using >> Checkstyle, PMD and Clirr. > > I think we need to define what those metrics are in some way that we all > can reference, and *then* make sure we have the proper plugins in place > to break the build when the metrics are violated. Well, obviously ;) Thanks, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
