Voting in Committers
Hi, This was already discussed on members@ but others in my TLP community are still not satisfied and want a more "public" discussion. I think the main question is whether [1] is a policy document and therefore satisfies the "stated otherwise" clause in this document [2]. The answer I got on members@ is that [1] is not a policy document and therefore a vote as to whether to make someone a committer defaults to majority rules unless the TLP has voted otherwise, and a -1 vote is not a veto unless the TLP has voted otherwise. And if that's true, would it be ok to be more explicit on [1] that it isn't a policy document? I know it says that "Each project has different approaches to managing new committers" but it still could mean that this is the policy unless the TLP has voted differently. 1. http://community.apache.org/newcommitter.html 2. http://www.apache.org/foundation/voting.html Thanks in advance, -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
(Apologies if you get this twice. I'm having email issues) Doug, The thread on members@ was titled "Committer Qualifications". I asked a question about the -1 vote on 9/7/13 and the reply I got was that committer voting does not have vetoes, and the document at [1] also seems to say that. The document at [1] also does not define "consensus" nor does it say that it must apply to committer votes. And, it might help to have a definition of "consensus" as definition 1b in [2] says that it does not require unanimity. [1] http://www.apache.org/foundation/voting.html [2] http://www.merriam-webster.com/dictionary/consensus Thanks, -Alex On 10/1/13 8:21 PM, "Doug Cutting" wrote: >Lots of people on this list are also on members@, and, so far, none have >objected to my statements. If this continues, it would indicate a lack of >controversy. > >Doug >On Oct 1, 2013 7:36 PM, "Justin Mclean" wrote: > >> Hi, >> >> > I don't find the discussion on members@ that comes to this conclusion. >> If >> > you cannot see members@ how do you know this? >> >> I was informed by a member on Flex private and here [1] which you >>already >> responded to. >> >> Thanks, >> Justin >> >> 1. http://markmail.org/thread/chfagblj72cv7zrt >> >> >> >> - >> 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 project bylaws
Hi Doug, Sorry to be so picky, but my ultimate goal here is to save time for my project and all future graduating projects by avoiding as much thrashing on this kind of issue as possible. To me, agreeing on "the norm" is not the same as policy, especially policy that does not allow for exceptions. And again, to me, "consensus != unanimity". And if it is "policy" then at least Struts is non-conforming: [1] Would this prior discussion also be on general@ or some other list? -Alex [1] http://struts.apache.org/dev/bylaws.html On 10/2/13 9:32 AM, "Doug Cutting" wrote: >On Tue, Oct 1, 2013 at 11:13 PM, Alex Harui wrote: >> The thread on members@ was titled "Committer Qualifications". I asked a >> question about the -1 vote on 9/7/13 and the reply I got was that >> committer voting does not have vetoes, and the document at [1] also >>seems >> to say that. > >I followed up on that thread on members@, to get some clarity. > >This issue has come up before. I don't have time to search the >archives now, but I recall that folks agreed then that the norm at >Apache is consensus for committer additions. The mention of >"procedural" votes on the voting page has been a source of confusion. >I suspect it is meant to allude to release plans and the like. We >should clarify that it isn't meant to refer to committer or PMC member >votes, that those are generally subject to consensus votes. > >Doug > >- >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 project bylaws
On 10/2/13 10:09 AM, "Doug Cutting" wrote: >On Wed, Oct 2, 2013 at 9:49 AM, Alex Harui wrote: >> To me, agreeing on "the norm" is not the same as policy, especially >>policy >> that does not allow for exceptions. > >I agree. Establishing whether there is a norm is a useful first step. > That's what I'm trying to take. Thus far I've seen noone disagree >that consensus is most common for committer additions at Apache. I've >also seen folks suggest that they prefer having norms than having >explicit bylaws for their projects. I don't anticipate any policy >being established as a result of this discussion, except perhaps >better documenting what the assumed default is for projects that don't >choose to have explicit bylaws. > >> And again, to me, "consensus != unanimity". > >This might be another case where better documentation would help. In >my experience at Apache, consensus is equated with unanimity. In my tour of the internet since my last post and your reply, it does appear that most Apache-related information indicates that committer voting uses consensus and thus the Voting document [1] is out of date. I found this link as well [2]. I'd be tempted to replace the Voting document [1] with this [2], although I'm not sure I understand the difference between "consensus" and "unanimous consensus". Your thoughts? [1] http://www.apache.org/foundation/voting.html [2] http://www.oss-watch.ac.uk/resources/meritocraticGovernanceVoting -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On 10/2/13 11:11 AM, "Roy T. Fielding" wrote: >On Oct 2, 2013, at 10:20 AM, Alex Harui wrote: >> On 10/2/13 10:09 AM, "Doug Cutting" wrote: >> >>>In my tour of the internet since my last post and your reply, it does >> appear that most Apache-related information indicates that committer >> voting uses consensus and thus the Voting document [1] is out of date. > >It isn't out of date. It is just plain wrong. It does not reflect any >of our projects, but rather presents an incomplete summary based on >someone's personal experience. I would like to propose a rewrite of [1] by borrowing heavily from [2] but making sure to emphasize that projects are allowed to have different rules for all of them (or is the code-commit veto required for all projects). Any objections to me trying to do that? I'll try to get something out this evening. For me, it would have saved our project time to have [1] be more accurate and describe a set of default voting procedures in more detail. I'm also tempted to ask the board to approve a resolution to remove the requirement that graduating podlings create a set of by-laws, and waive the obligation for existing TLPs. It seem like it should be optional. Thanks, -Alex [1] http://www.apache.org/foundation/voting.html [2] http://httpd.apache.org/dev/guidelines.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On 10/2/13 12:58 PM, "Marvin Humphrey" wrote: >On Wed, Oct 2, 2013 at 11:35 AM, Alex Harui wrote: >> I would like to propose a rewrite of [1] by borrowing heavily from [2] >>but >> making sure to emphasize that projects are allowed to have different >>rules >> for all of them (or is the code-commit veto required for all projects). >> Any objections to me trying to do that? > >Rather than a "rewrite", I suggest proposing small, incremental, >reversible >changes. Governance is easy to mess up. Well, "small, incremental" was hard to do given the significantly different information this document must now convey. I tried to keep as much as possible yet incorporate feedback from Doug and Roy. Below is my proposed version, and below it is the svn diff in case that makes it easier to see what changed. Most of the changes were made at the beginning. I'm sure I haven't nailed it so feel free to comment. And I'm not quite sure how to do a table in mdtext. I'm off to sleep so I'll respond several hours from now. Thanks for reading... -Alex --- Updated voting.mdtext -- Title: Apache Voting Process Notice:Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at . http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. At the Apache Software Foundation, two decisions must be made by a vote held on a project's mailing list. The two decisions are: 1. Code modifications, 1. Package releases Other decisions are commonly made via votes as well, but a project may draft by-laws or guidelines that describe variations to the voting processes described below. If a project does not draft by-laws or guidelines, it is assumed that any votes held to make any of the decisions listed below follow the processes described below. Many projects make the following decisions via voting: 1. Approving a new committer 1. Approving a new PMC member 1. Approving a new PMC Chair 1. Removing a committer 1. Removing a PMC member 1. Approving by-laws or guidelines or changes to by-laws or guidelines Many project by-laws and guidelines describe other decisions made via voting. Use of [lazy consensus](#LazyConsensus) is recommended for as many other decisions as possible. Here is a table of the default voting processes: ActionApprovalDuration Code Modification[lazy consensus](#LazyConsensus)72 hours Approve Release[majority](#Majority)72 hours Approve New Committer[consensus](#Consensus)72 hours Approve New PMC Member[consensus](#Consensus)72 hours Approve New PMC Chair[consensus](#Consensus)72 hours Remove Committer[consensus-but-one](#ConsensusButOne)72 hours Remove PMC Member[consensus-but-one](#ConsensusButOne)72 hours Approve/Change By-laws/Guidelines[majority](#Majority)72 hours Approve Donation[consensus](#Consensus)72 hours # Binding Votes # Who is permitted to vote is, to some extent, a project-specific thing. However, the default rule is that for Code Modification, any committer's veto counts, but for all other decisions only PMC members have binding votes, and all others have their votes considered of an indicative or advisory nature only. By default, only "active" PMC members may cast votes. Project's can define their own definition of active, but the default definition is whether that member has sent an email on any Apache mailing list, made a change to any asset under Apache version control, or voted on any vote thread. This low bar is intended to cover "mature" projects that don't do much other than file quarterly reports. # Implications of Voting # In some cases and communities, the exercise of a vote carries some responsibilities that may not be immediately obvious. For example, in some cases a favourable vote carries the implied message 'I approve **and** I'm willing to help.' Also, an unfavourable vote may imply that 'I disapprove, but I have an alternative and will help with that alternative.' The tacit implications of voting should be spelt out in the community's guidelines. However, **in no
Re: Apache project bylaws
On 10/3/13 6:23 AM, "Marvin Humphrey" wrote: >On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui wrote: >> On 10/2/13 12:58 PM, "Marvin Humphrey" wrote: > >>> Rather than a "rewrite", I suggest proposing small, incremental, >>>reversible >>> changes. Governance is easy to mess up. >> >> Well, "small, incremental" was hard to do given the significantly >> different information this document must now convey. > >I appreciate the labor you've put in, but what we have here is akin to a >big patch on highly sensitive mission-critical code for which there are no >tests. I hope we can find a less costly way to integrate your efforts. It is a big patch for sure, but I'm not sure I agree with equating it to code. It is probably always going to be "just words" and I'm not sure you can create tests. I think even laws don't have tests, they only have to survive the reviews of the approvers and are always subject to revision later. But hopefully the reviewers will think through whether the things they thought were "right" about the old version are retained and whether the things that were "wrong" have been removed, and new content appears to be "right". > >> I tried to keep as >> much as possible yet incorporate feedback from Doug and Roy. > >Even if it was "wrong", people have been quoting from that document, >referencing it and following its guidance for a long time. I'm quite >irritated that something "wrong" has persisted for so long and has been >used >so many times as the basis for settling disputes. > >My take is that if that fundamental a document is "wrong", something is >dreadfully "wrong" with how hard-won wisdom gets handed down at the ASF. > >Let's step back for a moment and reassess what we're trying to accomplish. >We're starting with a voting document which is apparently "wrong" and >trying >to make it quasi-authoritative. But when we're finished turd polishing, >there >will still be no boundaries demarcating where the authoritative stuff >begins >and ends. > >We have this problem with the Incubator website, too. It started off with >buckets of poorly-thought-through text scooped out of mailing lists and >dumped >into version control. Years later, certain portions of it have been >carefully >wordsmithed or even negotiated under high heat; as a result, making a >minor >change has the potential to obliterate a great deal of other people's hard >work. But from just looking at the surface, you can't tell what's >garbage and >what's crucial. > >Personally, I'm not eager to spend a lot of cycles negotiating large >revisions >to highly-utilized governance documentation under such a flawed regime. >I'd >rather that we limit ourselves to small tweaks, or if we're going to go >all >out, draw up a set of default bylaws which will in the future be set off >from >other documentation and subject to review-then-commit by some governing >body >charged with oversight. Some good points in there. I know you want to revise the incubator site and I wish you well on your efforts to do so because I agree it needs it., However I just want to change this one document, and it shouldn't require the restructuring of a site, so I want to separate the two efforts, although maybe this effort will influence yours. So how about this: I will go all out and rewrite this one document so it will demarcate what is authoritative and what isn't. And I will try to make it clear that the goal of the document is to define a set of default by-laws. And I will retain the entirety of the old document for historical reference. To do so, I will insert the rewrite at the beginning of the document after I get lazy consensus on the following text which will go at the very beginning. This document is under revision. The original can be found here (#link_to_original_further_down). All decision based on the original document remain valid and the original document remains valid until further notice. The text color of the original document has been changed to (brown) to help delineate the boundaries of the original content. All authoritative sections will be demarcated with: --this section is authoritative-- And end with: --end of authoritative section-- My understanding is that only the code-modification and release voting approval type is authoritative. Please correct me if I'm wrong. > >> Below is my >> proposed version, and below it is the svn diff in case that makes it >> easier to see what changed. Most of the
Re: Apache project bylaws
On 10/3/13 8:48 AM, "Joseph Schaefer" wrote: >Good Lord man all you need to add is a one-sentence >statement that personnel votes are consensus votes not >procedural (simple majority) votes. Hmm. Maybe I'm reaching too far, but my hope was to put in this document a definition of consensus and a set of defaults for by-laws so that other new projects don't have as much if any work to do in defining their project-specific by-laws. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On 10/3/13 9:51 AM, "Joseph Schaefer" wrote: >The definitions are in a glossary somewhere, the more >we denormalize the locations of our common understandings >the harder it will be to maintain sanity over discussions. OK, found the glossary. I will try to leverage it more in the next revision. It will probably need to have consensus-but-one added to it. > >Projects don't need to be encouraged to write their own >bylaws, most don't bother and that's proper. Unfortunately, new TLPs are all copying the same board resolution which dictates that we need to write bylaws. That's independent of this thread, but something that I also suggested changing. >We don't need >to spell every possible decision making process out in detail >because they should have experienced the normal processes during >incubation under competent mentorship. Well, maybe we got lucky but we got through incubation without any major conflicts about who should be added and didn't have to deal with removing anyone. I think there should be defaults for handling removals in the voting document. > >In other words I agree with Marvin that widespread changes >to documents that have been widely referenced are not a good >idea, no matter what the board happens to think today. Just >clarify the actual issues before us, e.g. how to vote properly >on personnel issues, and that should entirely suffice. Even Greg >doesn't seem to know what consensus voting means in this context, >so there's surely room for improvement. OK, I'll try again tonight. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
OK, here is my next offering. The patch form is at [1] Some notes: -This offering has 3 new entries to glossary.html as well. -I was very tempted to move the Veto sections from Voting.html to Glossary and merge the Consensus Gauging through Silence section from Voting into Glossary. -I am also tempted to remove the empty section about "Procedural Votes or Opinion Polls" but I know you folks are looking for the minimum set of changes. -There are some sentences in Voting I'm not sure are accurate such as: 1) "and all others are either discouraged from voting" 2) "procedural votes from developers and committers are sometimes considered binding..." 3) "Only votes by PMC members are considered binding on code-modification issues" For #3, Can committers who are not PMC members have veto a code change? Thanks, -Alex [1] https://paste.apache.org/9uhY voting.mdtext Title: Apache Voting Process Notice:Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at . http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Because one of the fundamental aspects of accomplishing things within the Apache framework is doing so by consensus, there obviously needs to be a way to tell whether it has been reached. This is done by voting. There are essentially five types of vote: 1. Code modifications (including voting to accept new code donations) 1. Package releases 1. Approving people (as Committer, PMC Member, PMC Chair) 1. Removing people (as Committer or PMC Member) 1. Procedural (including approval of project bylaws) Votes on procedural issues follow the common format of [majority approval](glossary.html#MajorityApproval) unless otherwise stated. That is, if there are more favourable votes than unfavourable ones, the issue is considered to have passed -- regardless of the number of votes in each category. (If the number of votes seems too small to be representative of a community consensus, the issue is typically not pursued. However, see the description of [lazy consensus](#LazyConsensus) for a modifying factor.) Votes on code modifications follow a different model. In this scenario, a negative vote constitutes a [veto](#Veto) , which cannot be overridden. Again, this model may be modified by a [lazy consensus](#LazyConsensus) declaration when the request for a vote is raised, but the full-stop nature of a negative vote is unchanged. Under normal (non-lazy consensus) conditions, the proposal requires three positive votes and no negative ones in order to pass; if it fails to garner the requisite amount of support, it doesn't -- and typically is either withdrawn, modified, or simply allowed to languish as an open issue until someone gets around to removing it. Votes on whether a package is ready to be released or not use yet a different mechanism: are there are least three binding votes in favour of the release? See more about this [below](#ReleaseVotes). Votes on approving people require [consensus approval](glossary.html#ConsensusApproval) approval. Votes on removing people require [consensus-but-one](glossary.html#ConsensusButOne). The voting process for adding people, removing people and procedural voting may be modified and further refined by project bylaws. If a project's bylaws do not specify an alternative voting process then the above process is assumed to apply. # Binding Votes # Who is permitted to vote is, to some extent, a community-specific thing. However, the basic rule is that only PMC members have binding votes, and all others are either discouraged from voting (to keep the noise down) or else have their votes considered of an indicative or advisory nature only. Unless otherwise specified by a project's bylaws, only [active members)(glossary.html#ActiveMembers) who have been active in the last 6 months may cast binding votes. A different definition of active member may also be set in a project's bylaws. That's the general rule. In actual fact, things tend to be a little looser, and procedural votes from developers and committers are sometimes considered binding if the voter has acquired enough merit and respect in the community. Only votes by PMC members are co
Re: Apache project bylaws
Reviving this thread. I've invited others to join in as well. As a reminder, the proposed changes are here: http://mail-archives.apache.org/mod_mbox/incubator-general/201310.mbox/%3cC e743d6a.14a96%25aha...@adobe.com%3e And my goal is not just to fix up the voting doc, but to try to define a default set of bylaws so projects don't have to, or have less to decide. -Alex On 10/4/13 11:25 AM, "Doug Cutting" wrote: >On Fri, Oct 4, 2013 at 9:55 AM, Alex Harui wrote: >> Who is permitted to vote is, to some extent, a community-specific thing. >> However, the basic rule is that only PMC members have binding votes, and >> all others are either discouraged from voting (to keep the noise down) >>or >> else have their votes considered of an indicative or advisory nature >>only. > >I'd suggest dropping the bit about 'discouraged from voting' and >replace 'advisory only' with simply 'advisory'. A non-PMC vote may be >taken quite seriously or it might not be. The only points you need to >make here is that non-PMC votes are not binding but are generally >welcome. > >> Unless otherwise specified by a project's bylaws, only [active >> members)(glossary.html#ActiveMembers) who have been active in the last 6 >> months may cast binding votes. A different definition of active member >> may also be set in a project's bylaws. > >I think that policy is less universal and I'd suggest not implying it >was a default rule for all projects without bylaws. Some projects >have periods of low activity and I'd expect votes of PMC members to >still be considered valid even if they've not contributed for six >months. For example, we want a low-activity project to be able to >apply a few patches and make a release even if fewer than three PMC >members were active in applying those patches over the last six >months. My thinking here is that the definition of "active" includes other activities besides just applying changes to code so that even low-activity projects must have folks who count as active because they've at least filed board reports. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Majority vs Lazy Majority
Hi, Someday I will get back to improving the Voting and Glossary pages, but meanwhile, the Apache Flex PMC is still trying to construct a set of bylaws and we are currently discussing whether there is a difference between "Majority Approval" which is in the Glossary and "Lazy Majority" which isn't, but is used in a lot of other project bylaws but seems to have the same meaning. To me, if "Lazy" means that silence give assent, I don't see how you can the count votes of those who assent. Thoughts? -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
IMO, there are two problems: 1) We're trying to train folks to manage IP for their community but they have to seek approval from folks are aren't as vested in their community. My analogy is telling a new city council member: "Welcome to the city council. For the next year all of your decisions will require ratification by 3 state senators". 2) Release voting takes a long time. It would seem like tools should be able to reduce the time on several of the steps, except for this one from [1] "compile it as provided, and test the resulting executable on their own platform". Sometimes I think about trying to get on the IPMC and helping some podling get a release out but: A) Really, I just want to help check the legal aspects of a podling's release and don't have bandwidth to want to take on the other roles implied by being on the IPMC. B) I don't want to take the time to figure out how to build and test a release that I have no vested interest in. Now, incubating releases are not official releases, right? So why have such time- consuming requirements to get approval from the IPMC? Let's assume that the podling folks tested the building and operation of the source package. Could we build an ant script that any IPMC member or any PMC member from any TLP (to expand the pool of potential helpers to folks who supposedly know how) can run just to check: 1) source package has the name "incubating" 2) source package is signed 3) unzip source package 4) grab a tag from SVN/Git 5) Diff 6) Run Rat (without any fileset exclusions) Then some podling writes to general@ and says: "can we get legal approval to release? Please run the release checker ant script with the following inputs " Then it could run while I read through all of the other ASF emails and eventually I get a report that contains mainly a list of non-Apache files in the RAT report that I review and comment on if needed. To me, if you're reviewing a RAT report, you are a building inspector who has looked around inside. Can we make it that "simple"? For sure, if any podling member is qualified for IPMC before graduation they should be nominated and added, and I suppose we could also approve them to cast binding votes as a release checker which may be a lower bar and maybe less of a time commitment, but I think if it is possible to have a larger group of folks approve incubating releases mainly be reviewing RAT reports that might make it easier for a podling to get a release out the door and still assist in the training of the podling's future PMC members. [1] http://www.apache.org/dev/release.html#approving-a-release My two cents (probably more), -Alex On 11/9/13 9:38 PM, "Marvin Humphrey" wrote: >On Sat, Nov 9, 2013 at 4:11 AM, Dave Brondsema wrote: >> On 11/09/2013 02:23 AM, Jake Farrell wrote: > >>> If mentors are not performing their duties to vote on a given releases >>>for >>> a podling, then it is up to the IPMC as a whole to help that podling by >>> doing the do diligence and casting a vote. We all asked to be apart of >>>the >>> IPMC or where honored by a nomination and accepted the role. It is up >>>to us >>> to show these podlings what the Apache was really means. These projects >>> have all come to the ASF and we (the IPMC) have openly voted them into >>> incubation, its up to us to help them succeed. >> >> While this is true in theory it's hard in practice to wrangle those >> votes together. > >That's not the only problem. While IPMC volunteers who perform >"freelance" >release reviews keep the Incubator from grinding to a halt, our reliance >on >them undermines the Incubator's effectiveness as an IP clearinghouse. I >wish >that we would redirect those volunteer energies elsewhere. > >IPMC members who vote +1 on an initial incubating release are endorsing >the >the code import and IP clearance process[1], as well as any work done >in-house >since incubation started. Votes on subsequent incubating releases are >less >weighty because they chiefly endorse work done in-house since the last >release. > >Non-Mentors who swoop in at the last minute to vote +1 on a codebase >they've >never looked at produced by a community they've never interacted with are >not >in a position to make such endorsements, particularly for the first >incubating >release. > >They are like building inspectors who never go inside. > >>> Merit stands above all else, and the contributors that you have >>>pointed out >>> are all exceptional individuals that have advanced their projects and >>> continued to do so after graduation within the ASF. There are no short >>>cuts >>> here, merit is earned. I am 100% behind helping individuals that show >>> exceptional merit within a podling and deserve to be apart of the IPMC >>>and >>> have a binding vote. >> >> Yes, lets do this. No new structures, minimal risks. > >True. It seems that a number of people find this approach attractive. >Let's >focus on the challenges: > >1. Candidates have to be nominated. >2.
Re: Cultivating Outstanding IP Stewards
On 11/10/13 5:46 AM, "Benson Margulies" wrote: >A summarized agreement with this thread: > >The bottom line, I think, is that _someone_ has to provide the >supervision that the board delegates to a PMC. > >The virtue of the 'demolish the incubator' proposal is that it makes >that point absolutely clear. If there were no incubator, the board >would need to see three people whom it could trust to form the initial >core of the project. The board has reiterated that it wants the IPMC >to manage the bootstrap to a state: a PMC that the board can delegate >to. What's the fastest path to that state? > >If you look at it this way, then you could look at Mentors in a >slightly different light. They have two critical jobs at the outset: >(a) detailed IP supervision until members of the podling community >know what to do, and (b) get the members of the podling community up >to speed as fast as possible. > >(c) then becomes: get those people onto the IPMC. That's the only tool >the incubator has from the board, so the incubator should just use it. I guess the problem I have with that is, during my days in incubation, I would have been hesitant to accept membership in the IPMC. I still don't want to be a member of the IPMC. It comes with greater obligations. IOW, why do I need to be approved as a candidate for state office if I just want to be on my town council? > >Once (c) is accomplished, the podling doesn't necessarily graduate. It >is prudent to continue with some IPMC supervision for a bit, to look >out for various bears. > >One could hope that this schema is a near-complete solution to vote >problems. The _first_ release benefits from mentors who signed up to >be there and vote, and subsequent releases have votes from inside the >group. I should have provided a more concise summary in my write-up. It is: 1) Establish the role of "Release Auditor" in the Incubator. 2) Incubating releases need 3 votes from Release Auditors 3) Any current or former TLP PMC member is automatically a Release Auditor 4) Podling members can be approved as a Release Auditor by vote of the IPMC. 5) Release Auditors check the process and legal aspects of a release and are not required to build and test the release package. 6) Can we build an Ant script that does the grunt work of preparing a report for release auditing? Thanks, -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
On 11/13/13 10:14 AM, "Marvin Humphrey" wrote: > >While a number of people have expressed a preference for the approach of >electing more podling contributors directly onto the IPMC, in practice it >remains uncertain whether the IPMC is capable of identifying, nominating >and >voting in enough candidates -- as evidenced by some threads currently in >progress on private@incubator. > >I propose that the experiment take the following form: > >1. The initial PPMC shall be composed exclusively of IPMC members. >2. PPMC votes are binding for every release except the first. >3. One IPMC vote is required for each release after the first. > >I believe that this model provides sufficient oversight because the first >release must cross a high bar, and because it changes the dynamics of >electing PPMC members: even core contributors will now have to earn PPMC >membership, demonstrating to an initial PPMC composed of IPMC members that >they understand the Apache Way well enough to steward their project. Isn't there a possible bug here where given a higher bar for entry to the PPMC (you would now have to prove you understand the legal aspects of Apache releases before you can get on the PPMC) that it will burden the IPMC folks on the PPMC because they are the only ones who can cast votes to accept new committers, and if a first release happens but there's only one newbie who truly gets the legal aspects that the PPMC only grows by 1 and can still be left hanging if the IPMC folks walk away? I still think that having a "Release Auditor" role provides backup for getting incubator releases out without having folks have to be on the IPMC to approve the legal aspects of a release. Just like any ASF Member can backup busy PMC Chairs for some actions, any TLP PMC member should be able to backup a busy IPMC member for release auditing. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
On 11/14/13 9:07 PM, "Marvin Humphrey" wrote: >On Wed, Nov 13, 2013 at 10:47 AM, Alex Harui wrote: >> I still think that having a "Release Auditor" role provides backup for >> getting incubator releases out without having folks have to be on the >>IPMC >> to approve the legal aspects of a release. Just like any ASF Member can >> backup busy PMC Chairs for some actions, any TLP PMC member should be >>able >> to backup a busy IPMC member for release auditing. > >Speaking as someone who would presumably be suitable for this "Release >Auditor" role, I'm opposed to the idea -- and not just because I don't >want to >get stuck doing all the dirty work. > >People who sign up to Mentor a podling should expect to vote on releases >-- >especially the first. The Incubator PMC tasks Mentors with overseeing >the IP >clearance processes. A Mentor who votes +1 on the first incubating >release is >implicitly affirming that IP clearance was done properly -- because that >was >their assignment, and if something had gone awry they would surely not >vote to >release. Well, sure, clearly a highly-engaged mentor can better manage IP clearance. But is release voting really an approval of IP clearance? I thought it was more about IP "maintenance": making sure that everything in the package has a header. Usually there is a significant amount of time between the incubating IP hitting the repo and it being offered for release and I thought the clearance had to happen when it hit the repo, not at release voting time. > >A +1 vote from a "Release Auditor" who did not participate in IP >clearance is >much less meaningful: all it tells you is that whatever superficial >inspection >they performed on the finished product did not reveal any defects. If >some >committer mistakenly attaches an ALv2 header to a file that shouldn't have >one, a "Release Auditor" won't find that. To catch such problems, you >need >someone monitoring the the dev and commits lists: possibly a Mentor, >ideally a >project contributor. I thought the main point of this thread was to find a way to unblock podlings looking to release but their mentors dis-engaged, even temporarily. Are you saying that the IPMC members who step in to help (like the ones who recently stepped in for VXQuery) must do the forensics of IP clearance by scanning the commit emails? Seems like folks doing "release auditing" can do that as well if that's really required. We might even make a tool that searches through repo history for add/remove of copyrights. > >The most meaningful +1 votes are those cast by enlightened core >contributors, >because they speak from deep knowledge of the code base and its history. >IP >stewardship is a continuous process, and the Incubator's goal should be to >graduate communities with the motivation and expertise to attend to it >over >the long term -- not to certify code. Agreed. The only purpose of having a Release Auditor role is to expand the pool of folks who can vote on a release without requiring them to become full-fledged IPMC members. Now if you're saying that having backup voters is not going to meet some requirement of IP safety, it seems like it can just be made a requirement of a backup vote to do whatever that work is. If you're saying that will never work because the only folks who can validate a release are folks who are engaged in the podling, then even having other IPMC folks backup them isn't going to work either, and solutions need to be found to somehow get those mentors to find the time to meet their obligations. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
On 11/16/13 8:47 AM, "Upayavira" wrote: > > > >Alex, > >I'm not sure I see the difference between a release auditor and an IPMC >member. If someone is sufficiently clued up to audit a release, then >they're surely ready to join the Incubator PMC. Am I missing something? To me, there is more responsibility in being on the IPMC, like reviewing proposals for new podlings and voting on their graduation and becoming a mentor. Personally, that's why I don't want to be on the IPMC, but I might be willing to help IP audit a podling's release. Just like some projects don't have all committers on the PMC, a Release Auditor is just someone who can do that specific task, and there is no need to vote them in if they are already on some other TLP PMC because any member of a TLP PMC supposedly knows how to do release auditing. > >My interest is in a lesser level of involvement, where someone has shown >merit within their own PPMC and can get a binding vote there, but >no-where else. That feels to me like a very useful intermediate step to >have. I agree, except for the no-where else part. If you know how to check a RAT report and have an idea of what should be in the NOTICE files, you should be able to help out any other podling by reviewing their release and casting a binding vote so they can learn how to do that. I'd say that 3 IPMC members must vote to give a person Release Auditor status if they are not already on a TLP PMC. Consider this: I am an the Flex PMC but not the IPMC, but if I join the PPMC of some new podling, why shouldn't I be able to cast a binding vote for that podling's releases? -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
On 11/17/13 3:17 AM, "Upayavira" wrote: > >With a two tier model - with PPMC membership granting voting rights on >podling releases, then a podling would start with just mentors on its >PPMC. If you clearly knew what you were doing, you'd get voted onto the >PPMC pretty quickly, and thus you'd be able to vote on your releases. My concerns with this is that: 1) I think there is more to PPMC membership than just voting on releases. I think the first major votes for Apache Flex was what the project icon was going to be, and voting in new committers. 2) I thought the main thrust of this thread is about what to do when mentors get too busy. If they are too busy then either they won't grant worthy podling newbies the right to cast binding votes on releases, or they will do so too hastily. All I'm suggesting is that there is an existing list of qualified folks that is much larger than the IPMC to help back up busy mentors and allow a podling to get a release out. If you think that "all TLP PMC members" is too wide a net, the backup could also just be "any ASF member". -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
On 11/17/13 10:38 AM, "Upayavira" wrote: > >Also, any ASF member can ask to join the Incubator PMC. So, "any ASF >member" can technically review any vote, simply by sending an email to >the Incubator PMC private list - so we have that situation already. I'd >have no issue with members of other PMCs volunteering with the incubator >and the incubator PMC also. Again, it should be relatively easy for them >to join. So again, don't we more or less have that already? I'm just saying that from my personal perspective, I'm still shying away from being an IPMC member. It is a larger role than I would want, even though I know I can certainly just do the part I want to. Maybe there are other folks who could and want to help with releases who are also like me and are hestitant to join the IPMC. If the IPMC wants to take the time to vote in folks as full IPMC members in order to grow their ranks to try to find more folks to help with podling releases that's it's choice. I was just proposing that there is a large existing list of folks who could probably help without requiring them to be IPMC members. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
FWIW, I've been saying that I might be interested in helping with IP
auditing of podling releases, but not in the larger role of IPMC member.
You're right that temporary and restricted IPMC membership may be less
work, but here's a larger proposal anyway:
1. Establish role of 'IP Auditor' ('Steward' might have gender
implications).
1.a. All past and present members of TLP PMCs automatically become IP
Auditors.
1.b. New IP Auditors require approval by 3 other IP Auditors.
2. Change release voting to require two kinds of votes: Majority vote on
quality and consensus vote (with vetos allowed) on IP management. This
will emphasis the importance of IP management, not only in the incubator,
but throughout the ASF.
Yes, this doesn't address the clearance and maintenance of IP as it is
introduced to and modified in the repo, just the process of verifying that
things are labelled correctly (assuming clearance and maintenance was done
properly). Regarding clearance and maintenance, I don't know if there are
tools like the ones schools use to check for copying and plagiarism or
tools that highlight header changes, but IP Auditors could have a role
there as well.
In the incubator, PPMC's would be formed as they are now, but worthy PPMC
candidates can be promoted to IP Auditor at any time.
-Alex
On 11/20/13 1:57 AM, "Bertrand Delacretaz" wrote:
>On Wed, Nov 20, 2013 at 10:41 AM, Joseph Schaefer
> wrote:
>> Can I just ask how many people have we encountered who upon
>> being offered IPMC membership turned it down with grounds along
>> these lines?...
>
>I'm not saying there are any, hence starting my suggesting with
>"assuming Upayavira's concerns are true".
>
>My "temporary PMC member election" suggestion is easy to implement and
>revert, I thought it might be easier to agree on and move on than the
>larger proposals seen in this thread.
>
>-Bertrand
>
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
>
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Release Verification Checklist
On 12/1/13 4:47 PM, "Marvin Humphrey" wrote: >On Sun, Dec 1, 2013 at 1:52 PM, Dave Fisher wrote: >> One note I have is I don't think we should be teaching that some of >>release >> steps are "optional" when they are required. > >Don't get me wrong -- I would actually prefer to make each PPMC member do >the >work for each item. The main rationale behind making the checklist items >"optional" is something else: to avoid adding yet more design pressure >onto >the checklist. Making all items "required" means that we have to >anticipate >all possible edge cases in advance, lest we make it impossible to vote >for a >release which would otherwise pass but gets hung up on a technicality. Just curious: how do you know someone didn't just copy-paste the form with boxes already checked? Can we not make a tool that performs these checks? IMO, make everything required. Let the mentors or other IPMC members grant exceptions if you hit edge cases. This is just an experiment, not new policy that will be in place forever, right? FWIW, I would also drop the "all tests passed". That would make it easier to create a tool that checks everything else. I'm pretty sure our mentors never ran the tests. The PPMC members are probably sufficiently invested in making sure quality is sufficient, one way or another. For Flex, we didn't even have all tests donated to the repo for our first release. I ran the artifacts against the Adobe copy of the tests, but no non-Adobe folks had such an opportunity. -Alex - 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 12/11/13 9:51 PM, "Marvin Humphrey" wrote: > >I'm curious what others think. There's room for us to disagree, since >release >votes do not require consensus... That's the part I've found curious. There's no whistleblower provision for someone who thinks they see something that puts the foundation at risk from stopping those to don't see it. Certainly, quality is subjective and thus consensus is too strict, but the process we use to get a consensus veto to change seems appropriate if a -1 vote is based on a foundation/law issue. Some of our policies do have wiggle room, but I don't think all of them do. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about jar files in svn.
My understanding of the link I posted way back is that the source package cannot contain compiled output that will be executed by the customer. IMO, whether it is "external" or not doesn't matter. The JAR used by the Compress tests is hopefully just data, not some part of its functionality. On 12/19/13 10:40 AM, "Henry Saputra" wrote: >Ah I see. > >So the point of concern is the "external" jars, but jars that are >generated by the project itself (for example for tests) should be >fine? > >- Henry > >On Thu, Dec 19, 2013 at 10:34 AM, sebb wrote: >> On 19 December 2013 18:26, Henry Saputra >>wrote: >>> But at the end, when a podling prepare a release there should not >>> include jar files as part of the source release artifacts to be VOTED >>> on, is this correct? >> >> I think that depends on what the jar files are. >> For example. Apache Commons Compress includes some jar files in SVN >> and the source release as part of the test data. >> >> But I would not expect to find "external" jar files in the source >>release. >> >>> - Henry >>> >>> On Thu, Dec 19, 2013 at 9:21 AM, Marvin Humphrey >>> wrote: On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk wrote: > We¹re having a discussion over in d...@river.apache.org that was >triggered by > the recent discussion here about the Spark podling release. The River discussions seem to be playing out productively. Here are links for other people who may be interested: https://issues.apache.org/jira/browse/RIVER-432 http://markmail.org/thread/abppti56ipnhnnfy > To be more specific, there doesn¹t seem to be any doubt that jars >shouldn¹t > be included in source release packages, but would it be fair to say >that > they should also not be in the svn? My understanding is that it is fine to store jars in version control outside of the main source tree, analogous to providing a separate "-deps" download. Between that and technical solutions which download deps on the fly such as Ivy and Maven, I think that renders the question about whether binaries can reside in the main source tree within version control moot. But there's no strictly enforced policy AFAIK because we discourage people from considering our source control repositories distribution points. (Note to podlings: this is why we make links to source control only available through the developer portions of our websites, etc.) That way we don't have to be rigid about enforcing the policies which apply to releases at every single commit point, even as we make best efforts to keep our trees clean. FWIW, the same principles which give us a measure of flexibility about LICENSE and NOTICE in version control could arguably apply to jar files as well. Here's Board member Doug Cutting back in September on legal-discuss@apache: http://s.apache.org/GNP I think perhaps you're looking for clear lines where things are actually a bit fuzzy. Certainly releases are official distributions and need LICENSE and NOTICE files. That line is clear. On the other hand, we try to discourage folks from thinking that source control is a distribution. Rather we wish it to be considered our shared workspace, containing works in progress, not yet always ready for distribution to folks outside the foundation. But, since we work in public, folks from outside the foundation can see our shared workspace and might occasionally mistake it for an official distribution. We'd like them to still see a LICENSE and NOTICE file. So it's not a hard-and-fast requirement that every tree that can possibly be checked out have a LICENSE and NOTICE file at its root, but it's a good practice for those trees that are likely to be checked out have them, so that folks who might consume them are well informed. Again, policy flexibility with respect to version control becomes academic if you can restructure the build. Nevertheless, I hope that this additional background is helpful for River's ongoing discussions. Cheers, Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org >>> >>> - >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >
Re: Question about jar files in svn.
I am not an expert, we only graduated a year ago. But I think there are two rules in here: 1) Source archive must not contain compiled source code that is part of the product's functionality. There is leeway on compiled source code processed during testing. I think the board may pull your release off the distribution server if they find out you have not followed this rule. 2) Your distribution point for the release must be from the distribution server AND its mirrors (and I think, Maven Repos). I'm pretty sure you will be required to rewrite website and any other public information that tells folks anything else. While I think the rest is just "guidance", IIRC from our incubator mentors and various email threads, the goal of managing information in SVN/Git repos is to enable folks who do pull stuff from those repos to understand the IP ownership of the files and also know that the stuff isn't a trojan horse containing viruses. As PMC members we have a responsibility to the ASF to make sure we don't make mistakes there, so common practices like a "deps" folder help eliminate mistakes. I think for Apache Flex, we don't store any compiled code in the main repos, if anywhere. I've been told that for some projects, making a release is as simple as zipping an "svn export", so you might actually save time by not having binaries in the repo. -Alex On 12/20/13 8:49 AM, "Greg Trasuk" wrote: > >Thanks everyone for the input. To summarize, it appears that the >consensus argument is: > >- Jar files are not prohibited by policy in project repositories (svn), >although they may not make a lot of sense. >- Source distributions must not distribute executable code in binary >form. i.e. Don¹t ship dependency jars in the source archive. However it >may be acceptable to include things like jar files that are processed >during testing (sample archives, for instance). >- The project repositories are not generally considered ³distributions², >but we need to be a little careful to avoid users¹ confusion on this >point. > >And just to be clear, I take this as valuable input from from the experts >at Incubator, not a ruling. Obviously, the River PMC makes decisions for >River, and Incubator bears no responsibility for anything we might get >wrong. > >Cheers, > >Greg Trasuk >PMC Chair, Apache River. > > >- >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: [VOTE] Graduation of Apache Allura from the Incubator
Since we're still piling on, I just went to https://forge-allura.apache.org/p/allura/ and was pretty sure I had been redirected to SourceForge. It look and feel of that page looks like all of the other SourceForge projects like the Open@Adobe sites I have visited. I would think that: 1) Apache wouldn't want to have SourceForge branding on Apache infrastructure 2) SourceForge wouldn't want Apache to have SourceForge branding on Apache infrastructure. Are folks sure this is ok? -Alex On 3/17/14 9:09 AM, "sebb" wrote: >On 17 March 2014 15:17, Cory Johns wrote: >> On Mon, Mar 17, 2014 at 6:58 AM, sebb wrote: >> >>> On 15 March 2014 01:23, Justin Mclean wrote: >>> > >>> > While it's clear in the text and from the domain that the project is >>>an >>> ASF one, the subtitles "Forge software for hosting software projects" >>>and >>> "Brought to you by: brondsem, masterbunnyfu, rbowen, vansteenburgh" and >>> lack of links back to the ASF don't immediately give that impression. >>> >>> That's a good point. >>> >>> The board decided a long time ago that @author tags were deprecated in >>> code; partly because they get out of date, but mainly because the ASF >>> is a community, and code is a co-operative effort. >>> >>> Seems to me the "Brought to you" sentence has similar problems, and >>> should be removed. >> >> >> Well, I should note that the "Brought to you by" line is actually >> automatically generated from the project permissions, so there is little >> chance of it getting out of date. > >What about when people move on from Allura and no longer have permissions? >That does not necessarily mean that their contribution to the project >is no longer important. >Even if their code has been entirely replaced by later changes, they >still contributed to the software. > >> That said, it will be more useful as we >> move more of the Allura work (specifically, ticket activity) over from >>the >> old SourceForge location to the Apache hosted Allura instance, as is the >> plan. > >Same issue; the ASF is about community-developed code, not individual >coders. >Individuals come and go; the ASF hopeully will outlast us all! > >> >>> >>> >> Also I think (almost?) all other TLPs include the ASF feather which >>> links back to the main ASF page. >>> >>> >> I have updated the page at https://forge-allura.apache.org/p/allura/ to >> include the ASF feather logo which links to >> http://www.apache.org/foundation/ > >The ASF feather is normally present in the header, not just the home page. >Is it possible to add it there? > >> >>> > It also quite hard for someone outside the project to see what is >>> happing on the mailing list due to the large amount at allure ticket >>> emails. Have you consider having a separate issues list? >>> >>> +1 >> >> >> This has been raised before and some things have been done to improve >>the >> tracker notifications on the mailing list (combining status change and >> comment notifications, fixing threading, etc) and it was decided at the >> time that it was reasonable to continue to include that traffic (with >> improvements) on the list. However, I believe the possibility of >>splitting >> it in the future was left open, should anyone continue to feel it was a >> problem. >> >> Still, this doesn't seem to me like something that should block >>graduation, >> as the tracker communications are indeed related to Allura development. > >Agreed the destination of tracker notifications is not a blocker to >graduation. >But could perhaps become a blocker to community growth, so needs to be >monitored. > >- >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: [VOTE] Graduation of Apache Allura from the Incubator
I'm not a branding expert. Has the Apache VP of Branding approved the look? You are correct that the word SourceForge is not on the site, but I thought branding included colors, icons, and layout and the goal is to prevent confusion, and I was definitely confused, but it could just be me. There are several Adobe links that take you to SourceForge so maybe I've experienced that more than others. -Alex On 3/17/14 9:53 AM, "Cory Johns" wrote: >Alex, > >The project is Allura, which does power the developer tools at >SourceForge, >and we're using an Allura instance on an Apache VM to "self-host" the >project. Since Allura is a project management platform, in the interests >of "eating our own dogfood," we obviously want to continue to use Allura >to >manage the Allura project (and eventually open it up for other Apache >projects to use as well). > >There shouldn't be any SourceForge branding or references on the Apache >Allura instance, aside from the overall look and feel of the platform >being >similar, since it is in fact the same platform (though SourceForge does >theme Allura to some degree, for example in the tools menu). > > >On Mon, Mar 17, 2014 at 12:23 PM, Alex Harui wrote: > >> Since we're still piling on, I just went to >> https://forge-allura.apache.org/p/allura/ >> and was pretty sure I had been redirected to SourceForge. It look and >> feel of that page looks like all of the other SourceForge projects like >> the Open@Adobe sites I have visited. I would think that: >> >> >> 1) Apache wouldn't want to have SourceForge branding on Apache >> infrastructure >> 2) SourceForge wouldn't want Apache to have SourceForge branding on >>Apache >> infrastructure. >> >> Are folks sure this is ok? >> >> -Alex >> >> On 3/17/14 9:09 AM, "sebb" wrote: >> >> >On 17 March 2014 15:17, Cory Johns wrote: >> >> On Mon, Mar 17, 2014 at 6:58 AM, sebb wrote: >> >> >> >>> On 15 March 2014 01:23, Justin Mclean >> wrote: >> >>> > >> >>> > While it's clear in the text and from the domain that the project >>is >> >>>an >> >>> ASF one, the subtitles "Forge software for hosting software >>projects" >> >>>and >> >>> "Brought to you by: brondsem, masterbunnyfu, rbowen, vansteenburgh" >>and >> >>> lack of links back to the ASF don't immediately give that >>impression. >> >>> >> >>> That's a good point. >> >>> >> >>> The board decided a long time ago that @author tags were deprecated >>in >> >>> code; partly because they get out of date, but mainly because the >>ASF >> >>> is a community, and code is a co-operative effort. >> >>> >> >>> Seems to me the "Brought to you" sentence has similar problems, and >> >>> should be removed. >> >> >> >> >> >> Well, I should note that the "Brought to you by" line is actually >> >> automatically generated from the project permissions, so there is >>little >> >> chance of it getting out of date. >> > >> >What about when people move on from Allura and no longer have >>permissions? >> >That does not necessarily mean that their contribution to the project >> >is no longer important. >> >Even if their code has been entirely replaced by later changes, they >> >still contributed to the software. >> > >> >> That said, it will be more useful as we >> >> move more of the Allura work (specifically, ticket activity) over >>from >> >>the >> >> old SourceForge location to the Apache hosted Allura instance, as is >>the >> >> plan. >> > >> >Same issue; the ASF is about community-developed code, not individual >> >coders. >> >Individuals come and go; the ASF hopeully will outlast us all! >> > >> >> >> >>> >> >>> >> >> Also I think (almost?) all other TLPs include the ASF feather which >> >>> links back to the main ASF page. >> >>> >> >>> >> >> I have updated the page at https://forge-allura.apache.org/p/allura/ >>to >> >> include the ASF feather logo which links to >> >> http://www.apache.org/foundation/ >> > >> >The ASF feather is normally present in the header, not ju
Re: Process question on release votes
I asked this same question not too long ago. The answer I got back was that the PMC voters would have to vote -1 in order to execute their duties as stewards of licenses and IP. Thus folks are not concerned that some core of folks who don't care could somehow get the votes for such a bad release. That's a little too trusting for me, but I'm relatively new hereŠ -Alex On 3/17/14 10:10 AM, "John D. Ament" wrote: >Hi all, > >While not specifically incubator related, was wondering if someone at >the incubator may provide me some insight. > >Right now, release votes cannot be veto'd. This seems like an >oversight IMHO. If a release candidate is visibly wrong (e.g. bad >licenses, or something else), surely the release candidate can be >veto'd no? > >John > >- >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: [VOTE] Graduation of Apache Allura from the Incubator
On 3/17/14 1:30 PM, "Rich Bowen" wrote: > >On 03/17/2014 01:05 PM, Alex Harui wrote: >> I'm not a branding expert. Has the Apache VP of Branding approved the >> look? You are correct that the word SourceForge is not on the site, >>but I >> thought branding included colors, icons, and layout and the goal is to >> prevent confusion, and I was definitely confused, but it could just be >>me. >> There are several Adobe links that take you to SourceForge so maybe >>I've >> experienced that more than others. >> >> -Alex >Sourceforge is the largest and most visible user of Apache Allura >(incubating). It's not the Allura looks like SourceForge. It's that >SourceForge looks like Allura. If our VP of Branding is ok with it, I can't argue. But for me, the first impression I get is that Apache is hosting this project at SourceForge. Yes, the word "SourceForge" doesn't actually exist on that page, but the colors and layout are as significant to me as the colors and layout of any major department store. This may be because most of my visits to SourceForge are for Adobe projects now hosted on SourceForge like this one: https://sourceforge.net/adobe/flexsdk/wiki/About/ -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Flex IP Clearance
Despite having the best mentors one could hope for, it appears the Apache Flex PMC missed one thing, which is that all SGAs needed to go through the IP Clearance process. We did review the IP before it went into the repos, but we did not fill out forms and get approval from Incubator. Adobe has made several donations. All but one is already in a repo. And Digital Primates made another which is also in a repo. It appears that the Digital Primates donation may have some file header and copyright issues that need to be sorted out, which prompted a question on legal-discuss and the discovery that we had not followed the clearance process completely. Should we now retroactively submit the IP Clearance forms? Or are there other steps we need to take first? Thanks, -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Where does copyright information go for a binary distribution?
Hi James, Welcome to Apache. I wish I could help more, but I mainly wanted to thank you for going through all of this effort to get these files right. I'm learning a lot from this thread, and I am as confused about the right answer as you are. But here's my guess: You are going to create a very long LICENSE file. It will have several copies of the BSD license because you have several BSD dependencies. For each BSD dependency, copy the BSD license from that dependency's site. It should have the copyright notice as part of the license. The same holds true for MIT license but I think you only have one MIT licensed dependency, but make sure you grab the license from the provider's site which should have the copyright notice in it. I don't think you want to put the "canonical" BSD and MIT licenses in the LICENSE file. Regarding the NOTICE file, I don't see any dependencies in your list that require attribution in a way that requires more than what you are putting in the NOTICE file. The BSD required attribution is satisfied by copying the full content of the provider's version of the BSD license with its copyright into the LICENSE file. Any source code donated from outside Apache has an owner. That owner may want their copyright in the NOTICE file. They have the option of not having their copyright anywhere in the source or NOTICE. In theory, that owner helped you or gave you permission to replace their old headers on those source files with Apache headers. And now, we'll see if I passed the testŠ -Alex On 3/26/14 6:06 PM, "James Taylor" wrote: >The copyright for the bits we're bundling. See the LICENSE file I included >at the end of my email. For example: > >Guava, version 12.0.1, http://code.google.com/p/guava-libraries/ >Copyright 2008 Google Inc. > >Is that the correct way to include the Copyright? Or is this not required? > >Also, how do I know if something is a "required attributions"? > > >On Wed, Mar 26, 2014 at 6:02 PM, sebb wrote: > >> On 27 March 2014 00:52, James Taylor wrote: >> > Where does the copyright information go in our case? >> >> What copyright information? >> Where was it originally? >> >> > >> > On Wed, Mar 26, 2014 at 5:48 PM, sebb wrote: >> > >> >> On 26 March 2014 23:55, James Taylor wrote: >> >> > Hello, >> >> > I'm getting a release ready for Apache Phoenix (incubating) and >>have a >> >> > question about where copyright information should go for our binary >> >> > distribution. It seems that there's quite a bit of variation, as >>all >> >> > projects are different. So I'll describe our binary distribution, >>and >> >> > perhaps others who have a similar situation can learn from this. >> >> > >> >> > Our binary distribution bundles numerous modules with the following >> >> > licenses: >> >> > 1) Apache 2 licensed bits whose home is the ASF >> >> > 2) Apache 2 licensed bits whose home is not the ASF >> >> > 3) BSD Clause 3 licensed bits >> >> > 4) BSD 2-Clause licensed bits >> >> > 5) MIT licensed bits >> >> > >> >> > We bundle all these bits together into a single jar, so the >>original >> >> NOTICE >> >> > from these bundled modules is no longer present. >> >> > >> >> > Is the follow the correct way to do this? >> >> > a) Create a LICENSE file that includes the Apache 2 license text >> >> >> >> +1 >> >> >> >> > b) Since all of the bits we bundle have "permissive" licenses, we >>do >> not >> >> > include anything extra in our NOTICE file. It'll be the bare >>minimum >> as >> >> > outlined here: >>http://www.apache.org/dev/licensing-howto.html#simple >> >> >> >> Not necessarily, that depends on what is present in the >>NOTICE/LICENSE >> >> files that are included in the bundled jars. >> >> >> >> NOTICE files in particular must be examined to see if they contain >> >> attributions that apply to the bits you are bundling. >> >> In which case the attributions must be carried forward into the new >> NOTICE >> >> file >> >> >> >> This is all described here: >> >> >> >> http://www.apache.org/dev/licensing-howto.html#alv2-dep (et seq.) >> >> >> >> > c) Instead, we append to our LICENSE file the following for each >> module >> >> > that we bundle (including transitive dependencies): >> >> >i) the copyright information for the module >> >> >ii) a link to the license text >> >> >> >> LICENSE and NOTICE are not alternates. >> >> >> >> LICENSE files have to contain licenses/pointers for ALL bundled bits. >> >> >> >> NOTICE files have to contain required attributions only. >> >> >> >> > Below is an example (minus the standard Apache 2 license). >> >> > >> >> > Please let me know if we're doing this correctly. >> >> > >> >> > Thanks, >> >> > James >> >> > - >> >> > >> >> > >> >> > The Apache License, Version 2.0, also applies to the following >>bundled >> >> > libraries: >> >> > >> >> > JAnsi, version 1.11, http://jansi.fusesource.org/ >> >> > Copyright (c) 2009-2013 FuseSource, Corp >> >> > >> >> > HawtJNI, version 1.8, http://fusesource.co
Nightly Builds from non-ASF Servers
The Apache Flex project currently uses builds.a.o and Jenkins to create nightly builds. We are looking into creating a relatively-complex custom CI setup on external servers with lots of different browsers involved in automated testing of the nightly builds. One of our PMC members wants to know if there are any ASF restrictions on serving nightly-builds from non-ASF servers. Thanks, -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[IP CLEARANCE] [VOTE] Apache Flex BlazeDS Donation from Adobe
Apache Flex received the BlazeDS code base from Adobe. The IP Clearance document will eventually show up here when SVN pub sub comes back up. https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearanc e/flex-blazeds.xml Eager folks can probably see the copy in SVN or CMS. Please vote to approve this contribution. Lazy consensus applies. If no -1 votes are cast within the next 72 hours, the vote passes. Thanks, -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[IP CLEARANCE] [VOTE] Apache Flex-related Donation from Adobe
Apache Flex received a donation of a collection of Flex-related website and source code assets from Adobe Systems Inc. More details below. The IP Clearance document will eventually show up here when SVN pub sub comes back up. https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearanc e/flex-adc-pmd-squiggly-fdb-tdf.xml Eager folks can probably see the copy in SVN or CMS. Please vote to approve this contribution. Lazy consensus applies. If no -1 votes are cast within the next 72 hours, the vote passes. Thanks, -Alex In the donation is: 1. Several Flex articles from the ADC web-site. 2. An updated version of the FDB debugger that contains support for ActionScript Workers 3. The FlexPMD source code 4. The Mobile Trader demo application 5. The specification for the MXML language 6. An XML merging utility source code from the Flex QA team. 7. The Squiggly spell-checker source code 8. The Tour De Flex application source code 9. The source code for a prototype of a code coverage utility that I wrote. Here are links to the ADC articles: http://www.adobe.com/devnet/flex/videotraining.html http://www.adobe.com/devnet/flex/testdrive.html http://www.adobe.com/devnet/flex/testdrivemobile.html http://www.adobe.com/devnet/flex/articles/mobile-development-flex-flashbuil der.html http://www.adobe.com/devnet/flex/articles/flex3and4_differences.html http://www.adobe.com/devnet/flex/articles/itemrenderers_pt1.html http://www.adobe.com/devnet/flex/articles/employee-directory-android-flex.h tml http://www.adobe.com/devnet/flex/articles/mobile-skinning-part1.html http://www.adobe.com/devnet/flex/articles/flex-mobile-performance-checklist .html http://www.adobe.com/devnet/flex/articles/flashbuilder_blazeds.html http://www.adobe.com/devnet/flex/articles/spark_layouts.html http://www.adobe.com/devnet/flex/articles/flex-mobile-development-tips-tric ks-pt4.html http://www.adobe.com/devnet/flex/articles/flex4_skinning.html http://www.adobe.com/devnet/flex/articles/flex4_viewport_scrolling.html http://www.adobe.com/devnet/flex/articles/flex4_effects_pt1.html FlexPMD is currently on Open@Adobe here: http://sourceforge.net/adobe/flexpmd/home/Home/ The Mobile Trader demo application is described here: http://www.adobe.com/devnet/flex/samples/mobile-trader-application.html And here: http://coenraets.org/blog/2011/03/flex-on-the-ipad/ The XML merge utility is a small set of files that should have been in the BlazeDS donation Squiggly is described here: http://labs.adobe.com/technologies/squiggly/ Tour De Flex is described here: http://www.adobe.com/devnet/flex/tourdeflex.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP CLEARANCE] [VOTE] Apache Flex BlazeDS Donation from Adobe
Thanks for checking. Should be published now. -Alex On 4/21/14 6:27 PM, "Jake Farrell" wrote: >Hey Justin >Alex has not published (or attached) anything to that review so there is >nothing public to be viewable yet > >-Jake > > >On Mon, Apr 21, 2014 at 9:04 PM, Justin Mclean >wrote: > >> Hi, >> >> Looks like I don't have access to: >> https://reviews.apache.org/r/20506/ >> >> Is the review URL correct/have correct permissions? What's require to >>get >> access to it? >> >> (I can access the other review URL in the other Adobe donation). >> >> Thanks, >> Justin >> - >> 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: [DISCUSS] [IP CLEARANCE] Apache Flex BlazeDS Donation from Adobe
Good catch. Answer's inline. On 4/21/14 10:07 PM, "Justin Mclean" wrote: >Hi, > >Look good to me there's 2000 odd files that are Apache licensed and no >file licensed in another way. There are a few .txt files missing a >licence header but that's probably not an issue. There are however a >couple of files that do probably need to be removed. Can this be done >after this IP clearance process or does it need to be part of this >process? > >The files in question are: >- MyriadWebPro fonts in >./apps/samples/WEB-INF/flex-src/inventory/src/assets/fonts/ This should not have been in the donation. Will remove before checking into repo. >- Nokia phone images in ./apps/samples/images. Did Adobe create these >files or licence them from Nokia? If so would we need permission from >Nokia to use them? These should not have been in the donation. Will remove before checking into repo. >- Binary localhost.keystore in ./qa/apps/qa-manual/WEB-INF/flex Will remove before checking into the repo. >- A couple of class files in ./qa/classes/tools and ./qa/classes/utils. >Do we have (or need) the source code for these? Will remove these as well. The MergeXML.java and related classes are in the other donation. It is one of the reasons why we held up IP Clearance for BlazeDS until now. Thanks, -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] [IP CLEARANCE] Apache Flex-related Donation from Adobe
Also good catch. Answers in-line. On 4/21/14 10:59 PM, "Justin Mclean" wrote: >Hi, > >This donation contains quite a few binary files (pdfs, gif, jpeg, even a >coueple of mp3s) but not unusual give the native of the donation (mostly >technical documentation and examples). > >There a few files which are problematic I think: >- There several testdrive_win.car and testdrive_mac.car files that >contain among other files Adobe Flex 4.1 framework swz's and swfobject.js. Will remove those. >- Adobe Flex framework swz files and playerProductInstall.swf can be >found in several places as well eg >./ADCExport_expanded/devnet/flex/testdrive/testdrive_files/FlexWebTestDriv >e_CF/testdrive_setup/testdrive_setup_JAVA/test/ Rats, I thought I scanned for those. Will remove as well. >- And as much as I would like this to be donated I'm sure it can't be: >./TourDeFlex/src/objects/AIR20/Globalization/srcview/Sample-AIR2-Globaliza >tion/libs/playerglobal.swc Definitely will remove this. >- This file probably contains fonts that need to be licenced: >./flexpmd/flexunit-theme/src/main/resources/fonts/fonts.fla Will remove this as well. >- Looks like Squiggly uses Hunspell (GPL/MLP dual licence) - may need to >double check that none of it licence headers have been replaced with >Apache ones In theory, no Hunspell files are in the donation. Thanks -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT][IP CLEARANCE] [VOTE] Apache Flex BlazeDS Donation from Adobe
No -1 votes were submitted so the code base is cleared for import. Some adjustments were made to the code base as a result of a review of its contents. Thanks -Alex On 4/21/14 10:17 AM, "Alex Harui" wrote: >Apache Flex received the BlazeDS code base from Adobe. > >The IP Clearance document will eventually show up here when SVN pub sub >comes back up. >https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearan >c >e/flex-blazeds.xml > > >Eager folks can probably see the copy in SVN or CMS. > >Please vote to approve this contribution. Lazy consensus applies. If no -1 >votes are cast within the next 72 hours, the vote passes. > > >Thanks, >-Alex > > >- >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
[RESULT][IP CLEARANCE] [VOTE] Apache Flex-related Donation from Adobe
No -1 votes were submitted to the code base is cleared for import. Some adjustments were made to the code base as a result of a review of its contents. Thanks -Alex On 4/21/14 10:22 AM, "Alex Harui" wrote: >Apache Flex received a donation of a collection of Flex-related website >and source code assets from Adobe Systems Inc. > >More details below. > >The IP Clearance document will eventually show up here when SVN pub sub >comes back up. >https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearan >c >e/flex-adc-pmd-squiggly-fdb-tdf.xml > > >Eager folks can probably see the copy in SVN or CMS. > >Please vote to approve this contribution. Lazy consensus applies. If no -1 >votes are cast within the next 72 hours, the vote passes. > >Thanks, > >-Alex > > >In the donation is: > > >1. Several Flex articles from the ADC web-site. >2. An updated version of the FDB debugger that contains support for >ActionScript Workers >3. The FlexPMD source code >4. The Mobile Trader demo application >5. The specification for the MXML language >6. An XML merging utility source code from the Flex QA team. >7. The Squiggly spell-checker source code >8. The Tour De Flex application source code >9. The source code for a prototype of a code coverage utility that I >wrote. > > >Here are links to the ADC articles: >http://www.adobe.com/devnet/flex/videotraining.html > >http://www.adobe.com/devnet/flex/testdrive.html > >http://www.adobe.com/devnet/flex/testdrivemobile.html > >http://www.adobe.com/devnet/flex/articles/mobile-development-flex-flashbui >l >der.html > >http://www.adobe.com/devnet/flex/articles/flex3and4_differences.html > >http://www.adobe.com/devnet/flex/articles/itemrenderers_pt1.html > >http://www.adobe.com/devnet/flex/articles/employee-directory-android-flex. >h >tml > >http://www.adobe.com/devnet/flex/articles/mobile-skinning-part1.html > >http://www.adobe.com/devnet/flex/articles/flex-mobile-performance-checklis >t >.html > >http://www.adobe.com/devnet/flex/articles/flashbuilder_blazeds.html > >http://www.adobe.com/devnet/flex/articles/spark_layouts.html > >http://www.adobe.com/devnet/flex/articles/flex-mobile-development-tips-tri >c >ks-pt4.html > >http://www.adobe.com/devnet/flex/articles/flex4_skinning.html > >http://www.adobe.com/devnet/flex/articles/flex4_viewport_scrolling.html > >http://www.adobe.com/devnet/flex/articles/flex4_effects_pt1.html > >FlexPMD is currently on Open@Adobe here: > >http://sourceforge.net/adobe/flexpmd/home/Home/ > >The Mobile Trader demo application is described here: >http://www.adobe.com/devnet/flex/samples/mobile-trader-application.html > >And here: http://coenraets.org/blog/2011/03/flex-on-the-ipad/ > >The XML merge utility is a small set of files that should have been in the >BlazeDS donation > >Squiggly is described here: > >http://labs.adobe.com/technologies/squiggly/ > >Tour De Flex is described here: > >http://www.adobe.com/devnet/flex/tourdeflex.html > > > > > >- >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: Reviewing license / notice and bundled software
In the "Bundling an AL Font" thread on legal-discuss, sebb said: "It is useful to mention all 3rd party inclusions in the LICENSE file, including ones under AL2.0: - Makes it much easier for the consumer to ensure that the code uses a license with which they are comfortable. - it helps the ASF project to ensure that all external inclusions are accounted for. Yes, it means updating the file every time an external version is updated, but the license still has to be checked in case it has changed." Not sure it can be mandated though. -Alex On 7/17/14 5:53 PM, "Justin Mclean" wrote: >Hi, > >Lets take for instance slider as they have just put up an RC for voting. > >Slider bundles a few things and may have some Apache Licensed software >bundled. Can you tell easily what those bits are? And if so what >versions? Source headers here are no help as all Apache source headers >are the same. While no changes to LICENSE would be required for Apache >bundled software, there may be missing items from the NOTICE file if you >bundled software also has NOTICE files. BTW I don't think there is any >issue with the RC in this case but it's hard to determine without a list >of what has been bundled. > >Thanks, >Justin >- >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
[IP CLEARANCE] Radii8 for Apache Flex
Apache Flex received the Radii8 code base from Judah Frangipane. http://incubator.apache.org/ip-clearance/flex-radii8.html Please vote to approve this contribution. Lazy consensus applies. If no -1 votes are cast within the next 72 hours, the vote passes. Thanks, -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP CLEARANCE] Radii8 for Apache Flex
Good questions, I have asked the grantor about that one source file.
Maybe incubator folks with more experience can help answer these questions.
1) Regarding the package matching the grant. The code base granted was
not going to pass IP clearance. It needed headers and a proper LICENSE
and NOTICE. I was given authority by the grantor to update headers. I
took the granted software, added headers, threw out a few files (with the
grantor's permission) I found while doing so that would not pass IP
clearance and presented that package for review. Folks with more
experience: is this a correct procedure or should I have proceeded some
other way?
2) Regarding icons. The icons in question are common and trivial (">" and
">>" for 'more' and 'lots more', down arrow, etc). My scanners did not
pick up any copyright notices in those files. Folks with more experience:
Does the grantor need to provide proof-positive in order to get clearance,
or do we trust the provenance if there is no evidence to the contrary?
3) Is there a restriction agains PSD files? We have some checked into SVN
for our website already.
4) Is the grantor of a code base required to do pre-donation scrubbing in
public? Every Adobe donation I worked on was scrubbed internally then a
grant was submitted and a package submitted for IP clearance. I would
think many grantors would not want to have the scrub public as early
scrubs could end up naming names or discovering potentially embarrassing
mis-use of IP.
Thanks,
-Alex
On 8/21/14 8:43 PM, "Justin Mclean" wrote:
>Hi,
>
>Mostly good but -1 (binding) as it still needs a little more clean up
>
>First off the code in bundle for IP clearance doesn't match what is
>recorded in the grant. The grant specifies this [1]. Not sure if this is
>a major issue or not but I expected them to be the same.
>
>While the Github repo only has one user, some of the code varies in style
>which may indicate that the code came from multiple people/sources and is
>of unknown licence. For example concatenateMetaDataXMLItems in
>ClasSUtils.as in com.flexcapacitor.utils. A quick google search turns up
>the same code here [2] which a) predates the code being in the github
>repo and may of been where the code may of came from. Of course not easy
>to tell but this at least needs confirmation that this is not an issue.
>I notice that this file may incorrectly have an Apache licence header but
>they depends on the license of the code in question. In the same file I
>also see isSimple which looks like it was copied from the Flex SDK (not
>an issue just an observation) but could also indicate that source in this
>file has come from various different places. I only checked a couple of
>methods in that file and only a few likely files so there may be other
>files/methods with similar issues in the donation.
>
>Solution is to get the donor to double check that all code was written by
>then and/or has a compatible licence, in particular when the style is
>different.
>
>There are also possibly some icons than may have non compatatble licences
>in there. I'm not aware of the original license of the icons but as most
>icons have been blacked out I assume that it was a non compatible one.
>
>Here are some of the non blacked out ones. I may of missed some.
>
>./Radii8Remote/src/assets/icons/down_disclosure.png
>./Radii8Remote/src/assets/icons/down_disclosure2.png
>./Radii8LibraryAssets/src/assets/icons/effects/divider_vertical.png
>./Radii8Remote/src/assets/icons/down_disclosure2.png
>./Radii8Remote/src/assets/icons/more.png
>./Radii8Remote/src/assets/icons/more2.png
>./Radii8LibraryAssets/src/assets/icons/effects/playhead_light.png
>./Radii8LibraryAssets/src/assets/icons/effects/playhead.png
>
>Easy solution is to black out these files - assuming they have an
>incompatible licence that is.
>
>A minor issue may exist with the binary file PortraitMode.psd. Does this
>need to be a photoshop file or can it be converted to a different format?
>If not are we OK with photoshop files in the repo?
>
>I'll also note that these issues could of been fixed before bringing it
>to the incubator if the Flex PMC rather than a single person had been
>involved in grant process.
>
>Thanks,
>Justin
>
>1 https://github.com/monkeypunch3/Radii8/tree/ApacheFlexRelease1.0
>2. http://pastebin.com/b5zPNGWF
>
>
>-
>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: [IP CLEARANCE] Radii8 for Apache Flex
On 8/22/14 12:59 PM, "jan i" wrote:
>
>In my opinion you did the right thing, but I could not find the process
>you
>ran through documented.
>
>I would have liked to see a txt file, documenting
>1) that you changed the files, of course with permission
>2) which files you removed.
>
>Having done that, would have avoided questions, and it was documented for
>the future.
OK, I will add that to the next review request after we resolve the
question about the one source file and the icons. Do you have any
experience or opinion to offer on point #2 (below).
>
>
>> 2) Regarding icons. The icons in question are common and trivial (">"
>>and
>> ">>" for 'more' and 'lots more', down arrow, etc). My scanners did not
>> pick up any copyright notices in those files. Folks with more
>>experience:
>> Does the grantor need to provide proof-positive in order to get
>>clearance,
>> or do we trust the provenance if there is no evidence to the contrary?
>>
>> 3) Is there a restriction agains PSD files? We have some checked into
>>SVN
>> for our website already.
>>
>
>Remark there is a big difference between having content (in general) on a
>web page, or part of a release
I saw your comment in a prior post about redistribution restrictions. I
will investigate.
Thanks,
-Alex
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Websites, WebApps, and Release Policy
Hi Incubator Folks, My understanding is that changes to a website like flex.a.o don't require a release vote, even though one could consider and html file pushed to the site as publishing source beyond the group that owns it. But what about web apps? Apache Flex is designed for creating web apps made from source code that is compiled into a SWF. Today, Apache Flex announced the release of Tour De Flex. The source code is in one of our git repos, the source package is up on dist.apache.org, and a compiled version of the source is on flex.a.o here: http://flex.apache.org/tourdeflex/explorer.html Users are playing with the app at that link and reporting bugs. I'm wondering: can we modify the source with a bug fix and post the modified source and compiled results on flex.a.o without a release vote? Tour De Flex is potentially different from most web apps because its job is to show you the source code behind the scenes. Most web apps can be published without their source. Also, can we make other modifications? One user found that a link was broken and we fixed it by copying an asset to where the source said the link was. Therefore what is on flex.a.o right now is no longer the compiled results of the source. Thanks, -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[CANCEL][IP CLEARANCE] Radii8 for Apache Flex
Cancelling. Preparing new review based on feedback on this thread.
New lazy vote thread out soon.
On 8/22/14 4:28 PM, "Justin Mclean" wrote:
>Hi
>
> 2) Regarding icons. The icons in question are common and trivial
>(">"
> and ">>" for 'more' and 'lots more', down arrow, etc).
>
>Give that the origin of the original icons are unknown and presumedly the
>non blacked out icons in question came from the same place (although that
>is also unknown). If so they would have the same licence and we would
>need to abide by the terms of that license.
>
>A simple question do we know where they come from?
>
>Thanks,
>Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
[IP CLEARANCE] Radii8 for Apache Flex (2nd pass)
I have received more information from the grantor and updated the review package. http://incubator.apache.org/ip-clearance/flex-radii8.html The review URL is the same. I removed the old zip of sources and replaced it with the updated package. The updated package has a "2" on the end of its file name in case you forget to delete the first package I put up for review. Changes in this package: 1) added ipclearance.txt to describe changes made to the granted software in preparation for IP Clearance 2) removed PSD files with the grantor's permission based on concerns from Jan I 3) replaced four icons with blacked out versions provided by the grantor The grantor claims ownership/authorship of the other 3 icons pointed out by Justin, namely: ./Radii8LibraryAssets/src/assets/icons/effects/divider_vertical.png ./Radii8LibraryAssets/src/assets/icons/effects/playhead_light.png ./Radii8LibraryAssets/src/assets/icons/effects/playhead.png The grantor claims ownership of the concatenateMetaDataXMLItems in ClasSUtils.as that was pointed out by Justin. Please vote to approve this contribution. Lazy consensus applies. If no -1 votes are cast within the next 72 hours, the vote passes. Thanks, -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Websites, WebApps, and Release Policy
Hi Justin, Are you addressing me personally or Roman or the incubator in general? -Alex On 8/25/14 3:21 PM, "Justin Mclean" wrote: >Hi, > >The whole point point of the release process is to: >1. Have legal overview by the PMC >2. Engage and involve the community > >Why would we want to avoid either? As [1] says "Under no circumstances >are unapproved builds a substitute for releases. If this policy seems >inconvenient, then release more often." > >I'd also note also at [1]: >"Deviations from this policy may have an adverse effect on the legal >shield's effectiveness, or the insurance premiums Apache pays to protect >officers and directors, so are strongly discouraged without prior, >explicit board approval." > >Thanks, >Justin > >1. http://www.apache.org/dev/release.html >- >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
[RESULT][IP CLEARANCE] Radii8 for Apache Flex (2nd pass)
72 hours passed without any objections. The code base has been cleared for Apache Flex repos. Thanks, -Alex On 8/25/14 2:29 PM, "Alex Harui" wrote: >I have received more information from the grantor and updated the review >package. > >http://incubator.apache.org/ip-clearance/flex-radii8.html > >The review URL is the same. I removed the old zip of sources and replaced >it with the updated package. The updated package has a "2" on the end of >its file name in case you forget to delete the first package I put up for >review. > >Changes in this package: >1) added ipclearance.txt to describe changes made to the granted software >in preparation for IP Clearance >2) removed PSD files with the grantor's permission based on concerns from >Jan I >3) replaced four icons with blacked out versions provided by the grantor > >The grantor claims ownership/authorship of the other 3 icons pointed out >by Justin, namely: >./Radii8LibraryAssets/src/assets/icons/effects/divider_vertical.png >./Radii8LibraryAssets/src/assets/icons/effects/playhead_light.png >./Radii8LibraryAssets/src/assets/icons/effects/playhead.png > >The grantor claims ownership of the concatenateMetaDataXMLItems in >ClasSUtils.as that was pointed out by Justin. > >Please vote to approve this contribution. Lazy consensus applies. If no -1 >votes are cast within the next 72 hours, the vote passes. > > >Thanks, >-Alex > > >- >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
Code Donations and Committer Righs
I'd like to know: if a code base is donated to Apache under a Software Grant, do most projects grant committer rights to the code authors at the same time or do most projects require that the donors submit patches as other non-committers normally do? Thanks, -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Committer Voting and Vetos
In a past discussion about by-laws, some folks were adamant that voting for new committer and PMC members be consensus votes so a single person can block the adding of a candidate. Do any projects use some form of majority voting for new committers? What are the reasons for allowing vetoes? Thanks, -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Code Donations and Committer Righs
Hi Ross, Yes, I am asking here because of lack of consensus in the Flex project. In this particular scenario the Flex TLP has received a donation from non-committers. I know one of our mentors mentioned that he was given committer rights to different project for bringing in a code base after that project got started. Most of the Flex PMC seems to agree, but I was looking for data from other projects to support this. -Alex On 9/26/14 9:00 AM, "Ross Gardler (MS OPEN TECH)" wrote: >It really depends on the project. I don't think there are enough cases of >code coming into an existing project via SGA to be able to say "most >projects". Fact is most have never faced this issue. I could give you my >personal opinion but I'm pretty sure someone on this list would have a >different opinion. This is something best discussed with the receiving >project and brought here if there is a lack of consensus. > >If the code is coming in as a new project then the normal incubating >proposal process sees a list of initial committers - in other words for a >new project then it would be expected that all original contributors >(that wanted to come along) would be given commit rights. Though whether >that is the case or not depends on the proposers/champion/mentor. > >Ross > >Microsoft Open Technologies, Inc. >A subsidiary of Microsoft Corporation >MS Open Tech is hiring! Ask me for details if anyone you know is >interested (http://aka.ms/msopentechjobs) > >-Original Message- >From: Alex Harui [mailto:aha...@adobe.com] >Sent: Thursday, September 25, 2014 8:57 PM >To: general@incubator.apache.org >Subject: Code Donations and Committer Righs > >I'd like to know: if a code base is donated to Apache under a Software >Grant, do most projects grant committer rights to the code authors at the >same time or do most projects require that the donors submit patches as >other non-committers normally do? > >Thanks, >-Alex > > >- >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: Code Donations and Committer Righs
For more context, there has been only one prior donation from non-committers to Flex and that was completed only 26 days ago. All but one other donation has come from Adobe and are parts of existing Flex products that Adobe provided before the transition to Apache. -Alex On 9/28/14 9:51 AM, "Justin Mclean" wrote: >Hi, > >For some context the Flex project has has several donations that have >ended up get little or no involvement from the community or the people >who donated them after donation. For most projects donations (once a >project is top level) are reasonably rare and from what I can see most >donations come for people already involved in the community. If someone >is involved it should take almost no time for them be offered committer >ship after donation, but with automatically awarding committership to >people you don't really know if they will continue to be involved or not. >For some projects automatic committership may work, but given Flex's >history with donations it's probably not suitable choice of action. > >Thanks, >Justin >- >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: Code Donations and Committer Righs
>I¹m also not sure what history you mean. The only donation that I know of >that there was no follow through was the Swiz donation. Also for context: The Swiz folks never submitted the software grant so technically it hasn't been donated. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Convenience Binary Policy
Hi, I’m wondering whether modifications to the set of bundled jars in a convenience binary package can be made after release without voting. And if not, I’m looking for any other quick-fix ideas for the following scenario. Flex has many different release packages. One is an SDK called FlexJS 0.0.2. Another is an Installer application. Most folks use the installer to download Flex binary packages, unpack them and execute a script in the package to download any dependencies. The FlexJS install script was working great until about two weeks ago, when the code the installer uses to fetch a jar from SourceForge stopped working. It wasn’t a major problem because FlexJS is in ‘alpha’ stage and only about 5 folks download it per day and they can go get the binary package and use Ant to run the script and it will succeed. However, last night, a community member realized that he was giving a talk on FlexJS on Tuesday morning which could cause a rise in the number of folks who would try to use the installer and subsequently fail. Any new vote plus mirror propagation time will not be in time for the talk. A workaround I tested was to add the jar from SourceForge to the binary package. No other files are touched, although I suppose I should update LICENSE and NOTICE. This works because the install script sees the jar and skips trying to download it. I can take this modified binary package, host it somewhere, change the installer’s config.xml that it fetches from flex.a.o so that it will pick up this package instead of the one on dist (actually, the mirrors) and the FlexJS 0.0.2 install will start working again. I know we can’t go messing around with source packages without a vote, but what about binary packages? Is it against policy to do something like this, and if so, can exceptions be made? Thanks, -Alex
Re: Convenience Binary Policy
On 10/20/14, 4:13 PM, "Ted Dunning" wrote: >On Mon, Oct 20, 2014 at 3:08 PM, Alex Harui wrote: > >> I know we can’t go messing around with source packages without a vote, >>but >> what about binary packages? Is it against policy to do something like >> this, and if so, can exceptions be made? >> > >I may not have followed this quite correctly, here is what I understood of >the situation as you described it: > >1) there is a bug in the FlexJS distro, considered low priority due to >sparse use > >2) you needed a quickly corrected binary distribution > >3) you created a correct distribution artifact and put it somewhere >non-Apache > >4) you aren't claiming that the artifact you created is an Apache release >and you are pointing some workshop participants at your release. > >I fail to see any problem whatsoever in what you did. You used Apache >software to create a derived work which you are asking people to use in an >instructional setting. As far as I can tell, the only claim you are >making >is that your artifact is FlexJS with a fix that should be incorporated >upstream before long. > >What's the problem? Well, the use of the Installer sort of implies that folks are getting the same binary kit that was on dist/mirrors. So one of our PMC members is objecting to this plan, even though the net result of what ends up on the user’s disk is the same. We won’t be pointing just the workshop participants at this modified binary, essentially everyone who uses the installer to install FlexJS 0.0.2 will get it. This may not be a fair analogy, but suppose you bundled an external jar in a binary distro and found out much later that the jar was corrupted and needed a quick fix. Would you do what I just did and post a corrected binary somewhere outside Apache and then update your downloads page to point just the binary link there instead of the usual dist/mirrors? For Flex, we don’t need to update our downloads page because the binary on dist/mirrors works if you unpack it yourself and run Ant, so the Installer makes it a bit different. No flex.a.o page is going to point there, but the Installer app you downloaded from flex.a.o will point there. Maybe that’s a better question: are their policies about where and to what the binary links on a project’s download page can point? Can it point outside the ASF to stuff that wasn’t generated at the same time as the source that was voted on? -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Convenience Binary Policy
On 10/20/14, 4:57 PM, "Ted Dunning" wrote: >On Mon, Oct 20, 2014 at 4:49 PM, Justin Mclean >wrote: > >> > 4) you aren't claiming that the artifact you created is an Apache >>release >> > and you are pointing some workshop participants at your release. >> >> My understanding is Alex does want to use this as an official release >>and >> have the officially released Apache Flex installer download and install >>it. We don’t have to do that. The bits on dist/mirrors can stay untouched, and the downloads page won’t change either. The main thing is whether the Installer app can point somewhere else. >> The new binary would be available to everyone / the general public and >>not >> just the people attending the talk. This is true. Anyone using the Installer would get the modified binary. > >No vote, not official. > >If he wants to build his own installer, fine. If it says it is >downloading >an Apache artifact, it should be voted. The Installer has a DropDown list of releases, such as “Apache Flex SDK 4.13.0” and “Apache FlexJS 0.0.2”. What if the entry that points to the modified package says “Apache FlexJS 0.0.2 (unofficial)” or “Unofficial Fix for Apache FlexJS 0.0.2”? But it would be the same Installer, not my own. Or does that get into the “promoting nightly builds” territory even though all the compiled code came from an official release? -Alex
Re: Convenience Binary Policy
On 10/20/14, 5:54 PM, "Ted Dunning" wrote: > >Why not just roll your own installer that has these additional options? > >Then this is the Acme Software Foundation installer and you can do what >you >like. I suppose we could, but it wouldn’t be easily found by folks who arrive at flex.a.o looking for FlexJS. They’ll probably end up using the current Installer and getting an error. I guess you are saying that there is no quick fix of a convenience binary. I guess I’ve been reading things like Marvin/Roy in this thread [1] that says that a binary package isn’t official which made me think we had more flexibility. Here’s the quote from Marvin quoting Roy: An official release by the Apache Software Foundation consists of source code which has been audited by a PMC. Of course it is not possible to audit an entire codebase at each release point, but we achieve that effective result through PMC monitoring of a "commits" list: if the last release was fully reviewed, each delta since then has also been reviewed, and we can demonstrate that the difference between the two releases is the sum of those deltas, then the current release has been reviewed. Binaries combine that carefully audited source code with an opaque build machine, and the result is not audit able. Releasing source is an "act of the foundation". A binary package is an act of the individual who prepared it. The Foundation was not set up to take on the liability associated with binary releases: http://s.apache.org/roy-binary-deps-3 How is that different from any of our other projects? End users don't compile Java. Hell, most developers don't compile Java. We distribute plenty of binaries. We just don't call them SOURCE. The source is what we review. The source is what we bless. If anyone wants to go further than that, they are free to do so as long as they don't call the result an Apache release. It is a binary package, a user convenience, a download hosted by openoffice.org. I don't care. And this from Bertrand [2] To clarify, the ASF only releases source code - votes on releases are not "more" about source, they are *only* about source. What is the piece I’m missing that says we have to vote to update the binary package? -Alex [1] http://mail-archives.apache.org/mod_mbox/incubator-general/201410.mbox/%3cC AAS6=7hmpfr-matbeppepa0vybo6n35yfxkdttnqnmf+6_g...@mail.gmail.com%3e [2] http://mail-archives.apache.org/mod_mbox/incubator-general/201410.mbox/%3cC AEWfVJ=hfp_oc-byyokjm0opm5a_bxa4+yozdvfvrs3ufzy...@mail.gmail.com%3e
Re: Convenience Binary Policy
Sorry, my last response crossed paths with this. We can and will make another release, but no, it was only 24 hours ago that we realized we might get a bump in installs from the talk on Tuesday and only 10 hours since I proved we could workaround the problem with a change to the binary package. No plan involving votes and mirrors would fix the problem in time. So I am looking for reasons why we can/can’t update a binary package in less time than the whole vote + mirrors latency. Thanks, -Alex On 10/20/14, 9:09 PM, "Ross Gardler (MS OPEN TECH)" wrote: >Regardless of whether you can/can't do this (others are commentating, I >won't add to that) - wouldn't it be easier to just build a release and >call a vote. My guess is that you spent more than three days from >identification of the problem to distribution and discussion here. >Remember, if you take the time to make a release nobody can veto it >(although if there are good community reasons to not release you'd be >expected to honor that). > >Ross > >-Original Message- >From: Alex Harui [mailto:aha...@adobe.com] >Sent: Monday, October 20, 2014 4:47 PM >To: general@incubator.apache.org >Subject: Re: Convenience Binary Policy > > > >On 10/20/14, 4:13 PM, "Ted Dunning" wrote: > >>On Mon, Oct 20, 2014 at 3:08 PM, Alex Harui wrote: >> >>> I know we can’t go messing around with source packages without a >>>vote, but what about binary packages? Is it against policy to do >>>something like this, and if so, can exceptions be made? >>> >> >>I may not have followed this quite correctly, here is what I understood >>of the situation as you described it: >> >>1) there is a bug in the FlexJS distro, considered low priority due to >>sparse use >> >>2) you needed a quickly corrected binary distribution >> >>3) you created a correct distribution artifact and put it somewhere >>non-Apache >> >>4) you aren't claiming that the artifact you created is an Apache >>release and you are pointing some workshop participants at your release. >> >>I fail to see any problem whatsoever in what you did. You used Apache >>software to create a derived work which you are asking people to use in >>an instructional setting. As far as I can tell, the only claim you are >>making is that your artifact is FlexJS with a fix that should be >>incorporated upstream before long. >> >>What's the problem? >Well, the use of the Installer sort of implies that folks are getting the >same binary kit that was on dist/mirrors. So one of our PMC members is >objecting to this plan, even though the net result of what ends up on the >user’s disk is the same. We won’t be pointing just the workshop >participants at this modified binary, essentially everyone who uses the >installer to install FlexJS 0.0.2 will get it. > >This may not be a fair analogy, but suppose you bundled an external jar >in a binary distro and found out much later that the jar was corrupted >and needed a quick fix. Would you do what I just did and post a >corrected binary somewhere outside Apache and then update your downloads >page to point just the binary link there instead of the usual >dist/mirrors? For Flex, we don’t need to update our downloads page >because the binary on dist/mirrors works if you unpack it yourself and >run Ant, so the Installer makes it a bit different. No flex.a.o page is >going to point there, but the Installer app you downloaded from flex.a.o >will point there. > >Maybe that’s a better question: are their policies about where and to >what the binary links on a project’s download page can point? Can it >point outside the ASF to stuff that wasn’t generated at the same time as >the source that was voted on? > >-Alex > > > >- >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: Convenience Binary Policy
Let me see if I can tie all of the responses back into one thread. Thanks Ross, for confirming that vote periods can be shorter. However, there still isn’t enough time to get through vote + mirror latency before Tuesday in San Francisco. I think Ted just said I can update the binary package but I have to “label it according to what it is”. I think that implies that it cannot be the binary package for FlexJS 0.0.2, but why not? Is it because it isn’t a true result of running the build script? Or because I should tweak LICENSE and NOTICE in the binary package? Ted also said that I could post a new installer. If I post an installer that only offers to install this modified binary package, none of the installer code needs to change other than where it picks up the list of packages to offer. But that’s a source code change, so isn’t that like advertising a nightly/development build to the public? Or can you offer nightly binary packages, but not nightly source packages? Another option for a modified installer is one that codes around the SourceForge download problem. I’m investigating that now, but that will also be a source code change. Brane said that the Flex Community is used to voting on binary packages, but I don’t think that’s true. We’re just trying to find out if there really is any policy against modification of a binary package. I think our PMC is more concerned about making new visitors to Apache and Flex happy as long as we don’t break any rules. -Alex On 10/20/14, 10:01 PM, "Ross Gardler (MS OPEN TECH)" wrote: > >Ok. Well remember that the release vote period is a guideline. If this is >such a trivial change maybe it would be acceptable to use a shorter vote >period. As long as you have three +1 (meaning three people have verified >the release) you would be good to go, without long debates about policy >and intent ;-) > >Having said that it's always good to clarify things. > >-Original Message- >From: Alex Harui [mailto:aha...@adobe.com] >Sent: Monday, October 20, 2014 9:41 PM >To: general@incubator.apache.org >Subject: Re: Convenience Binary Policy > >Sorry, my last response crossed paths with this. > >We can and will make another release, but no, it was only 24 hours ago >that we realized we might get a bump in installs from the talk on Tuesday >and only 10 hours since I proved we could workaround the problem with a >change to the binary package. No plan involving votes and mirrors would >fix the problem in time. So I am looking for reasons why we can/can’t >update a binary package in less time than the whole vote + mirrors >latency. > >Thanks, >-Alex > >On 10/20/14, 9:09 PM, "Ross Gardler (MS OPEN TECH)" > wrote: > >>Regardless of whether you can/can't do this (others are commentating, I >>won't add to that) - wouldn't it be easier to just build a release and >>call a vote. My guess is that you spent more than three days from >>identification of the problem to distribution and discussion here. >>Remember, if you take the time to make a release nobody can veto it >>(although if there are good community reasons to not release you'd be >>expected to honor that). >> >>Ross >> >>-Original Message- >>From: Alex Harui [mailto:aha...@adobe.com] >>Sent: Monday, October 20, 2014 4:47 PM >>To: general@incubator.apache.org >>Subject: Re: Convenience Binary Policy >> >> >> >>On 10/20/14, 4:13 PM, "Ted Dunning" wrote: >> >>>On Mon, Oct 20, 2014 at 3:08 PM, Alex Harui wrote: >>> >>>> I know we can’t go messing around with source packages without a >>>>vote, but what about binary packages? Is it against policy to do >>>>something like this, and if so, can exceptions be made? >>>> >>> >>>I may not have followed this quite correctly, here is what I >>>understood of the situation as you described it: >>> >>>1) there is a bug in the FlexJS distro, considered low priority due to >>>sparse use >>> >>>2) you needed a quickly corrected binary distribution >>> >>>3) you created a correct distribution artifact and put it somewhere >>>non-Apache >>> >>>4) you aren't claiming that the artifact you created is an Apache >>>release and you are pointing some workshop participants at your release. >>> >>>I fail to see any problem whatsoever in what you did. You used Apache >>>software to create a derived work which you are asking people to use >>>in an instructional setting. As far as I can tell, the only claim you >>>are making is that your artifact is FlexJS with a fix that sho
Re: Convenience Binary Policy
On 10/21/14, 5:57 AM, "Marvin Humphrey" wrote: > >The problem is that we lack a concise policy document. That's where the >"ASF >release policy codification proposal" as worked through on legal-discuss >a few >months ago is supposed to help. > > http://s.apache.org/aGm > https://github.com/rectang/asfrelease Hi Marvin, IMO, this version of the document also doesn’t prohibit me from updating the binary package without a vote. It seems like some portions of this document is supposed to apply to binary packages like the LICENSE/NOTICE sections so I think that’s why there is still ongoing debate on the Flex mailing list about whether I can in fact modify the FlexJS binary package. At this point, unless someone not on the Flex PMC says that we can’t make the modifications, I am planning to add a new entry to the Flex Installer that points to bits that are hosted on my personal server called “Apache FlexJS 0.0.2 (with Jburg)” and expose it to the general public. All of the compiled bits are the same, but I have added the jburg.jar to the package to workaround the problem. The original binary package will remain on dist/mirrors. Thanks, -Alex
Re: [VOTE] Release Apache Flex SDK Installer 1.0.8-incubating
On 11/1/12 1:16 PM, "sebb" wrote: >>> The key C1708693 does not appear to be available from the normal >>> public PGP key servers. >> >> I presume you would like Om to publish his key. > > Yes, that is required so end users can fetch it if required. > > Also AIUI it is used by Nexus. > The document at [3] in the section "Signing Basics" only seems to require that the key be in the KEYS file. Om's key is there at [4]. > There should be an EOL at EOF. > I.e. the last line in source files should have an EOL. > > [Whether the EOL is LF or CRLF or CR is immaterial to this discussion.] > > Otherwise the files in the SVN tag aren't the same as the files in the > source archive. > "Should" or "must"? Is this a release blocker? [3] http://www.apache.org/dev/release-signing [4] http://www.apache.org/dist/incubator/flex/KEYS Thanks, -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Flex SDK Installer 1.0.8-incubating
On 11/1/12 2:50 PM, "Alexei Fedotov" wrote: > I mention ./LICENSE file from the source release and naturally assume > this is the source release license. > Then I assume Apache source release should be generally Apache > licensed. This is not necessarily true for a binary release which can > contain compatibly licensed components. > Hi Alexei, I think there may in fact be a problem with the LICENSE file and the Open_Sans font. However, I I am confused about what steps we are supposed to execute to address your second concern. I'm not sure what you mean by "adding BSD-like...". There are two files in the source release that have a BSD license using the Modified BSD template and substituting Adobe as the organization. Why isn't what we did the correct way to handle this? >>>> 2. Something like BSD license. >>>> >>>> The first item I cannot understand completely, the second one can be >>>> resolved by adding BSD-like licensed files during build. >>>> >>>> So the question is why do you use non-standard LICENSE for the source >>>> release? -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Flex SDK Installer 1.0.8-incubating
On 11/1/12 3:04 PM, "Alexei Fedotov" wrote: > First, I'm not a lawyer. More experienced guys will tell us more. > > In our project (Openmeetings) we keep the files which are not Apache > licensed in different places, e.g. at googlecode, and collect them > during the build process via wget. We do not include them into a > source release. > OK, thanks. We include our in the LICENSE file per this document [1] Where it says: "All the licenses on all the files to be included within a package should be included in the LICENSE document. This LICENSE (courtesy of Apache HTTPD) is a good example. The Apache License is at the top of the LICENSE document. After that, the license for each non-Apache licensed component is included, along with a clear explanation of which files that license applies to." We'll see if others have to say, but I think we are conforming. [1] http://incubator.apache.org/guides/releasemanagement.html#best-practice-lice nse -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Flex SDK Installer 1.0.8-incubating
On 11/1/12 4:08 PM, "Alexei Fedotov" wrote: > Thanks for explaining, I finally got Carol's point on installer. > > I still cannot fully understand the licensing. I have checked that > installer/src/com/adobe/utils/IntUtil.as (which is mentioned in LICENSE > file as Adobe licensed) contains Apache license header. After more digging, I think the issue is that IntUtil.as shouldn't have an Apache header. It comes from external projects under Modified BSD. Then I think it would make sense to have the Adobe/BSD license in the LICENSE file? > > Why do you need any additional attributions for Apache licensed file? After more digging, I think this is here because these are binary files that, while under Apache license, are not sourced from a.o, so technically, third-party. It isn't clear from here [5] that if it is under Apache it doesn't have to be called out in the LICENSE file. > > BTW, file paths are incorrect in the LICENSE file. Agreed. But not critical? [5] http://www.apache.org/legal/resolved.html#required-third-party-notices -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Flex SDK Installer 1.0.9-incubating
Looks like when Om built the source archive, some unicode characters got mangled (maybe confused as Windows double-byte?). Is this a release blocker given that this code is disabled? We turned off locales so no code path will touch these mangled strings. Or is there a rule that the source archive must match what is in SVN? -Alex On 11/7/12 9:01 AM, "Bertrand Delacretaz" wrote: > On Wed, Nov 7, 2012 at 5:30 PM, Om wrote: >> Can you please try running ant source-package locally to see if you can >> repro this?... > > On my mac, running ant source-package -DFLEX_HOME=/tmp in a checkout > of [1] produces a zip and a tar.gz file under ./release, which both > contain a correct RuntimeLocale.as file. That same file is garbled > when I unpack the archives that you posted for release. > > -Bertrand > > [1] http://svn.apache.org/repos/asf/incubator/flex/utilities/trunk/installer > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Graduate Apache Flex podling from Apache Incubator
This is a call for vote to graduate the Apache Flex podling from Apache Incubator. Apache Flex entered the Incubator in December of 2011. We have made significant progress with the project since moving over to Apache. We have 34 committers listed on our status page at [1] including 6 accepted after the podling was formed. Another 5 committers were recently approved after we started the vote to graduate and are not yet listed on the status page. We completed two releases (Apache Flex 4.8.0-incubating and Apache Flex SDK Installer 1.0.9-incubating). The community of Apache Flex is active, healthy and growing and has demonstrated the ability to self-govern using accepted Apache practices. The Apache Flex community voted overwhelmingly to graduate [2]. You can view the discussion at [3]. We have prepared and reviewed our charter. You can view it at [4]. Please cast your votes: [ ] +1 Graduate Apache Flex podling from Apache Incubator [ ] +0 Indifferent to the graduation status of Apache Flex podling [ ] -1 Reject graduation of Apache Flex podling from Apache Incubator because ... This vote will be open for at least 72 hours. [1] http://incubator.apache.org/projects/flex [2] http://markmail.org/message/ps3rjgv76vlw4sh5 [3] http://markmail.org/thread/ej4z47rr3ba532uv [4] https://cwiki.apache.org/confluence/display/FLEX/Graduation+Resolution -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Apache Flex podling from Apache Incubator
Is it ok to close this vote? It happened over the long holiday weekend in the US and we only got five total votes, three from our mentors. Thanks, -Alex On 11/22/12 11:57 AM, "Alan Cabrera" wrote: > +1 - binding > > Regards, > Alan > > On Nov 21, 2012, at 11:03 PM, Alex Harui wrote: > >> This is a call for vote to graduate the Apache Flex podling from Apache >> Incubator. >> >> Apache Flex entered the Incubator in December of 2011. We have made >> significant progress with the project since moving over to Apache. We have >> 34 committers listed on our status page at [1] including 6 accepted after >> the podling was formed. Another 5 committers were recently approved after we >> started the vote to graduate and are not yet listed on the status page. >> >> We completed two releases (Apache Flex 4.8.0-incubating and Apache Flex SDK >> Installer 1.0.9-incubating). >> >> The community of Apache Flex is active, healthy and growing and has >> demonstrated the ability to self-govern using accepted Apache practices. >> >> The Apache Flex community voted overwhelmingly to graduate [2]. You can view >> the discussion at [3]. >> >> We have prepared and reviewed our charter. You can view it at [4]. >> >> Please cast your votes: >> >> [ ] +1 Graduate Apache Flex podling from Apache Incubator >> [ ] +0 Indifferent to the graduation status of Apache Flex podling >> [ ] -1 Reject graduation of Apache Flex podling from Apache Incubator >> because ... >> >> This vote will be open for at least 72 hours. >> >> [1] http://incubator.apache.org/projects/flex >> [2] http://markmail.org/message/ps3rjgv76vlw4sh5 >> [3] http://markmail.org/thread/ej4z47rr3ba532uv >> [4] https://cwiki.apache.org/confluence/display/FLEX/Graduation+Resolution >> >> -- >> Alex Harui >> Flex SDK Team >> Adobe Systems, Inc. >> http://blogs.adobe.com/aharui >> >> >> - >> 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 > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT][VOTE] Graduate Apache Flex Podling from Apache Incubator
The IPMC has approved the proposal to recommend the resolution to the Board. Results: 8 "+1" votes, no "0" votes, no "-1" votes. +1 Bertrand Delacretaz (IPMC) +1 Greg Reddin (IPMC) +1 Dave Fisher (IPMC) +1 Chris A. Mattman (IPMC) +1 Alan Cabrera (IPMC) +1 Suresh Marru (IPMC) +1 Christian Grobmeier (IPMC) +1 Benson Marguiles (IPMC) I will send an email to the Board asking to include the resolution in the agenda for the next Board meeting. Vote Thread Message ID: ccd30e35.48e5a%aha...@adobe.com Thanks everyone, -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui == WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software, for distribution at no charge to the public, related to development of expressive web applications that deploy to all major browsers, desktops and devices (including smartphones, tablets and tv). NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache Flex Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Flex Project be and hereby is responsible for the creation and maintenance of software related to development of expressive web applications that deploy to all major browsers, desktops and devices (including smartphones, tablets and tv); and be it further RESOLVED, that the office of "Vice President, Apache Flex" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Flex Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Flex Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Flex Project: Alex Harui Carol Frampton Christophe Herreman Chuck Mastrandrea Dave Fisher Erik de Bruin Espen Skogen Gordon Smith Greg Reddin Igor Costa Iwo Banas Jeff Tapper Jeffry Houser Jeremy Tellier Jonathon Campos Jun Heider Justin Mclean Kevin Korngut Leif Wells Martin Heidegger Michael Jordan Michael Labriola Michael Schmalle Michelle Yaiser Nicholas Kwaitkowski Omar Gonzalez OmPrakash Muppirala Peter Elst Peter Ent Rui Silva Ryan Frishberg Sebastian Mohr Scott Delamater Tink NOW, THEREFORE, BE IT FURTHER RESOLVED, that Alex Harui be appointed to the office of Vice President, Apache Flex, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Flex PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Flex Project; and be it further RESOLVED, that the Apache Flex Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Flex podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Flex podling encumbered upon the Apache Incubator Project are hereafter discharged. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
On 1/14/13 7:01 AM, "Chen, Pei" wrote: >> Really is it so bad to say to a project with a bug in their license and >> notice info: >> fix this in trunk and show me the revision and I'll go ahead and approve your >> release as-is. >> Running through iterations of this is very labor-intensive for the project, >> and >> anything we can do to cut down on the pain involved in cutting incubator >> releases is IMO worthwhile. > > + 1 for this! > Perhaps it would be nice for the podling to just come up with a list of all of > the 3rd party libraries in a Jira and have a group (possibly from legal) that > reviews them and helps them officially construct the LICENSE/NOTICE files the > first time around (There are usually a lot of grey areas and not an easy > straight reference to an outdated list of approved compatible licenses). Most > of the committers are developers and not lawyers- so it would be nice to have > developers do what they do best and focus on building awesome code. I don't agree. As a member of a recently graduated podling, it was impressed on me that the point of incubation was to not only figure out the Apache Way of meritocracy and voting, but also to get the legal aspects right. IMO, Apache is not GitHub: it is a corporation with bylaws and is a legal entity, so we have to get the legal stuff right and it is our responsibility as developers to learn enough about the legal stuff to get it right. If there is a grey area, err on the side of caution or ask Apache Legal. Yes, it is painful and slows you down, but usually, the same laws also protect you. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
On 1/14/13 9:20 AM, "Joe Schaefer" wrote: > The thing is Alex, all of this effort > to dot our i's and cross our t's on the legal > issues really is only for the benefit > of major corporations who want to incorporate > our work into some corporate-branded application. > Actual end users of our software do not benefit > one iota from the type of nitpicking we do on > general@incubator, nor does the org's reputation > for clean IP hinge on these considerations. > > My attitude is to let the elephants in our projects > provide their own feedback directly to the projects > on the legal nitpicks that cause them pain- we do not > need to police these minor issues on their behalf in a > generic way. > I'm not sure I know what an "elephant" is in this context. And I'm not quite sure what issues are considered 'i' and 't'. IMO, it was a good lesson for our podling to see that we can get delayed by not getting the LICENSE and NOTICE and other files right, so we had proper expectations set for when we became a TLP. And IMO, because IANAL and nobody else in the podling is either, it was good to have other sets of eyes on the reviews. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release
On 1/25/13 8:28 AM, "Chen, Pei" wrote: > I am actually glad that it is discussed here so that other podlings or future > podlings are aware of these fundamental items (since not everyone may > subscribe to legal-discuss). > > Is this philosophy or policy also true for parts of a code base that are > intricate to the basic functionality of the software such as icons, gifs, > jpgs, and statistical models in this case (which were approved to be > distributed under the same ASL2.0 terms)? I'm pretty sure that icons, gifs, jpgs are ok in both source and binary dists. My mental model for source dists is whether the file can do any harm and what the developer would do to verify its safety. For icons, gifs, jpgs, I would load them in a display program, and if they contained a virus, they probably wouldn't load. I don't know what your statistical model is, but I would think of it the same way. The binary dist is just supposed to be a pre-compiled version of the source dist. > > Can those be included in the source or binary dist or both? > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release
On 1/25/13 10:20 AM, "Benson Margulies" wrote: > On Fri, Jan 25, 2013 at 11:36 AM, Alex Harui wrote: >> >> >> >> On 1/25/13 8:28 AM, "Chen, Pei" wrote: >> >>> I am actually glad that it is discussed here so that other podlings or >>> future >>> podlings are aware of these fundamental items (since not everyone may >>> subscribe to legal-discuss). >>> >>> Is this philosophy or policy also true for parts of a code base that are >>> intricate to the basic functionality of the software such as icons, gifs, >>> jpgs, and statistical models in this case (which were approved to be >>> distributed under the same ASL2.0 terms)? >> I'm pretty sure that icons, gifs, jpgs are ok in both source and binary >> dists. My mental model for source dists is whether the file can do any harm >> and what the developer would do to verify its safety. For icons, gifs, >> jpgs, I would load them in a display program, and if they contained a virus, >> they probably wouldn't load. > > > >> >> I don't know what your statistical model is, but I would think of it the >> same way. > > > No way. A big model is a giant opportunity for trojan horses. > Sorry, that's really what I meant: to think about that file as to whether it can do any harm and how to determine its safety. I haven't looked at the file, but it sounds like you know it can do harm. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator voting status page
On 1/29/13 12:53 AM, "Daniel Shahaf" wrote: > > I have a current example. Flex and Wink haven't updated their > podlings.xml entries to > status="graduated" > , therefore certain infra scripts still consider them podlings rather > than PMCs. My bad. I somehow missed that in the list of tasks to do. Flex should be fixed now. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Creation of the Incubator Ombudsman
On 6/16/13 10:36 AM, "Alan Cabrera" wrote: > >On Jun 15, 2013, at 10:52 AM, Joseph Schaefer >wrote: > >> This is a suggestion that has come up in the past, and the typical >>counter-argument is that this is something the chair needs to provide >>themselves. >> >> Sent from my iPhone > >The usual reason for an ombudsman is to have a safe third party to bring >up issues up privately. Podling members may feel too intimidated to >complain to mentors/IPMC chairs to complain. Maybe the complaint may be >an absentee, or problem, mentor or chair. One never knows. Just curious, is the ombudsman not allowed to be a mentor for a podling? Otherwise, that podling doesn't have a safe third-party? -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[DRAFT] Apache Flex Podling Exit Interview (if there was such a thing) (was Re: [PROPOSAL] Mandatory podling exit interviews)
First, a disclaimer. This is just my personal take on things and no one else on the Apache Flex PMC was involved in writing this. As the PMC chair of a relatively recently graduated podling, I would like to suggest that if you choose to implement "exit interviews" they should probably be optional, and I would argue that they should be requested at least 3 months after graduation, after the transition from podling to project is hopefully complete. First, there are potential nightmares in the transition, and second, after that dust settles, there is hopefully time to reflect. Regarding anonymity, I would suggest that any naming of names should happen outside the interview and on private@. Anyway, the exit interview for Apache Flex would be short. It would say: "We started with four mentors, one dropped out, the other three were great, two remain on the project PMC. When you have enough active mentors, the Incubator works just fine. Yes, documentation could be better, but we figured it out and graduated and are off an running as a TLP." Now if the interview contained an open comments section, I would say the following: I've been scanning what must be hundreds of emails in at least 3 threads trying to fix the Incubator. Personally, I think the Incubator is working as well as should be expected. Can it be better? Maybe. Because I think there really is only one "problem", and that is simply "time". In fact, "time" is the root cause of all "problems" at Apache, especially at the other main source, which is Infra, and it amazes me that it doesn't really get mentioned explicitly in these discussions. To me, it is par for the course when you have a group of volunteers running things. I haven't done much volunteering, but are there other organizations as large as Apache that is administered by volunteers? Big charities seem to have paid administrators. Infra has some paid folks, and I haven't checked Apache history, but I would imagine Infra was once all-volunteer until it was decided it was not going to scale and donation money was diverted to fund fully-dedicated people to it. And still, they are underfunded as lots of minor requests slip through the cracks. It may simply be time to try to get more donation money diverted to pay one or two folks to serve on the IPMC. You can try every new idea you want, but they will all fail if folks simply don't have the time and energy to execute them. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Instead of a Bill how about a Booklet? (was Re: [DISCUSS] PodlingBillOfRights)
Hi, As a newbie, I've generally quietly watched from the sidelines, but now I'm jumping in. +1 about "expectations" vs "rights". In fact, it occurred to me that a booklet or pamphlet more like the "What to expect whenŠ" book would be better. IMO, correctly set expectations make for happier people. Here is my draft of "What to expect when you enter the Apache Incubator". 1) Apache is staffed by volunteers, and a few paid, but overworked IT folks known as Infra. As such, there is a very good chance that you will get different answers from different respondents, and responses may be delayed. This is not like your paid corporate job where there is administration and infrastructure whose mind-share is fully dedicated to serving you. 2) Apache has been around long enough and is large enough to have its own culture, with its own societal rules and tribal history. Lots of it is written down, but it is hard to find. Try to remember the last time you started at a new company or team or club and how, even though there were documents to read, there was always important stuff that you had to learn some other way. Apache is no different, but with volunteers, even less is written down, and people's recollections of history can vary widely and nobody is paid to serve your needs except Infra which is overloaded. 3) Some folks are quiet, some are noisy, some complain, some are optimistic. If you've worked on a large team, you've probably found this to be true on that team as well. Success usually comes from finding out which folks you deal with are of which personality type, and how best to work with those people. 4) Often you just have to be patient. Pick your battles. Prioritize your needs. Ask politely once for really important things, then plead again a few days later. 5) Learn how to use an internet search engine. Try to find information before you ask. The results may be hard to understand or confusing and be careful about reading snippets without taking in some of the larger context. But then your question will be better defined. Bonus if you can quote a web page as part of your question. 6) Some folks want there to be a "bill of rights", but you don't have any "rights" because there are no authority figures at Apache to enforce those rights. Any "violations" have to be dealt with "socially". You can seek help from the IPMC or even the board, but even they are volunteers and will try to address the problem socially as well. You can expect and demand respectful discourse, but sometimes tempers will boil over. That happens in many workplaces, homes and other gatherings of people. Expect it here as well, even more so sometimes, as there are relatively few face-to-face encounters to encourage civility and limit chances of mis-interpretation. 7) Your mentors may get too busy to follow the details of activity in your podling. Use the [MENTOR] tag in the subject to try to catch their attention. Escalate to the Incubator IPMC if they still don't have time to respond. 8) Embrace diversity. Every podling is a little bit different and your new podling may not exactly match up against existing documentation or prior history. Ask for guidance, keep in mind that answers may vary, and make your decision keeping these things in mind. A) The primary goal is to cover your and Apache's butt legally. This may require you to change build scripts and release packages in a way that is painful for you and your customers. B) Apache only officially releases source code. This may be a pain point for any existing customers used to downloading binary packages. C) At Apache, open source isn't just about making released source code available. It is about trying to get the community involved early and often before the source code is "release-ready". 9) Expect the unexpected. Sometimes, a document you find may be out-of-date, and/or mention things that don't apply to you and when you ask about it, you'll get a totally surprising answer. 10) Expect a ton of email. The temptation will be to unsubscribe from some of the lists you are told to subscribe to, but it is important to learn how to filter out stuff and skim other stuff as it helps you learn about the people and personalities you will be dealing with post-graduation on occasion, and if you end up on your project's PMC, you will be responsible for mining important information from that email stream. Now this may seem like it should make you run away screaming, but it all adds up to one thing: This is the "cost" of getting a group of volunteers to provide free software to a community of developers and users. You are doing a good deed by coming to Apache. You could just go to GitHub, but Apache provides some legal and logistical processes that should make your customers feel more secure that the code you want to work on will be available to the customer "forever" without fear that some individual can disappear and sink the whole ship, or some legal issue wi
Re: [PROPOSAL] Creation of the Incubator Ombudsman
FWIW, my concerns about an Ombudsman are: 1) I had no idea what an Ombudsman was. I'd heard of it, but never had to work with one before. I had to go look it up. If I had a complaint, I'm not sure I would know to look up that word to find the email address to complain to. 2) If you create a role like this, what happens when the folks who take it on run out of time and energy (see my comments about time in my 'exit interview' draft) and we can't find anybody else who wants to take that on for all of Apache? Roles like 'ombudsman' imply at least some sort of authority or the ability to get the authorities to act, but with all-volunteers, the person who is being complained about probably just ran out of time and there is no way to enforce that. We think of Apache as a community, and I'd prefer a community without a police station where the neighbors just have to work things out among themselves. An ombudsman implies a sort of anonymous tip line and some sort of resolution by enforcement. I'd rather go with what Jim referenced, that those of you who have the time and energy take on the role of community welcomers (you don't have to be an 'elder' which implies 'old'), visit a new podling and say "Hey, I live five houses down (meaning, I'm not on following your podling on email), lived in this neighborhood for many years, and you have great neighbors (meaning mentors), but if you ever need anything, come knock on my door day or night." Then no individual is committed to have to visit 'every' podling. There isn't some email address that you don't know who will answer. My 2 cents, -Alex On 6/20/13 5:01 AM, "Bertrand Delacretaz" wrote: >On Sun, Jun 16, 2013 at 7:42 PM, Alan Cabrera >wrote: >> ...I think that it would be a great idea to have an ASF wide ombudsman >>instead... > >We don't have that, and I don't think we need it - people should feel >free to contact people that they trust (officers, board members, ASF >members) privately if there's a need, and not having someone elected >in the ombudsman role means people are free to talk to whoever they >think will help. > >-Bertrand > >- >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: Instead of a Bill how about a Booklet? (was Re: [DISCUSS] PodlingBillOfRights)
On 6/21/13 7:12 AM, "Chip Childers" wrote: >On Thu, Jun 20, 2013 at 08:22:00PM +0100, Upayavira wrote: >> If, for whatever reason, they are unable or >> unwilling to, you can ask on the incubator general list. If the optic is >> too sensitive to discuss in public (eg a potential committer) you may >> contact the incubator ombudsman at x...@apache.org. > >Shouldn't this be priv...@incubator.apache.org *first*, and then the >ombudsman only when it's a "complaint" that doesn't seem to be addressed >through normal list discussions? Even private@ could be readable by the person you are complaining about, plus this assumes there will be an ombudsman, which isn't clear will be the case. I would say it this way: 11) Expect to be frustrated (or annoyed or even angered) at least once by the failure of people to act as you justifiably think they should based on whatever documents or emails you've read, or the role they claim responsibility for, or even based on common sense. You might need one more binding vote, or need consensus on what looks like a simple question but ends up being debated for days when you need a ruling "yesterday". If you choose to lodge a complaint against an individual, remember that every mailing list is archived, some of them publicly, and the individual you are complaining about may someday see what you have written. Before complaining about an individual, find a mentor or ASF member and approach them off-list, mainly as a sanity check to make sure your complaint is justified in someone else's view, but also so that mentor or ASF member can offer different ways to potentially resolve the problem. It is generally wise not to name names in your early emails as you may not be able to predict any existing relationship between the person you are writing to and are writing about. A good way to choose an ASF member is by getting a sense for who they are by their writings on general@incubator or other ASF mailing lists. In other words, if you are new to the neighborhood, it is prudent to be careful complaining about one of your neighbors to the other neighbors until you understand the relationships between them. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Mandatory podling exit interviews
On 6/21/13 5:58 AM, "Upayavira" wrote: > > >On Fri, Jun 21, 2013, at 01:52 PM, Marvin Humphrey wrote: >> On Thu, Jun 20, 2013 at 2:18 AM, Upayavira wrote: >> >> > As in any such survey, author identity should be optional. Sometimes >>it >> > can be deduced, but not always, and if someone would rather not >>mention >> > their name, we should give them that opportunity. >> >> "Sometimes" preserving anonymity is not good enough. It would be >> irresponsible of us to solicit candid feedback when identity will be >> revealed >> "sometimes". >> >> If respondents state that they would prefer to remain anonymous, at the >> very >> least we must limit publication of any natural language responses to >> private@incubator -- which would be unfortunate because it shunts >> discussion >> that ought to take place in public onto a private list. Furthermore, we >> should tell them outright that they are fooling themselves if they think >> no >> IPMC members will be able to guess who they are. >> >> I'm not even sure we can realistically preserve anonymity for "scale of >>1 >> to >> 10", multiple choice, true/false and so on given the very limited pool >>of >> potential respondents. We're going to have to think really hard about >> what we >> ask and what we publish -- and if we try hard to scrub and fail, I'm >> going to >> feel really bad. >> >> Nevertheless, if an "anonymous" option that can only be discussed >> privately is >> the price of consensus, I'm still on board. It's better than nothing. > >Exactly. I've seen many surveys where the name is optional, but 5 of 6 >people fill in their name. So much for anonymity. > >I would say make the name field optional and have a 'keep my comments >private' tickbox, default unticked. They likely won't be able to keep it >from any members of the IPMC, but at least would allow them to say "you >are a complete bunch of loosers" without it getting into the public >domain. As a newbie, it seemed like the IPMC and ASF as a whole was like how the movies portray the Mafia in the sense that you had to earn your way in, and folks were pretty tight-knit and knew each other personally. There is no way I would name any names in any email where I didn't know exactly who would read it, so I would never name names in a survey or in an email to an ombudsman or private@. Not because of fear that a 'hit' would be put on me, but just that it could burn bridges I might need later. That's why I just offered another section to the "What to expect" thread about finding a mentor or ASF member to work with to resolve complaints against individuals. If the matter cannot be resolved directly and off-list, that mentor or ASF member should help the crafting of any email that ends up on-list. Just because the person you are complaining about isn't in the IPMC, there is no guarantee they won't be invited to join the day after you write your email to private@. I would actually suggest giving up on trying to find a way to provide anonymity and adding a warning to the survey/exit-interview to caution folks about naming names. In theory, the complaints about individuals you are worrying about missing have been alluded to on the dev list of that project and addressed via the help of mentors or other ASF members long before the project graduates and an exit interview happens. If some person filling out the exit interview has something else to say that requires they remain anonymous, they should also voice that with a mentor or ASF member, and they should have done so long before graduation as well back when the incident or issue was taking place. My five cents, -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP CLEARANCE] BigCouch
Just testing my own knowledge of this stuff: A) isn't it true that if you are not the copyright holder or agent of the copyright holder, you need some sort of paper or email trail giving you permission to move copyrights? B) isn't it true that there are cases where the copyright stays in the file and even the license header does not change? For example, third-party works with compatible licenses? I remember this being a source of much confusion when donating stuff in my recent past. Thanks, -Alex On 6/26/13 12:35 PM, "Robert Newson" wrote: >Part of the process was to get a signed release from Cloudant (Adam >Kocoloski, also a CouchDB PMC member), I think that covers the legal >bits. All I've done is make the headers in the contribution the same >as those in core couchdb (the short ASLv2 bit and no 'Copyright >Cloudant' line). > >B. > > >On 26 June 2013 20:29, Noah Slater wrote: >> Thanks for the clarification Dennis. I'll toss this on a list of things >>to >> circle back to at some point. If someone wants to split of a separate >>thread >> about it right now, be my guest. >> >> >> On 26 June 2013 20:22, Dennis E. Hamilton >>wrote: >>> >>> I don't think I've seen the template before, or it was too long ago >>>and I >>> failed to notice at the time. >>> >>> Noah has explained my concern and added discussion on remedies. (I >>>won't >>> be creating a JIRA issue and it appears that others have a better >>>sense of >>> what would express what is appropriate. I just saw what was clear to >>>me was >>> inappropriate.) >>> >>> With respect to that checklist, my only lingering concern is that it is >>> difficult to know what was actually done, following the instructions as >>> given, especially with regard to the headers of files, given how the >>>item is >>> worded. >>> >>> I would definitely change the heading from "Copyright" to "Licensing" >>>too. >>> >>> - Dennis >>> >>> -Original Message- >>> From: Robert Newson [mailto:rnew...@apache.org] >>> Sent: Wednesday, June 26, 2013 09:36 AM >>> To: general@incubator.apache.org; dennis.hamil...@acm.org >>> Cc: Noah Slater >>> Subject: Re: [IP CLEARANCE] BigCouch >>> >>> Dennis, >>> >>> I'm following the instructions I'm given, I don't know if this is the >>> place to comment on the process the incubator project has been >>> following up to this point. Have I followed it incorrectly? I don't >>> know you personally, are you pointing out problems with *this* ip >>> clearance thread in particular or are you commenting on the template >>> itself? Had you seen the template before today? >>> >>> B. >>> >>> >>> On 26 June 2013 17:27, Dennis E. Hamilton >>>wrote: >>> > Under the heading "Copyright" there is an item with text "Check and >>>make >>> > sure that the papers that transfer rights to the ASF [have] been >>>received. >>> > It is only necessary to transfer rights for the package, the core >>>code, and >>> > any new code produced by the project." >>> > >>> > In the next box it says >>> > >>> > "Check and make sure that the files have been donated have been >>>updated >>> > to reflect the *new* ASF copyright. ... " [emphasis mine]. >>> > >>> > It is my understanding that an SGA is not a transfer of rights but a >>> > grant of license. This language is all wrong, wherever it comes >>>from. It >>> > suggests what appears to be a copyright transfer when everything we >>>are told >>> > around here is that the ASF neither requires nor does such things. >>> > Furthermore, adding ASF copyright notices in the headers for >>>individual >>> > files that are otherwise unchanged is very naughty. (Unless, of >>>course, >>> > there has indeed been a copyright transfer, and I'm not all that >>>sure about >>> > even that case.) >>> > >>> > - Dennis >>> > >>> > PS: And, of course, the license grant is about more than the >>>exclusive >>> > rights of copyright holders, too. In any case, the non-exclusive >>>licenses >>> > granted in SGAs and CLAs are not transfers. (Since "standing" is >>>much in >>> > the news today, another way to put it is that the ASF has no power >>>to sue >>> > for infringement of copyright in the contributed works, nor any >>>patent >>> > infringement related to the use of the contributed works.) >>> > >>> > -Original Message- >>> > From: Noah Slater [mailto:nsla...@apache.org] >>> > Sent: Wednesday, June 26, 2013 08:14 AM >>> > To: general@incubator.apache.org; dennis.hamil...@acm.org >>> > Subject: Re: [IP CLEARANCE] BigCouch >>> > >>> > Dennis, can you clarify your concerns please? >>> > >>> > The page you are looking at is generated from a template. Bob has >>>simply >>> > filled in the dates as he stepped through the process. >>> > >>> > Which specific guidelines do you not believe have been followed? >>> > >>> > Why do you believe that an SGA has not been filed? >>> > >>> > >>> > On 26 June 2013 16:05, Dennis E. Hamilton >>> > wrote: >>> > >>> >> That page talks about transfer of copyright and addition of Apache >>> >> cop
Re: [PROPOSAL] Creation of the Incubator Ombudsman
On 7/30/13 12:50 PM, "Christian Grobmeier" wrote: >On Tue, Jul 30, 2013 at 9:44 AM, Bertrand Delacretaz > wrote: >> On Tue, Jul 30, 2013 at 5:55 AM, Marvin Humphrey >> wrote: >>> ...Bertrand was skeptical about an ASF-wide ombud, but didn't raise >>>any objection >>> to an Incubator-specific position. >>> http://s.apache.org/NAa >> ... >> >> Just laziness on my part...what I said there also applies to an >> Incubator ombudsman, I'll repeat it here: I don't think we need it - >> people should feel >> free to contact people that they trust (IPMC members, mentors, ASF >> members) privately if there's a need, and not having someone elected >> in the ombudsman role means people are free to talk to whoever *they* >> think will help. > >+1 to what Bertrand said. +1 from me too. However... >If podlings don't know where to go we need to tell them they can ping >people >they trust in private AND they always can speak about problems in public >on general@. Discussing things in public is what we always (should) do. ...as a newbie in Apache and a member of a recently graduated podling, I have to say that if our mentors had completely failed us so I couldn't go to them in private, I wouldn't know who else to ping in private because I didn't know anybody else in Apache. However, just about any issues I can think of would be able to be at least introduced on general@ without naming names and maybe some volunteer watching general@ would offer to help in private. > >That said, if you would like to start that experiment I don't object, >but I don't expect anything from it. Same here, and I don't have a binding vote anyway. But I would prefer an experiment where instead of hiding behind a title like Ombud, (and if you must have a title, I like "Community Advocate" better), that the experiment just be that one or two people introduce themselves to each podling offering to be the sounding board and advocate if their mentors and shepherds get too busy. Even now, as a new TLP with few experienced Apache folks on it, it would be good to know who in Apache is willing to help out if we get stuck. I figure everyone is busy enough as it is and that it has to be a big deal before asking on board@. I guess members@ is a possibility, but if someone like JimJag "visited" our dev list and volunteered to help out new TLPs as well that would make Apache appear all that more friendly and welcoming. -Alex > >Cheers >Christian > >> -Bertrand >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > > >-- >http://www.grobmeier.de >https://www.timeandbill.de > >- >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: [PROPOSAL] Creation of the Incubator Ombudsman
On 7/30/13 5:05 PM, "Marvin Humphrey" wrote: >Bertrand, Christian, Alex, > >On Tue, Jul 30, 2013 at 12:44 AM, Bertrand Delacretaz > wrote: >> people should feel >> free to contact people that they trust (IPMC members, mentors, ASF >> members) privately if there's a need, and not having someone elected >> in the ombudsman role means people are free to talk to whoever *they* >> think will help. > >I question how well the Incubator communicates to newcomers that such >resources are available to them. What if a podling contributor has no >"people >that they trust" because they don't know anybody around here? I think an explanation of what to do if your mentors fail you would be a good addition to "What to Expect". I think I proposed one in this thread a while back. I've seen enough grumbling about how hard it is to find the right document with the right information in Apache that I know it isn't just me. Honestly, I thought I'd read all of the incubator docs when we entered but don't recall reading the Process_Description document. But most of the time, I learn by searching. Trying to read and remember all of the incubator documentation is overwhelming and won't stick until it becomes more applicable. That's the value of mentors, they try to keep tabs on the discussion in the podling and give sage advice and point to the right document when you need it. What we're discussing here is what to do if the mentors run out of time to keep up with their podling. For me, I'm pretty sure that if you or Jim Jag or anyone who thinks they have the time had emailed our dev list with a friendly welcome and an "feel free to ask if you need help" I would have remembered that. Maybe an alert needs to be sent to general@ when a new podling's dev list is ready so friendly folks can offer their help in a way that gets archived? That happens a few days after the vote result and IIRC, the well-wishing and welcomes where then left on general@. > >I'm also skeptical that the absence of an ombud makes things easier >because newcomers are "free" to find the best person to talk to. That's >like >saying that an airport is better off without a help desk. My conern with "ombud" is that you don't know who you are talking to. Airports are relatively impersonal compared to Apache. And folks have raised concerns about giving someone responsibility for covering ALL podlings. One thing I learned from other volunteering is that you can't formalize volunteers too much or force them to do things. It is better to identify momentum and give it nudges in the right direction. Creating a role could over formalize what should just be a welcoming committee. The person with that role is negligent as soon as they run out of time to welcome the latest podling. I think that's Bertrand's point. Don't make one person do it, find a way to channel those motivated to do it. One possibility is a wiki page where each new podling is listed. Then you or JimJag or anyone can send the "ask if you need help" email and mark on the wiki page that they did it. Other folks can also add their welcomes, and you can see which podlings haven't been welcomed. But nobody is "required" to do it. I suppose you could also have a help.a.o page where folks who have time to back up the mentors can add their names so a podling can look to see who currently says they have spare cycles to help. That would be your airport help desk staffed by volunteers, not somebody who "has" to do it. And then folks can pick who they want to start with. A small photo and description of who you are would make such a page appear more friendly and help folks choose. > >The difference between the Incubator's overview documentation (what we >think >you need to know) and the information in WhatToExpect (what you really >need to >know) is jarring. > >http://incubator.apache.org/incubation/Process_Description.html >http://wiki.apache.org/incubator/WhatToExpect > >If we're so approachable, why doesn't anybody know it? This is another lesson I learned from other volunteering. Nothing ever goes as planned. The process description is how it should work, but what to expect is about what will probably happen as you try to execute how it should work. I don't know if you have kids, but the What To Expect book about pregnancy was also quite different from what I was taught in school or saw in movies. -Alex > >Marvin Humphrey > >- >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Creation of the Incubator Ombudsman
On 8/2/13 9:36 AM, "Roman Shaposhnik" wrote: >On Fri, Aug 2, 2013 at 2:17 AM, Christian Grobmeier >wrote: >> On Fri, Aug 2, 2013 at 1:41 AM, Marvin Humphrey >> wrote: >> I think either the Champion or the Chair should do it. I have a slight >> preference for the chair. >> The champion is already known to the project. Having the chair saying >> "Hi" is like some formal, >> official welcome > >Good point! Agreed, but it would be more welcoming and more of a "committee" if several folks took the time to welcome. I have to admit that currently for me, I'm the busy neighbor who works odd hours and doesn't have time to bring you a pie or cookies. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Creation of the Incubator Ombudsman
On 8/5/13 8:05 AM, "Marvin Humphrey" wrote: >On Fri, Aug 2, 2013 at 9:59 AM, Alex Harui wrote: >> On 8/2/13 9:36 AM, "Roman Shaposhnik" wrote: >>>On Fri, Aug 2, 2013 at 2:17 AM, Christian Grobmeier >>> wrote: >>>> On Fri, Aug 2, 2013 at 1:41 AM, Marvin Humphrey >>>> wrote: >>>> I think either the Champion or the Chair should do it. I have a slight >>>> preference for the chair. The champion is already known to the >>>>project. >>>> Having the chair saying "Hi" is like some formal, official welcome >>> >>>Good point! >> >> Agreed, but it would be more welcoming and more of a "committee" if >> several folks took the time to welcome. > >That sounds hard to coordinate, because all the members of the "committee" >would have to subscribe to the podling dev list in order to reply on the >welcome thread. Despite the best of intentions, I would anticipate >diminishing participation over time. Would they have to subscribe or would it just go to moderation and a moderator could push it through. I wasn't thinking there'd be dozens, just more than one. > >How about if either the Champion or the Mentor who handles mailing list >set-up >sends a cross-posted "Welcome Foo to the Incubator" message to the >podling dev >list and general@incubator once the dev list goes live? That would give >IPMC >members and other interested parties who are already subscribed to >general@incubator the chance to say hello. And embedding a ><mailto:dev-subscr...@foo.incubator.apache.org> link would give people an >opportunity to get involved with the podling right as it revs up. +1 -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[PROPOSAL] Flex for Apache Incubator
Hi everyone, I would like to propose Flex to be an Apache Incubator project. Here's a link to the proposal: http://wiki.apache.org/incubator/FlexProposal Thank you, Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Flex for Apache Incubator
(http://wiki.phonegap.com/w/page/46311152/apache-callback-proposal). > After that announcement, Nitobi has been acquired by Adobe. > If Falcon JS will be released, it would be possible to integrate > Falcon JS compilation with PhoneGap (HTML5/JavaScript based mobile > apps for a variety of platforms). Even if it is possible to compile > ActionScript 3 into iOS or Android applications (native), the > ActionScript 3 -> JavaScript -> PhoneGap approach would be equally > powerful, and could be completely supported with open source tools. Of > course, that would depend on the availability of the Falcon JS > cross-compilation feature. > > 7) Adobe Flash runtimes > http://www.adobe.com/products/flashplatformruntimes.html > The runtimes currently targeted by the Flex SDK (without Falcon JS) are > http://www.adobe.com/products/flashplayer.html > http://www.adobe.com/products/air.html > I would suggest to add the long-term goal of adding another > (non-proprietary) runtime to the Flex SDK (e.g. Falcon JS with the > cross-compiler) I would hesitate to make that a goal, even a long-term goal. I would prefer to focus the project contributors on strategies I think will be more achievable, but it is my understanding that is up to the project once established. > > 8) Open standards support > The whole proposal does not mention open standards, JavaScript, or the > buzz word "HTML5". Again, it might make sense to make support of open > standards with Adobe Flex a high-level goal. I'm unclear whether such goals are typically part of these proposals. We've heard from the community that a migration strategy is important, but Adobe has no official recommendation on whether it is cross-compilation, or porting the code to JavaScript and other open standards, or something else and hope to create a project within Apache and use the "Apache Way" to decide. > > It's exciting to see Adobe's willingness to contribute Flex to the ASF. > > Raju Bitter > Software Architect & Open Source Evangelist > > >> Hi everyone, >> >> I would like to propose Flex to be an Apache Incubator project. >> >> Here's a link to the proposal: >> http://wiki.apache.org/incubator/FlexProposal >> >> Thank you, >> >> Alex Harui >> Flex SDK Team >> Adobe Systems, Inc. >> http://blogs.adobe.com/aharui >> >> >> - >> 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 > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Flex for Apache Incubator
Yes, that is fine. On 12/20/11 2:27 AM, "Bertrand Delacretaz" wrote: > On Tue, Dec 20, 2011 at 5:55 AM, Kalle Korhonen > wrote: >> On Mon, Dec 19, 2011 at 6:09 PM, Greg Stein wrote: >>> Agreed. That is/was my read, too. >> >> Even still, companies don't participate in ASF projects, individuals >> do. To me, the proposal implies Adobe is a participating entity. The >> sentence in question would read better as "To that end, employees of >> Adobe will only have minority representation on the initial committers >> list" > > I agree that this makes things clearer - as podlings often take > existing proposals as a template to create new ones, I have changed > the proposal with your above suggestion, it reads now "To that end, > Adobe employes only have a minority representation on the initial > committers list". > > Alex, does that work for you? > > -Bertrand > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Flex for Apache Incubator
Responses inline: On 12/20/11 12:30 PM, "Raju Bitter" wrote: > Hi Alex, > > re-reading the proposal, a few other questions came to my mind: > > 1) Flash Player SDK > What are you referring to, when listing the "Adobe Flash Player SDK" > under "External Dependencies". The Adobe website says: > http://www.adobe.com/products/flashplayer_sdk/ > "Sorry, page not available", and then: >> As of October 1, 2007, the Macromedia® Flash® Player 7 SDK will no >> longer be available. The migration path for the Flash Player 7 SDK >> is Adobe® Flash Lite 3. >> The Adobe Flash Lite 3 runtime provides mobile and consumer electronics >> device manufacturers the ability to deliver the most engaging mobile >> experiences across devices. > Does the Flash Player SDK still exist as a product? I guess not. The main thing we need is a file called playerglobal.swc which is on the FlashPlayer downloads page. I had seen it referenced as the Flash Player SDK at one time, but it looks like that is no longer true. I will double-check and then update the proposal. > > 2) Action Script Virtual Machine (AVM) > In November 2006 Adobe open source the Flash Player Script engine: > http://www.mozilla.org/en-US/press/mozilla-2006-11-07.html > Is the source code of Tamarin still the current version of the Action > Script Virtual Machine in Flash Player 11? If there is a new version of > the AVM (2+), will that be contributed to the Apache Software Foundation > as well? > > It doesn't really make sense to only contribute a compiler, if there is > no open source implementation of a runtime/scripting engine available, > but that might only be my personal view. If the community would decide > to create a an open standards based runtime for Flex, would that mean > the community would have to start from zero? This proposal is about Adobe Flex which is separate from Tamarin. And separate from the future of Tamarin. I cannot speak to anything related to Tamarin. > > 3) Commercial support for Apache Flex > Does Adobe plan to offer support for an Apache Flex product? If yes, > what kind of support would be planned. I read somewhere that Adobe will > not offer any support for Flex 4.6+ to new customers, but I'm not sure, > if that's still the current plan. Adobe is not currently planning to offer support for Flex released from Apache, but that could change. > > 4) Flash Player > Are there any plans to open source a stripped-down version of Flash > Player, e.g. the discontinued version of Flash Player for mobile) in the > future (similar to the pure open source Flex SDK vs. the commercial > SDK)? The Apache community could continue working on a browser-based > mobile runtime for Apache Flex, if that was the case. This proposal is about Adobe Flex which, while it runs in the Flash Player, is separate from the Flash Player. I cannot speak to any plans related to the Flash Player. > > I hope I don't sound to skeptical here, but Adobe Flex is quite > different from most Apache projects I've been in contact with. It's a > powerful compiler with an interesting language, but it looks like the > output of the compiler can only be used with Adobe-owned proprietary > software at the moment. This proposal is about Adobe Flex which in my mind is largely the ActionScript source code that forms a framework that enables folks to easily and quickly produce useful applications. The compiler source we are donating in this proposal is actually being superceded by a whole new compiler code base in a project at Adobe called Falcon that will likely be donated to Apache later. Given that Tamarin is open source and the SWF file format is public, I don't think there is much to stop someone else from creating their own SWF player. So while the current reality is that these SWFs only run in Adobe-owned players, I don't think there is a technical reason for it. > > Raju > >> Hi everyone, >> >> I would like to propose Flex to be an Apache Incubator project. >> >> Here's a link to the proposal: >> http://wiki.apache.org/incubator/FlexProposal >> >> Thank you, >> >> Alex Harui >> Flex SDK Team >> Adobe Systems, Inc. >> http://blogs.adobe.com/aharui >> >> >> - >> 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 > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Flex for Apache Incubator
Listing them might be nearly impossible. I don't think we know them all. What are the rules around something like: riaflex dot blogspot dot com Or www dot cflex dot net I think there's lots of sites like these out there. Thanks, -Alex On 12/20/11 2:24 PM, "Ross Gardler" wrote: > The proposal says "Existing Flex-related conferences, podcasts and > websites should be allowed to continue using ³Flex² as part of their > name - Apache Flex will have to create guidelines for that." > > Whilst I don't see any problem with that in principle it would be > really useful to itemise these items so that we know what we are > dealing with. > > Ross > > On 20 December 2011 09:02, Leo Simons wrote: >> On Mon, Dec 19, 2011 at 9:20 PM, Alex Harui wrote: >>> I would like to propose Flex to be an Apache Incubator project. >>> >>> Here's a link to the proposal: >>> http://wiki.apache.org/incubator/FlexProposal >> >> Pasted inline: >> >> = Apache Flex Proposal = >> >> == Abstract == >> >> Apache Flex is an application framework for easily building >> Flash-based applications for mobile devices, the browser and desktop. >> >> == Proposal == >> >> Apache Flex allows developers to target a variety of platforms, >> initially Apple iOS, Google Android, RIM !BlackBerry, Microsoft >> Windows, and Mac OS X with a single codebase. Flex provides a >> compiler, skinnable user-interface components and managers to handle >> styling, skinning, layout, localization, animation, module-loading and >> user interaction management. >> >> == Background == >> >> Apache Flex is the software evolution of the popular Adobe Flex SDK project. >> Adobe Flex SDK evolved from the need to provide developers with an >> easy programming model for creating rich Internet applications that >> can run in the browser, on the desktop or on mobile devices. >> >> Adobe Flex SDK has always focused on a single goal: to provide >> application developers with all of the constructs needed to boost >> their productivity while building large-scale, visually expressive >> applications. This meant that Flex provided all the traditional UI >> components in a way that designers and developers could interact with >> them along with a dynamic scripting language, !ActionScript, and a >> declarative markup language, MXML. >> >> Adobe will donate the Flex trademark to the Apache Software Foundation >> as part of the incubation process. The source code, documentation and >> related assets will all be contributed to the Apache Foundation as >> Flex. >> >> == Rationale == >> >> Content developers need to target multiple screens and the cost of >> creating applications native to every target platform is high. >> Additionally, the dominant window to the web is quickly becoming >> devices, mostly phones, and delivering consistent experiences is key. >> The Apache Flex project exists to bring the focus back to a consistent >> development model, one where a single application can run the exact >> same way across the web, desktop and mobile devices. >> >> == Initial Goals == >> >> * Donate all Adobe Flex SDK source code and documentation to the >> Apache Software Foundation. >> * Setup and standardize the open governance of the Apache Flex project. >> * Rename all assets from Adobe Flex SDK to Apache Flex in project >> source code, docs, tests and related infrastructure. >> >> == Current Status == >> >> Flex is a mature software project. 1.0 was shipped in March of 2004 >> with 7 major releases having shipped since. The most recent release >> was the 4.6 version which shipped on November 29th, 2011. >> >> == Meritocracy == >> >> The Adobe Flex source code is available to the community on the Adobe >> opensource site: >> http://opensource.adobe.com/wiki/display/flexsdk/Flex+SDK. Currently, >> while the community has been invited to contribute patches to the >> codebase, only Adobe employees decided on which patches to commit. >> There were no external committers and this caused frustration in the >> community. >> >> Going forward, both Adobe and our community are eager to become one >> single merit-based community working together. To that end, Adobe >> will only have minority representation on the initial committers list. >> Adobe is working to educate our community with meetings and blog >> posts on how the Apache model makes this possible for them. >>
Re: [PROPOSAL] Flex for Apache Incubator
Hi Raju, Yes, we hope to contribute Falcon before it is finished, but it isn't ready to be contributed now, and the rest of the Flex SDK is and we have a large group of folks eager to get started on it. There will be some overlap between folks working on Falcon and on the SDK, but I think the overlap is small enough that Falcon might be its own project or sub-project proposal to the incubator. It is a separate code base and separate set of engineers in Adobe at this time. Deepa is on vacation right now, but when she returns she will be in a new role. Our understanding is that there isn't much need for Product Management if we get accepted into the incubator. I am pretty much the main point of contact with respect to Flex at Adobe and tasked with working out the timelines for when other Adobe source code will be contributed to Apache. This is a new road for me so I'm hoping to just get the Flex SDK in, learn from that experience and then work with other teams like the Falcon team to figure out a good timeframe for proposing their source code that minimizes impact to their schedules yet allows those interested to get involved. -Alex On 12/20/11 6:01 PM, "Raju Bitter" wrote: > Alex, > > I have been watching this recording of a session in the Flex Summit a week > ago: > http://tv.adobe.com/watch/flex-community-summit-december-2011/open-discussion- > about-falcon-and-falconjs/ > > Greg DeMichillie, Sr. Director of Product Management, and Danny > Winokur, VP/GM Interactive Business Unit are leading the discussion, > and in that discussion the conclusion seems to be that it makes sense > to contribute the unfinished Falcon compiler work to Apache. Falcon is > the next version of the ActionScript/MXML compiler for Flex, and will > bring performance improvements of 10 x to ActionScript compilation. > > The result of that discussion seems to be that > 1) The community should get access to the Falcon compiler BEFORE it > will be released. > 2) There is enough interest in the community to help Adobe finish the > Falcon ActionScript compiler. > 3) The community might be responsible for finishing the MXML -> > ActionScript compilation unit of Falcon. > > I'll try to reach out to Deepa Subramaniam to see if there has been a > decision made by now on the Falcon topic, but it might be easier for > you to reach out to Greg or Danny directly to see what the status is. > If Falcon would be contributed to Apache before the work has been > finished, that should be included in the proposal. > > Best, > Raju > > 2011/12/21 Alex Harui : >> Responses inline: >> >> >> On 12/20/11 12:30 PM, "Raju Bitter" wrote: >> >>> Hi Alex, >>> >>> re-reading the proposal, a few other questions came to my mind: >>> >>> 1) Flash Player SDK >>> What are you referring to, when listing the "Adobe Flash Player SDK" >>> under "External Dependencies". The Adobe website says: >>> http://www.adobe.com/products/flashplayer_sdk/ >>> "Sorry, page not available", and then: >>>> As of October 1, 2007, the Macromedia® Flash® Player 7 SDK will no >>>> longer be available. The migration path for the Flash Player 7 SDK >>>> is Adobe® Flash Lite 3. >>>> The Adobe Flash Lite 3 runtime provides mobile and consumer electronics >>>> device manufacturers the ability to deliver the most engaging mobile >>>> experiences across devices. >>> Does the Flash Player SDK still exist as a product? >> I guess not. The main thing we need is a file called playerglobal.swc which >> is on the FlashPlayer downloads page. I had seen it referenced as the Flash >> Player SDK at one time, but it looks like that is no longer true. I will >> double-check and then update the proposal. >>> >>> 2) Action Script Virtual Machine (AVM) >>> In November 2006 Adobe open source the Flash Player Script engine: >>> http://www.mozilla.org/en-US/press/mozilla-2006-11-07.html >>> Is the source code of Tamarin still the current version of the Action >>> Script Virtual Machine in Flash Player 11? If there is a new version of >>> the AVM (2+), will that be contributed to the Apache Software Foundation >>> as well? >>> >>> It doesn't really make sense to only contribute a compiler, if there is >>> no open source implementation of a runtime/scripting engine available, >>> but that might only be my personal view. If the community would decide >>> to create a an open standards based runtime for Flex, would that mean >>> the community would have to start from zero? >> T
Re: Flex status
On 3/12/12 9:39 AM, "Bertrand Delacretaz" wrote: >> >> It's a bit unfortunate that the migration is taking so long. Once you >> have everything in place, it would be great if you could take some >> time (perhaps together with people from OpenOffice) to compile a list >> of lessons learned for use by potential future podlings that need to >> migrate a large and complex project history to Apache... > > Ok, IIUC the main hurdles are legal vetting of some parts of the code > on the Adobe side, and trouble getting the JIRA data imported > (INFRA-4380). Both are also taking more time than expected. > Other issues are that Infra doesn't always get on things right away so a JIRA import file I submit may take a week before someone actually tries it and finds it doesn't work, and that Apache (and Adobe) didn't have a good way to transfer multi-GB files. More disk space on the Apache private folder server or an FTP dropbox would be helpful. There is also a question of scalability. Having everyone in one SVN repository really puts a strain when donating tons of files because the SVN import for a project has to take down SVN for others. And of course, the question of disk space on the server. Similar for JIRA instances. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Revised Flex Podling Report for April
Hello, Per advice from our Mentors, I have edited the text in the “how can incubation run more smoothly” section of the Flex report for April. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [MENTORS] Third Party source
On 6/7/12 1:58 PM, "Greg Reddin" wrote: > Hi Incubator, > > See the email below from Alex Harui. I need help figuring out what to do here. > > I'm not sure if Jeff was ever an employee of Macromedia or what the > full situation is. Perhaps Alex can clarify if needed. Jeff was an employee of Macromedia and Adobe but left before Adobe donated his code. > > Essentially, we wanted to offer Jeff commit rights to make the > modification as suggested by Roy. But Jeff indicated he's too busy to > do it. Since he owns the copyright and seems willing to donate the > code, what would be the appropriate methodology here. Do we need a > software grant? Would it be sufficient to have an ICLA on file from > Jeff? Adobe already donated the code with Jeff's permission, but with Jeff's copyright still in the headers per [1], which also says we should not modify the copyright in those headers without his permission. "Should a project move non-ASF copyright notices from Apache source files to the NOTICE file? No. If the copyright owner is still involved with the project, they should move the notice themselves or permit us to do so..." [1] http://www.apache.org/legal/src-headers.html -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [MENTORS] Third Party source
On 6/7/12 3:00 PM, "Greg Stein" wrote: >> "Should a project move non-ASF copyright notices from Apache source files to >> the NOTICE file? >> No. If the copyright owner is still involved with the project, they should >> move the notice themselves or permit us to do so..." > > That policy exists for us to be nice to the original copyright holder, > and to ensure that we don't accidentally remove a statement. > > Since we have the grant from Adobe, just move the copyright notice > yourself. I suspect we'd even have the right to remove it entirely, > but again: to be nice, we'll retain it in the NOTICE file. > > Jeff doesn't have to do it himself: that's just deference to his > wishes and ensuring that we don't pre-suppose or get them wrong. > No offense, but are you absolutely sure? Unless I misunderstood the Adobe legal team, we could not remove the copyrights without Jeff's permission, otherwise we would have done so prior to donation. Furthermore, in [1] it also says the following: "Treatment of Third-Party Works The term "third-party work" refers to a work not submitted directly to the ASF by the copyright owner or owner's agent. Do not modify or remove any copyright notices or licenses within third-party works. Do ensure that every third-party work includes its associated license, even if that requires adding a copy of the license from the third-party download site into the distribution. Do not add the standard Apache License header to the top of third-party source files. Minor modifications/additions to third-party source files should typically be licensed under the same terms as the rest of the rest of the third-party source for convenience. Major modifications/additions to third-party should be dealt with on a case-by-case basis by the PMC." [1] http://www.apache.org/legal/src-headers.html The Adobe legal team and Roy both agreed that we need permission or give him committer status. Thanks, -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [MENTORS] Third Party source
On 6/7/12 3:33 PM, "Greg Stein" wrote: > On Thu, Jun 7, 2012 at 6:13 PM, Greg Reddin wrote: >> On Thu, Jun 7, 2012 at 5:00 PM, Greg Stein wrote: >>> Jeff doesn't have to do it himself: that's just deference to his >>> wishes and ensuring that we don't pre-suppose or get them wrong. >> >> Ah, so there's no legal requirement to deal with here. Adobe cleared >> that up with the software grant? > > From the description you provided, it sounded like Jeff was employed > by Adobe when he wrote the code. Thus, Adobe actually owns the > copyrights via work-for-hire rules. And thus, Adobe has the right to > grant his work to the ASF under the already-filed Software Grant. > > So based on my understanding from your description: yeah. We don't > need anything from Jeff. > > To be polite, we ask his wishes (and he's already said "whatever", it > seems), but we don't *have* to ask. > Jeff ran a company and wrote the code while at that company then was acquired by Macromedia (and then by Adobe). The copyrights are for that company, and the agreement when acquiring Jeff and his company was such that Adobe retained his company's copyright in the headers of those files. Otherwise, the headers would have copyright to Adobe and would have just changed them. Thanks, -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [MENTORS] Third Party source
On 6/8/12 9:07 AM, "Sam Ruby" wrote: > On Fri, Jun 8, 2012 at 9:28 AM, Kalle Korhonen > wrote: >> On Thu, Jun 7, 2012 at 11:06 PM, Roy T. Fielding wrote: >>> I fear we are miscommunicating again. >>> Only the copyright owner is allowed to (re)move copyright notices >>> or permit others to (re)move them on the owner's behalf. >> >> Interesting, why is that? Is it so by the law? > > It would be helpful if somebody could point out the actual words in > the copyright headers being discussed. I may have missed it. I will describe the situation in more detail below. > > In this case, Adobe isn't hard to reach here. We should seek their > opinion, and respect it. Adobe legal's opinion will be included in the detail below. > > If Adobe wishes us to retain the headers, my opinion is that we should > evaluate the impact that such a request will have on the community, > and either follow their request or decline the contribution. > > If Adobe collectively takes the time to understand our position and > agrees to moving it, there are a number of ways that this can be > expressed clearly. I still maintain that having an Adobe employee do > such a move would be the simplest and clearest way, but other ways are > possible too. Here is a more detailed description of the situation: An individual starts a company and writes some code. Macromedia acquires that individual and the code. Each source file has a header: /* * Written by Individual * Copyright (c) 1998-2003 Individual's Company * All rights reserved. */ Adobe acquires Macromedia. The code is incorporated into a larger product via Macromedia and Adobe engineers. New files in the larger product have Adobe copyrights, but the acquired code must retain the original copyrights according to Adobe Legal. The individual leaves Adobe. Adobe wishes to donate the code to Apache. The individual's agreement upon acquisition allows Adobe to donate such code and it is donated via a software grant. Adobe Legal says that Adobe engineers can replace the Adobe copyrights with Apache headers, but Adobe engineers still do not have the right to replace the individual's copyrights in the other files, and [1] says that Apache folks should not either. So, this is not really an Adobe issue. Adobe does not own the copyright to the files in question and therefore cannot agree to moving it, but Adobe did have permission to donate the code. The individual involved is willing to allow the copyright to be moved, and we asked here to find out how formal the permission referred to in [1] must be. [1] http://www.apache.org/legal/src-headers.html -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [MENTORS] Third Party source
On 6/8/12 11:36 AM, "Greg Stein" wrote: > On Jun 8, 2012 2:33 PM, "Sam Ruby" wrote: >> >> On Fri, Jun 8, 2012 at 1:28 PM, Alex Harui wrote: >>> >>> The individual involved is willing to >>> allow the copyright to be moved, and we asked here to find out how > formal >>> the permission referred to in [1] must be. >>> >>> [1] http://www.apache.org/legal/src-headers.html >> >> Would it be possible for the individual to send a signed letter to >> secret...@apache.org? Or fax such to to +1-919-573-9199? >> >> If such is possible,we will file it in our foundation records and >> confirm to the PPMC that it has been received. > > As Roy said, why not just an email to flex-dev? Sam, I had already asked the individual to send an email to flex-dev before I saw your reply. I will try to remember to forward a copy to secretary@ Thanks, -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: RAT status page gone?
On 6/10/12 8:50 PM, "David Crossley" wrote: > The RAT status page is giving a 404 Not Found > http://incubator.apache.org/projects/rat.html > > The source is still there in SVN at content/projects/rat.xml > but the generated html is gone on the server. > > Perhaps Robert deleted it by accident when doing graduation tidy up. > > Anyway i tried editing that page source and podlings.xml hoping > that the CMS would regenerate it. No. > > Can someone help? > I think Rat became Creadur [1]. [1] http://creadur.apache.org/ -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: What is the legal basis for enforcing release policies at ASF?
On 8/20/15, 5:27 PM, "William A Rowe Jr" wrote: >It is generally AL code all the time. I don't know where you invented a >'kick-in' concept, but unless the committers are violating their >ICLA/CCLA, >nothing could be further from the truth. Committers sometimes make mistakes. IIRC, Justin recently caught a mistake where some files accidentally got their non-AL headers replaced with AL headers. Large codebase contributions, especially initial podling code grants might be messy as well until scrubbed and approved for an official ASF release. I know from experience. -Alex
Re: Question related to IP Clearance and software grant
On 9/1/15, 7:16 AM, "Emmanuel Lécharny" wrote: >Hi guys, > >is a code donation require a software grant signed from the employer of >the people who wrote the code ? In other words, do we require that the >employer explicitely allow the employees to work on some code ? > >M understanding is that it's required, and the employer must sign the >grant and a CCLA (or add the employee names to an existing CCLA, >extending it). Is that correct ? IANAL, but IMO, there are three separate issues: 1) Who can sign the grant? Some person or entity owns the code and someone with authority from said entity must sign the grant. Employees rarely own code. I have to go up about 3 levels of management to get a VP who has sufficient authority to sign grants for my employer. 2) Who are the initial committers? If there is any such requirement that initial committers must be folks who wrote the code, then Flex was certainly an exception. Only a very small subset of folks who wrote the code were on the initial committers list. However, there was a sufficient group of customers that volunteered to create a community around Flex. 3) How can employees contribute? That’s up to the employee and employer, but it is important to make sure you understand the rules. There are employers that own what you do no matter when you do it. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly
Apologies if I’m way off base here as I’m not familiar with Corinthia or QT Editor. If Corinthia were to develop the web-based editor mentioned upthread and make that the preferred/recommended editor for the project, does that make the QT Editor optional enough for Apache? Apache Flex is a UI Toolkit for web apps as well as desktop and mobile apps and the community is working on a version that outputs HTML/JS/CSS that can be consumed by Apache Cordova to target multiple platforms. -Alex On 9/7/15, 2:37 AM, "Greg Stein" wrote: >On Sep 7, 2015 4:12 PM, "Jochen Theodorou" wrote: >>... >> I am not sure that approach is realistic. I mean, if you say it must be >optional and not required, then there must be an existing alternative. And >that alternative must be not LGPL. If there is such a toolkit, then why >not >go with that right away? The project has to manage its resources well. > >Exactly. Without an alternative, then you have a pile of code that doesn't >meet any user expectations. > >If it can be released as a library, for downstream users to produce an >editor, then okay. But an releasing an editor with no UI is kind of a >non-starter. :-( > >Given the UI landscape, and its licensing, I can see why Corinthia would >like to host elsewhere. One day, we'll see some permissive UI >libraries > >Cheers, >-g
