From martinnancy@example.net Fri May 02 16:01:45 2008 Return-Path: <martinnancy@example.net> Delivered-To: martinnancy@example.net Received: (qmail 76022 invoked from network); 2 May 2008 16:01:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 May 2008 16:01:42 -0000 Received: (qmail 33263 invoked by uid 500); 2 May 2008 16:01:42 -0000 Delivered-To: martinnancy@example.net Received: (qmail 32859 invoked by uid 500); 2 May 2008 16:01:41 -0000 Mailing-List: contact martinnancy@example.net; run by ezmlm Precedence: bulk Reply-To: martinnancy@example.net list-help: <mailto:martinnancy@example.net> list-unsubscribe: <mailto:martinnancy@example.net> List-Post: <mailto:martinnancy@example.net> List-Id: <general.ws.apache.org> Delivered-To: mailing list martinnancy@example.net Received: (qmail 32848 invoked by uid 99); 2 May 2008 16:01:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 May 2008 09:01:41 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of martinnancy@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO yw-out-1718.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 May 2008 16:00:55 +0000 Received: by yw-out-1718.google.com with SMTP id 6so100439ywa.88 for <martinnancy@example.net>; Fri, 02 May 2008 09:01:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; bh=2irxoOFoXU7C/RvvdjiLZTVrRenc0oDyaWus2Ha5HLU=; b=FBKsIroGmwMqZNaMz0Xw+oQZQC90bnDkdN2shsSvUWhnMBufrSdl/U2+pgK830leqIZqUmhGBg+uYaCJsM7sh+xr5HPZAH8BASwHZq9EGDNW3ve3F4gIC7N1BlE4sNx+IgYh3ylebPXLdXsa19xNsIiOjTTmZO1OHHgTv2Dmark= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; b=fjk/Va2JgEdwoNsc0ScY5okqq7Z3c0rkNUXjPwg45Z6HLfBRB+9B+POtP/SRnzs7H8NIa/JoWn3lvF9rH8QziO6GYerd/hiUpR6NtJEm50Mm5ms5+FFqW8r3YcoK+vLVMlw8LCCq5cjVzTMSrYMCUjjuSFJqpT5/RYKnS3jUmxg= Received: by 83.161.120.155 with SMTP id n5mr3629703ybg.73.1209743693851; Fri, 02 May 2008 08:54:53 -0700 (PDT) Received: from ?83.161.120.155? ( [83.161.120.155]) by mx.google.com with ESMTPS id i34sm13764508wxd.15.283.161.120.155.54.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 May 2008 08:54:52 -0700 (PDT) Message-ID: <martinnancy@example.net> Date: Fri, 02 May 2008 11:54:39 -0400 From: Davanum Srinivas <martinnancy@example.net> User-Agent: Thunderbird 83.161.120.155 (Windows/20080213) MIME-Version: 1.0 To: Axis developer list <martinnancy@example.net>, martinnancy@example.net, martinnancy@example.net, martinnancy@example.net, martinnancy@example.net Subject: [ANN] Apache Axis2 1.4 Released X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, Just over 8 months since the 1.3 release, we are very proud to announce the release of Apache Axis2 version 1.4. Downloads are available at: ~ http://ws.apache.org/axis2/download.cgi The Maven2 main repository has the latest jars as well. Apache Axis2 is a complete re-design and re-write of the widely used Apache Axis engine and is a more efficient, more scalable, more modular and more XML-oriented Web services framework. It is carefully designed to support the easy addition of plug-in "modules" that extend its functionality for features such as security and reliability. Modules supporting WS-Security/Secure-Conversation (Apache Rampart), WS-Trust (Apache Rahas), WS-Reliable Messaging (Apache Sandesha) and WS-Eventing (Apache Savan) will be available soon after the Apache Axis2 1.4 release. Please see these projects' own sites for further information. Major Changes Since 1.3: - - Support for JAXWS and JSR 181 Annotations (See 7 samples in the binary distribution) - - Experimental CORBA Support - - Fixed tons of small and not-so-small bugs (See list in release-notes.html in the binary distribution) Known Issues and Limitations in 1.4 Release: - - Need to use wsimport/wsgen tools in JDK1.6 for JAXWS code generation. - - Please see JIRA for the current status of bugs We welcome any and all feedback at: ~ martinnancy@example.net (please include "[axis2]" in the subject, please subscribe first) ~ martinnancy@example.net (please include "[axis2]" in the subject, please subscribe first) ~ http://issues.apache.org/jira/browse/AXIS2 Thank you for your interest in Apache Axis2! The Axis2 Development Team http://ws.apache.org/axis2/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFIGzk/gNg6eWEDv1kRApJ8AJ0ehHS6I4yGb1veE7Cc/UA2TPE1rQCfR+o+ Km0PhkgghwcSxyeY1G74s2c= =2sDC -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: martinnancy@example.net For additional commands, e-mail: martinnancy@example.net From martinnancy@example.net Fri May 02 19:48:17 2008 Return-Path: <martinnancy@example.net> Delivered-To: martinnancy@example.net Received: (qmail 87091 invoked from network); 2 May 2008 19:48:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 May 2008 19:48:12 -0000 Received: (qmail 49041 invoked by uid 500); 2 May 2008 19:48:12 -0000 Delivered-To: martinnancy@example.net Received: (qmail 48657 invoked by uid 500); 2 May 2008 19:48:11 -0000 Mailing-List: contact martinnancy@example.net; run by ezmlm Precedence: bulk Reply-To: martinnancy@example.net list-help: <mailto:martinnancy@example.net> list-unsubscribe: <mailto:martinnancy@example.net> List-Post: <mailto:martinnancy@example.net> List-Id: <general.ws.apache.org> Delivered-To: mailing list martinnancy@example.net Received: (qmail 48646 invoked by uid 99); 2 May 2008 19:48:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 May 2008 12:48:11 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of martinnancy@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO wf-out-1314.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 May 2008 19:47:26 +0000 Received: by wf-out-1314.google.com with SMTP id 25so1344547wfc.28 for <martinnancy@example.net>; Fri, 02 May 2008 12:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=z5BRH6iIAapFFnGpKoXY7LCXTlXK9OEC+zC5W9qiArU=; b=k+03I5qpDYzlZJRL+dawn/WbeN6SLnzI39z3iEvbrMoLPyOviWFaT8AK64SJQ+zU2c9FFSJ6wbWfUMqp8J5MSJaXnNQGcOInH7OHckM8DP3bLnXZWV5NpE7wG53ohsgZYd6fpoZoSSMZ02PPDvgK0Ip7OGJQdYp8+DslbiiyHNg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=atqmU5mtRo2qhAJyt3Pbny6cEM9UcKJthFKBPjjwI1umFw74O1zlwA9rOMHScKR9fn0pVmJOXlUVJqHcfG05Td2TidggLI1hncO0cGQMIyYuKrUuIWQcSbPOFWQchA3MnpXtnAs4kheuZntFbUY1Z6qBDAcXTTMNJK9j/uttx/Q= Received: by 83.161.120.155 with SMTP id s18mr1401725wfj.156.1209757661159; Fri, 02 May 2008 12:47:41 -0700 (PDT) Received: by 83.161.120.155 with HTTP; Fri, 2 May 2008 12:47:41 -0700 (PDT) Message-ID: <martinnancy@example.net> Date: Fri, 2 May 2008 15:47:41 -0400 From: "Ajith Ranabahu" <martinnancy@example.net> To: "martinnancy@example.net" <martinnancy@example.net> Subject: Fwd: Voting on release artifacts - Binary vs Source In-Reply-To: <martinnancy@example.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8927_11619824.1209757661145" References: <martinnancy@example.net> <martinnancy@example.net> <martinnancy@example.net> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_8927_11619824.1209757661145 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Forwarding to the general list due to popular demand ---------- Forwarded message ---------- From: Ajith Ranabahu <martinnancy@example.net> Date: Fri, May 2, 2008 at 1:21 PM Subject: Re: Voting on release artifacts - Binary vs Source To: martinnancy@example.net Hi, Thanks Jeremy for the pointer - I understand the why source is a must (otherwise why would you call it opensource :)) What I was trying to say was that I was under the impression that binary release artifacts are as important as source artifacts. However what this discussion (and the draft incubator proposal) tells me is that binaries are considered just a convenience and may not play a significant role in the voting process. What I am thinking is during the voting process (for a release) we should only post a source distribution. Once it is approved release manager can put up all the binary artifacts. To me signatures and hashes are a way for you to verify the authenticity and nothing more. IMHO during the vote users may or may not check the accuracy/legitimity of the hashes/signatures. If the release manager screws up the signing of artifacts that will be reported by infra (say the Key is invalid or the hashes are not right) [ I made a mistake in the signatures during the last Xml Schema release. The files that should have the .asc extension were in .gpg (signatures were fine though). However during the voting process this never came up (I know people tested the artifacts since we went on several RC cycles). What that tells me is that perhaps there is very little signature/checksum checking in practice. Anyway the mistake was reported by Henk (infra) and corrected later] So what I am trying to say is that to be in par with the Apache mentality of "source is the most important artifact" we should slightly augment our voting procedures so that we give priority to the source. The voting thread should indicate clearly that you check the source artifacts. Better yet we can post only the source for a vote - so that what people vote on would be the source and not the binary. Well - I did not send this to the general list since asking questions like 'are we fully Apache compliant ?' in public seemed a bit drastic to me. I was thinking we should treat this as a WS internal matter before we put it out to general@ or legal@ Ajith On Fri, May 2, 2008 at 9:12 AM, Jeremy Hughes <martinnancy@example.net> wrote: > There are some good points on the (still draft) release management page > @incubator [1]. In the end it's up to the project as to what's in a release. > I say the release *has* to include binaries to the user community happy. It > *should* release source zips (source is always available in SVN of course), > so that users are encouraged to become contributors as they debug any issues > they have. > > It's possible for voting to be against a particular SVN revision number > (ie. the source), but it also needs to be against the released artifacts, > since release signing happens once you have artifacts (ie binary and source > zips) that you want to release, and voting on the release should include a > check that the signature file is correct. Ideally there'd be a check that > the binaries relate to the source. > > [1] > http://incubator.apache.org/guides/releasemanagement.html#best-practice-source > > Cheers, > Jeremy > > 2008/5/1 Ajith Ranabahu <martinnancy@example.net>: > > Hi all, > > I've been wanting to ask this question from the pmc for about a week or > > so but did not get time to write a detailed email. Since most of the guys > > here are not in the member list (where an important discussion about "what > > Apache distributes?" happened) here is an excerpt. > > > > During one of the JCP discussions a point came up which resulted in the > > digression of "what Apache distributes as releases, is it code or > > binaries". Roy T Fielding, One of the Apache veterans, stated that Apache > > distributes source code and most importantly the voting should happen with > > the source code. Indeed HTTPD seem to follow this routine but AFAIK all of > > us in the WS world always voted on artifacts including binaries. There are > > many instances I have tested releases only with the binary artifacts without > > looking at the source (The source gets attention when there is a problem !). > > Again I suppose a good proportion of our users used the binaries and never > > tried building from source unless they absolutely have to. > > > > Now my question is whether what we have been doing all these years is > > the right Apache way. The discussion in the member list did not conclude > > with anything concrete and my brief search did not yield any concrete > > documents. However I think this is something we should clarify and get a > > clear understanding of the procedures before a potential clash. > > > > I suppose Glen/Dims/Sanjiva or any other folks who've been around Apache > > for a while would be able to shed some light on to this :) > > > > Thanks > > -- > > Ajith Ranabahu > > > > Reading, after a certain age, diverts the mind too much from its > > creative pursuits. Any man who reads too much and uses his own brain too > > little falls into lazy habits of thinking - Albert Einstein > > > -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein ------=_Part_8927_11619824.1209757661145 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Forwarding to the general list due to popular demand<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Ajith Ranabahu</b> &lt;<a href="mailto:martinnancy@example.net">martinnancy@example.net</a>&gt;<br> Date: Fri, May 2, 2008 at 1:21 PM<br>Subject: Re: Voting on release artifacts - Binary vs Source<br>To: <a href="mailto:martinnancy@example.net">martinnancy@example.net</a><br><br><br>Hi,<br>Thanks Jeremy for the pointer - I understand the why source is a must (otherwise why would you call it opensource :)) What I was trying to say was that I was under the impression that binary release artifacts are as important as source artifacts. However what this discussion (and the draft incubator proposal) tells me is that binaries are considered just a convenience and may not play a significant role in the voting process.<br> <br>What I am thinking is during the voting process (for a release) we should only post a source distribution. Once it is approved release manager can put up all the binary artifacts. To me signatures and hashes are a way for you to verify the authenticity and nothing more. IMHO during the vote users may or may not check the accuracy/legitimity of the hashes/signatures. If the release manager screws up the signing of artifacts that will be reported by infra (say the Key is invalid or the hashes are not right) [ I made a mistake in the signatures during the last Xml Schema release. The files that should have the .asc extension were in .gpg (signatures were fine though). However during the voting process this never came up (I know people tested the artifacts since we went on several RC cycles). What that tells me is that perhaps there is very little signature/checksum checking in practice. Anyway the mistake was reported by Henk (infra) and corrected later]<br> <br>So what I am trying to say is that to be in par with the Apache mentality of &quot;source is the most important artifact&quot; we should slightly augment our voting procedures so that we give priority to the source. The voting thread should indicate clearly that you check the source artifacts. Better yet we can post only the source for a vote - so that what people vote on would be the source and not the binary.<br> <br>Well - I did not send this to the general list since asking questions like &#39;are we fully Apache compliant ?&#39; in public seemed a bit drastic to me. I was thinking we should treat this as a WS internal matter before we put it out to general@ or legal@<br> <font color="#888888"> <br>Ajith</font><div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Fri, May 2, 2008 at 9:12 AM, Jeremy Hughes &lt;<a href="mailto:martinnancy@example.net" target="_blank">martinnancy@example.net</a>&gt; wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> There are some good points on the (still draft) release management page @incubator [1]. In the end it&#39;s up to the project as to what&#39;s in a release. I say the release *has* to include binaries to the user community happy. It *should* release source zips (source is always available in SVN of course), so that users are encouraged to become contributors as they debug any issues they have.<br> <br>It&#39;s possible for voting to be against a particular SVN revision number (ie. the source), but it also needs to be against the released artifacts, since release signing happens once you have artifacts (ie binary and source zips) that you want to release, and voting on the release should include a check that the signature file is correct. Ideally there&#39;d be a check that the binaries relate to the source.<br> <br>[1] <a href="http://incubator.apache.org/guides/releasemanagement.html#best-practice-source" target="_blank">http://incubator.apache.org/guides/releasemanagement.html#best-practice-source</a><br><br>Cheers,<br>Jeremy<br> <br><div class="gmail_quote"> 2008/5/1 Ajith Ranabahu &lt;<a href="mailto:martinnancy@example.net" target="_blank">martinnancy@example.net</a>&gt;:<div><div></div><div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi all,<br>I&#39;ve been wanting to ask this question from the pmc for about a week or so but did not get time to write a detailed email. Since most of the guys here are not in the member list (where an important discussion about &quot;what Apache distributes?&quot; happened) here is an excerpt.<br> <br>During one of the JCP discussions a point came up which resulted in the digression of &quot;what Apache distributes as&nbsp; releases, is it code or binaries&quot;. Roy T Fielding, One of the Apache veterans, stated that Apache distributes source code and most importantly the voting should happen with the source code. Indeed HTTPD seem to follow this routine but AFAIK all of us in the WS world always voted on artifacts including binaries. There are many instances I have tested releases only with the binary artifacts without looking at the source (The source gets attention when there is a problem !). Again I suppose a good proportion of our users used the binaries and never tried building from source unless they absolutely have to. <br> <br>Now my question is whether what we have been doing all these years is the right Apache way.&nbsp; The discussion in the member list did not conclude with anything concrete and my brief search did not yield any concrete documents. However I think this is something we should clarify and get a clear understanding of the procedures before a potential clash. <br> <br>I suppose Glen/Dims/Sanjiva or any other folks who&#39;ve been around Apache for a while would be able to shed some light on to this :)<br clear="all"><br>Thanks<br><font color="#888888">-- <br>Ajith Ranabahu<br><br> Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein </font></blockquote></div></div></div><br> </blockquote></div><br><br clear="all"><br>-- <br>Ajith Ranabahu<br><br>Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein </div></div></div><br><br clear="all"><br>-- <br>Ajith Ranabahu<br><br>Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein ------=_Part_8927_11619824.1209757661145-- From martinnancy@example.net Fri May 02 21:17:51 2008 Return-Path: <martinnancy@example.net> Delivered-To: martinnancy@example.net Received: (qmail 23095 invoked from network); 2 May 2008 21:17:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 May 2008 21:17:48 -0000 Received: (qmail 77195 invoked by uid 500); 2 May 2008 21:17:49 -0000 Delivered-To: martinnancy@example.net Received: (qmail 76768 invoked by uid 500); 2 May 2008 21:17:48 -0000 Mailing-List: contact martinnancy@example.net; run by ezmlm Precedence: bulk Reply-To: martinnancy@example.net list-help: <mailto:martinnancy@example.net> list-unsubscribe: <mailto:martinnancy@example.net> List-Post: <mailto:martinnancy@example.net> List-Id: <general.ws.apache.org> Delivered-To: mailing list martinnancy@example.net Received: (qmail 76757 invoked by uid 99); 2 May 2008 21:17:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 May 2008 14:17:48 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of martinnancy@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO an-out-0708.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 May 2008 21:17:03 +0000 Received: by an-out-0708.google.com with SMTP id c36so361555ana.22 for <martinnancy@example.net>; Fri, 02 May 2008 14:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=/bm0MLPaMMM6mtAK51uKqK2EXlaF/KMWnNZqPwJ7tPQ=; b=n9gwPBJ03bqYIAewzNhY50k/QXbOhMQ84uQi8rjagaxsvv60CqeY7r0j98Bxcndc5X2QoxLgyTleeTrMcg1haA5BXsfOCHmN5056H30dts69ZL/UkDLVa/NUyH0D9TsvDRXbnvM0VLTcuFUxeUZHcL7FG8MTimBR1ETwhIFQiyg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qyRhqHXoeF4OiWL3VwSyE0st0UTUgF/G6Gwtv3GPSpfx66y/F0fjnn8VioMEf+fPPuQlHGCPpuI1S3TToV1vCi2qvnx4IdkVsWmn5Gx0E9ShPsEU3Ur38/vP2MqQ3M8TmCJJTUjhpC8sETinBkXLeDQIF3183Lj37hRmVzFojVQ= Received: by 83.161.120.155 with SMTP id j5mr5381891anc.112.1209763036661; Fri, 02 May 2008 14:17:16 -0700 (PDT) Received: by 83.161.120.155 with HTTP; Fri, 2 May 2008 14:17:16 -0700 (PDT) Message-ID: <martinnancy@example.net> Date: Fri, 2 May 2008 22:17:16 +0100 From: "David Illsley" <martinnancy@example.net> To: martinnancy@example.net Subject: Re: Voting on release artifacts - Binary vs Source In-Reply-To: <martinnancy@example.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <martinnancy@example.net> <martinnancy@example.net> <martinnancy@example.net> <martinnancy@example.net> X-Virus-Checked: Checked by ClamAV on apache.org I disagree - I think the Apache process makes the minimum we should vote on be the source (and I agree that on many levels, it's the most important thing). However I think we need to do more. The number of problems we have had with actual broken releases *with* posted binaries means I think we can't do without them. I do trust the release managers, but even release managers are human and mistakes happen. I personally want to test the thing that the majority of users will download and use so that I can accurately vouch for its quality. Speaking for myself: From a philosophical perspective, the source is most important As a user of software from apache.org I want to know that the binary I download has been tested by at least a couple of experts I think we can and should satisfy both and don't see a strong downside to doing so. David On Fri, May 2, 2008 at 8:47 PM, Ajith Ranabahu <martinnancy@example.net> wrote: > Forwarding to the general list due to popular demand > > > > ---------- Forwarded message ---------- > From: Ajith Ranabahu <martinnancy@example.net> > Date: Fri, May 2, 2008 at 1:21 PM > Subject: Re: Voting on release artifacts - Binary vs Source > To: martinnancy@example.net > > > Hi, > Thanks Jeremy for the pointer - I understand the why source is a must > (otherwise why would you call it opensource :)) What I was trying to say was > that I was under the impression that binary release artifacts are as > important as source artifacts. However what this discussion (and the draft > incubator proposal) tells me is that binaries are considered just a > convenience and may not play a significant role in the voting process. > > What I am thinking is during the voting process (for a release) we should > only post a source distribution. Once it is approved release manager can put > up all the binary artifacts. To me signatures and hashes are a way for you > to verify the authenticity and nothing more. IMHO during the vote users may > or may not check the accuracy/legitimity of the hashes/signatures. If the > release manager screws up the signing of artifacts that will be reported by > infra (say the Key is invalid or the hashes are not right) [ I made a > mistake in the signatures during the last Xml Schema release. The files that > should have the .asc extension were in .gpg (signatures were fine though). > However during the voting process this never came up (I know people tested > the artifacts since we went on several RC cycles). What that tells me is > that perhaps there is very little signature/checksum checking in practice. > Anyway the mistake was reported by Henk (infra) and corrected later] > > So what I am trying to say is that to be in par with the Apache mentality of > "source is the most important artifact" we should slightly augment our > voting procedures so that we give priority to the source. The voting thread > should indicate clearly that you check the source artifacts. Better yet we > can post only the source for a vote - so that what people vote on would be > the source and not the binary. > > Well - I did not send this to the general list since asking questions like > 'are we fully Apache compliant ?' in public seemed a bit drastic to me. I > was thinking we should treat this as a WS internal matter before we put it > out to general@ or legal@ > > Ajith > > > > On Fri, May 2, 2008 at 9:12 AM, Jeremy Hughes <martinnancy@example.net> wrote: > > > There are some good points on the (still draft) release management page > @incubator [1]. In the end it's up to the project as to what's in a release. > I say the release *has* to include binaries to the user community happy. It > *should* release source zips (source is always available in SVN of course), > so that users are encouraged to become contributors as they debug any issues > they have. > > > > It's possible for voting to be against a particular SVN revision number > (ie. the source), but it also needs to be against the released artifacts, > since release signing happens once you have artifacts (ie binary and source > zips) that you want to release, and voting on the release should include a > check that the signature file is correct. Ideally there'd be a check that > the binaries relate to the source. > > > > [1] > http://incubator.apache.org/guides/releasemanagement.html#best-practice-source > > > > Cheers, > > Jeremy > > > > > > 2008/5/1 Ajith Ranabahu <martinnancy@example.net>: > > > > > > > > > > > Hi all, > > > I've been wanting to ask this question from the pmc for about a week or > so but did not get time to write a detailed email. Since most of the guys > here are not in the member list (where an important discussion about "what > Apache distributes?" happened) here is an excerpt. > > > > > > During one of the JCP discussions a point came up which resulted in the > digression of "what Apache distributes as releases, is it code or > binaries". Roy T Fielding, One of the Apache veterans, stated that Apache > distributes source code and most importantly the voting should happen with > the source code. Indeed HTTPD seem to follow this routine but AFAIK all of > us in the WS world always voted on artifacts including binaries. There are > many instances I have tested releases only with the binary artifacts without > looking at the source (The source gets attention when there is a problem !). > Again I suppose a good proportion of our users used the binaries and never > tried building from source unless they absolutely have to. > > > > > > Now my question is whether what we have been doing all these years is > the right Apache way. The discussion in the member list did not conclude > with anything concrete and my brief search did not yield any concrete > documents. However I think this is something we should clarify and get a > clear understanding of the procedures before a potential clash. > > > > > > I suppose Glen/Dims/Sanjiva or any other folks who've been around Apache > for a while would be able to shed some light on to this :) > > > > > > Thanks > > > -- > > > Ajith Ranabahu > > > > > > Reading, after a certain age, diverts the mind too much from its > creative pursuits. Any man who reads too much and uses his own brain too > little falls into lazy habits of thinking - Albert Einstein > > > > > > > > -- > Ajith Ranabahu > > Reading, after a certain age, diverts the mind too much from its creative > pursuits. Any man who reads too much and uses his own brain too little falls > into lazy habits of thinking - Albert Einstein > > > -- > Ajith Ranabahu > > Reading, after a certain age, diverts the mind too much from its creative > pursuits. Any man who reads too much and uses his own brain too little falls > into lazy habits of thinking - Albert Einstein -- David Illsley - IBM Web Services Development --------------------------------------------------------------------- To unsubscribe, e-mail: martinnancy@example.net For additional commands, e-mail: martinnancy@example.net From martinnancy@example.net Fri May 02 23:02:14 2008 Return-Path: <martinnancy@example.net> Delivered-To: martinnancy@example.net Received: (qmail 59947 invoked from network); 2 May 2008 23:02:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 2 May 2008 23:02:11 -0000 Received: (qmail 74433 invoked by uid 500); 2 May 2008 23:02:11 -0000 Delivered-To: martinnancy@example.net Received: (qmail 73966 invoked by uid 500); 2 May 2008 23:02:10 -0000 Mailing-List: contact martinnancy@example.net; run by ezmlm Precedence: bulk Reply-To: martinnancy@example.net list-help: <mailto:martinnancy@example.net> list-unsubscribe: <mailto:martinnancy@example.net> List-Post: <mailto:martinnancy@example.net> List-Id: <general.ws.apache.org> Delivered-To: mailing list martinnancy@example.net Received: (qmail 73955 invoked by uid 99); 2 May 2008 23:02:10 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 May 2008 16:02:10 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of martinnancy@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO rv-out-0708.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 May 2008 23:01:26 +0000 Received: by rv-out-0708.google.com with SMTP id c5so207425rvf.28 for <martinnancy@example.net>; Fri, 02 May 2008 16:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=HoAe6MHEVQnbqhlTOY1IRGHqyE3G4BYBb+//WZiktPE=; b=wH70kGB1HR4r609xBlrwBt3Awndkw+XTpIJe8WDCIt0+TVi6XY9Wmto8eWDVKfgq2YflFqXck1j5yxLZ/L+D4CMQYlbiQ8bfYGCLMll8FmYvcQpXozy9QJAijGjsMxsDonVzJEXIJPIgVI7JJy6vbdFEYgOjP9w7NDx+M8Nc+DU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=XUZSctegwhT3uJMfgV9sIkFqe6+7pUrU07Y6cXiu+i2KPu2+s8yy2XqZEiiNOjXgpRF1JMae5ukporeuqp55yeACws1bVu1nd+Pyf1oEcm2NQaKQovZiPLPzerkNyoMdmLSw3rgWwPbeewsfpnIIxNnl/XzlmNLtLrbxsyuWk6w= Received: by 83.161.120.155 with SMTP id a13mr1469471wff.50.1209769300815; Fri, 02 May 2008 16:01:40 -0700 (PDT) Received: by 83.161.120.155 with HTTP; Fri, 2 May 2008 16:01:40 -0700 (PDT) Message-ID: <martinnancy@example.net> Date: Fri, 2 May 2008 19:01:40 -0400 From: "Ajith Ranabahu" <martinnancy@example.net> To: martinnancy@example.net Subject: Re: Voting on release artifacts - Binary vs Source In-Reply-To: <martinnancy@example.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9466_33445407.1209769300797" References: <martinnancy@example.net> <martinnancy@example.net> <martinnancy@example.net> <martinnancy@example.net> <martinnancy@example.net> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_9466_33445407.1209769300797 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi David, Please see my comments in line On Fri, May 2, 2008 at 5:17 PM, David Illsley <martinnancy@example.net> wrote: > I disagree - I think the Apache process makes the minimum we should > vote on be the source (and I agree that on many levels, it's the most > important thing). > > However I think we need to do more. The number of problems we have had > with actual broken releases *with* posted binaries means I think we > can't do without them. > Yes - we've had problems before and very likely there would be glitches in the future. But most of the issues we've had in the past were either due to not following the protocol (changing stuff after the vote) or inadequate testing. Both these issues have been addressed to a great extent I suppose (Our release managers are experienced and well aware of the process. The test suites have improved tremendously). I don't think things will be drastically different if we do the source first approach. Again the build process is fully automated and all that is needed is a simple maven command. If all testers use the source release we might even get to issues sooner than later (failing test cases in specific platforms for example may be caught quickly with a build from source) > > I do trust the release managers, but even release managers are human > and mistakes happen. I personally want to test the thing that the > majority of users will download and use so that I can accurately vouch > for its quality. > This is actually a valid argument. We've had complaints earlier that the war distribution not containing some jars etc and I definitely see the advantage of such artifacts being tested before we hit the release. However what I see here is a situation like the following Think of the Ubuntu/Debian apt-get/Synaptic process. I usually get all my software as debs (mostly via synaptic) and these are almost always binaries. But stuff like the Apache HTTPD server are never released as binary [ I found an anomaly here. The Apache server has a win32 installer release and I've no clue how they handle the voting process regarding that ] The point here is that ubuntu/debian crowd provides the deb by themselves for convenience. If the deb for HTTPD breaks should I hold Apache responsible ? In our case we've become the provider of both the source and the convenience. But it is definitely two different things and one may even say they are orthogonal. > > Speaking for myself: > From a philosophical perspective, the source is most important > As a user of software from apache.org I want to know that the binary > I download has been tested by at least a couple of experts > I agree to you - we should cater for the needs of the user at the end of the day. However IMHO we should be careful not to violate the principles we stand for as a foundation. So here is what I suggest 1. We include a statement in every release vote noting to people that the source distribution needs to be tested (along with the binaries) 2. Whoever puts a +1 need to put the +1 after testing at least the source release (and possibly the other binary artifacts as well). This should be an agreement between ourselves. We may potentially add a statement in the download page saying that the binaries are provided as a convenience (just like the fineprint we have about the hashes and signatures) -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein ------=_Part_9466_33445407.1209769300797 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi David,<br>Please see my comments in line<br><br><div class="gmail_quote">On Fri, May 2, 2008 at 5:17 PM, David Illsley &lt;<a href="mailto:martinnancy@example.net">martinnancy@example.net</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I disagree - I think the Apache process makes the minimum we should<br> vote on be the source (and I agree that on many levels, it&#39;s the most<br> important thing).<br> <br> However I think we need to do more. The number of problems we have had<br> with actual broken releases *with* posted binaries means I think we<br> can&#39;t do without them.<br> </blockquote><div><br>Yes - we&#39;ve had problems before and very likely there would be glitches in the future. But most of the issues we&#39;ve<br>had in the past were either due to not following the protocol (changing stuff after the vote) or inadequate testing. Both these issues have been addressed to a great extent I suppose (Our release managers are experienced and well aware of the process. The test suites have improved tremendously). I don&#39;t think things will be drastically different if we do the source first approach. Again the build process is fully automated and all that is needed is a simple maven command. If all testers use the source release we might even get to issues sooner than later (failing test cases in specific platforms for example may be caught quickly with a build from source)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br> I do trust the release managers, but even release managers are human<br> and mistakes happen. I personally want to test the thing that the<br> majority of users will download and use so that I can accurately vouch<br> for its quality.<br> </blockquote><div><br>This is actually a valid argument. We&#39;ve had complaints earlier that the war distribution not containing some jars etc and I definitely see the advantage of such artifacts being tested before we hit the release.&nbsp; However what I see here is a situation like the following<br> <br>Think of the Ubuntu/Debian apt-get/Synaptic process. I usually get all my software as debs (mostly via synaptic) and these are almost always binaries. But stuff like the Apache HTTPD server are never released as binary [ I found an anomaly here. The Apache server has a win32 installer release and I&#39;ve no clue how they handle the voting process regarding that ]&nbsp; The point here is that ubuntu/debian crowd provides the deb by themselves for convenience. If the deb for HTTPD breaks should I hold Apache responsible ? <br> <br>In our case we&#39;ve become the provider of both the source and the convenience.&nbsp; But it is definitely two different things and one may even say they are orthogonal.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <br> Speaking for myself:<br> &nbsp;From a philosophical perspective, the source is most important<br> &nbsp;As a user of software from <a href="http://apache.org" target="_blank">apache.org</a> I want to know that the binary<br> I download has been tested by at least a couple of experts<br> </blockquote><div><br>I agree to you - we should cater for the needs of the user at the end of the day.&nbsp; However IMHO we should be careful not to violate the principles we stand for as a foundation. So here is what I suggest<br> <br>1. We include a statement in every release vote noting to people that the source distribution needs to be tested (along with the binaries)<br>2. Whoever puts a +1 need to put the +1 after testing at least the source release&nbsp; (and possibly the other binary artifacts as well). This should be an agreement between ourselves. We may potentially add a statement in the download page saying that the binaries are provided as a convenience (just like the fineprint we have about the hashes and signatures)<br> <br><br></div></div><br>-- <br>Ajith Ranabahu<br><br>Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein ------=_Part_9466_33445407.1209769300797-- From martinnancy@example.net Sun May 04 01:45:01 2008 Return-Path: <martinnancy@example.net> Delivered-To: martinnancy@example.net Received: (qmail 44539 invoked from network); 4 May 2008 01:45:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 4 May 2008 01:45:00 -0000 Received: (qmail 81797 invoked by uid 500); 4 May 2008 01:45:01 -0000 Delivered-To: martinnancy@example.net Received: (qmail 81171 invoked by uid 500); 4 May 2008 01:44:59 -0000 Mailing-List: contact martinnancy@example.net; run by ezmlm Precedence: bulk Reply-To: martinnancy@example.net list-help: <mailto:martinnancy@example.net> list-unsubscribe: <mailto:martinnancy@example.net> List-Post: <mailto:martinnancy@example.net> List-Id: <general.ws.apache.org> Delivered-To: mailing list martinnancy@example.net Received: (qmail 81160 invoked by uid 99); 4 May 2008 01:44:59 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 May 2008 18:44:59 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of martinnancy@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO wf-out-1314.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 04 May 2008 01:44:06 +0000 Received: by wf-out-1314.google.com with SMTP id 25so284075wfc.28 for <martinnancy@example.net>; Sat, 03 May 2008 18:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=l1GiCVKZ+DLXORmyajUhK75agjHXw4zMokxGFnKSpk4=; b=UU6+h6e4b8U3mr7gEBWq49G5hrS2fGE0QxUQ6hFYlIxJ4Q2ylB11BqWdHHO24w7q8tv8G3300V3QajUkfX3kdTkbhKpXt1dkhVfdUiwZK5k2tC6T7eCgAdUzOCP1fbYZrpl3A1l9dn5Lb7Ti0stVUQNd1KZRhuqzASowhGdVYLc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=qrucIn7Es/Epa3aR2DX16GzAGnR9xUXHtifQg4LBE4eNa6WtdnnpdbxR2HAkChV+81TMJLsVDHOBp9VK48zcUcvKddONZhE6nw80BvwpNsdCVmMGUHKjQeclfOxmuGVU0khXo9psNtSS4nYmKn9AAs5dfiP4Yb6uiWKJnBa8yBM= Received: by 83.161.120.155 with SMTP id x5mr1901905wfc.40.1209865467276; Sat, 03 May 2008 18:44:27 -0700 (PDT) Received: by 83.161.120.155 with HTTP; Sat, 3 May 2008 18:44:27 -0700 (PDT) Message-ID: <martinnancy@example.net> Date: Sat, 3 May 2008 21:44:27 -0400 From: "Davanum Srinivas" <martinnancy@example.net> To: "martinnancy@example.net" <martinnancy@example.net> Subject: What makes one be a WS PMC member? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Checked: Checked by ClamAV on apache.org So, over at the private@ws a thread got generated, i'm trying to push that here. My personal opinion on selection of new PMC members is as follows: - - People who work should take the blame :) (PMC members have legal yes/no for releases) - - People who i think will stick around (subjective) - - People who i think have been around for a while (objective - check email archives/JIRA/svn commits) - - More than 1 WS project (would be good but not necessary or sufficient) - - Engage of mailing lists properly for discussions (subjective - how many emails? how much do you drive to closure?) - - Technical expertise (may be, but not necessary or sufficient) thanks, dims --------------------------------------------------------------------- To unsubscribe, e-mail: martinnancy@example.net For additional commands, e-mail: martinnancy@example.net From martinnancy@example.net Sun May 04 02:28:45 2008 Return-Path: <martinnancy@example.net> Delivered-To: martinnancy@example.net Received: (qmail 56662 invoked from network); 4 May 2008 02:28:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 4 May 2008 02:28:42 -0000 Received: (qmail 93076 invoked by uid 500); 4 May 2008 02:28:43 -0000 Delivered-To: martinnancy@example.net Received: (qmail 92598 invoked by uid 500); 4 May 2008 02:28:42 -0000 Mailing-List: contact martinnancy@example.net; run by ezmlm Precedence: bulk Reply-To: martinnancy@example.net list-help: <mailto:martinnancy@example.net> list-unsubscribe: <mailto:martinnancy@example.net> List-Post: <mailto:martinnancy@example.net> List-Id: <general.ws.apache.org> Delivered-To: mailing list martinnancy@example.net Received: (qmail 92587 invoked by uid 99); 4 May 2008 02:28:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 May 2008 19:28:42 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of martinnancy@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO wf-out-1314.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 04 May 2008 02:27:54 +0000 Received: by wf-out-1314.google.com with SMTP id 25so293661wfc.28 for <martinnancy@example.net>; Sat, 03 May 2008 19:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=mjBj7WV7YmrXlsiSG0sWzswcS+tDUrv1GMrIowPikbY=; b=qt+98iksNj68xikV8rH9Sepm3Xg5+mHSFKN2tNCWTlRepueL8jKPJpkzgfVDBuCfSakP5hMvzqfgTbJA9lrQZE85+8LcIQN6etOPkiv39sBoILQEMMZUg0HxZVk3L54ONucfdLG/wacB44MSeZIRCUVhLs3YJYbtxlLc+nwDDTo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=XG/+mZbb2H7q85+Gbn32LZj1MyECVvq5EWvDN8pNQIX6j2/6e042i7lAZULCXMcK9Q6WDhBw2Z3Gl8xY1kGlVsIk/vzkkDnZLqXkXjMLuug0HPiZpv0ygOVB9fYNOCWpRYJvZSzsCMM5GeQNYad3NGLz3p7Z4ZQSxtvPMzrf2jY= Received: by 83.161.120.155 with SMTP id o2mr1901926wff.132.1209868088692; Sat, 03 May 2008 19:28:08 -0700 (PDT) Received: by 83.161.120.155 with HTTP; Sat, 3 May 2008 19:28:08 -0700 (PDT) Message-ID: <martinnancy@example.net> Date: Sat, 3 May 2008 22:28:08 -0400 From: "Davanum Srinivas" <martinnancy@example.net> To: "martinnancy@example.net" <martinnancy@example.net> Subject: Duties of the PMC members MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Checked: Checked by ClamAV on apache.org Folks, Here's something (see below) that i had sent to a the board mailing list a few years back (added one more item from the original draft). So I'd ask the Existing WS PMC Members to consider for example - How many commits they made in the recent past - How may releases they reviewed in the recent past - How many discussions they engaged in the recent past - How many JIRA's they raised/resolved in the recent past - .... You can do this very simply by using the excellent Apache/MarkMail tool, See example searches for svn commit activity. http://apache.markmail.org/search/?q=subject%3A%22svn+commit%22+from%3Aglen+order%3Adate-backward http://apache.markmail.org/search/?q=subject%3A%22svn+commit%22+from%3Adeepal+order%3Adate-backward http://apache.markmail.org/search/?q=subject%3A%22svn+commit%22+from%3Asanjiva+order%3Adate-backward http://apache.markmail.org/search/?q=subject%3A%22svn+commit%22+from%3Asamisa+order%3Adate-backward http://apache.markmail.org/search/?q=subject%3A%22svn+commit%22+from%3Adims+order%3Adate-backward Then make a determination on whether they should still continue to be PMC members or not for themselves. There is a thread going on in the private@ws for cleaning up of the PMC member list. I am sure this email will help people make up their minds a bit more. thanks, -- dims =========================================== Folks, Am trying to come up with bullet items (which can be expanded later) on what the board expects from a PMC and its members. Does anyone know if there is a document that already has this kind of list? Can folks please help refine/expand this list. (May be each line item should start with "Thou Shalt" :)=20 #1: Timely and accurate reports based on the rotation schedule in the foundation svn module #2: Create and maintain a charter that governs the PMC/project(s) #3: Take decisions affecting progress and health of the projects(s), ensure smooth functioning and create a conducive work atmosphere for everyone in the community. #4: Focus efforts more on community building rather than on code. #5: Ensure all community members (not just PMC members) participate in decision-making processes (ex: limit IRC usage, ban private lists for dev related decisions) #6: Work with Infrastructure to meet day-to-day requirements of community members. #7: Interact with other PMC's/Projects to learn best practices, reuse code, increase synergy, avoid duplication of effort. #8: Work with the board for refining policies and practices to better serve the needs of the community. #9: Work hard to add new individuals to the community, provide mentoring and enable them to join the PMC. 10: Keep strict watch on legal issues w.r.t copyrights, patents and licenses. Work proactively with our legal resources to avoid problems to folks who use our projects. 11: Be active and hands on contributor whether it is commits or JIRA's or answering questions on user or dev mailing list. =========================================== -- Davanum Srinivas 888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4 http://davanum.wordpress.com --------------------------------------------------------------------- To unsubscribe, e-mail: martinnancy@example.net For additional commands, e-mail: martinnancy@example.net From martinnancy@example.net Sun May 04 02:35:36 2008 Return-Path: <martinnancy@example.net> Delivered-To: martinnancy@example.net Received: (qmail 59632 invoked from network); 4 May 2008 02:35:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 4 May 2008 02:35:32 -0000 Received: (qmail 96478 invoked by uid 500); 4 May 2008 02:35:33 -0000 Delivered-To: martinnancy@example.net Received: (qmail 96026 invoked by uid 500); 4 May 2008 02:35:31 -0000 Mailing-List: contact martinnancy@example.net; run by ezmlm Precedence: bulk Reply-To: martinnancy@example.net list-help: <mailto:martinnancy@example.net> list-unsubscribe: <mailto:martinnancy@example.net> List-Post: <mailto:martinnancy@example.net> List-Id: <general.ws.apache.org> Delivered-To: mailing list martinnancy@example.net Received: (qmail 96015 invoked by uid 99); 4 May 2008 02:35:31 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 May 2008 19:35:31 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [83.161.120.155] (HELO eero.baz.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 04 May 2008 02:34:45 +0000 Received: by eero.baz.org (Postfix, from userid 1017) id EDBC389A5B; Sat, 3 May 2008 22:33:25 -0400 (EDT) Received: from [83.161.120.155] (pool-72-93-81-62.bstnma.fios.verizon.net [83.161.120.155]) by eero (tmda-ofmipd) with ESMTP; Sat, 03 May 2008 22:33:23 -0400 Message-ID: <martinnancy@example.net> Date: Sat, 03 May 2008 22:33:34 -0400 User-Agent: Thunderbird 83.161.120.155 (Windows/20080421) MIME-Version: 1.0 To: martinnancy@example.net Subject: Re: What makes one be a WS PMC member? References: <martinnancy@example.net> In-Reply-To: <martinnancy@example.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Glen Daniels <martinnancy@example.net> X-Virus-Checked: Checked by ClamAV on apache.org Hey dims: Davanum Srinivas wrote: > - - People who work should take the blame :) (PMC members have legal > yes/no for releases) > - - People who i think will stick around (subjective) > - - People who i think have been around for a while (objective - check > email archives/JIRA/svn commits) > - - More than 1 WS project (would be good but not necessary or sufficient) > - - Engage of mailing lists properly for discussions (subjective - how > many emails? how much do you drive to closure?) > - - Technical expertise (may be, but not necessary or sufficient) +1 to all of this, dims. As has been discussed before in other projects [1], some folks believe that essentially all committers should be PMC members. From my POV, if you trust someone enough to give them commit rights to your code, it seems a pretty small (and reasonable) step to also enfranchise them with the right to VOTE. Note that while it's true we respect committer votes a great deal in the WS PMC, non-PMC committers, technically, cannot actually use a -1 to veto code changes! [2] So I very much agree with dims' list here when considering, but I also tend towards defaulting to +1 unless I perceive a problem with one of the elements on this list. Thanks, --Glen [1] http://markmail.org/message/ydlyhbe6xigtw4nb [2] http://www.apache.org/foundation/voting.html --------------------------------------------------------------------- To unsubscribe, e-mail: martinnancy@example.net For additional commands, e-mail: martinnancy@example.net From martinnancy@example.net Mon May 05 14:54:45 2008 Return-Path: <martinnancy@example.net> Delivered-To: martinnancy@example.net Received: (qmail 39465 invoked from network); 5 May 2008 14:54:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 5 May 2008 14:54:42 -0000 Received: (qmail 37277 invoked by uid 500); 5 May 2008 14:54:43 -0000 Delivered-To: martinnancy@example.net Received: (qmail 36669 invoked by uid 500); 5 May 2008 14:54:41 -0000 Mailing-List: contact martinnancy@example.net; run by ezmlm Precedence: bulk Reply-To: martinnancy@example.net list-help: <mailto:martinnancy@example.net> list-unsubscribe: <mailto:martinnancy@example.net> List-Post: <mailto:martinnancy@example.net> List-Id: <general.ws.apache.org> Delivered-To: mailing list martinnancy@example.net Received: (qmail 36658 invoked by uid 99); 5 May 2008 14:54:41 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 May 2008 07:54:41 -0700 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [83.161.120.155] (HELO relay02.pair.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 05 May 2008 14:53:46 +0000 Received: (qmail 68860 invoked by uid 0); 5 May 2008 14:54:01 -0000 Received: from unknown (HELO ?83.161.120.155?) (unknown) by unknown with SMTP; 5 May 2008 14:54:01 -0000 X-pair-Authenticated: 83.161.120.155 Message-ID: <martinnancy@example.net> Date: Mon, 05 May 2008 20:24:00 +0530 From: Sanjiva Weerawarana <martinnancy@example.net> Organization: WSO2 Inc. User-Agent: Thunderbird 83.161.120.155 (X11/20080227) MIME-Version: 1.0 To: martinnancy@example.net Subject: Re: Duties of the PMC members References: <martinnancy@example.net> In-Reply-To: <martinnancy@example.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Dims, what has motivated you to suddenly want to trim the WS PMC? Also, a PMC conversation should be on the private list and not on the general@ list. As I said on the PMC list where this thread started, PMC membership is one of the (many) criteria for ASF membership nomination and acceptance. I encourage those who intend to stick around ASF "for ever" and hence desire to become members to *not* leave the PMC. Going inactive "for a while" does not make it a crime. We have 200+ (I've lost count .. wouldn't surprise me if its not even more) committers in the WS project now. If you really have intention of contributing again then definitely please do excuse yourself. Sanjiva. Davanum Srinivas wrote: > Folks, > > Here's something (see below) that i had sent to a the board mailing > list a few years back (added one more item from the original draft). > So I'd ask the Existing WS PMC Members to consider for example > > - How many commits they made in the recent past > - How may releases they reviewed in the recent past > - How many discussions they engaged in the recent past > - How many JIRA's they raised/resolved in the recent past > - .... > > You can do this very simply by using the excellent Apache/MarkMail > tool, See example searches for svn commit activity. > http://apache.markmail.org/search/?q=subject%3A%22svn+commit%22+from%3Aglen+order%3Adate-backward > http://apache.markmail.org/search/?q=subject%3A%22svn+commit%22+from%3Adeepal+order%3Adate-backward > http://apache.markmail.org/search/?q=subject%3A%22svn+commit%22+from%3Asanjiva+order%3Adate-backward > http://apache.markmail.org/search/?q=subject%3A%22svn+commit%22+from%3Asamisa+order%3Adate-backward > http://apache.markmail.org/search/?q=subject%3A%22svn+commit%22+from%3Adims+order%3Adate-backward > > Then make a determination on whether they should still continue to be > PMC members or not for themselves. There is a thread going on in the > private@ws for cleaning up of the PMC member list. I am sure this > email will help people make up their minds a bit more. > > thanks, > -- dims > > =========================================== > Folks, > > Am trying to come up with bullet items (which can be expanded later) > on what the board expects from a PMC and its members. Does anyone know > if there is a document that already has this kind of list? Can folks > please help refine/expand this list. > > (May be each line item should start with "Thou Shalt" :)=20 > > #1: Timely and accurate reports based on the rotation schedule in the > foundation svn module > #2: Create and maintain a charter that governs the PMC/project(s) > #3: Take decisions affecting progress and health of the projects(s), > ensure smooth functioning and create a conducive work atmosphere for > everyone in the community. > #4: Focus efforts more on community building rather than on code. > #5: Ensure all community members (not just PMC members) participate in > decision-making processes (ex: limit IRC usage, ban private lists for > dev related decisions) > #6: Work with
{'source': 'Apache Software Foundation Public Mail Archives'}