Re: Release Verification Checklist
On Tue, Dec 10, 2013 at 5:45 AM, Marvin Humphrey mar...@rectangular.com wrote: On Mon, Dec 9, 2013 at 2:34 AM, ant elder ant.el...@gmail.com wrote: I know you're passionate about this Marvin but as it stands I'll be voting against this proposal. I plan to propose this as an experiment Well ok, earlier you said you'd planed it as a change to the Incubator policy page but if its just an experiment then fine by me, i've already said in the experiment discussions that i'd support anyone doing some experiments. 1) This proposal doesn't help podlings with the first release It helps by clarifying what we expect from podlings. We're effectively replacing that absurd monstrosity, the Incubator's Release Management Guide... http://incubator.apache.org/guides/releasemanagement.html ... with a one page checklist: http://incubator.apache.org/guides/release_manifest.txt The first release will be easier because podlings will spend less time thrashing through docs trying to discover what is required. Compliance isn't that much work in the grand scheme of things -- the big problem has been that the Incubator couldn't tell you the spec. 3) The proposal adds new artificial process around doing a release when we should be teaching podlings how TLPs do things I think podlings which have their act together ought to have the option of filling in a checklist rather than being forced to wait weeks hoping some random IPMC member wanders by. Incubator releases are not official ASF releases so there is not and should not be the same expectations around them. A lot of people seem to think this, but it's not true. Incubator releases are official ASF releases. If we could find a way to have Incubator PMC members accept a lower bar for doing podling releases it would make a massive improvement to everyones experience of the Incubator. We shouldn't be sticklers for inconsequential minutiae, but since the Incubator is a TLP like any other and its releases are subject to Foundation-wide policy, I don't believe we have much freedom to accept a lower bar. Your request is impossible. That doesn't seem to be true from past evidence. I could trawl back through the archives and pull out numerous instances of podling releases with known flaws being approved by the Incubator PMC, ASF directors, and in some instances with the blessing of the ASF board. Even the Incubator policy document says No release made by a Podling will be endorsed by the ASF. Unendorsed releases may be made by Podlings ... The main purpose of the voting is to protect the folks who make release decisions. So long as they're not just wildly throwing about +1 votes with no thought then the ASF will be fine with having some wiggle room on release quality for Incubating projects. We could go ask the board for clarification, but not so long ago Roy told us: The Incubator is that PMC. Make a decision and run with it. If it doesn't work out, try another decision and run with that. The only time the board should step in (with a hammer) is when no decisions are being made. Isn't that enough to at least try some experiments with easier releases? ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Release Verification Checklist
On Mon, Dec 9, 2013 at 12:30 PM, ant elder ant.el...@gmail.com wrote: On Mon, Dec 9, 2013 at 11:04 AM, Bertrand Delacretaz Define lower bar. Do you see any of the review items http://incubator.apache.org/guides/release_manifest.txt as optional? ...Probably all of those could be optional or fixed next time. I've done releases with invalid signatures in the past and there is some automated thing in the ASF distribution area that sends you an email about it and you just have to resign the artifact... I have no problem with clear and documented decisions to relax some of the release checklist criteria for an incubating release, as long as that doesn't put the foundation at risk. Failing tests clearly fall into this category, a reviewer can then very much say the tests are failing but I still give my +1 to the release. Dubious code provenance OTOH can potentially put the foundation at risk, so I'd be much stricter on that. With the suggested checklist this process, bargaining included, becomes very clear and understandable for new podlings - they just need to look at existing release manifests. I like Marvin's description of http://incubator.apache.org/guides/releasemanagement.html as an absurd monstrosity and I think we're making progress with this new checklist. The more content we can remove from the mess that's the incubator.apache.org the better. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance before releasing
Therefore, when we say that incubating releases can have small IP loose ends, we mean: * This is an official release, created by an act of the Foundation. * It is known to violate policy. * It could be removed, but no one has done so yet. I'm comfortable with relying on prosecutorial discretion for inconsequential small stuff, but not something major like source code provenance. Well, that third line is not what I meant. In law, and so in Foundation policy, there is always a concept of materiality. Nothing is perfect. People make mistakes, and the legal framework that we're working in when we make a release has room for them. If some PMC makes a release with 10 lines of 'category X' code in it, I do not believe that anyone thinks that removing it is appropriate or necessary. I was really trying to talk about trivial issues. Maybe I should have written 'tiny' instead of small. Maybe I should have focussed on LN problems, where there are many opportunities to make an immaterial error. The bottom line should be a repetition of your repetition of Doug - a release is a release, incubator or not. If we deleted every release from the main Foundation distro area that had some divergence from some policy, no matter how tiny, my suspicion is that the distro area would become rather sparse. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance before releasing
On Tue, Dec 10, 2013 at 11:30 AM, Benson Margulies bimargul...@gmail.com wrote: If we deleted every release from the main Foundation distro area that had some divergence from some policy, no matter how tiny, my suspicion is that the distro area would become rather sparse. Yes quite. And lets not forget how the rules keep changing eg not so long ago people were insisting that all sorts of stuff absolutely must be put in the NOTICE file where as now it absolutely must NOT be there, who know what it will be like next year. And the Incubator _is_ different and does have different policy and rules, hence on occasion podlings being permitted to do releases which include GPL dependencies while Incubating and just fixing those up as a graduation requirement. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[SHEPHERD'S VIEW] Drill
Apologies for tardiness in completing the review. I have reviewed the community and have concluded that it is very active and healthy. IMO, #3 in the issues to address before graduation is not critical and can be successfully mitigated by documenting the tasks that are currently being executed by single individuals. My recommendation is that the Drill podling begin the graduation process after completion of the next release.
Re: [Apache Stratos] [Incubating] Setting up Jenkins
Hey Imesh I can help, who are you trying to grant permissions to? -Jake On Mon, Dec 9, 2013 at 10:49 PM, Imesh Gunaratne im...@apache.org wrote: Hi All, I'm writing regarding setting up Jenkins for Apache Stratos (incubating). According to instructions given here [1] I tried to grant permissions to one of the committers but it was not successful. I also wrote to Apache Infra mail list but couldn't find any solutions. Really appreciate if anyone could help on this. [1] http://wiki.apache.org/general/Jenkins#How_do_I_get_an_account Many Thanks Imesh
Re: Shepherding December 2013
Hey Marvin For Aurora everything is progressing nicely. All initial setup and on boarding is completed and development has started using ASF infrastructure (jira/reviewboard/etc). No blockers or issues at this time. Usergid was not listed in the reports for this month, as a new podling less than 3 months old they should be reporting, have not dug into the xml yet to see what was not configured correctly. -Jake On Mon, Dec 9, 2013 at 3:04 PM, Marvin Humphrey mar...@rectangular.comwrote: Allura (No shepherd review filed.) Aurora (No shepherd review filed.) BatchEE Marvin Humphrey (marvin): Podling did not report. Please report next month. Also, please edit podlings.xml metadata and address all FIXME tags. Apache: Project Drill Marvin Humphrey (marvin): The report is admirably thorough and must have taken a long time to prepare. Perhaps consider that a report with a reduced level of detail similar to the other reports may be more in line with Board expectations. The report was filed too late to be incorporated into a review by the assigned shepherd. Please file on time. Please wrap future reports at 77 columns, and please take more care with making indentation reflect logical hierarchy. Also, use only s.apache.org URL shorteners in future reports. Otherwise, someone downstream must clean up the report -- either someone from the IPMC (I took care of reformatting this month) or the Board -- before it is published in the official Board minutes. Falcon (No shepherd review filed.) Kalumet John Ament (johndament): Kalumet seems to be OK, but a little bit slow. They have been incubating for a little over 2 years now, I think if they can get together on another release shortly they should consider graduating, there was some confusion for a little while over IPMC vs PPMC votes which caused a delay in getting their 0.6 release out the door. MRQL Dave Fisher (wave): This podling achieved one benchmark towards successful incubation - a release. When commits and mailing list activity are reviewed this looks like a tiny community with only a single developer and some administrative support. I am not sure if this another example of a community that is mostly from a single corporation and is doing all of the work outside and contributing it through one person with off-list decision making and communication. If so then the mentors need to look into it and get the real decision making process in public. There is a user ML, but the only email ever on that list was the release announcement. NPanday Justin Mclean (jmclean): Last report was July 2013. At noted in the current report there are some issues to overcome for the project to move forward. In the last month there been some increased activity on the mailing lists (thanks to the last shepherd) but as yet no fixes or patches have been submitted. The project currently has only one mentor (just appointed) and the PPMC seems to have gone missing. Ripple (No shepherd review filed.) S4 John Ament (johndament): The board report reflects my sentiments as well. S4 seems to be in a bit of rut. I tried kicking off some conversations on the dev mailing list, no luck. It seems like there are at best five active participants, between the users list and dev list. Considering that there hasn't been a commit since last board report, it doesn't come off as a good sign for me. I think retirement may be an option to start exploring. Sentry (No shepherd review filed.) Sirona Marvin Humphrey (marvin): Podling did not report. Please report next month. Storm Raphael Bircher (rbircher) Storm has started three months ago. It is quite active and looks ok, so far. They created a last release outside Apache and they work now at the IP. I noticed that http://incubator.apache.org/storm/ still not exist. If you search at Google for storm, you only find the GitHub page. I find a minimal site on the Apache server important. so people can easely find ML and co. Streams (No shepherd review filed.) Tajo (No shepherd review filed.) Twill (No shepherd review filed.) Wave Christian Grobmeier (grobmeier): It was discussed to end graduation because lack of momentum, which led to a lot of emails. So far there are a couple of people around but to
Re: [SHEPHERD'S VIEW] Drill
On Tue, Dec 10, 2013 at 6:22 AM, Matt Franklin m.ben.frank...@gmail.com wrote: Apologies for tardiness in completing the review. I have reviewed the community and have concluded that it is very active and healthy. IMO, #3 in the issues to address before graduation is not critical and can be successfully mitigated by documenting the tasks that are currently being executed by single individuals. My recommendation is that the Drill podling begin the graduation process after completion of the next release. Glad to hear that Drill is doing so well! The reason we have the Sunday deadline for shepherd reviews and the Monday email before the Wednesday report filing is to allow time for a podling to respond, as Drill did a few months ago. I doubt this review will prove controversial, but I see you've also addressed this email to both general@incubator and Drill's dev list just in case -- good thinking. Thanks for coming through, Matt! Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Shepherding December 2013
On Tue, Dec 10, 2013 at 6:42 AM, Jake Farrell jfarr...@apache.org wrote: For Aurora everything is progressing nicely. All initial setup and on boarding is completed and development has started using ASF infrastructure (jira/reviewboard/etc). No blockers or issues at this time. I've taken the liberty of putting this into the report. :) I've also updated the report template to encourage Mentors to add notes and to reflect that a number of Mentors have been doing so already (e.g. Christian Grobmeier commented on Wave this month): -Shepherd notes: +Shepherd/Mentor notes: Usergid was not listed in the reports for this month, as a new podling less than 3 months old they should be reporting, have not dug into the xml yet to see what was not configured correctly. Good spot! The problem is that Usergrid was missing the monthly attribute. I've committed a fix. - reporting group=1November,December,January/reporting + reporting group=1 monthly=trueNovember,December,January/reporting We'll look forward to a report from Usergrid next month. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Apache Stratos] [Incubating] Setting up Jenkins
Hi Jake, Thank you very much for your quick response. I would like to grant permissions to my apache user: Username: imesh Email: im...@apache.org Many Thanks Imesh On Tue, Dec 10, 2013 at 8:06 PM, Jake Farrell jfarr...@apache.org wrote: Hey Imesh I can help, who are you trying to grant permissions to? -Jake On Mon, Dec 9, 2013 at 10:49 PM, Imesh Gunaratne im...@apache.org wrote: Hi All, I'm writing regarding setting up Jenkins for Apache Stratos (incubating). According to instructions given here [1] I tried to grant permissions to one of the committers but it was not successful. I also wrote to Apache Infra mail list but couldn't find any solutions. Really appreciate if anyone could help on this. [1] http://wiki.apache.org/general/Jenkins#How_do_I_get_an_account Many Thanks Imesh
Re: [Apache Stratos] [Incubating] Setting up Jenkins
done, please use the builds@ list if you have any questions -Jake On Tue, Dec 10, 2013 at 12:53 PM, Imesh Gunaratne im...@apache.org wrote: Hi Jake, Thank you very much for your quick response. I would like to grant permissions to my apache user: Username: imesh Email: im...@apache.org Many Thanks Imesh On Tue, Dec 10, 2013 at 8:06 PM, Jake Farrell jfarr...@apache.org wrote: Hey Imesh I can help, who are you trying to grant permissions to? -Jake On Mon, Dec 9, 2013 at 10:49 PM, Imesh Gunaratne im...@apache.org wrote: Hi All, I'm writing regarding setting up Jenkins for Apache Stratos (incubating). According to instructions given here [1] I tried to grant permissions to one of the committers but it was not successful. I also wrote to Apache Infra mail list but couldn't find any solutions. Really appreciate if anyone could help on this. [1] http://wiki.apache.org/general/Jenkins#How_do_I_get_an_account Many Thanks Imesh
LICENSE and NOTICE Role Models
In the process of preparing the LICENSE and NOTICE files for Storm, I started looking at what other Apache projects (both incubator and TLPs) have done. It seems like approaches are all over the map. I've even seen projects that don't have a NOTICE. My question to any mentors and PMC members is are there any projects that stand out as having done a really good job at this? (I understand that every circumstance is different.) One project that stood out to me was Cassandra. Storm actually shares some of the same dependencies, so I found their approach helpful. - Taylor - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance before releasing
ant elder wrote: Benson Margulies wrote: If we deleted every release from the main Foundation distro area that had some divergence from some policy, no matter how tiny, my suspicion is that the distro area would become rather sparse. Yes quite. And lets not forget how the rules keep changing eg not so long ago people were insisting that all sorts of stuff absolutely must be put in the NOTICE file where as now it absolutely must NOT be there, who know what it will be like next year. I disagree with that summary. The principles and constraints (not rules) do not keep changing. Instead it is that people seem to not understand those, and it takes time to weed out the misguided behaviours and documentation. -David And the Incubator _is_ different and does have different policy and rules, hence on occasion podlings being permitted to do releases which include GPL dependencies while Incubating and just fixing those up as a graduation requirement. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LICENSE and NOTICE Role Models
On Dec 10, 2013, at 6:15 PM, P. Taylor Goetz ptgo...@gmail.com wrote: In the process of preparing the LICENSE and NOTICE files for Storm, I started looking at what other Apache projects (both incubator and TLPs) have done. It seems like approaches are all over the map. I've even seen projects that don't have a NOTICE. My question to any mentors and PMC members is are there any projects that stand out as having done a really good job at this? (I understand that every circumstance is different.) I would not call these role models or any where near, but for Apache Airavata, we spent months during incubation to get the LN files right (thanks to our patient mentors). If useful here are the pointers: Source LN files (essentially there are no third party sources bundled, hence ALV2 only): https://svn.apache.org/repos/asf/airavata/trunk/LICENSE https://svn.apache.org/repos/asf/airavata/trunk/NOTICE The binary distribution bundles a whole bunch of dependencies and we had to manually traverse through every bundled jar: https://svn.apache.org/repos/asf/airavata/trunk/modules/distribution/airavata-server/src/main/resources/LICENSE https://svn.apache.org/repos/asf/airavata/trunk/modules/distribution/airavata-server/src/main/resources/NOTICE Note: In recent past there have been more clarifications on NOTICE file needing to be even more minimalistic, we did not yet adhere to these policies yet. So recently released incubator projects might have better examples. Suresh One project that stood out to me was Cassandra. Storm actually shares some of the same dependencies, so I found their approach helpful. - Taylor - 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: [Apache Stratos] [Incubating] Setting up Jenkins
Hi Jake, Thanks so much! Yes for sure, will do. Many Thanks Imesh On Wed, Dec 11, 2013 at 2:15 AM, Jake Farrell jfarr...@apache.org wrote: done, please use the builds@ list if you have any questions -Jake On Tue, Dec 10, 2013 at 12:53 PM, Imesh Gunaratne im...@apache.orgwrote: Hi Jake, Thank you very much for your quick response. I would like to grant permissions to my apache user: Username: imesh Email: im...@apache.org Many Thanks Imesh On Tue, Dec 10, 2013 at 8:06 PM, Jake Farrell jfarr...@apache.orgwrote: Hey Imesh I can help, who are you trying to grant permissions to? -Jake On Mon, Dec 9, 2013 at 10:49 PM, Imesh Gunaratne im...@apache.org wrote: Hi All, I'm writing regarding setting up Jenkins for Apache Stratos (incubating). According to instructions given here [1] I tried to grant permissions to one of the committers but it was not successful. I also wrote to Apache Infra mail list but couldn't find any solutions. Really appreciate if anyone could help on this. [1] http://wiki.apache.org/general/Jenkins#How_do_I_get_an_account Many Thanks Imesh
Re: LICENSE and NOTICE Role Models
Thanks Suresh, that's a big help. Having a recently approved example helps a lot. The source vs. binary release examples help as well. It's kind of interesting to see how this has changed over time and varies from project to project. Taylor On Dec 10, 2013, at 9:22 PM, Suresh Marru sma...@apache.org wrote: On Dec 10, 2013, at 6:15 PM, P. Taylor Goetz ptgo...@gmail.com wrote: In the process of preparing the LICENSE and NOTICE files for Storm, I started looking at what other Apache projects (both incubator and TLPs) have done. It seems like approaches are all over the map. I've even seen projects that don't have a NOTICE. My question to any mentors and PMC members is are there any projects that stand out as having done a really good job at this? (I understand that every circumstance is different.) I would not call these role models or any where near, but for Apache Airavata, we spent months during incubation to get the LN files right (thanks to our patient mentors). If useful here are the pointers: Source LN files (essentially there are no third party sources bundled, hence ALV2 only): https://svn.apache.org/repos/asf/airavata/trunk/LICENSE https://svn.apache.org/repos/asf/airavata/trunk/NOTICE The binary distribution bundles a whole bunch of dependencies and we had to manually traverse through every bundled jar: https://svn.apache.org/repos/asf/airavata/trunk/modules/distribution/airavata-server/src/main/resources/LICENSE https://svn.apache.org/repos/asf/airavata/trunk/modules/distribution/airavata-server/src/main/resources/NOTICE Note: In recent past there have been more clarifications on NOTICE file needing to be even more minimalistic, we did not yet adhere to these policies yet. So recently released incubator projects might have better examples. Suresh One project that stood out to me was Cassandra. Storm actually shares some of the same dependencies, so I found their approach helpful. - Taylor - 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: LICENSE and NOTICE Role Models
On Tue, Dec 10, 2013 at 8:10 PM, P. Taylor Goetz ptgo...@gmail.com wrote: It's kind of interesting to see how this has changed over time and varies from project to project. Here's Roy Fielding in June 2008, saying exactly the same thing you'll hear from us now: http://s.apache.org/Y4v If the notices aren't required by the bits in the package, then they don't belong in NOTICE. That means there will be a different NOTICE file required for each differently packaged set of bits. We must do this by hand. Because the file is named NOTICE, people tend to think it's for anything notice-ish. This is a pernicious misconception which keeps coming back over and over like a weed, and it used to be that not a lot of people besides Roy were effective at combatting it. Here's Roy in 2008 again: http://s.apache.org/ZIU Furthermore, I assume it is not problematic to have more stuff in the NOTICE file(s) than is really required. Yes, it is problematic. Consider it a tax on all downstream recipients. Roy can't be everywhere, though, and there are a lot of TLPs who have messy licensing documentation because they didn't get proper guidance. The Licensing How-To, added earlier this year, provides a cookbook approach which is supposed to yield appropriately sparse LICENSE and NOTICE files. http://www.apache.org/dev/licensing-howto.html Hopefully the Incubator is now more consistently graduating projects whose licensing documentation approaches the unchanging minimalist ideal. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LICENSE and NOTICE Role Models
Thanks Marvin, that helped me out quite a bit! - Taylor On Dec 11, 2013, at 12:24 AM, Marvin Humphrey mar...@rectangular.com wrote: On Tue, Dec 10, 2013 at 8:10 PM, P. Taylor Goetz ptgo...@gmail.com wrote: It's kind of interesting to see how this has changed over time and varies from project to project. Here's Roy Fielding in June 2008, saying exactly the same thing you'll hear from us now: http://s.apache.org/Y4v If the notices aren't required by the bits in the package, then they don't belong in NOTICE. That means there will be a different NOTICE file required for each differently packaged set of bits. We must do this by hand. Because the file is named NOTICE, people tend to think it's for anything notice-ish. This is a pernicious misconception which keeps coming back over and over like a weed, and it used to be that not a lot of people besides Roy were effective at combatting it. Here's Roy in 2008 again: http://s.apache.org/ZIU Furthermore, I assume it is not problematic to have more stuff in the NOTICE file(s) than is really required. Yes, it is problematic. Consider it a tax on all downstream recipients. Roy can't be everywhere, though, and there are a lot of TLPs who have messy licensing documentation because they didn't get proper guidance. The Licensing How-To, added earlier this year, provides a cookbook approach which is supposed to yield appropriately sparse LICENSE and NOTICE files. http://www.apache.org/dev/licensing-howto.html Hopefully the Incubator is now more consistently graduating projects whose licensing documentation approaches the unchanging minimalist ideal. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Release Verification Checklist
On Fri, Dec 6, 2013 at 8:53 AM, Roman Shaposhnik r...@apache.org wrote: On Thu, Dec 5, 2013 at 2:32 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Added to a new usage proposal section at https://wiki.apache.org/incubator/ReleaseChecklist - does that proposal work for you guys? I like it. It basically looks like sebb-in-a-box to me (or should be elastic sebb these days?) ;-) Thanks for weighing in! I've taken a stab at a second draft: http://incubator.apache.org/guides/release.html Also, here's a first take for a patch to the policy page which will be submitted as part of the PROPOSAL. The voting criteria are slightly modified in order to remain consistent with the Apache-wide three binding +1 votes rule, to require that the manifest is properly completed, and to accommodate Dave's request for a Mentor who is also an ASF Member (though I'm not totally clear about that request). https://paste.apache.org/4A1I Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
