Jenkins Access for Storm
I'd like to set up a Jenkins build for Storm. If someone could add me (username: ptgoetz) to the hudson-jobadmin group I would greatly appreciate it. Thanks in advance, Taylor - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP CLEARANCE] [VOTE] Apache Celix shared memory Remote Service Admin implementation (2nd attempt)
Hi Marcel, The ip looks good, but the ip clearance document is our historical record and needs to be updated. No need to re-run the vote if the document is corrected. On Dec 18, 2013, at 2:28 PM, Marcel Offermans wrote: Note that this is a new vote, after cancelling the previous one. Apache Celix received the donation of a shared memory implementation of the remote service admin specification. The donation is tracked by CELIX-81 [1]. The (updated) IP clearance document is placed under: https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/celix-shared-memory-rsa.xml The ip clearance document should provide one stop shopping to verify the provenance of the ip and the grant. Can you please update the above document to include the location of the grant from Thales Nederland B.V.? https://svn.apache.org/repos/private/documents/grants/thales-nederland-celix-remote-services-admin-bundle.pdf Thanks, Craig The software grant can be found in the appropriate document in svn (I’ve included a few relevant lines to make it easier to locate it): Thales Nederland B.V. file: thales-nederland-celix-remote-services-admin-bundle.pdf for: A remote services admin bundle and a discovery bundle which uses shared memory for information interchange. See: CELIX-81 Please vote to approve this contribution. Lazy consensus applies. If no -1 votes are cast within the next 72 hours, the vote passes. Greetings, Marcel [1] https://issues.apache.org/jira/browse/CELIX-81 Craig L Russell Secretary, Apache Software Foundation c...@apache.org http://db.apache.org/jdo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Subscribtion at the private list
I have the same issue (tried multiple time for a week). Will do the same. From: David Crossley cross...@apache.org To: general@incubator.apache.org Sent: Wednesday, December 18, 2013 11:29 PM Subject: Re: Subscribtion at the private list Raphael Bircher wrote: Hi all I'm still not subscribed at the private incubator list. I was sending a request, but for some reasons, I'm not registred yet. Can someone help me to get on the private list. Thanks! Gee, that is not good. If you still get no result, perhaps try contacting the moderators directly at private-owner@i.a.o -David Greetings Raphael - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about jar files in svn.
On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk tras...@stratuscom.com wrote: We’re having a discussion over in d...@river.apache.org that was triggered by the recent discussion here about the Spark podling release. The River discussions seem to be playing out productively. Here are links for other people who may be interested: https://issues.apache.org/jira/browse/RIVER-432 http://markmail.org/thread/abppti56ipnhnnfy To be more specific, there doesn’t seem to be any doubt that jars shouldn’t be included in source release packages, but would it be fair to say that they should also not be in the svn? My understanding is that it is fine to store jars in version control outside of the main source tree, analogous to providing a separate -deps download. Between that and technical solutions which download deps on the fly such as Ivy and Maven, I think that renders the question about whether binaries can reside in the main source tree within version control moot. But there's no strictly enforced policy AFAIK because we discourage people from considering our source control repositories distribution points. (Note to podlings: this is why we make links to source control only available through the developer portions of our websites, etc.) That way we don't have to be rigid about enforcing the policies which apply to releases at every single commit point, even as we make best efforts to keep our trees clean. FWIW, the same principles which give us a measure of flexibility about LICENSE and NOTICE in version control could arguably apply to jar files as well. Here's Board member Doug Cutting back in September on legal-discuss@apache: http://s.apache.org/GNP I think perhaps you're looking for clear lines where things are actually a bit fuzzy. Certainly releases are official distributions and need LICENSE and NOTICE files. That line is clear. On the other hand, we try to discourage folks from thinking that source control is a distribution. Rather we wish it to be considered our shared workspace, containing works in progress, not yet always ready for distribution to folks outside the foundation. But, since we work in public, folks from outside the foundation can see our shared workspace and might occasionally mistake it for an official distribution. We'd like them to still see a LICENSE and NOTICE file. So it's not a hard-and-fast requirement that every tree that can possibly be checked out have a LICENSE and NOTICE file at its root, but it's a good practice for those trees that are likely to be checked out have them, so that folks who might consume them are well informed. Again, policy flexibility with respect to version control becomes academic if you can restructure the build. Nevertheless, I hope that this additional background is helpful for River's ongoing discussions. Cheers, Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about jar files in svn.
But at the end, when a podling prepare a release there should not include jar files as part of the source release artifacts to be VOTED on, is this correct? - Henry On Thu, Dec 19, 2013 at 9:21 AM, Marvin Humphrey mar...@rectangular.com wrote: On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk tras...@stratuscom.com wrote: We’re having a discussion over in d...@river.apache.org that was triggered by the recent discussion here about the Spark podling release. The River discussions seem to be playing out productively. Here are links for other people who may be interested: https://issues.apache.org/jira/browse/RIVER-432 http://markmail.org/thread/abppti56ipnhnnfy To be more specific, there doesn’t seem to be any doubt that jars shouldn’t be included in source release packages, but would it be fair to say that they should also not be in the svn? My understanding is that it is fine to store jars in version control outside of the main source tree, analogous to providing a separate -deps download. Between that and technical solutions which download deps on the fly such as Ivy and Maven, I think that renders the question about whether binaries can reside in the main source tree within version control moot. But there's no strictly enforced policy AFAIK because we discourage people from considering our source control repositories distribution points. (Note to podlings: this is why we make links to source control only available through the developer portions of our websites, etc.) That way we don't have to be rigid about enforcing the policies which apply to releases at every single commit point, even as we make best efforts to keep our trees clean. FWIW, the same principles which give us a measure of flexibility about LICENSE and NOTICE in version control could arguably apply to jar files as well. Here's Board member Doug Cutting back in September on legal-discuss@apache: http://s.apache.org/GNP I think perhaps you're looking for clear lines where things are actually a bit fuzzy. Certainly releases are official distributions and need LICENSE and NOTICE files. That line is clear. On the other hand, we try to discourage folks from thinking that source control is a distribution. Rather we wish it to be considered our shared workspace, containing works in progress, not yet always ready for distribution to folks outside the foundation. But, since we work in public, folks from outside the foundation can see our shared workspace and might occasionally mistake it for an official distribution. We'd like them to still see a LICENSE and NOTICE file. So it's not a hard-and-fast requirement that every tree that can possibly be checked out have a LICENSE and NOTICE file at its root, but it's a good practice for those trees that are likely to be checked out have them, so that folks who might consume them are well informed. Again, policy flexibility with respect to version control becomes academic if you can restructure the build. Nevertheless, I hope that this additional background is helpful for River's ongoing discussions. Cheers, Marvin Humphrey - 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: Question about jar files in svn.
On 19 December 2013 18:26, Henry Saputra henry.sapu...@gmail.com wrote: But at the end, when a podling prepare a release there should not include jar files as part of the source release artifacts to be VOTED on, is this correct? I think that depends on what the jar files are. For example. Apache Commons Compress includes some jar files in SVN and the source release as part of the test data. But I would not expect to find external jar files in the source release. - Henry On Thu, Dec 19, 2013 at 9:21 AM, Marvin Humphrey mar...@rectangular.com wrote: On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk tras...@stratuscom.com wrote: We’re having a discussion over in d...@river.apache.org that was triggered by the recent discussion here about the Spark podling release. The River discussions seem to be playing out productively. Here are links for other people who may be interested: https://issues.apache.org/jira/browse/RIVER-432 http://markmail.org/thread/abppti56ipnhnnfy To be more specific, there doesn’t seem to be any doubt that jars shouldn’t be included in source release packages, but would it be fair to say that they should also not be in the svn? My understanding is that it is fine to store jars in version control outside of the main source tree, analogous to providing a separate -deps download. Between that and technical solutions which download deps on the fly such as Ivy and Maven, I think that renders the question about whether binaries can reside in the main source tree within version control moot. But there's no strictly enforced policy AFAIK because we discourage people from considering our source control repositories distribution points. (Note to podlings: this is why we make links to source control only available through the developer portions of our websites, etc.) That way we don't have to be rigid about enforcing the policies which apply to releases at every single commit point, even as we make best efforts to keep our trees clean. FWIW, the same principles which give us a measure of flexibility about LICENSE and NOTICE in version control could arguably apply to jar files as well. Here's Board member Doug Cutting back in September on legal-discuss@apache: http://s.apache.org/GNP I think perhaps you're looking for clear lines where things are actually a bit fuzzy. Certainly releases are official distributions and need LICENSE and NOTICE files. That line is clear. On the other hand, we try to discourage folks from thinking that source control is a distribution. Rather we wish it to be considered our shared workspace, containing works in progress, not yet always ready for distribution to folks outside the foundation. But, since we work in public, folks from outside the foundation can see our shared workspace and might occasionally mistake it for an official distribution. We'd like them to still see a LICENSE and NOTICE file. So it's not a hard-and-fast requirement that every tree that can possibly be checked out have a LICENSE and NOTICE file at its root, but it's a good practice for those trees that are likely to be checked out have them, so that folks who might consume them are well informed. Again, policy flexibility with respect to version control becomes academic if you can restructure the build. Nevertheless, I hope that this additional background is helpful for River's ongoing discussions. Cheers, Marvin Humphrey - 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: Question about jar files in svn.
Ah I see. So the point of concern is the external jars, but jars that are generated by the project itself (for example for tests) should be fine? - Henry On Thu, Dec 19, 2013 at 10:34 AM, sebb seb...@gmail.com wrote: On 19 December 2013 18:26, Henry Saputra henry.sapu...@gmail.com wrote: But at the end, when a podling prepare a release there should not include jar files as part of the source release artifacts to be VOTED on, is this correct? I think that depends on what the jar files are. For example. Apache Commons Compress includes some jar files in SVN and the source release as part of the test data. But I would not expect to find external jar files in the source release. - Henry On Thu, Dec 19, 2013 at 9:21 AM, Marvin Humphrey mar...@rectangular.com wrote: On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk tras...@stratuscom.com wrote: We’re having a discussion over in d...@river.apache.org that was triggered by the recent discussion here about the Spark podling release. The River discussions seem to be playing out productively. Here are links for other people who may be interested: https://issues.apache.org/jira/browse/RIVER-432 http://markmail.org/thread/abppti56ipnhnnfy To be more specific, there doesn’t seem to be any doubt that jars shouldn’t be included in source release packages, but would it be fair to say that they should also not be in the svn? My understanding is that it is fine to store jars in version control outside of the main source tree, analogous to providing a separate -deps download. Between that and technical solutions which download deps on the fly such as Ivy and Maven, I think that renders the question about whether binaries can reside in the main source tree within version control moot. But there's no strictly enforced policy AFAIK because we discourage people from considering our source control repositories distribution points. (Note to podlings: this is why we make links to source control only available through the developer portions of our websites, etc.) That way we don't have to be rigid about enforcing the policies which apply to releases at every single commit point, even as we make best efforts to keep our trees clean. FWIW, the same principles which give us a measure of flexibility about LICENSE and NOTICE in version control could arguably apply to jar files as well. Here's Board member Doug Cutting back in September on legal-discuss@apache: http://s.apache.org/GNP I think perhaps you're looking for clear lines where things are actually a bit fuzzy. Certainly releases are official distributions and need LICENSE and NOTICE files. That line is clear. On the other hand, we try to discourage folks from thinking that source control is a distribution. Rather we wish it to be considered our shared workspace, containing works in progress, not yet always ready for distribution to folks outside the foundation. But, since we work in public, folks from outside the foundation can see our shared workspace and might occasionally mistake it for an official distribution. We'd like them to still see a LICENSE and NOTICE file. So it's not a hard-and-fast requirement that every tree that can possibly be checked out have a LICENSE and NOTICE file at its root, but it's a good practice for those trees that are likely to be checked out have them, so that folks who might consume them are well informed. Again, policy flexibility with respect to version control becomes academic if you can restructure the build. Nevertheless, I hope that this additional background is helpful for River's ongoing discussions. Cheers, Marvin Humphrey - 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about jar files in svn.
My understanding of the link I posted way back is that the source package cannot contain compiled output that will be executed by the customer. IMO, whether it is external or not doesn't matter. The JAR used by the Compress tests is hopefully just data, not some part of its functionality. On 12/19/13 10:40 AM, Henry Saputra henry.sapu...@gmail.com wrote: Ah I see. So the point of concern is the external jars, but jars that are generated by the project itself (for example for tests) should be fine? - Henry On Thu, Dec 19, 2013 at 10:34 AM, sebb seb...@gmail.com wrote: On 19 December 2013 18:26, Henry Saputra henry.sapu...@gmail.com wrote: But at the end, when a podling prepare a release there should not include jar files as part of the source release artifacts to be VOTED on, is this correct? I think that depends on what the jar files are. For example. Apache Commons Compress includes some jar files in SVN and the source release as part of the test data. But I would not expect to find external jar files in the source release. - Henry On Thu, Dec 19, 2013 at 9:21 AM, Marvin Humphrey mar...@rectangular.com wrote: On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk tras...@stratuscom.com wrote: We¹re having a discussion over in d...@river.apache.org that was triggered by the recent discussion here about the Spark podling release. The River discussions seem to be playing out productively. Here are links for other people who may be interested: https://issues.apache.org/jira/browse/RIVER-432 http://markmail.org/thread/abppti56ipnhnnfy To be more specific, there doesn¹t seem to be any doubt that jars shouldn¹t be included in source release packages, but would it be fair to say that they should also not be in the svn? My understanding is that it is fine to store jars in version control outside of the main source tree, analogous to providing a separate -deps download. Between that and technical solutions which download deps on the fly such as Ivy and Maven, I think that renders the question about whether binaries can reside in the main source tree within version control moot. But there's no strictly enforced policy AFAIK because we discourage people from considering our source control repositories distribution points. (Note to podlings: this is why we make links to source control only available through the developer portions of our websites, etc.) That way we don't have to be rigid about enforcing the policies which apply to releases at every single commit point, even as we make best efforts to keep our trees clean. FWIW, the same principles which give us a measure of flexibility about LICENSE and NOTICE in version control could arguably apply to jar files as well. Here's Board member Doug Cutting back in September on legal-discuss@apache: http://s.apache.org/GNP I think perhaps you're looking for clear lines where things are actually a bit fuzzy. Certainly releases are official distributions and need LICENSE and NOTICE files. That line is clear. On the other hand, we try to discourage folks from thinking that source control is a distribution. Rather we wish it to be considered our shared workspace, containing works in progress, not yet always ready for distribution to folks outside the foundation. But, since we work in public, folks from outside the foundation can see our shared workspace and might occasionally mistake it for an official distribution. We'd like them to still see a LICENSE and NOTICE file. So it's not a hard-and-fast requirement that every tree that can possibly be checked out have a LICENSE and NOTICE file at its root, but it's a good practice for those trees that are likely to be checked out have them, so that folks who might consume them are well informed. Again, policy flexibility with respect to version control becomes academic if you can restructure the build. Nevertheless, I hope that this additional background is helpful for River's ongoing discussions. Cheers, Marvin Humphrey - 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about jar files in svn.
On 19 December 2013 18:57, Alex Harui aha...@adobe.com wrote: My understanding of the link I posted way back is that the source package cannot contain compiled output that will be executed by the customer. IMO, whether it is external or not doesn't matter. The JAR used by the Compress tests is hopefully just data, not some part of its functionality. Yes, the jars are test data. On 12/19/13 10:40 AM, Henry Saputra henry.sapu...@gmail.com wrote: Ah I see. So the point of concern is the external jars, but jars that are generated by the project itself (for example for tests) should be fine? Again, that's ambiguous. I would not expect to find jars of the project source in source releases. Note that the Compress test jars were manually created on various different systems. - Henry On Thu, Dec 19, 2013 at 10:34 AM, sebb seb...@gmail.com wrote: On 19 December 2013 18:26, Henry Saputra henry.sapu...@gmail.com wrote: But at the end, when a podling prepare a release there should not include jar files as part of the source release artifacts to be VOTED on, is this correct? I think that depends on what the jar files are. For example. Apache Commons Compress includes some jar files in SVN and the source release as part of the test data. But I would not expect to find external jar files in the source release. - Henry On Thu, Dec 19, 2013 at 9:21 AM, Marvin Humphrey mar...@rectangular.com wrote: On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk tras...@stratuscom.com wrote: We¹re having a discussion over in d...@river.apache.org that was triggered by the recent discussion here about the Spark podling release. The River discussions seem to be playing out productively. Here are links for other people who may be interested: https://issues.apache.org/jira/browse/RIVER-432 http://markmail.org/thread/abppti56ipnhnnfy To be more specific, there doesn¹t seem to be any doubt that jars shouldn¹t be included in source release packages, but would it be fair to say that they should also not be in the svn? My understanding is that it is fine to store jars in version control outside of the main source tree, analogous to providing a separate -deps download. Between that and technical solutions which download deps on the fly such as Ivy and Maven, I think that renders the question about whether binaries can reside in the main source tree within version control moot. But there's no strictly enforced policy AFAIK because we discourage people from considering our source control repositories distribution points. (Note to podlings: this is why we make links to source control only available through the developer portions of our websites, etc.) That way we don't have to be rigid about enforcing the policies which apply to releases at every single commit point, even as we make best efforts to keep our trees clean. FWIW, the same principles which give us a measure of flexibility about LICENSE and NOTICE in version control could arguably apply to jar files as well. Here's Board member Doug Cutting back in September on legal-discuss@apache: http://s.apache.org/GNP I think perhaps you're looking for clear lines where things are actually a bit fuzzy. Certainly releases are official distributions and need LICENSE and NOTICE files. That line is clear. On the other hand, we try to discourage folks from thinking that source control is a distribution. Rather we wish it to be considered our shared workspace, containing works in progress, not yet always ready for distribution to folks outside the foundation. But, since we work in public, folks from outside the foundation can see our shared workspace and might occasionally mistake it for an official distribution. We'd like them to still see a LICENSE and NOTICE file. So it's not a hard-and-fast requirement that every tree that can possibly be checked out have a LICENSE and NOTICE file at its root, but it's a good practice for those trees that are likely to be checked out have them, so that folks who might consume them are well informed. Again, policy flexibility with respect to version control becomes academic if you can restructure the build. Nevertheless, I hope that this additional background is helpful for River's ongoing discussions. Cheers, Marvin Humphrey - 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:
Re: Jenkins Access for Storm
done Have fun!! On 20 December 2013 01:23, P. Taylor Goetz ptgo...@gmail.com wrote: I'd like to set up a Jenkins build for Storm. If someone could add me (username: ptgoetz) to the hudson-jobadmin group I would greatly appreciate it. Thanks in advance, Taylor - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Jenkins Access for Storm
Thanks Olivier! On Dec 19, 2013, at 6:11 PM, Olivier Lamy ol...@apache.org wrote: done Have fun!! On 20 December 2013 01:23, P. Taylor Goetz ptgo...@gmail.com wrote: I'd like to set up a Jenkins build for Storm. If someone could add me (username: ptgoetz) to the hudson-jobadmin group I would greatly appreciate it. Thanks in advance, Taylor - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - 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: Release Verification Checklist
Marvin Humphrey wrote: ant elder wrote: All the stuff required to be checked when voting on a release should be documented in the ASF doc about releases. That its not in that doc suggests its not required. If someone thinks something is required then they should go get consensus around that with the wider ASF and get the ASF doc updated. There was a time not long ago, where hardly anything was documented. Rather it was just common-sense. So in my opinion, not being in those docs does not mean that it is not required. (Not sure where to insert some other comments in this thread, so will just dump them here.) I am concerned about potentially changing the way we do things. So, two comments with that in mind: Votes should also encourage anyone to vote (though of course as non-binding). With this SVN based technique, how do they do that? The current new guides/release.html says contains a link URL for the Manifest. I suppose that they could be encouraged to copy the text from SVN and reply via the dev mail list. If the dev list PPMC vote passes including 3+ IPMC members then there is no need for this second vote. The wording gives a slight twist which might sway the understanding of why we do such things. Also some good stuff is in the old guides/releasemanagement.html so we do need to ensure that is over at a.o/dev/. -David OK, I've done the research and I've migrated the manifest proposal to a new documentation page with the links. The ReleaseChecklist wiki page is now a home for optional checklist items. http://incubator.apache.org/guides/release.html https://wiki.apache.org/incubator/ReleaseChecklist Applying your criteria to the current checklist has resulted in the migration of two items to the optional list: * Each expanded source archive matches the corresponding SCM tag. It turns out the only place matching the SCM tag was documented is the Incubator's Release Management guide. Here's Leo Simons making the case against: http://markmail.org/message/2ncepopzgnshtyd6. * Build instructions are provided, unless obvious I haven't found any documentation that this is required anywhere on www.apache.org/dev or www.apache.org/legal. Bertrand, between me arguing that this won't come into play often enough and Ant and Olivier arguing that we should only include blockers documented elsewhere, I've made the judgment call that this should be moved to the optional list as well. Please let us know if you object. Podling releases are not quite the same as TLP releases, thats why they have the DISCLAIMER and incubating naming. I think we should be making it easier for podlings to do releases, if its really necessary then make an audit of the last release a requirement of graduation. I am passionately committed to making it easier for podlings to release, by granting limited self-governance to those who earn it. The proposal under consideration is a win for *both* streamlining the release voting process and improving release oversight. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Release Verification Checklist
On Thu, Dec 19, 2013 at 5:07 PM, David Crossley cross...@apache.org wrote: There was a time not long ago, where hardly anything was documented. Rather it was just common-sense. So in my opinion, not being in those docs does not mean that it is not required. If there are required items which have been inadvertently left off, we can add them later. We are already set to track optional items on the ReleaseChecklist wiki page as well. There should be a low threshold for adding an optional item to the wiki, and a high threshold for adding a required item to the default checklist. I have added the following text to the Experimental Release Guide to clarify: Each review item in the default Manifest is either required by Foundation-wide policy and would block a release by any Apache top-level project, or is required by Incubator policy. I can think of one item which was left off and should probably added to the default checklist in my opinion: 1.2 RM apache.org release signing key present in KEYS file. Votes should also encourage anyone to vote (though of course as non-binding). With this SVN based technique, how do they do that? The PPMC VOTE must be called on the podling dev list. Non-binding votes may be cast as they are now -- via email -- and I agree that they should be encouraged. If the dev list PPMC vote passes including 3+ IPMC members then there is no need for this second vote. Current Incubator policy requires the second vote on general@incubator. http://incubator.apache.org/incubation/Incubation_Policy.html#Releases If the majority of all votes is positive, then the Podling SHALL send a summary of that vote to the Incubator's general list and formally request the Incubator PMC approve such a release. The experiment maintains this procedure. Also some good stuff is in the old guides/releasemanagement.html so we do need to ensure that is over at a.o/dev/. The experimental release guide supplants the old one as a spec, but not as an archive of opinions about best practices. A single document cannot serve well in both capacities. We need both, and they must be separate. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Release Verification Checklist
On Fri, Dec 13, 2013 at 6:42 PM, sebb seb...@gmail.com wrote: The current source release artifacts must be released via the ASF mirroring system. Download pages must not point directly to the ASF servers; they must use the mirror CGI scripts Also old releases must not be left on the mirroring system; any download links must use the ASF archive server. The download pages must also include links to sigs and hashes and the KEYS file, all of which must be on the ASF servers (not via mirrors). I agree that these are all important, but as they are not directly related to the release artifacts and do not block a release, they belong in a different checklist. I've started a GraduationChecklist wiki page so that the suggestions do not get lost. https://wiki.apache.org/incubator/GraduationChecklist Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Subscribtion at the private list
Hi, On Thu, Dec 19, 2013 at 1:20 AM, Raphael Bircher r.birc...@gmx.ch wrote: I'm still not subscribed at the private incubator list. I was sending a request, but for some reasons, I'm not registred yet. Can someone help me to get on the private list. Thanks! I checked through the backlog of recent subscription requests and approved the new IPMC members. Welcome! Apologies for the delay. It seems like we need a few new moderators for private@incubator. Any volunteers? BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about jar files in svn.
On Thu, Dec 19, 2013 at 10:40 AM, Henry Saputra henry.sapu...@gmail.com wrote: So the point of concern is the external jars, but jars that are generated by the project itself (for example for tests) should be fine? One main concern is oversight for what goes into an an Apache release. It's not realistic to perform a line-by-line review for all source code in a release candidate, but if we trust our version control and our commit notification systems, we can have confidence that the what goes into a release has been reviewed over time by the PMC. Checking that the expanded content of the source archive matches an export from a version control tag is a useful (albeit not universally appropriate) way of verifying that the release is what it says it is. A compiled binary, on the other hand, is an opaque product of source code plus build environment. It can't be reviewed, and the build machine is potentially a target for crackers. Hence, these quotes from Roy: http://s.apache.org/roy-binary-deps-2 I consider them to be trojan horses. I wouldn't hesitate for a second to delete them outright. Actually, what I've done in the past (yes, I have done this before) is move them to a subdir of my homedir and then tell the relevant project to WTFU and do it right. Note, however, I would not delete the ones in archive -- that would be silly. http://s.apache.org/roy-binary-deps-3 People have to understand this. There will always be a role for downstream commercial or non-commercial redistributions of Apache products. Why? Because the ASF is incapable of taking on the enormous liability associated with released binaries that are not produced in a controlled environment with a controlled set of tools. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Subscribtion at the private list
I'd volunteer. What does it involve? Of course I am new here. Thanks. -- Lars From: Jukka Zitting jukka.zitt...@gmail.com To: general general@incubator.apache.org Sent: Thursday, December 19, 2013 8:29 PM Subject: Re: Subscribtion at the private list Hi, On Thu, Dec 19, 2013 at 1:20 AM, Raphael Bircher r.birc...@gmx.ch wrote: I'm still not subscribed at the private incubator list. I was sending a request, but for some reasons, I'm not registred yet. Can someone help me to get on the private list. Thanks! I checked through the backlog of recent subscription requests and approved the new IPMC members. Welcome! Apologies for the delay. It seems like we need a few new moderators for private@incubator. Any volunteers? BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
