Re: Google Services License, was: Re: [GSoC] [DISCUSS] Development of GData biding
On 6/4/08, Mike Edwards [EMAIL PROTECTED] wrote: Luciano, Yes, I'm no lawyer either. It just brought me up short to find that the code itself is licensed under Apache license, but then there is this other pile of legal stuff which applies to any *use* of the code. What purpose does the code have other than to be used??? So I want to make sure that we have thought through what this means - I don't want to see Tuscany in general being subjected to any kinds of legal limitations just because we decided to include some Google code in our SVN. Copyright licenses pertain to copying (and performing). Patents pertain to use. Software is a little odd since a copy of the program must be created before it can be used. I don't know whether we need to ask the wider Apache community about this - does anyone have the necessary legal experience to offer advice? I recommend posting this question to the legal-discuss list Robert Yours, Mike. Luciano Resende wrote: Let me start with a DISCLAIMER that I'm not a lawyer, so all that I'm going to say here is my own understanding. I think that the link you sent, is more towards the usage of google services (e.g blogger, calendar, etc)... and GData Java Client API would be the Apache Licensed code that could be used to programatically access these services. Having said that, I'd compare this to using an apache licensed api to access some kind of proprietary services from Amazon or any other company. Based on that, I think the usage of the api should be fine, but connecting to actual google services would require a google account and also that the user has accepted those license terms. Well, this is just how I understood. Any other Thoughts ? On Tue, Jun 3, 2008 at 12:26 AM, Mike Edwards [EMAIL PROTECTED] wrote: Luciano Resende wrote: Hey Mike What are your concerns with regards to license ? Looking at [1], it looks like the GData Java Client is Apache License 2. [1] http://code.google.com/p/gdata-java-client/ On Mon, Jun 2, 2008 at 10:01 PM, Mike Edwards [EMAIL PROTECTED] wrote: Douglas Leite wrote: After analyzing the Google Data API and the code of binding-atom, binding-atom-abdera, and binding-feed, I propose an approach to start the development of the GData biding. I propose creating a new type of binding: biding-gdata. Similarly as binding-atom-abdera, that extends the binding-atom, this new kind of binding would extend the binding-atom too. The implementation of the invokers (linke GetInvoker, PostInvoker, and PutInvoker) would be done using the GData Java Client, that provides tools and an abstract layer, abstracting the necessity of handling with HTTP requests/responses and XML's processing. The binding-gdata could extend the binding-rss aiming to allow RSS feeds. This approach looks like the binding-feed, but reusing the binding-atom and binding-rss, and using the GData Java Client to implement the invokers. What do you think about? Douglas, We need to take some care over the idea of using the GData Java Client - we need to check out the legal terms that apply to the client code, since it does not appear to have a license that is compatible with the Apache open source license, as far as I can tell. I'm not saying that you can't use the Google code, but we do need to ask to see what the right way would be to use this code. Yours, Mike. Luciano, What about this page, linked off the one above: http://code.google.com/tos.html Yours, Mike.
Re: Google Services License, was: Re: [GSoC] [DISCUSS] Development of GData biding
On Wed, Jun 4, 2008 at 7:59 AM, Luciano Resende [EMAIL PROTECTED] wrote: I'm About to forward to legal@ to get further advice. i recommend legal-discuss as the first point of contact - robert
Re: Graduation
On 5/22/08, Paul Fremantle [EMAIL PROTECTED] wrote: Congratulations everyone! +1 Robert Paul On Thu, May 22, 2008 at 3:43 AM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: That's great news. ++Vamsi On Thu, May 22, 2008 at 2:44 AM, Matthieu Riou [EMAIL PROTECTED] wrote: Special order 7B, Establish the Apache Tuscany Project, was approved by Unanimous Vote of the directors present. Congratulations guys! Matthieu -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com
Re: Mirror of release artifacts
On Wed, Apr 16, 2008 at 8:41 AM, ant elder [EMAIL PROTECTED] wrote: I think thats a separate issue but if its the reason we stopped using the mirrors then i think we need to start using them again. It may not be clearly documented yet but i think the current ASF/incubator policy is that releases MUST be distributed via the mirrors. +1 http://incubator.apache.org/incubation/Incubation_Policy.html#Releases (last line) if you want to collect download statistics from a mirrored download then google/yahoo analytics is probably your best bet - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mirror of release artifacts
On Wed, Apr 16, 2008 at 4:51 PM, Luciano Resende [EMAIL PROTECTED] wrote: Distribution links pointing to the place below is enough ? http://www.apache.org/dist/incubator/tuscany/java/sca/1.1-incubating/ no: releases must be downloaded from mirrors and not from the main apache server (see http://incubator.apache.org/guides/releasemanagement.html#release-distribution) As for using google analytics for download information, this would be much easier, but can someone please show me an example that only count the actual downloads, instead of just page load/visit ? it's not really possible to count downloads from mirrors. it is possible to count the number of times that the mirroring script is executed which is a reasonable proxy. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GSoc08 Application: Hadoop Map/Reduce SCA Integration Project
On Sun, Mar 30, 2008 at 5:06 AM, Chris Trezzo [EMAIL PROTECTED] wrote: Hello everyone, I have posted a rough draft proposal for the project entitled Simplify the development of Map/Reduce applications and their integration with various sources of information. The draft is located here: http://www.cse.ucsd.edu/~ctrezzo/gsocapplication.html Any comments/suggestions would be highly appreciated. just throwing out an idea... but would it be possible/beneficial to wrap Map/Reduce resources using SCAs the other way round as well? for example, take an abstract service which performs some possibly intensive analytic computation. at smaller scales or development, the analytic components might be assembled into a simple web service running on a single container. at the the largest scales, the work may need to be farmed out to one of a number of clouds. perhaps an active management layer might be able to make decisions to route the processing to different possibly hetrogeneous resources based on data and meta-data (cloud load, time of day and so on) . for example, during local night these computations might be directed to a grid formed on general purpose PCs used during the day. (who usually just lurks...) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commercial Dev Support
On Sat, Mar 22, 2008 at 6:57 PM, Evo Eftimov [EMAIL PROTECTED] wrote: We are a solution provider company planning to implement Tuscany as SCA Container for large SOA project. What kind of commercial support packages are offered by Tuscany to end clients apache is a non-profit organisation. apache tuscany is an open, collaborative project involves contributors from many different backgrounds. apache does not, indeed cannot offer commerical support for tuscany or any other project. commercial support for apache projects is provided by independent third parties who either contribute or know the codebase well. it would not be ethical for apache to recommend any particular one. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Java SCA Release 1.1-incubating and new Incubator distribution policy
On Feb 4, 2008 3:09 PM, Simon Laws [EMAIL PROTECTED] wrote: On Feb 3, 2008 7:04 PM, Robert Burrell Donkin [EMAIL PROTECTED] wrote: On Feb 3, 2008 5:10 PM, Simon Laws [EMAIL PROTECTED] wrote: On Feb 3, 2008 4:55 PM, Robert Burrell Donkin [EMAIL PROTECTED] wrote: On Feb 3, 2008 3:53 PM, Simon Laws [EMAIL PROTECTED] wrote: snip When we get the go ahead it's left from me to upload the artifacts to www.apache.org/dist/incubator/tuscany/, set the correct group and permissions as documented and then integrate the new release page into the Tuscany web site. yep (it's not really a go-ahead, more a make-sure-you-know-what-you're-doing) you're planning to use the dynamic script? (rather than a custom download script) Yes. in that case, the script looks ok to me make sure that the signatures are correct and uploaded at the same time as the release. is your key available from a public key server? Yep, it's here http://pgp.mit.edu:11371/pks/lookup?search=simon+lawsop=vindex great look like everything's covered. fine by me to upload whenever you're ready. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Java SCA Release 1.1-incubating and new Incubator distribution policy
On Feb 1, 2008 4:00 PM, Simon Laws [EMAIL PROTECTED] wrote: Hi The Tuscany project is now ready to distribute its Java SCA Release 1.1-incubating. Following up from Robert's recent post to the Tuscany dev list [1] I am posting here before proceeding to copy the artifacts up to www.apache.org/dist/incubator. i volunteered to walk podlings through their first release under the new policy (at least until the documentation is completed) please take a look at http://incubator.apache.org/guides/releasemanagement.html#release-distribution are there any questions you have that it doesn't answer...? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Java SCA Release 1.1-incubating and new Incubator distribution policy
On Feb 3, 2008 3:10 PM, sebb [EMAIL PROTECTED] wrote: On 03/02/2008, Robert Burrell Donkin [EMAIL PROTECTED] wrote: On Feb 1, 2008 4:00 PM, Simon Laws [EMAIL PROTECTED] wrote: Hi The Tuscany project is now ready to distribute its Java SCA Release 1.1-incubating. Following up from Robert's recent post to the Tuscany dev list [1] I am posting here before proceeding to copy the artifacts up to www.apache.org/dist/incubator. i volunteered to walk podlings through their first release under the new policy (at least until the documentation is completed) please take a look at http://incubator.apache.org/guides/releasemanagement.html#release-distribution are there any questions you have that it doesn't answer...? Some of the incubator dist directories contain KEYS files, some don't - is there a policy on that? incubator policy is just to follow apache policy http://www.apache.org/dev/release-signing.html#policy so ATM a KEYS file is not mandatory but is recommended - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Java SCA Release 1.1-incubating and new Incubator distribution policy
On Feb 3, 2008 3:53 PM, Simon Laws [EMAIL PROTECTED] wrote: We know how we want our distribution directories structured (see start of thread). great There is a draft release page here ( http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+1.1-incubating). I'd appreciate it if you could give the URLs a quick once over to see if they are as you would expect re. mirroring. a few minor, non-normative recommendations It can take a day or so for releases to propagate to all mirrors, so if you are downloading something near the release date, please be patient and retry the links from this page in the event that a selected mirror does not yet have the download. i've found that it works better to hold off the announcement until the mirrors have sync'd and i can test for myself that everything has worked. (saves embarrasements.) so, i tend to initially put a notice saying that the release is not yet available and then remove it once i've tested the downloads. The PGP signatures can be verified using PGP or GPG. First download the KEYS as well as the asc signature file for the relevant distribution. Make sure you get these files from our main distribution directory, rather than from a mirror (the asc and md5 links below take you to the main distribution directory). Then verify the signatures using, for example i've found that users find sums easier than signatures. most users will not be strongly connected to the apache web of trust. so they are going to need to understand how to interpret the results. if you recommend checking signatures, considering copying or linking to some of the content on http://www.apache.org/dev/release-signing.html#faq. When we get the go ahead it's left from me to upload the artifacts to www.apache.org/dist/incubator/tuscany/, set the correct group and permissions as documented and then integrate the new release page into the Tuscany web site. yep (it's not really a go-ahead, more a make-sure-you-know-what-you're-doing) you're planning to use the dynamic script? (rather than a custom download script) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Java SCA Release 1.1-incubating and new Incubator distribution policy
On Feb 3, 2008 5:10 PM, Simon Laws [EMAIL PROTECTED] wrote: On Feb 3, 2008 4:55 PM, Robert Burrell Donkin [EMAIL PROTECTED] wrote: On Feb 3, 2008 3:53 PM, Simon Laws [EMAIL PROTECTED] wrote: snip When we get the go ahead it's left from me to upload the artifacts to www.apache.org/dist/incubator/tuscany/, set the correct group and permissions as documented and then integrate the new release page into the Tuscany web site. yep (it's not really a go-ahead, more a make-sure-you-know-what-you're-doing) you're planning to use the dynamic script? (rather than a custom download script) Yes. in that case, the script looks ok to me make sure that the signatures are correct and uploaded at the same time as the release. is your key available from a public key server? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[NOTICE] Releases - archive.apache.org
i've now deleted the original releases from people.apache.org/dist/incubator. copies can be found in archives.apache.org/dist/incubator. the .htaccess seems to be working ok but please check the links ASAP. i will unsubscribe from this list no earlier than thursday. if you find you have any questions after then please ask on general. - robert signature.asc Description: This is a digitally signed message part
Re: New Distribution Policy [WAS Re: [Vote] Release Tuscany Java SCA 1.1-incubating (RC1)]
On Jan 13, 2008 4:03 PM, Simon Laws [EMAIL PROTECTED] wrote: snip Thanks for the pointer. Haven't got into the the detail of the release distribution documentation you refer to yet but something did catch my eye. In the section on mirroring ( http://incubator.apache.org/guides/releasemanagement.html#understanding-mirroring) there is a sentence... The artifacts are downloaded from machines outside Apache control so users must verify them. While the mirrored release artifacts (gzipped tar files and zip jar files are the most common artifacts) must be used, the mirrored checksums, KEYS and signature files (.asc and .md5 files) must *never* be used. All links must refer to the original documents on www.apache.org. Can I confirm that what this is saying is that the download page, and any associated mirroring scripts, that the Tuscany Incubator project presents must ensure that the user links to zip/gz from a mirror and links to checksums, signatures etc from http://www.apache.org/dist/incubator/, I.e. this sentence is about Tuscany getting it's web page right rather than something a user has to do explicitly. on the tuscany website: * any links to artifacts must use the mirroring functions * any links to signatures, sums and KEYS must be to the originals on http://www.apache.org/dist/incubator/ any user who downloads an artifact will be obtaining a mirrored copy. apache has no control over the contents of these mirrors and so the user should verify the release. this can be done by checking a sum or the signatures (which is best depends on the circumstances). read http://www.apache.org/dev/release-signing.html for more details - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Archiving Releases
On Wed, 2008-01-09 at 23:04 +, Robert Burrell Donkin wrote: incubator releases now need to be distributed using the standard apache system. new releases will need to be mirrored and uploaded to www.apache.org/dist. see http://incubator.apache.org/guides/releasemanagement.html#release-distribution for more details. please post questions about the new process on general. as part of this process, i'm archiving all existings releases from people.apache.org to archive.apache.org. redirects will ensure that existing URLs do not need to be changed. i see that tuscany has releases in people.apache.org/dist/incubator/tuscany. unless anyone jumps in, i plan to archive these in the near future. i'll stay subscribed for to this list till sunday 13th so if anyone has any questions about the archiving process please reply to this email. i've copied the existing tuscany releases from people.apache.org to the archives and added a redirect. please wait till the mirrors have sync'd and check that the links still work ok. unless anyone jumps in, i will remove the originals not earlier than sunday. - robert signature.asc Description: This is a digitally signed message part
New Distribution Policy [WAS Re: [Vote] Release Tuscany Java SCA 1.1-incubating (RC1)]
new releases need to follow the revised distribution policy. some initial document is available at http://incubator.apache.org/guides/releasemanagement.html#release-distribution but please ask on the general list before distributing a new release. the tuscany community will need to take some decisions so please take a look now. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Archiving Releases
On Fri, 2008-01-11 at 09:28 -0800, Luciano Resende wrote: Hey Robert With the current distribution setup, we use the apache http logs to count the number of downloads of each tuscany releases. With this new setup, will we still be able to get the download counts from the http logs ? for the old releases, possibly but the details may change new releases will use the mirrors so counting releases this way will no longer be possible. i've heard that some projects use something like google analytics to count mirrored downloads. - robert signature.asc Description: This is a digitally signed message part
[NOTICE] Archiving Releases
incubator releases now need to be distributed using the standard apache system. new releases will need to be mirrored and uploaded to www.apache.org/dist. see http://incubator.apache.org/guides/releasemanagement.html#release-distribution for more details. please post questions about the new process on general. as part of this process, i'm archiving all existings releases from people.apache.org to archive.apache.org. redirects will ensure that existing URLs do not need to be changed. i see that tuscany has releases in people.apache.org/dist/incubator/tuscany. unless anyone jumps in, i plan to archive these in the near future. i'll stay subscribed for to this list till sunday 13th so if anyone has any questions about the archiving process please reply to this email. - robert signature.asc Description: This is a digitally signed message part
Re: Tuscany Subproject News Bulletin? Would it be useful?
On 8/8/07, haleh mahbod [EMAIL PROTECTED] wrote: snip I am not sure if we are agreeing that a news bulletin per subproject is worth the effort or not given all the new ideas that were shared on this thread. I could go ahead and start this as an experiment, but its content is dependent on input from everyone. We can try it for a while and evaluate if it is useful or should be removed. FWIW (in summary) i believe that news is definitely worth the effort but it's easy to underestimate the energy required... MOTWYW - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Subproject News Bulletin? Would it be useful?
On 8/7/07, ant elder [EMAIL PROTECTED] wrote: On 8/6/07, Robert Burrell Donkin [EMAIL PROTECTED] wrote: snip i believe now that blog aggregation is the best structure for news. for this to be effective does require a consensus that committers are going to spend a little time regularly blogging about new features. And we have this with the Tuscany blog at http://apache-tuscany.blogspot.com/. Maybe we just need to be a bit more focused and proactive about the content would put up there. +1 letting people know that the content's there is also important for example, planetapache is widely read. maybe it would be good to aggregate the feed. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Subproject News Bulletin? Would it be useful?
On 8/6/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi Tuscan Contributors and Users, I have been thinking about how we can further enhance the flow of information in Tuscany. New interesting things happen on regular basis and information is either embedded in an email, in code/commit log, embedded in a webpage on TuscanyWiki or the website. Users of Tuscany may have interesting information to share, but not have a place to share this information. A new person coming to Tuscany may not be able to easily find the information in archive since they don't know what to look for. Users who are tracking the project may not have time to read the details of each email and would probably appreciate finding information quickly. Note that this is not a particular characteristic of Tuscany. It is just the nature of open source projects. Lots of good information to dig into in svn, in mailing list, on websites, etc. Here is a proposal. How about a news bulletin for each subproject that resides on TuscanyWiki and gets linked into from Tuscany website download page. This is a live page, contributed to by all. It is not a replacement for any of the existing communication mechanism. It is a quick pointer to information that will help people find the latest news. For example the SCA bulletin could be: Development bulletin board - Community is working on the next release of project. You can participate in this thread of discussion ML thread if interested.. - There is a quick guide to getting started link here - Major efforts in progress, example OSGI , Integration with Geronimo, Use your imagination... Anything that can be shared with the community to help them understand what's going on Users bulletin board - Here is a scenario that SCA is used in and here are some examples to share link to a page that the data is Use your imagination Anything that can be shared with the community Questions: Do you agree that we should spend effort on further enhancing information flow or there is enough already? If yes, What type of information would you like to see so that information can be better organized? If you agree that we can further enhance information flow, would the idea of news bulletin work? If not, what else? I'll take care of the initial draft of the webpages if I know there is interest to keep these pages live, otherwise there is no point to just add another page to the wiki. this is a bit of a history lesson (probably a poor one since it's based on my fallible memory rather than objective research) so please feel free to skip or ignore. in fact, this would probably have been better as a blog but it's a little late now... in the beginning there was [EMAIL PROTECTED] then java became xml, jakarta and cocoon. when jakarta was young (http://jakarta.apache.org/site/news/news-2000.html), jakarta created news then lots of news (http://jakarta.apache.org/site/news/index.html). news proved very popular. too popular, in fact. so, this grew into the jakarta newsletter which then became the apache newsletter. but all things have their time: and running a newsletter takes a lot of energy. what starts as a pleasure becomes a chore. the theory was that blogging would be a better way of managing news. thus http://www.planetapache.org/. this been a very successful in many ways but it turned out that most people prefer to talk about more personal matters. which is cool in many ways. IMHO planetapache is a major force in retaining cohesiveness now that there are so many members and projects. but i still believe that news is great way to build community and interest in a project. it's also personally rewarding though it's easy to underestimate the time that maintaining good news takes. i believe now that blog aggregation is the best structure for news. for this to be effective does require a consensus that committers are going to spend a little time regularly blogging about new features. good luck and i hope this takes off :-) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release process guide checklist, was Fwd: [VOTE] Release SDO Java 1.0-incubating
On 7/24/07, ant elder [EMAIL PROTECTED] wrote: I agree we could do things to improve our releases. Most ASF releases end up having several RCs, its a natural part of the process, I'm not sure it indicates any failing somewhere. IMHO when you use the RC method, having multiple RCs does not indicate a failing. it really indicates that committers are carefully vetting the candidates. There's already lots of doc about doing releases in the ASF - on the ASF main dev pages and within the Incubator site etc. If there's omissions from those existing guides we should get them updated. Tuscany having a 'formal release guide' makes me nervous it would just be used as a stick to beat people with when some issue is discovered. An issue with is that currently making our releases is quite a manual process, fixing this would be more worthwhile than writing more documentation (IMHO). IMO there's a balance to be struck. each project develops it's own house style for releases. recording this house style allows more developers to act as release managers. IMHO automation is difficult to perfect. recording the house style helps to manage the automation process. though a worthy investment, it is best to adopt an incremental approach. automate more but do not put off automation or releases to wait for the other. the incubator release guide is the next document on my personal hit list. i'd like to see a menu of ways that releases are done at apache allowing project to pick and choose their house style by combining a number of well documentation alternatives. it'd be great if the tuscany team would consider feeding any release documentation they develop back into the release guide and create a style guide linked to the details. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release process guide checklist, was Fwd: [VOTE] Release SDO Java 1.0-incubating
On 7/24/07, ant elder [EMAIL PROTECTED] wrote: snip - change builds to use the maven release plugin to avoid most of the manual steps when creating a release - use maven to as much as possible automate the adding of dependency information to the LICENSE and NOTICE files - update the RAT tool to validate the legal aspects (LICENSE/NOTICE/DISCLAIMER exist) of things like artifacts in the temp maven repository - update RAT to validate the signatures of all downloadable artifacts i've talked to brett before about integrating parts of RAT into the maven release plugin jochen has developed a maven plugin but being able to pass or fail relies on more function being added to RAT i had hoped to be able to find more cycles now but IMAP is tough and a personal priority (since i use it to read my mail) so i'm not sure when i'll be able to find the cycles. SO any help on RAT would be gratefully accepted ;-) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IP CLEARANCE] An external contribution to Apache Tuscany
On 6/5/07, Simon Nash [EMAIL PROTECTED] wrote: I'm following up on this thread which has gone very quiet. AFAIK there has not yet been an acknowledgement of the software grant form by an officer of the ASF. Can anyone who is an officer of the ASF help with this, please? i'm not an officer but any member or officer (for example, your mentors) can check this by examining the cclas.txt in subversion. i've taken a look and it's in the file. hope this is good enough for you. sorry about the delay - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A front-page for tuscany-java-sca downloads
On 11/8/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Thanks for all the feedbacks. I have updated the site. Please review it again. http://people.apache.org/~rfeng/tuscany/incubator-M2/downloads/ just FYI should be easy enough to update that page for mirroring once tuscany graduations. see http://www.apache.org/dev/release-download-pages.html for details. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: KEYS file contents
On 10/16/06, kelvin goodson [EMAIL PROTECTED] wrote: Can anyone help me 1) get the correct format for my gpg KEYS file and see below 2) confirm that I can just append it to the file at https://svn.apache.org/repos/asf/incubator/tuscany/KEYS yeh - just append it (everything that isn't an export will be ignored by import) snip which doesn't identify me in the same way that the existing one in svn identifies Jeremy. My guess is I need to get that format of header before adding it to the svn file. gpg --list-keys rdonkin pub 1024D/B1313DE2 2003-01-15 uid Robert Burrell Donkin (CODE SIGNING KEY) [EMAIL PROTECTED] uid Robert Burrell Donkin [EMAIL PROTECTED] uid Robert Burrell Donkin [EMAIL PROTECTED] sub 1024D/7D0D4DED 2006-06-18 [expires: 2008-06-17] sub 2048g/48F0B49F 2005-05-30 BTW if you are still on GnuPG 1.2.2, i strongly recommend upgrading to a more recent version - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where are we with release content?
On 9/21/06, kelvin goodson [EMAIL PROTECTED] wrote: I ran the irat release auditing tool discussed by russel burrell donkin and jeremy boynes on the apache general list against the java sdo sub-hierarchy. FYI it started as RAT (Release Audit Tool) but google wouldn't let me have that name (there's a basic implementation over at sourceforge with that name) so the google project is arat (A Release Audit Tool). maybe it'll become aRAT since the RAT accronym is already in use. FYI attached is the output that it's giving in case you want to get an idea what it can do. ATM it's just really a grep: pretty basic and very user unfriendly. i've created a group and added a link to it from the google home page (http://code.google.com/p/arat/) just in case discussions here become a little OT. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where are we with release content?
On 9/21/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Sep 21, 2006, at 6:57 AM, kelvin goodson wrote: In trying to follow the release management draft guidelines at http://incubator.apache.org/guides/releasemanagement.html I have a few questions. that's brave :-) i'm not surprised you have questions since they are only half done as yet... 1) for a source distribution the guidelines say Check for version controlhttp://incubator.apache.org/guides/ releasemanagement.html#best-practice-sourcefiles, but the linked info currently only says ... TODO: describe what a source distribution is; version control for distributions; add content to release documents; export not checkout so can anyone elaborate what's required here? IMO a source distribution is an archive with all the source needed to rebuild the project. Conceptually, I would define that as being a signed tarball of an export of the svn URL pointing to the tag. An export not a checkout because the export does not contain the hidden .svn directories used to manage the changes. +1 When cutting the final release IMO it should be built from such an export rather than out of a normal working tree. That way you know for sure that the source distro will actually build and that, given the same conditions (like platform), anyone should be able to reproduce a binary distro. +1 good explanation: create an issue in JIRA, patch those words in and i'll apply the patch :-) IOW a source distro is a prereq - an binary distros are nice to haves. +1 users like binary distros but they are not necessary. source only releases are sometimes useful in the early stages of a project (to encourages active developers) or when users general received binaries from downstream packagers 2) Guidelines say --- Jars -- should include a standards compliant manifest, and goes on to say ... TODO Lots of projects get this wrong and (by default) most tools produce substandard manifests. Offer some guidance on values TODO: Add how to create a specification complient MANIFEST http://jakarta.apache.org/commons/releases/ prepare.html#checkjarmanifest the jakarta link just talks about how maven builds a standard file and adds non standard (jakarta specific?) elements to the manifest file. So I don't know whether (a) letting maven do its stuff will make us compliant and (b) whether the inclusion of non standard elements in a manifest file makes the file non compliant. Can anyone point to a definition of a standard manifest file? I think Robert means substandard rather than non-standard as the JAR spec is fairly minimalist about what *must* be in there. yes: sub-standard is more accurate the original, basic specification is pretty liberal but there are a number of other specifications which (arguable) mandate information. a fully standards compliant jar should IMHO comply with all these various standards. there is a consensus (based on 5 years of feedback cutting jars in jakarta) about which fields are required to prevent criticism of the MANIFEST for non-compliance with some Sun specification or other. need to dig out the references. The default behaviour of Maven's archiver is not to add much but you can address that using manifest configuration entries in the pom. recommend setting the following: Extension-Name: org.apache.XXX Specification-Title: YYY Specification-Vendor: The Apache Software Foundation Specification-Version: nnn Implementation-Vendor-Id: org.apache Implementation-Title: YYY Implementation-Vendor: The Apache Software Foundation Implementation-Version: nnn An alternative is to add a full OSGi header - we've experimented with the plugin from Felix to do this but 1) there is no released version yet, and 2) I have not found a way of preventing it from adding all project dependencies into the generated bundle. 3) ASF doc says ... incubating projects should contain the STATUS document describing. TODO: check this I've looked at our STATUS doc that went out with M1 and it contains general project info which would be the same for SDO as for SCA I think. I'm having trouble knowing where maven might look for a STATUS file or how to configure it to pick one up. Can anyone help with how I should do this please? I tried placing a STATUS file alongside the NOTICE file etc in distribution/sdo but that didn't get picked up, so I guess maven already knows about NOTICE files somehow and needs to be taught about STATUS files. We chatted about this earlier on IRC and ... * Tuscany's STATUS file lies here https://svn.apache.org/repos/asf/ incubator/tuscany/STATUS * you can reference that from the assembly plugin's config file * doing so can be a problem as it is a reference to a resource outside the maven project We'd mentioned possibly using an svn external to symlink from the distro project to the root - did that work out? don't worry too much if it turns out to be a PITA the TODO note is that i'm
Re: Whats required to become a Tuscany Committer?
On 7/27/06, ant elder [EMAIL PROTECTED] wrote: One of the reasons I started this thread was to try to get a common understanding about what everyone expects is required to become a Tuscany committer. Its hard to publicly say you think someone isn't ready yet, even on the private list, so a common understanding would mean nominations would more likely get unanimous approval. If a nomination is being discussed on the private list how do we know when its ok to call a public vote on the dev list? Are just a few positive responses enough? Are lots of positive responses required? Or just no negative ones? Or does there need to be at least positive responses from all the committers active in that area? I think maybe the latter of those for now while there's still not so many of us, but what do others think? this is a good question with lots of depth :-) it's even tougher for a podling and so lacking history and tradition to rely on. you need to work answers to this queston yourselves but i would like to say something about nominations... i do think that there is some merit in discussing whether someone is quite ready but i believe that the nomination is personal, not collective. i'm towards the conservative end of the spectrum when it comes to nominating new committers. i see nomination as a personal commitment which includes supervising the nomimee's first weeks and months at apache. this include reading every commit message promptly and being the first to dive in with corrections for any mistakes (technical or social) they make. i'll also make time to ensure that any personal mail they send to me will be answered quickly. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
