Re: Accepting patches in a podling
On Thu, Sep 16, 2010 at 1:41 AM, Benson Margulies bimargul...@gmail.com wrote: ...It takes about two minutes to make a JIRA. If the contributor can't spare those two minutes, how are they having time to make a patch at all?... ...Perhaps this is because I'm accustomed, at both my day job and on several Apache projects, to seeing JIRA as the central organizing tool of everything that gets done. If there isn't a JIRA, it doesn't exist... I think that's the key in this discussion: if a project considers JIRA their central organizing tool, it's fine to require patches to go there. If another project prefers patches on the dev list, that also works, though JIRA helps make the intentional contribution bit more explicit. In both cases, authors of substantial contributions (whatever that means) need to have an iCLA on file. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Accepting patches in a podling
- Original Message From: Bertrand Delacretaz bdelacre...@apache.org To: general@incubator.apache.org Sent: Thu, September 16, 2010 7:40:22 AM Subject: Re: Accepting patches in a podling On Thu, Sep 16, 2010 at 1:41 AM, Benson Margulies bimargul...@gmail.com wrote: ...It takes about two minutes to make a JIRA. If the contributor can't spare those two minutes, how are they having time to make a patch at all?... ...Perhaps this is because I'm accustomed, at both my day job and on several Apache projects, to seeing JIRA as the central organizing tool of everything that gets done. If there isn't a JIRA, it doesn't exist... I think that's the key in this discussion: if a project considers JIRA their central organizing tool, it's fine to require patches to go there. If another project prefers patches on the dev list, that also works, though JIRA helps make the intentional contribution bit more explicit. In both cases, authors of substantial contributions (whatever that means) need to have an iCLA on file. It means independently copyrightable. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Accepting patches in a podling
- Original Message From: David Lutterkort lut...@redhat.com To: general@incubator.apache.org Sent: Wed, September 15, 2010 7:33:45 PM Subject: Re: Accepting patches in a podling On Tue, 2010-09-14 at 04:22 +0200, Daniel Shahaf wrote: FWIW, what Subversion uses: http://subversion.apache.org/docs/community-guide/community-guide.html#patches http://subversion.apache.org/docs/community-guide/community-guide.html#patch-manager ; Briefly, all patches go to dev@, and only the unlucky patches that were neither applied nor rejected get stashed in the issue tracker to avoid being dropped on the floor. This seems a very workable approach - going through Jira for everything is too much work on the part of the contributer. I'll use that as the submission policy for Deltacloud from now on: * Patch submittes must have a CLA on file Well IMO this should only be a requirement for substantial changes. Minor bugfixes and such aren't even copyrightable, so just take them if they're posted to the list without disclaimers. If you use reasonable judgement about minor changes, you don't need to burden an occasional contributor with any paperwork- the license ensures your actions are defensible. * Patches need to go to the dev@ list (and be ACK'd there) * In some cases, we might ask the submitter to put the patch into Jira (e.g., for large contributions) Only tangentially related: is there a way to make subversion (especially via git-svn) distinguish between a committer and an author ? That would help keep the patch submission trail much more transparent. With cvs we used to have a way of formatting log messages to indicate independent authorship. Unfortunately there is no such thing available with subversion, so you can be a bit creative in how you denote authorship in the log message. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Accepting patches in a podling
This seems a very workable approach - going through Jira for everything is too much work on the part of the contributer. On the one hand, I want to stand off and let any community make its own way within the light constraints of the license policy. On the other hand, I am honestly mystified by this. It takes about two minutes to make a JIRA. If the contributor can't spare those two minutes, how are they having time to make a patch at all? On CXF, or Lucene, I've never seen anyone complain that attaching JIRAs to patches was in any respect a barrier. Perhaps this is because I'm accustomed, at both my day job and on several Apache projects, to seeing JIRA as the central organizing tool of everything that gets done. If there isn't a JIRA, it doesn't exist. I suppose if you see JIRA as this 'over there' irritant containing complaints from users then it would seem a waste of time to use it for patch management.
Re: Accepting patches in a podling
On Tue, 2010-09-14 at 04:22 +0200, Daniel Shahaf wrote: FWIW, what Subversion uses: http://subversion.apache.org/docs/community-guide/community-guide.html#patches http://subversion.apache.org/docs/community-guide/community-guide.html#patch-manager Briefly, all patches go to dev@, and only the unlucky patches that were neither applied nor rejected get stashed in the issue tracker to avoid being dropped on the floor. This seems a very workable approach - going through Jira for everything is too much work on the part of the contributer. I'll use that as the submission policy for Deltacloud from now on: * Patch submittes must have a CLA on file * Patches need to go to the dev@ list (and be ACK'd there) * In some cases, we might ask the submitter to put the patch into Jira (e.g., for large contributions) Only tangentially related: is there a way to make subversion (especially via git-svn) distinguish between a committer and an author ? That would help keep the patch submission trail much more transparent. David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Accepting patches in a podling
On Sep 15, 2010, at 4:41 PM, Joe Schaefer wrote: - Original Message From: David Lutterkort lut...@redhat.com To: general@incubator.apache.org Sent: Wed, September 15, 2010 7:33:45 PM Subject: Re: Accepting patches in a podling On Tue, 2010-09-14 at 04:22 +0200, Daniel Shahaf wrote: FWIW, what Subversion uses: http://subversion.apache.org/docs/community-guide/community-guide.html#patches http://subversion.apache.org/docs/community-guide/community-guide.html#patch-manager ; Briefly, all patches go to dev@, and only the unlucky patches that were neither applied nor rejected get stashed in the issue tracker to avoid being dropped on the floor. This seems a very workable approach - going through Jira for everything is too much work on the part of the contributer. I'll use that as the submission policy for Deltacloud from now on: * Patch submittes must have a CLA on file Well IMO this should only be a requirement for substantial changes. Minor bugfixes and such aren't even copyrightable, so just take them if they're posted to the list without disclaimers. If you use reasonable judgement about minor changes, you don't need to burden an occasional contributor with any paperwork- the license ensures your actions are defensible. I'm mystified about what license you are talking about. This particular item proposes that patches posted to dev@ are ok if submitted by someone who has a CLA on file. You say you don't need to burden an occasional contributor with any paperwork. So what license are you talking about? The CLA that the contributor didn't file? Craig * Patches need to go to the dev@ list (and be ACK'd there) * In some cases, we might ask the submitter to put the patch into Jira (e.g., for large contributions) Only tangentially related: is there a way to make subversion (especially via git-svn) distinguish between a committer and an author ? That would help keep the patch submission trail much more transparent. With cvs we used to have a way of formatting log messages to indicate independent authorship. Unfortunately there is no such thing available with subversion, so you can be a bit creative in how you denote authorship in the log message. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@oracle.com P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Accepting patches in a podling
- Original Message From: Craig L Russell craig.russ...@oracle.com To: general@incubator.apache.org Sent: Wed, September 15, 2010 8:05:01 PM Subject: Re: Accepting patches in a podling On Sep 15, 2010, at 4:41 PM, Joe Schaefer wrote: - Original Message From: David Lutterkort lut...@redhat.com To: general@incubator.apache.org Sent: Wed, September 15, 2010 7:33:45 PM Subject: Re: Accepting patches in a podling On Tue, 2010-09-14 at 04:22 +0200, Daniel Shahaf wrote: FWIW, what Subversion uses: http://subversion.apache.org/docs/community-guide/community-guide.html#patches http://subversion.apache.org/docs/community-guide/community-guide.html#patch-manager ; Briefly, all patches go to dev@, and only the unlucky patches that were neither applied nor rejected get stashed in the issue tracker to avoid being dropped on the floor. This seems a very workable approach - going through Jira for everything is too much work on the part of the contributer. I'll use that as the submission policy for Deltacloud from now on: * Patch submittes must have a CLA on file Well IMO this should only be a requirement for substantial changes. Minor bugfixes and such aren't even copyrightable, so just take them if they're posted to the list without disclaimers. If you use reasonable judgement about minor changes, you don't need to burden an occasional contributor with any paperwork- the license ensures your actions are defensible. I'm mystified about what license you are talking about. The Apache License. This particular item proposes that patches posted to dev@ are ok if submitted by someone who has a CLA on file. You say you don't need to burden an occasional contributor with any paperwork. So what license are you talking about? The CLA that the contributor didn't file? Right, I'm saying that not every patch submission requires a iCLA on file. If it's a minor patch and noone objects to its inclusion, just include it. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Accepting patches in a podling
On Wed, 2010-09-15 at 19:41 -0400, Benson Margulies wrote: This seems a very workable approach - going through Jira for everything is too much work on the part of the contributer. On the one hand, I want to stand off and let any community make its own way within the light constraints of the license policy. On the other hand, I am honestly mystified by this. It takes about two minutes to make a JIRA. If the contributor can't spare those two minutes, how are they having time to make a patch at all? On CXF, or Lucene, I've never seen anyone complain that attaching JIRAs to patches was in any respect a barrier. Perhaps this is because I'm accustomed, at both my day job and on several Apache projects, to seeing JIRA as the central organizing tool of everything that gets done. If there isn't a JIRA, it doesn't exist. I suppose if you see JIRA as this 'over there' irritant containing complaints from users then it would seem a waste of time to use it for patch management. If someone who has never used Jira turns up with a one line tweak, sending them to Jira could require 15 minutes of their time to create an account, choosing yet another password, recording it somewhere, working out which project to put the bug in, which component, what all the boxes mean. This is all stuff that takes MUCH more effort than saying this tweak fixed it for me on a mailing list, if you've never used Jira before. Upayavira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Accepting patches in a podling
On Tue, Sep 14, 2010 at 2:58 AM, Benson Margulies bimargul...@gmail.com wrote: 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. Sounds good, and as it's about podlings I'd add and make those folks committers rather sooner than later. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Accepting patches in a podling
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
Re: Accepting patches in a podling
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
Re: Accepting patches in a podling
David, Yes, current practice is exactly what Benson outlined. thanks, dims On 09/13/2010 08:58 PM, Benson Margulies wrote: 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 Lutterkortlut...@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
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
Re: Accepting patches in a podling
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. - 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
Re: Accepting patches in a podling
On Mon, Sep 13, 2010 at 9:49 PM, Joe Schaefer joe_schae...@yahoo.comwrote: 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
Re: Accepting patches in a podling
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.comwrote: On Mon, Sep 13, 2010 at 9:49 PM, Joe Schaefer joe_schae...@yahoo.comwrote: 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
Re: Accepting patches in a podling
Benson Margulies wrote on Mon, Sep 13, 2010 at 22:03:12 -0400: However, I thank Joe for pointing out that I was careful to avoid stating a requirement when I didn't know that one existed. Thanks for clarifying. To summarize, having all patches go via JIRA is one possible way of working, but there is no requirement to use it --- other ways are possible too. 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. FWIW, what Subversion uses: http://subversion.apache.org/docs/community-guide/community-guide.html#patches http://subversion.apache.org/docs/community-guide/community-guide.html#patch-manager Briefly, all patches go to dev@, and only the unlucky patches that were neither applied nor rejected get stashed in the issue tracker to avoid being dropped on the floor. 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. Yup. The difference being whether or not the dev list is CCed. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Accepting patches in a podling
Benson Margulies wrote on Mon, Sep 13, 2010 at 22:06:24 -0400: 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 For recommending, +1. Your original mail managed to sound to me as Our Policy is that all patches shall be attached to JIRA issues and get some checkbox filled, so I tried to clarify that point. a community more of less from scratch. In other words, this message was doubly not intended to be interpreted relative to the svn project, I didn't interpret anything you said as relative to Subversion. which is no longer a podling and was never being bootstrapped from scratch in the incubator. Best, Daniel On Mon, Sep 13, 2010 at 10:03 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Sep 13, 2010 at 9:49 PM, Joe Schaefer joe_schae...@yahoo.comwrote: 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
