Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
On Tue, Jun 23, 2015 at 3:21 PM, David Nalley da...@gnsa.us wrote: ...Tomcat, for instance, pushed out 4 releases in the month of May alone. It looks like they exceeded 20 releases in 2014. And there are plenty of projects doing more releases than Tomcat... Yes. Grepping for source-release.zip.sha1.*2014- at http://archive.apache.org/dist/sling/ shows 179 modules released for Sling in 2014 for example. Not as many votes though, as we sometimes have one vote for several related modules. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Ignite 1.2.0 release (RC2)
Hi, Moreover, modules under extdata are test only and are not used anywhere in the project. They are used to test code deployment functionality. Perhaps it would be best to make it clearer that they are used for test data or better still generate them. Can the files be generated from source? Would it be OK for us to proceed with this 1.2.0-incubating release and fix the issues mentioned in the next release shortly after? [1]/[2] The release policy (3.6) is quite clear on this. However if other IPMC members vote +1 I’ll consider changing my vote. Thanks, Justin 1. http://incubator.apache.org/guides/releasemanagement.html#check-list 2. http://incubator.apache.org/guides/release.html#checklist - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
On Tue, Jun 23, 2015 at 6:11 AM, Jochen Theodorou blackd...@gmx.org wrote: Am 23.06.2015 07:16, schrieb Marvin Humphrey: [...] How am I supposed to invite all the downstream developers of the world to start integrating with my awesome feature FOO before it gets formally released when our policy makes statement like: If the general public is being instructed to download a package, then that package has been released. Rather than invite them in before you make a release, why not release first and then invite them in? Are we really suggesting that I can not present at conference, tweet and otherwise promote the awesomeness of my project based on 'what's coming'? Why not release before presenting, tweeting, or promoting? I am not Roman, but my interpretation in combination with the above would be, that if releases require 72h+ and you cannot just upload it somewhere and say it is no release, that it takes ages. Something like continuous delivery for example looks for me impossible with apache. I think you are abusing the term 'continuous delivery' a bit. Keeping the codebase in an 'always releasable state' is quite different from releasing every commit or every n-th commit. So I see a bit of nuance here. The project should not be promoting/advertising non-released artifacts outside of it's own developer community (e.g. the folks who actually develop Apache $foo) The developer, however, may want to show off what he is working on. He may want to tweet about it, give a presentation or two, invite people to play with an upcoming feature. He might feature that functionality at https://people.apache.org/~ke4/ or his own web space. The difference is that an individual is doing that, and not communicating as if he is providing downloads/releases on behalf of the project itself. IOW, I would like to focus on answering the question of how can we empower our communities to effectively communicate *their* intent of how *they* expect an artifact to be consumed. They can communicate their intent by voting on a release. if every provided download is effectively a release, then you need the voting and all before you can release... that takes ages. Imagine you do around 13 releases per year. You will be easily busy with voting for over two months in total. It is deliberately 'slow'. Speaking personally, I understand the frustration with having a robust CI/CD pipeline, and keeping a codebase always releasable - and then having a 72 hour voting window (which in my experience is rarely only 72 hours). And I'll also note that this isn't the first project that has felt those pains. However, that time isn't necessarily about code quality, it's about the entire community having the opportunity to make a decision to release or not, rather than a RM making decisions on behalf of the entire project - which tends to disenfranchise community, and introduce a strata of being a RM or not into the power structure. I'll also say, projects don't seem to have a problem releasing frequently. Tomcat, for instance, pushed out 4 releases in the month of May alone. It looks like they exceeded 20 releases in 2014. And there are plenty of projects doing more releases than Tomcat. --David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
On 6/23/15, 3:11 AM, Jochen Theodorou blackd...@gmx.org wrote: Am 23.06.2015 07:16, schrieb Marvin Humphrey: [...] How am I supposed to invite all the downstream developers of the world to start integrating with my awesome feature FOO before it gets formally released when our policy makes statement like: If the general public is being instructed to download a package, then that package has been released. Rather than invite them in before you make a release, why not release first and then invite them in? Are we really suggesting that I can not present at conference, tweet and otherwise promote the awesomeness of my project based on 'what's coming'? Why not release before presenting, tweeting, or promoting? I am not Roman, but my interpretation in combination with the above would be, that if releases require 72h+ and you cannot just upload it somewhere and say it is no release, that it takes ages. Something like continuous delivery for example looks for me impossible with apache. IOW, I would like to focus on answering the question of how can we empower our communities to effectively communicate *their* intent of how *they* expect an artifact to be consumed. They can communicate their intent by voting on a release. if every provided download is effectively a release, then you need the voting and all before you can release... that takes ages. Imagine you do around 13 releases per year. You will be easily busy with voting for over two months in total. Yep, that’s the “tax” of Apache. IMO, its main reason for existing is to make users of ASF projects feel comfortable incorporating our source into their projects because we’ve done our due diligence on the IP/legal stuff on every line of source. Even for “alpha” quality code, when we say “here, go try this, it may be buggy” we are also saying “we feel pretty good it is safe to eventually be part of your production code and won’t have effects on how you license and use this code”. Yes, folks shouldn’t put alpha code into production, but you know how reality is: some manager sees your POC and suddenly you have a team adding more code on top of it. IIRC, the 72hr voting isn’t a hard rule. It is there to allow folks who aren’t paid to interact with the project every day and live in different time zones a chance to review. I’m pretty sure that if you find a way to involve volunteer folks in IP review in less time it would get ok’d and plenty of other projects would adopt such a process. There was one attempt to try to do serious IP review on every commit in order to avoid 72 hours at vote time. I’m not sure what happened to that proposal. -Alex
Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
On Jun 23, 2015, at 6:11 AM, Jochen Theodorou blackd...@gmx.org wrote: Am 23.06.2015 07:16, schrieb Marvin Humphrey: [...] How am I supposed to invite all the downstream developers of the world to start integrating with my awesome feature FOO before it gets formally released when our policy makes statement like: If the general public is being instructed to download a package, then that package has been released. Rather than invite them in before you make a release, why not release first and then invite them in? Are we really suggesting that I can not present at conference, tweet and otherwise promote the awesomeness of my project based on 'what's coming'? Why not release before presenting, tweeting, or promoting? I am not Roman, but my interpretation in combination with the above would be, that if releases require 72h+ and you cannot just upload it somewhere and say it is no release, that it takes ages. Something like continuous delivery for example looks for me impossible with apache. I see statements like this frequently, and I don’t understand them. There seems to be an assumption that during a 72-hour voting period, all work on a project has to grind to a halt, and everyone needs to focus on the release process. That certainly isn’t true. There’s no reason you can’t have a release process working on v3.62 (or whatever) while work proceeds on v3.63. Releases should be pipelined. Move the release candidate over to the release candidate repository for final QA and signoff, then carry on developing in the development repository. Yes, a 72-hour vote process imposes additional overall latency on the process, but surely the requirement to have at least three duly-empowered humans sign off on the release isn’t that onerous! Greg Trasuk snip -- Jochen blackdrag Theodorou blog: http://blackdragsview.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: June report prep
Great idea on taking notes. On Mon, Jun 22, 2015 at 5:17 PM, Sam Ruby ru...@intertwingly.net wrote: On Mon, Jun 22, 2015 at 11:43 AM, Marvin Humphrey mar...@rectangular.com wrote: On Mon, Jun 15, 2015 at 6:58 PM, Ted Dunning ted.dunn...@gmail.com wrote: On Mon, Jun 15, 2015 at 4:48 PM, Marvin Humphrey mar...@rectangular.com wrote: There are a few more cleanup and followup tasks to take care of in order to prepare for next month: * Assign podlings who did not report a monthly attribute in podlings.xml. * Remove any expired monthly attributes. * Run clutch.py. * Assign shepherds. * Generate the July report template and publish on the wiki. No hurry, so take a couple days to catch your breath. Will your schedule allow you to get to those by the end of this week? It should. After the presentation tomorrow at Spark Summit, I should be clear for a few days. Hi Ted -- can you take care of these items please? Once you close out this month's cycle, we might also have a conversation about how you think the report process could be improved. Happy to do so. So far, the support of the team has been absolutely extraordinary. The only suggestion so far is to help a new VP know that the support exists. My assumption was that I was jumping into the deep end. The facts were quite different. Well, I think we can do better yet if we integrate the Incubator's monthly reporting into whimsy. My perception is that the total burden is too high. In the past it was borne solely by the Chair, which was not at all sustainable. Now it is spread, but additional tooling can improve matters more. However, I'm trying to hold off on that conversation until the current Chair has actually performed all the tasks involved with the report and so groks the full scope. Hint hint. ;) One thing that would be helpful is to take good notes during this process. Anything you can do via the command line can be done via a script - this includes SVN and LDAP. Anything that requires user input is generally easier when done via a HTML form (buttons, textareas, checkboxes and the like). And steps like remove expired monthly attributes can be automated away entirely. Marvin Humphrey - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: June report prep
On Mon, Jun 22, 2015 at 8:43 AM, Marvin Humphrey mar...@rectangular.com wrote: * Assign podlings who did not report a monthly attribute in podlings.xml. * Remove any expired monthly attributes. * Run clutch.py. * Assign shepherds. * Generate the July report template and publish on the wiki. No hurry, so take a couple days to catch your breath. Will your schedule allow you to get to those by the end of this week? It should. After the presentation tomorrow at Spark Summit, I should be clear for a few days. Hi Ted -- can you take care of these items please? Yes. Should have time tonight or a bit tomorrow while sitting in the airport.
Re: June report prep
On Mon, Jun 22, 2015 at 8:43 AM, Marvin Humphrey mar...@rectangular.com wrote: However, I'm trying to hold off on that conversation until the current Chair has actually performed all the tasks involved with the report and so groks the full scope. Hint hint. ;) Hint accepted.
Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
Hi, 2015-06-23 9:22 GMT-04:00 Alex Harui aha...@adobe.com: There was one attempt to try to do serious IP review on every commit in order to avoid 72 hours at vote time. I’m not sure what happened to that proposal. One related thread was http://markmail.org/message/jyicon7nkmfnf322 I never really followed up on that due to a career move that has reduced my time here, but the thread has some good ideas (and important concerns to address) for anyone who's interested in exploring alternatives. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Ignite 1.2.0 release (RC2)
On 23.06.2015 17:26, Justin Mclean wrote: Hi, Moreover, modules under extdata are test only and are not used anywhere in the project. They are used to test code deployment functionality. Perhaps it would be best to make it clearer that they are used for test data or better still generate them. Can the files be generated from source? There's nothing wrong with having binary files in a source release, and some just can't be generated. A trivial example: a bitmap image file. The fact that a file is binary, no matter what it's used for, can't be reason for holding back a release. Subversion, for example, has whole repository snapshots in its test suite. I've never heard any complaints. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
On Tue, Jun 23, 2015 at 6:21 AM, David Nalley da...@gnsa.us wrote: So I see a bit of nuance here. The project should not be promoting/advertising non-released artifacts outside of it's own developer community (e.g. the folks who actually develop Apache $foo) The developer, however, may want to show off what he is working on. He may want to tweet about it, give a presentation or two, invite people to play with an upcoming feature. He might feature that functionality at https://people.apache.org/~ke4/ or his own web space. The difference is that an individual is doing that, and not communicating as if he is providing downloads/releases on behalf of the project itself. That's definitely part of what I'm after, thanks! Acknowledging this need of individuals is an extremely useful intermediate step to understanding how the progressions goes: 0. starts with an individual working on cool, clearly pre-release stuff and inviting the whole world to pay attention 1. progresses to a subset of the project itself now recognizing how cool it is and collaborating with that individual on a feature branch. Still promoting to everybody, but now as a subset of PMC/committers 2. PMC agreeing that it is the most valuable feature in the next release and the project lives or dies by getting it right. Hence the project as a whole now needs to make binary, non-release artifacts available. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
On Mon, Jun 22, 2015 at 10:16 PM, Marvin Humphrey mar...@rectangular.com wrote: The distinction is between people who develop the Apache product, and those who use the Apache product. Well, that's part of the reason behind me starting this thread: I think it is time for us to explicitly acknowledge a third role: an downstream project developer integrating with Apache *project*. I believe we have enough evidence that this group of people has unique requirements. How am I supposed to invite all the downstream developers of the world to start integrating with my awesome feature FOO before it gets formally released when our policy makes statement like: If the general public is being instructed to download a package, then that package has been released. Rather than invite them in before you make a release, why not release first and then invite them in? Because I want their feedback during the release cycle, not after. IOW, I need them to download and integrate with half-baked functionality that I may be not comfortable putting into a release. Are we really suggesting that I can not present at conference, tweet and otherwise promote the awesomeness of my project based on 'what's coming'? Why not release before presenting, tweeting, or promoting? See above. After all, we have a really good way of communicating that type of intent when it comes to branding: if you want to communicate that Apache FOO is a poddling you MUST refer to it as Apache FOO (incubating). Simple and effective. Exact opposite of our release policy that seems to completely discount labeling for communicating intent. I'm sorry, but a -SNAPSHOT labeling of a version ID communicates as much (if not more) to me as a writing on a website does. Lets just recognize that. If artifacts are being consumed by people other than those who develop the Apache product, those artifacts need to be vetted and voted. Like I said -- I'm 100% with you when it come to source artifacts. Can somebody please explain to me what is a the danger to the foundation is a [P]PMC wants to make a clearly identifiable non-release artifacts available to the general public? Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Ignite 1.2.0 release (RC2)
On 23 June 2015 at 21:17, Branko Čibej br...@apache.org wrote: On 23.06.2015 21:14, Branko Čibej wrote: The fact that a file is binary, no matter what it's used for, can't be reason for holding back a release. Let me amend that: as long as it doesn't affect the functionality of the product in any way. Your amendment makes it very difficult to release a number of projects. Take AOO as an example, we use icons in the menuline, and of course they are stored a binaries. I think the real problem is that many projects actually have different binaries in their release which are needed for the project (not only test data), and looking at our TLP projects nobody complains. Maybe we should try to find another definition here. rgds jan i. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Ignite 1.2.0 release (RC2)
On 23.06.2015 21:14, Branko Čibej wrote: The fact that a file is binary, no matter what it's used for, can't be reason for holding back a release. Let me amend that: as long as it doesn't affect the functionality of the product in any way. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
On Tue, Jun 23, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: There is nothing preventing clearly identifiable non-release artifacts available to the general public. Many projects make automated nightly builds available for example. This! Honestly this has always been my personal interpretation of the policy (although now that I'm re-reading it I see how it could be interpreted in a radically different way). IOW, I've been mentoring a lot of poddlings and advising them that as long as they go out of their way to label 'nightly' artifacts as NON RELEASE, DON'T TRY IT AT HOME, DANGER!!! it is ok to make them available to general public (*). I have always though that, for example, -SNAPSHOT version designation is enough to communicate that type of intent. Same as SNAPSHOT/NONRELEASE tag on Docker image, etc. From what you're telling me it sounds like this should be acceptable to ASF (I know you're just voicing your viewpoint, not the official ASF). That still leaves the question of updating the policy which I'd love to collaborate with somebody to update -- but I don't think I can sign up for that job all by myself. Thanks, Roman. (*) an come on, do you really think that *general* public consumes something like apache common? These are our fellow developers -- they really don't have to be told what -SNAPSHOT designation means. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
On Tue, Jun 23, 2015 at 5:20 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: There is nothing preventing clearly identifiable non-release artifacts available to the general public. Many projects make automated nightly builds available for example. The release policy expressly says that nightly builds must not be made available to general public. It's my understanding that the reason the foundation can provide indemnification (to both commiters/PMC and downstream) is the fact that PMCs vote on releases under their delegated authority from the board. If the boundary for public use moves from voted on by a PMC to voted on by a PMC or labeled as non-release what are the ramifications? While I agree that this is a general issue that should be discussed, an example might help. This discussion started because the Geode PMC is publishing a docker artifact from their nightly builds and then pointing the general public to make use of that image. They have no released artifacts, so any downstream user necessarily will be using those non-vetted artifacts. Downstream developers and users *will* take the path of lease resistance. If that PMC wanted to continue relying on a binary docker image for community outreach indefinitely, would that be okay? If they wanted to rely on it and only have PMC blessed releases quarterly? -- Sean
Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
On Tue, Jun 23, 2015 at 10:48 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Tue, Jun 23, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: There is nothing preventing clearly identifiable non-release artifacts available to the general public. Many projects make automated nightly builds available for example. This! Honestly this has always been my personal interpretation of the policy (although now that I'm re-reading it I see how it could be interpreted in a radically different way). IOW, I've been mentoring a lot of poddlings and advising them that as long as they go out of their way to label 'nightly' artifacts as NON RELEASE, DON'T TRY IT AT HOME, DANGER!!! it is ok to make them available to general public (*). I have always though that, for example, -SNAPSHOT version designation is enough to communicate that type of intent. Same as SNAPSHOT/NONRELEASE tag on Docker image, etc. I agree. As long as the version designation of the artifact includes -SNAPSHOT or -DEV or whatever, I think that's sufficient to qualify as a clearly identifiable non-release artifact. FWIW, httpd always had nightly tarballs available for consumption and testing. I do think that the threshold is that it needs to come from an automated process blessed by the [P]PMC. If it requires a human to publish the nightly into the distribution channel, then I think that's probably where the line gets crossed and our voting rules apply. Nightly builds shouldn't be easily found - except deep inside developer-facing documentations. All obvious materials should point at the official, blessed releases. But, it's important to provide a channel for downstream people to test trunk/master/develop (whatever shiny name the project calls it). In today's day and age, producing Docker-like thingys is akin to producing RPMs. I won't go into why I think the centralized Docker Hub is a huge mistake - it's simply how you consume Docker thingys. I do wish that we could point folks at a specific Docker registries (a la an apt or yum repos), but having a single global registry is how Docker, Inc. apparently thinks that it'll justify its valuations. Sigh. Cheers. -- justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
On Tue, Jun 23, 2015 at 11:06 PM, Sean Busbey bus...@cloudera.com wrote: While I agree that this is a general issue that should be discussed, an example might help. This discussion started because the Geode PMC is publishing a docker artifact from their nightly builds and then pointing the general public to make use of that image. They have no released artifacts, so any downstream user necessarily will be using those non-vetted artifacts. Once releases are made, then I think any Geode documentation would definitely shift to referring to the released versions. However, Geode isn't yet ready to cut a release. I do doubt that anyone who picks up a nightly Geode build right now is going to put it into production. So, I'm not overly worried. By the time the project is ready to graduate, there will be several releases (if not more) and I fully expect that this'll be a moot point. Downstream developers and users *will* take the path of lease resistance. If that PMC wanted to continue relying on a binary docker image for community outreach indefinitely, would that be okay? If they wanted to rely on it and only have PMC blessed releases quarterly? As I mentioned in my other email, as long as it's automated and producing a nightly artifact that is appropriately labeled, then, sure go for it, IMO. Cheers. -- justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Ignite 1.2.0 release (RC2)
Justin, You are right on binaries, however these 4 binaries are test only. Moreover, modules under extdata are test only and are not used anywhere in the project. They are used to test code deployment functionality. I agree that they should not be included in the source release, but the previous release also did have them. Would it be OK for us to proceed with this 1.2.0-incubating release and fix the issues mentioned in the next release shortly after? Thanks! --Yakov 2015-06-23 8:01 GMT+03:00 Justin Mclean jus...@classsoftware.com: Hi, Sorry -1 binding due to binary files in the source release. Will change my vote if there's a good reason for this or if I’m mistaken. I checked: - release contains incubating - DISCLAIMER exists - LICENSE and NOTICE good - Possible unexpected binary (see below) - All source files have Apache headers - Can compile from source I notice a few .gar in the source release. These are similar to .war files right? ./modules/core/src/test/resources/helloworld.gar ./modules/core/src/test/resources/helloworld1.gar ./modules/extdata/p2p/deploy/p2p.gar ./modules/extdata/uri/deploy/uri.gar The test files are probably OK, but the deploy files seem like they shouldn't be there. The LICENSE and NOTICE for the binary files also look incorrect give the number of jars and lack of information in LICENSE / NOTICE. This will need to be fixed at some point before graduation. See [1] for more info. The LICENSE/NOTICE files should be different for the binaries and reflect their contents. I’ve not looked at the the binaries in detail but from a quick look / picking a few jar at random I see: - jsch-0.1.50.jar is BSD so that would need to be added to binary LICENSE. - docker-1.9.0.jar if it;s docker then, while docker is Apache licensed it has a NOTICE file [2], so that would need to be added to the binary NOTICE file. - avax.servlet-api-3.0.1.jar may be problematic as it is CDDL + GPLv2. If this is an optional dependancy if may need to be downloaded separately. Your mentors should be able to help with what needed here or email here if the need a hand assembling / checking before you make a release. The best guidance can be found at [3]. Keep in mind the guiding principal [4] and it’s mostly straight forward. Thanks, Justin 1. http://www.apache.org/dev/licensing-howto.html#binary 2. https://github.com/docker/docker/blob/master/NOTICE 3. http://www.apache.org/dev/licensing-howto.html 4. http://www.apache.org/dev/licensing-howto.html#guiding-principle - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[CANCELED] Re: [VOTE] Release Apache Usergrid 1.0.2 (incubating) RC2
Canceling on behalf of the Usergrid podling. Thanks for noting these Justin. John On Mon, Jun 22, 2015 at 11:32 PM Justin Mclean jus...@classsoftware.com wrote: Hi, Sorry but it -1 binding until the font licenses had been sorted. I checked: - signatures and hashes correct - artefact has incubating in it’s name - DISCLAIMER exists - LICENSE and NOTICE ok - a couple of minor issues see below - no unexpected binaries in release - all source files have headers - can compile from source These files: ./portal/css/arsmarquette/ARSMaquettePro-Light.otf ./portal/css/arsmarquette/ARSMaquettePro-Medium.otf ./portal/css/arsmarquette/ARSMaquettePro-Regular.otf As far as I can tell are: Copyright (c) ARS Type®-Angus R. Shamal, 1999-2010. All rights reserved. And not licensed under an Apache compatible license. Is this correct? Looks like this had already been raised as an issue (and quite a while ago): https://issues.apache.org/jira/browse/USERGRID-238 Minor issues: - Having a little more information in the LICENSE file re version numbers/copyright holders and URLs while not legally required would be helpful. - NOTICE is missing year, please add this for next release. - LICENSE seems to be missing jQuery sparklines (BSD) (See ./portal/js/libs/jquery/jquery.sparkline.min.js) Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
Am 23.06.2015 07:16, schrieb Marvin Humphrey: [...] How am I supposed to invite all the downstream developers of the world to start integrating with my awesome feature FOO before it gets formally released when our policy makes statement like: If the general public is being instructed to download a package, then that package has been released. Rather than invite them in before you make a release, why not release first and then invite them in? Are we really suggesting that I can not present at conference, tweet and otherwise promote the awesomeness of my project based on 'what's coming'? Why not release before presenting, tweeting, or promoting? I am not Roman, but my interpretation in combination with the above would be, that if releases require 72h+ and you cannot just upload it somewhere and say it is no release, that it takes ages. Something like continuous delivery for example looks for me impossible with apache. IOW, I would like to focus on answering the question of how can we empower our communities to effectively communicate *their* intent of how *they* expect an artifact to be consumed. They can communicate their intent by voting on a release. if every provided download is effectively a release, then you need the voting and all before you can release... that takes ages. Imagine you do around 13 releases per year. You will be easily busy with voting for over two months in total. bye blackdrag -- Jochen blackdrag Theodorou blog: http://blackdragsview.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
On Tue, Jun 23, 2015 at 5:06 AM, Roman Shaposhnik r...@apache.org wrote: Hi! let me start by saying that I feel proud about the rigor with which ASF approaches management of the ultimate foundation deliverables: the source releases put out by our communities. If you read our policy document: http://www.apache.org/dev/release.html and only focus on the source releases it is obvious to me that we strike a great balance between fostering innovation while practicing strict IP hygiene. Unfortunately, I can't really say the same for the parts of the policy that covers binary convenience artifacts. The way our policy talks about these artifacts seems to invite different interpretations which is especially problematic for training podlings in the Apache Way (hence even though this discussion is perfectly applicable to TLPs I'm starting it here on general@incubator). I dont agree with your interpretation of the release page. It doesn't define a release as source - it says anything that is published beyond the group that owns it and specifically mentions nightly builds. Also the following page is specific about distributing unreleased materials outside the project development community: http://www.apache.org/dev/release-distribution.html#unreleased The biggest source of confusion that I personally witnessed comes from interpreting 'general public' vs. 'developers'. The problem there seems to come from the false assumption that our projects always have a user base that is non-developer in nature. For projects like libraries or frameworks this is simply not the case. The end-users of such projects are always, by definition, developers. The ASF has had alot of projects for a long time (perhaps the majority) where the user-base are developers. But it has always been the case that developer here means someone who participates in the development of the project. The ASF use of the terms User and Developer are documented on the glossary page: www.apache.org/foundation/glossary.html Think of them as downstream developers integrating with ASF projects via binary artifacts. These folks always embed ASF project into larger systems. They also, typically, live and die by the level of API compatibility that the upstream ASF-produced dependencies maintain. This, in turn, puts pressure on ASF upstream projects to maintain a healthy and convenient channel for managing non-release, downstream integration binary artifacts. Unfortunately, our current release policy is extremely confusing when it comes to this very important use case. I don't agree that its confusing - it seems clear to me that distributing unreleased material outside the development community is against the policy. What's worse, in my opinion it gets in the way of fostering user community for projects where users == downstream developers. How am I supposed to invite all the downstream developers of the world to start integrating with my awesome feature FOO before it gets formally released when our policy makes statement like: If the general public is being instructed to download a package, then that package has been released. Release an alpha or experimental version. Also, I think its worth mentioning that this isn't just an intellectual exercise, but is a specific issue raised about the Geode PPMC publishing nightly builds to Docker Hub: * http://s.apache.org/SfK Niall Are we really suggesting that I can not present at conference, tweet and otherwise promote the awesomeness of my project based on 'what's coming'? I've always assumed that we are not and the way policy is currently worded is just sloppy. I know that there's been a number of threads over the years that tilted at the windmill of clarifying our policies around binary releases. At this point, I'm actually taking a step back and asking a bigger question: why don't we take a more nuanced approach towards the very issue of what makes a release a release. IOW, I would like to focus on answering the question of how can we empower our communities to effectively communicate *their* intent of how *they* expect an artifact to be consumed. After all, we have a really good way of communicating that type of intent when it comes to branding: if you want to communicate that Apache FOO is a poddling you MUST refer to it as Apache FOO (incubating). Simple and effective. Exact opposite of our release policy that seems to completely discount labeling for communicating intent. I'm sorry, but a -SNAPSHOT labeling of a version ID communicates as much (if not more) to me as a writing on a website does. Lets just recognize that. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Ignite 1.2.0 release (RC2)
Hi, There's nothing wrong with having binary files in a source release, and some just can't be generated. There’s no issue with .png, .gif, or .jog or the like that’s true, but in this case the files in question are the equivalent of a war file i.e. compiled code. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Ignite 1.2.0 release (RC2)
Hi, I think the real problem is that many projects actually have different binaries in their release which are needed for the project (not only test data), and looking at our TLP projects nobody complains. In general most binary files are not an issue but jars, wars or other compiled files (dll, exes etc etc) are. So when [1] say no binaries, what it mean to say is no unexpected binaries. The text makes it a bit clearer. I’ve certainly reviewed many incubator and TLP releases that included binary files and normally it’s not an issue. Thanks, Justin 1. http://incubator.apache.org/guides/releasemanagement.html#check-list - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
On Tue, Jun 23, 2015 at 6:22 AM, Alex Harui aha...@adobe.com wrote: Yep, that’s the “tax” of Apache. IMO, its main reason for existing is to make users of ASF projects feel comfortable incorporating our source into their projects because we’ve done our due diligence on the IP/legal stuff on every line of source. Even for “alpha” quality code, when we say “here, go try this, it may be buggy” we are also saying “we feel pretty good it is safe to eventually be part of your production code and won’t have effects on how you license and use this code”. Yes, folks shouldn’t put alpha code into production, but you know how reality is: some manager sees your POC and suddenly you have a team adding more code on top of it. I think I just got it! Let me continue the tax analogy: at this point ASF has a flat one-size-fits-all tax of putting something, anything out there. We optimize for the most demanding case: the case of guaranteeing clean IP AND reasonably stable functionality. What I'm suggesting here is that perhaps we should think about having a progressive tax. A tax that starts small for things that have very little potential to cause ASF trouble and culminate with the most demanding one. The one we currently have today. Does this make sense? Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
There is nothing preventing clearly identifiable non-release artifacts available to the general public. Many projects make automated nightly builds available for example. Sent from my Windows Phone From: Roman Shaposhnikmailto:ro...@shaposhnik.org Sent: 6/23/2015 12:23 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts On Mon, Jun 22, 2015 at 10:16 PM, Marvin Humphrey mar...@rectangular.com wrote: The distinction is between people who develop the Apache product, and those who use the Apache product. Well, that's part of the reason behind me starting this thread: I think it is time for us to explicitly acknowledge a third role: an downstream project developer integrating with Apache *project*. I believe we have enough evidence that this group of people has unique requirements. How am I supposed to invite all the downstream developers of the world to start integrating with my awesome feature FOO before it gets formally released when our policy makes statement like: If the general public is being instructed to download a package, then that package has been released. Rather than invite them in before you make a release, why not release first and then invite them in? Because I want their feedback during the release cycle, not after. IOW, I need them to download and integrate with half-baked functionality that I may be not comfortable putting into a release. Are we really suggesting that I can not present at conference, tweet and otherwise promote the awesomeness of my project based on 'what's coming'? Why not release before presenting, tweeting, or promoting? See above. After all, we have a really good way of communicating that type of intent when it comes to branding: if you want to communicate that Apache FOO is a poddling you MUST refer to it as Apache FOO (incubating). Simple and effective. Exact opposite of our release policy that seems to completely discount labeling for communicating intent. I'm sorry, but a -SNAPSHOT labeling of a version ID communicates as much (if not more) to me as a writing on a website does. Lets just recognize that. If artifacts are being consumed by people other than those who develop the Apache product, those artifacts need to be vetted and voted. Like I said -- I'm 100% with you when it come to source artifacts. Can somebody please explain to me what is a the danger to the foundation is a [P]PMC wants to make a clearly identifiable non-release artifacts available to the general public? Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
On 6/23/15, 4:16 PM, shaposh...@gmail.com on behalf of Roman Shaposhnik shaposh...@gmail.com on behalf of ro...@shaposhnik.org wrote: On Tue, Jun 23, 2015 at 6:22 AM, Alex Harui aha...@adobe.com wrote: Yep, that’s the “tax” of Apache. IMO, its main reason for existing is to make users of ASF projects feel comfortable incorporating our source into their projects because we’ve done our due diligence on the IP/legal stuff on every line of source. Even for “alpha” quality code, when we say “here, go try this, it may be buggy” we are also saying “we feel pretty good it is safe to eventually be part of your production code and won’t have effects on how you license and use this code”. Yes, folks shouldn’t put alpha code into production, but you know how reality is: some manager sees your POC and suddenly you have a team adding more code on top of it. I think I just got it! Let me continue the tax analogy: at this point ASF has a flat one-size-fits-all tax of putting something, anything out there. We optimize for the most demanding case: the case of guaranteeing clean IP AND reasonably stable functionality. What I'm suggesting here is that perhaps we should think about having a progressive tax. A tax that starts small for things that have very little potential to cause ASF trouble and culminate with the most demanding one. The one we currently have today. Does this make sense? Well, IMO, a progressive tax doesn’t make sense. Since you like my first analogy, let me try another one: peanuts. Many people have severe peanut allergies. Even trace amounts, like chocolate made in a factory where peanuts are processed can be a problem. If you advertise that your restaurant is completely safe for these folks, you cannot afford to experiment on the general public with new ingredient suppliers. Because if you screw up, not only have you harmed someone, your reputation is screwed up for a long time, if not forever. There is no progressive way of introducing peanuts into your menu. Roughly speaking, GPL and other category X licenses are peanuts. So until your product team has done its due diligence that there are no peanuts in the ingredients from your suppliers, don’t serve that food to anyone who walks in the door, and don’t advertise telling everybody to come in and try it. Now you can invite folks to help you prove that the food tastes good and doesn’t have peanuts in it. You can even go to conferences and invite these folks. They subscribe to your dev list and taste the nightly builds. But they are signing up to be a taste tester. They are not the general public. This is how I think about these things. I wish there was a better word than “release” because “release” has other meanings in other places which I think is the root cause of this sort of confusion on this topic. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
