Submitting patches
Generally I find that patches are much easier to process as Bugzilla attachments, rather than sent to the developer list as an attachment. And if the patch is large, it uses everyones mail resources, most of whom aren't interested. Just received such a patch on JMeter - the poster helpfully has a blog where he says that he followed the guidelines in: http://jakarta.apache.org/site/source.html#Patches which do indeed suggest sending patches to the developer mailing list. I'd like to suggest a change, so that the preferred method of submitting patches is via Bugzilla or JIRA. In the case of projects using JIRA, I believe that asks for a software grant, so it's important that code is submitted that way. [Actually, I'm not sure when emailed patches are appropriate...] I'd also like to split the patch section into two: Patch Creation Patch Submission Any objections to this? If not, I'll make a start on updating the text - and put a copy on my home page for review. Sebastian (sebb AT AO) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Submitting patches
Agreed and +1 to the changes.. sebb wrote: Generally I find that patches are much easier to process as Bugzilla attachments, rather than sent to the developer list as an attachment. And if the patch is large, it uses everyones mail resources, most of whom aren't interested. Just received such a patch on JMeter - the poster helpfully has a blog where he says that he followed the guidelines in: http://jakarta.apache.org/site/source.html#Patches which do indeed suggest sending patches to the developer mailing list. I'd like to suggest a change, so that the preferred method of submitting patches is via Bugzilla or JIRA. In the case of projects using JIRA, I believe that asks for a software grant, so it's important that code is submitted that way. [Actually, I'm not sure when emailed patches are appropriate...] In short : with very simple patches (eg fixing a typo in the docs) I think a patch as attachment is appropiate. Instead of applying the patch I will simply correct the typo by hand.. So it could be usefull to mention this. Though I prefer code patches to be in an issue tracker, so it is traceable (at least if people add the issuenumber in the commit message) Mvgr, Martin I'd also like to split the patch section into two: Patch Creation Patch Submission Any objections to this? If not, I'll make a start on updating the text - and put a copy on my home page for review. Sebastian (sebb AT AO) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Submitting patches
Hola, +1. For any kind of patch, attaching to an open issue is better. The poster can (and usually should) always email [EMAIL PROTECTED] to discuss the patch. Yoav On 3/26/06, Martin van den Bemt [EMAIL PROTECTED] wrote: Agreed and +1 to the changes.. sebb wrote: Generally I find that patches are much easier to process as Bugzilla attachments, rather than sent to the developer list as an attachment. And if the patch is large, it uses everyones mail resources, most of whom aren't interested. Just received such a patch on JMeter - the poster helpfully has a blog where he says that he followed the guidelines in: http://jakarta.apache.org/site/source.html#Patches which do indeed suggest sending patches to the developer mailing list. I'd like to suggest a change, so that the preferred method of submitting patches is via Bugzilla or JIRA. In the case of projects using JIRA, I believe that asks for a software grant, so it's important that code is submitted that way. [Actually, I'm not sure when emailed patches are appropriate...] In short : with very simple patches (eg fixing a typo in the docs) I think a patch as attachment is appropiate. Instead of applying the patch I will simply correct the typo by hand.. So it could be usefull to mention this. Though I prefer code patches to be in an issue tracker, so it is traceable (at least if people add the issuenumber in the commit message) Mvgr, Martin I'd also like to split the patch section into two: Patch Creation Patch Submission Any objections to this? If not, I'll make a start on updating the text - and put a copy on my home page for review. Sebastian (sebb AT AO) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Submitting patches
Indeed. Where the product has multiple versions, it may not be obvious where in SVN to find the appropriate code - and of course someone else may already be working on it. S. On 26/03/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hola, +1. For any kind of patch, attaching to an open issue is better. The poster can (and usually should) always email [EMAIL PROTECTED] to discuss the patch. Yoav On 3/26/06, Martin van den Bemt [EMAIL PROTECTED] wrote: Agreed and +1 to the changes.. sebb wrote: Generally I find that patches are much easier to process as Bugzilla attachments, rather than sent to the developer list as an attachment. And if the patch is large, it uses everyones mail resources, most of whom aren't interested. Just received such a patch on JMeter - the poster helpfully has a blog where he says that he followed the guidelines in: http://jakarta.apache.org/site/source.html#Patches which do indeed suggest sending patches to the developer mailing list. I'd like to suggest a change, so that the preferred method of submitting patches is via Bugzilla or JIRA. In the case of projects using JIRA, I believe that asks for a software grant, so it's important that code is submitted that way. [Actually, I'm not sure when emailed patches are appropriate...] In short : with very simple patches (eg fixing a typo in the docs) I think a patch as attachment is appropiate. Instead of applying the patch I will simply correct the typo by hand.. So it could be usefull to mention this. Though I prefer code patches to be in an issue tracker, so it is traceable (at least if people add the issuenumber in the commit message) Mvgr, Martin I'd also like to split the patch section into two: Patch Creation Patch Submission Any objections to this? If not, I'll make a start on updating the text - and put a copy on my home page for review. Sebastian (sebb AT AO) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Submitting patches
+1. I like having one place, Bugzilla, as the 'repository' for patches as opposed to email lists. Gary -Original Message- From: sebb [mailto:[EMAIL PROTECTED] Sent: Sunday, March 26, 2006 3:42 AM To: Jakarta General List Subject: Submitting patches Generally I find that patches are much easier to process as Bugzilla attachments, rather than sent to the developer list as an attachment. And if the patch is large, it uses everyones mail resources, most of whom aren't interested. Just received such a patch on JMeter - the poster helpfully has a blog where he says that he followed the guidelines in: http://jakarta.apache.org/site/source.html#Patches which do indeed suggest sending patches to the developer mailing list. I'd like to suggest a change, so that the preferred method of submitting patches is via Bugzilla or JIRA. In the case of projects using JIRA, I believe that asks for a software grant, so it's important that code is submitted that way. [Actually, I'm not sure when emailed patches are appropriate...] I'd also like to split the patch section into two: Patch Creation Patch Submission Any objections to this? If not, I'll make a start on updating the text - and put a copy on my home page for review. Sebastian (sebb AT AO) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Submitting patches
On Sun, 2006-03-26 at 12:41 +0100, sebb wrote: Generally I find that patches are much easier to process as Bugzilla attachments, rather than sent to the developer list as an attachment. And if the patch is large, it uses everyones mail resources, most of whom aren't interested. Just received such a patch on JMeter - the poster helpfully has a blog where he says that he followed the guidelines in: http://jakarta.apache.org/site/source.html#Patches which do indeed suggest sending patches to the developer mailing list. I'd like to suggest a change, so that the preferred method of submitting patches is via Bugzilla or JIRA. In the case of projects using JIRA, I believe that asks for a software grant, so it's important that code is submitted that way. [Actually, I'm not sure when emailed patches are appropriate...] I'd also like to split the patch section into two: Patch Creation Patch Submission Any objections to this? sounds good :) If not, I'll make a start on updating the text - and put a copy on my home page for review. no need to bother: if the feedback's positive then commit and we'll review the diffs. perhaps this information may be better at foundation level but any move can wait until you've patched... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Submitting patches
OK, here goes: http://people.apache.org/~sebb/source.html I removed the CVS references. Note that the #Patches anchor is referenced from getinvolved vendors so I kept the original heading and added subheadings for the various aspects. So long as there are no objections, I can apply the changes tomorrow and regenerate the site. S. On 26/03/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Sun, 2006-03-26 at 12:41 +0100, sebb wrote: Generally I find that patches are much easier to process as Bugzilla attachments, rather than sent to the developer list as an attachment. And if the patch is large, it uses everyones mail resources, most of whom aren't interested. Just received such a patch on JMeter - the poster helpfully has a blog where he says that he followed the guidelines in: http://jakarta.apache.org/site/source.html#Patches which do indeed suggest sending patches to the developer mailing list. I'd like to suggest a change, so that the preferred method of submitting patches is via Bugzilla or JIRA. In the case of projects using JIRA, I believe that asks for a software grant, so it's important that code is submitted that way. [Actually, I'm not sure when emailed patches are appropriate...] I'd also like to split the patch section into two: Patch Creation Patch Submission Any objections to this? sounds good :) If not, I'll make a start on updating the text - and put a copy on my home page for review. no need to bother: if the feedback's positive then commit and we'll review the diffs. perhaps this information may be better at foundation level but any move can wait until you've patched... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of TLPCactusAndJMeter by FelipeLeme
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by FelipeLeme: http://wiki.apache.org/jakarta/TLPCactusAndJMeter -- RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Testing PMC: * Henri Yandell ([MAILTO] [EMAIL PROTECTED]) + * Felipe Leme ([MAILTO] [EMAIL PROTECTED]) + NOW, THEREFORE, BE IT FURTHER RESOLVED, that be appointed to the office of Vice President, Testing, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of JakartaReport by FelipeLeme
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by FelipeLeme: http://wiki.apache.org/jakarta/JakartaReport -- * [JakartaBoardReport-September2005] * [JakartaBoardReport-December2005] * [JakartaBoardReport-March2006] + * [JakartaBoardReport-June2006] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of JakartaBoardReport-June2006 by FelipeLeme
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by FelipeLeme: http://wiki.apache.org/jakarta/JakartaBoardReport-June2006 The comment on the change is: Note sure if I used the proper release format; please feel free to fix it if nec New page: == Month Year Board Report == === Status === Chair to summarize Jakarta-wide news + the current state of affairs. === Releases === Cactus 1.17.2 was released on March 26th, 2006. === Community changes === New committers, pmc persons, asf members and departures. === Infrastructure news === Changes to the projects infrastructure. Migrations to Subversion, new vmware instances etc. === Subproject news === News related to various subprojects, if they have news. Volunteers for subproject news are desired, otherwise the Chair is responsible for finding out said news (and should mark that they had to do so). Subproject A Committer lands on Moon Subproject B Sending committer to Mars - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Submitting patches
On 3/26/06, sebb [EMAIL PROTECTED] wrote: OK, here goes: http://people.apache.org/~sebb/source.html I removed the CVS references. Note that the #Patches anchor is referenced from getinvolved vendors so I kept the original heading and added subheadings for the various aspects. So long as there are no objections, I can apply the changes tomorrow and regenerate the site. +1 ... looks great! S. Craig On 26/03/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Sun, 2006-03-26 at 12:41 +0100, sebb wrote: Generally I find that patches are much easier to process as Bugzilla attachments, rather than sent to the developer list as an attachment. And if the patch is large, it uses everyones mail resources, most of whom aren't interested. Just received such a patch on JMeter - the poster helpfully has a blog where he says that he followed the guidelines in: http://jakarta.apache.org/site/source.html#Patches which do indeed suggest sending patches to the developer mailing list. I'd like to suggest a change, so that the preferred method of submitting patches is via Bugzilla or JIRA. In the case of projects using JIRA, I believe that asks for a software grant, so it's important that code is submitted that way. [Actually, I'm not sure when emailed patches are appropriate...] I'd also like to split the patch section into two: Patch Creation Patch Submission Any objections to this? sounds good :) If not, I'll make a start on updating the text - and put a copy on my home page for review. no need to bother: if the feedback's positive then commit and we'll review the diffs. perhaps this information may be better at foundation level but any move can wait until you've patched... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Cactus 1.7.2 has been released
The Cactus project is pleased to announce the release of version 1.7.2. Cactus is a unit testing framework for testing server side java code. Goals - This release was created just because the previous 1.7.x releases have bundled an LGPL jar (jboss-j2ee.jar, necessary to run the samples), which is not allowe by ASF policies. Other than that, the only technical change is a new feature on the Maven plugin (https://issues.apache.org/jira/browse/CACTUS-231). Changes --- Please check the Changes page at http://jakarta.apache.org/cactus/changes.html for a full list of the changes in version 1.7.2 Known limitations and bugs: --- See http://issues.apache.org/jira/browse/CACTUS . For more information about Cactus, please visit http://jakarta.apache.org/cactus/ . Have fun, -The Cactus team
Re: Submitting patches
On 3/26/06, sebb [EMAIL PROTECTED] wrote: OK, here goes: http://people.apache.org/~sebb/source.html I removed the CVS references. Note that the #Patches anchor is referenced from getinvolved vendors so I kept the original heading and added subheadings for the various aspects. So long as there are no objections, I can apply the changes tomorrow and regenerate the site. snip/ Thanks for doing this. s/Buzilla/Bugzilla/ (Submitting Patches, 3rd para, 1st sentence). I'll pick it up if you miss it ;-) -Rahul S. snap/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Remove SVN restrictions
Vote to remove the SVN barriers within Jakarta such that all jakarta-* groups are merged into the one jakarta group with the exception of jakarta-hivemind, jakarta-slide, jakarta-cactus and jakarta-jmeter under the assumption that they are moving to having their own PMCs. Tapestry is already within its own auth group. [ ] +1 [ ] -1 If your -1 is only for a particular subproject (ie: you don't care what the rest of Jakarta does, feel free to say so). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Remove SVN restrictions
Hi! Definitely: [X ] +1 [ ] -1 Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
