On 09/17/2015 01:53 PM, Martin Kosek wrote: > On 09/17/2015 01:47 PM, Tomas Babej wrote: >> Hi fellow developers, >> >> more or less we tend to stick to the tradition of linking Trac tickets >> to the commit messages of the patches we send to the list. >> >> However, every now and then, a patch lands on the list, which is either >> linked to a BZ or does not contain any link at all. Admittedly, I am >> also guilty of this mishap. This poses certain problems, as we're trying >> to automate the bookkeeping and pushing-related processes with ipatool . >> >> Nevertheless, this useful habit is not formally agreed upon by >> developers nor documented in our wiki . I'd suggest we add it there, >> if we come to such consensus. >> >> This would mean: >> * Patches fixing an issue described only in BZ (rare issue) would need >> to create a Trac ticket referencing the BZ > > +1 > >> * Patches fixing an issue not tracked in Trac nor BZ would need to file >> a ticket in Trac and reference it > > I am not sure we are there yet. For typos and small fixes, I do not think we > need to create a hard requirement for a Trac ticket. But for patches that you > want to be considered for say backports to downstream releases, it is better > to > have the ticket with the right metadata and collection of the right hashes > that > the downstream release can digest.
I agree it might be a good idea to be less harsh on the trivial patches, however, how do we draw the line? This puts the decision burden on the contributor who might not have the necessary insight and/or information. I'd suggest we go this route, I don't want to put more obstacles for new contributors and small patches. However, then the regular FreeIPA committers need to notify the new contributors if their patch crosses the triviality barrier and warrants a ticket :) -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code