Sorry to go on and on, but this ***is*** gene...@***incubator***. We're supposed to promulgate good community practices to new podlings. I didn't and don't mean to be dictating anything to nonP-PMCs. I stand by a position of recommending JIRA as a process for an ordinary new podling, bootstrapping a community more of less from scratch.
In other words, this message was doubly not intended to be interpreted relative to the svn project, which is no longer a podling and was never being bootstrapped from scratch in the incubator. On Mon, Sep 13, 2010 at 10:03 PM, Benson Margulies <bimargul...@gmail.com>wrote: > > > On Mon, Sep 13, 2010 at 9:49 PM, Joe Schaefer <joe_schae...@yahoo.com>wrote: > >> He says should, not must. Mailing lists are contribution >> mechanisms as well (per the license), so patches submitted >> there which aren't marked "Not a contribution" are acceptable. >> Jira's checkbox is the belt and suspenders approach. >> > > The original question didn't mention mailing lists. It didn't mention any > specifics at all. I reported the practice on the projects I'm familiar with. > In some of them, JIRA is the critical mechanism for patch review -- even for > people with commit access! In others, it's just the standard means for > people to submit patches. JIRA makes it harder to miss a patch. A JIRA with > a patch sits there where you can get it on a list of JIRAs that are > unresolved. A patch just sent to a mailing list might just disappear into > the ether. > > However, I thank Joe for pointing out that I was careful to avoid stating a > requirement when I didn't know that one existed. > > I've never hung out on an ASF project that (still) used email patches as > the common practice, so I was unaware of it. > > So, if you asked me, I'd say that using JIRA or BZ items is good > organizational hygiene, giving more people visibility into the process and > making it harder to drop a good contribution on the floor -- but if you have > a working system involving an official mailing list, you have a working > system. > > On the other hand, I think that we all agree that a patch mailed by > personal email to a committer who commits it is not a good thing. > > > > > >> >> >> >> ----- Original Message ---- >> > From: Daniel Shahaf <d...@daniel.shahaf.name> >> > To: general@incubator.apache.org >> > Sent: Mon, September 13, 2010 9:43:09 PM >> > Subject: Re: Accepting patches in a podling >> > >> > So each patch /must/ go via JIRA and get some checkbox filled? >> > Seriously? >> > >> > 1. Over at Subversion, the practice has been to just say thankyou and >> > commit the patches. A few times, with large-scale contributions (eg: >> > someone sent us an SQL backend), we have required filing an ICLA first >> > --- but that has been needed VERY rarely. >> > >> > 2. So patch submitters get sent to JIRA just so they can /fill a >> > checkbox/? Never mind what the license says about submissions to the >> > mailing lists, why not simply ask them to write >> > >> > "I license the patch attached herewith under the Apache License, >> version >> >2.0" >> > >> > >> > at the top of their email? That's much less effort for them than >> filing >> > a JIRA. And imposing less work on patch submitters is Good. >> > >> > Benson Margulies wrote on Mon, Sep 13, 2010 at 20:58:06 -0400: >> > > All patches should be attached to JIRAs with the 'grant' checkbox >> checked. >> > > Only if they are large do you then have to contemplate asking for a >> CLA and >> > > going through the clearance process. Or so I understand it. >> > > >> > > On Mon, Sep 13, 2010 at 8:55 PM, David Lutterkort <lut...@redhat.com >> > >> wrote: >> > > >> > > > What is the offical process for accepting patches from >> non-comitters in >> > > > a podling ? Is it enough to insist that contributors that are not >> > > > committers have a CLA on file or do I also have to make them file >> each >> > > > patch in jira ? >> > > > >> > > > David >> > > > >> > > > >> > > > >> > > > >> --------------------------------------------------------------------- >> > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> > > > For additional commands, e-mail: general-h...@incubator.apache.org >> > > > >> > > > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> > For additional commands, e-mail: general-h...@incubator.apache.org >> > >> > >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> >
