Please add me to the ContributorsGroup for wiki.apache.org
Hi folks, I'm a new mentor of JSPWiki but unable to to make any changes (everything in an InmutablePage) - my login name is SiegfriedGoeschl Thanks in advance Siegfried Goeschl On 10.01.13 17:12, Marvin Humphrey wrote: On Thu, Jan 10, 2013 at 8:05 AM, Craig L Russell craig.russ...@oracle.com wrote: I've reviewed the report and hereby sign off on the report. The wiki page is marked as immutable. Is it just me? What's the username you use to log into http://wiki.apache.org/incubator? I suspect we need to add you to the ContributorsGroup, because I don't see anything resembling your name in either there or Administrators. See the boxed explanation at the top of the main wiki page. 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: Mesos - Shepherd's report
Hi Christian, I'm at BenjaminHindman (http://wiki.apache.org/incubator/BenjaminHindman). Thank you! Ben. On Sat, Jan 12, 2013 at 12:57 PM, Christian Grobmeier grobme...@gmail.comwrote: On a side note: if you want access to the wiki, no problem. Just mail your wiki name from this wiki: http://wiki.apache.org/incubator/ to genera@, and one of us will (hopefully) add you to the contributors group, which will allow you to post/edit your reports (and other stuff) Cheers Christian On Fri, Jan 11, 2013 at 9:04 PM, Andy Konwinski an...@berkeley.edu wrote: I've updated the wiki with the report text that Ben wrote. Thanks Ben! Also, thanks Alan for your friendly nudge. Andy On Fri, Jan 11, 2013 at 10:41 AM, Alan Cabrera l...@toolazydogs.com wrote: Sure! I'll add it this morning. Regards, Alan On Jan 11, 2013, at 10:26 AM, Benjamin Hindman wrote: Hi Alan, I don't have access to update the wiki. Is that something that you can help me resolve? In the mean time, I pinged one of the other committers yesterday to update the wiki with the following report (but haven't heard anything back yet): -- Three most important issues to address in the move towards graduation: 1. Add more committers (see issues below). 2. Do more releases (see issues below). 3. Grow community (do more meetups and try and get more people interested in hacking on codebase rather than just using the software). Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware of? We've had issues getting enough votes for adding committers and doing releases. We recently added a new mentor (thank you Jakob Homan!) who promptly helped out on one of our stalled releases, but we still have yet to conclude a committer vote (to be clear, the vote has received unanimous +1's from all existing committers, but nothing from any mentors). How has the community developed since the last report? We performed a meetup at AirBnB which drew a large crowd. The mailing list continued to be active in December. People are generally interested and excited about the project, but we have not gotten very many developers working in the codebase. We hope to rectify this in the coming months by holding some developer specific meetups to talk about working on and contributing to the project. How has the project developed since the last report? There were a considerable number of bug fixes, especially around the use of Linux cgroups for doing resource isolation. There was also a lot of work done on the slave/worker component of the system to enable upgrading Mesos without killing all tasks/processes that it is managing. See https://reviews.apache.org/dashboard/?view=to-groupgroup=mesos. On Fri, Jan 11, 2013 at 10:01 AM, Alan Cabrera l...@toolazydogs.com wrote: No report filed. No mentor interaction to get report out. With that said, the project seems pretty active. I'm wondering why they haven't graduated yet. With that said, the project needs more than one mentor, IMHO. Regards, Alan -- 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
Re: [DISCUSS] Expressing priorities about release reviews
I'd like to try to break this down a bit. I'm ignoring, for this reply, the questions Joe raises about supervising things other than the legal metadata. 1. Why are podlings having so much trouble getting the legal metadata correct? Every single existing Apache release is a sample. The top problem area seems to be NOTICE and LICENSE, with notices on individual source files far behind. 2. I agree with some in this thread that problems in this area are not sufficient reason to block any _single_ release. Copyright comes into existence whether or not you paste a notice on it. Failing to respect a third-party notice requirement is rude, but, as someone pointed out, is not a giant legal exposure. I also have a suspicion that many podling _releases_ (i.e. the source) have, in fact, no third-party license exposure at all. While it might not deserve to block any one release, I agree with the point that we can't be graduating podlings who don't know how to maintain this metadata. If (and I'm not being rhetorical here) we treat these as 'fix it next time', we'd better be sure that there is a next time. 3. Most of the reviewing in this area is done by sebb. We're lucky to have him paying attention to this at all, because it sure seems sometimes as if no one else does. Adding all of this up, I've got a very modest proposal. Let's create a checklist, put it prominently at the top of the relevant doc, and then see if we can't improve the visibility of this. Sebb, could I ask you to dump your checklist into this email thread? On Sat, Jan 12, 2013 at 5:59 PM, Craig L Russell craig.russ...@oracle.com wrote: The way I look at release reviews is that releases are the things that expose the Apache Foundation to the greatest legal risk, so it's critical that podlings learn to get them right. If they (podlings) don't get releases right in the incubator, what chance is there that they will succeed as a PMC? Technical review can only be done by folks who are knowledgeable about the code base. These are the committers on the project. Process review can be done by mentors. Ideally, license and notice reviews should be done first by mentors. But I don't expect that mentors will necessarily know as much as people in IPMC (and other volunteer release reviewers) about the legal requirements for release. From my perspective, even though it is at times painful, the release process works well. Everyone in the incubator contributes what they can to make sure that podlings learn how to release, and how important it is to release clean code. Even if the code doesn't work, the process does. Craig On Jan 12, 2013, at 11:29 AM, Joe Schaefer wrote: Yes you make a good point- that any effort towards review is welcome and appreciated. It's just that having an exclusive focus on the things we can actually review here, namely adherence to License and Notice policy, can leave people with the mistaken impression that that's all that a PMC should concern itself with. All of that daily effort that goes into validating commits on a project really should garner more appreciation from the PMC, if we could just find a way to be more trusting about who we let issue binding votes on behalf of the org. 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. From: Sergio Fernández sergio.fernan...@salzburgresearch.at To: general@incubator.apache.org Cc: Joe Schaefer joe_schae...@yahoo.com Sent: Saturday, January 12, 2013 2:22 PM Subject: Re: [DISCUSS] Expressing priorities about release reviews Joe, personally I appreciate such policies checking from the IPMC members. The technical quality of a release is responsibility of the project itself, which could be hard to be evaluated by people working on other topics. Therefore, all additional checkpoints are useful and grateful. Cheers, On 12/01/13 18:07, Joe Schaefer wrote: One of my long time pet peeves with how we PMC members participate in vetting releases is our penchant for focusing too much on the policies surrounding license and notice info. I really think our exclusive focus on things that really don't pose any organizational risk to either the org nor the project participants serves us well in our other, often unexpressed but far more relevant, goals about encouraging committers to participate in active review of their project's commit activity. Just think about this for a second, what's more likely for people to start suing us over, some bug in the NOTICE file or an undetected backdoor in one of our programs? I am personally far more concerned about the current state of the
The report/review cycle
This time around, the timing was as follows: Wed 09-01-2013: Deadline for podling reports Friday 11-01-2013: Practical board deadline Wed 16-01-2013: Board meeting In other words, we had a two day window for shepherds to digest reports, then go dig around to fill in their picture. Now, maybe things were unusually bad because of folks out for the new year until 07-01-2013. But, still, I feel as if we don't have enough time to react to reports (or the lack of reports) before we need to have the board report in place. What do people think of making the podling reporting deadline be a full week before the board's deadline? The board wants a weekend to review reports before they meet; I'd like a weekend for us to review reports before we need to get them delivered to the board. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Mesos - Shepherd's report
Added you Cheers Christian On Sat, Jan 12, 2013 at 10:08 PM, Benjamin Hindman benjamin.hind...@gmail.com wrote: Hi Christian, I'm at BenjaminHindman (http://wiki.apache.org/incubator/BenjaminHindman). Thank you! Ben. On Sat, Jan 12, 2013 at 12:57 PM, Christian Grobmeier grobme...@gmail.comwrote: On a side note: if you want access to the wiki, no problem. Just mail your wiki name from this wiki: http://wiki.apache.org/incubator/ to genera@, and one of us will (hopefully) add you to the contributors group, which will allow you to post/edit your reports (and other stuff) Cheers Christian On Fri, Jan 11, 2013 at 9:04 PM, Andy Konwinski an...@berkeley.edu wrote: I've updated the wiki with the report text that Ben wrote. Thanks Ben! Also, thanks Alan for your friendly nudge. Andy On Fri, Jan 11, 2013 at 10:41 AM, Alan Cabrera l...@toolazydogs.com wrote: Sure! I'll add it this morning. Regards, Alan On Jan 11, 2013, at 10:26 AM, Benjamin Hindman wrote: Hi Alan, I don't have access to update the wiki. Is that something that you can help me resolve? In the mean time, I pinged one of the other committers yesterday to update the wiki with the following report (but haven't heard anything back yet): -- Three most important issues to address in the move towards graduation: 1. Add more committers (see issues below). 2. Do more releases (see issues below). 3. Grow community (do more meetups and try and get more people interested in hacking on codebase rather than just using the software). Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware of? We've had issues getting enough votes for adding committers and doing releases. We recently added a new mentor (thank you Jakob Homan!) who promptly helped out on one of our stalled releases, but we still have yet to conclude a committer vote (to be clear, the vote has received unanimous +1's from all existing committers, but nothing from any mentors). How has the community developed since the last report? We performed a meetup at AirBnB which drew a large crowd. The mailing list continued to be active in December. People are generally interested and excited about the project, but we have not gotten very many developers working in the codebase. We hope to rectify this in the coming months by holding some developer specific meetups to talk about working on and contributing to the project. How has the project developed since the last report? There were a considerable number of bug fixes, especially around the use of Linux cgroups for doing resource isolation. There was also a lot of work done on the slave/worker component of the system to enable upgrading Mesos without killing all tasks/processes that it is managing. See https://reviews.apache.org/dashboard/?view=to-groupgroup=mesos. On Fri, Jan 11, 2013 at 10:01 AM, Alan Cabrera l...@toolazydogs.com wrote: No report filed. No mentor interaction to get report out. With that said, the project seems pretty active. I'm wondering why they haven't graduated yet. With that said, the project needs more than one mentor, IMHO. Regards, Alan -- 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 -- 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
Re: The report/review cycle
That would help a lot, especially with the all mentors sign policy. The chance that one or more mentor is unable to review and sign a report with a day or so notice is unfortunately high. A few more days in that schedule would make the probability of getting all three sigs much higher. On Sun, Jan 13, 2013 at 4:52 AM, Benson Margulies bimargul...@gmail.comwrote: What do people think of making the podling reporting deadline be a full week before the board's deadline? The board wants a weekend to review reports before they meet; I'd like a weekend for us to review reports before we need to get them delivered to the board.
Re: [DISCUSS] Expressing priorities about release reviews
On 13/01/13 12:45, Benson Margulies wrote: ... 3. Most of the reviewing in this area is done by sebb. We're lucky to have him paying attention to this at all, because it sure seems sometimes as if no one else does. Adding all of this up, I've got a very modest proposal. Let's create a checklist, put it prominently at the top of the relevant doc, and then see if we can't improve the visibility of this. Sebb, could I ask you to dump your checklist into this email thread? +1 We need to clone sebb's reviewing process as good practice and it would pull together the knowledge about NL. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: The report/review cycle
Hi, On Sun, Jan 13, 2013 at 2:52 PM, Benson Margulies bimargul...@gmail.com wrote: What do people think of making the podling reporting deadline be a full week before the board's deadline? That's what it used to be. Did it change? BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: The report/review cycle
It is a week before the board meeting, but not a week before the weekend before the board meeting. The board asked me to have our report in place by the end of the Friday before the Wednesday of the board meeting so that they could review over the weekend. On Sun, Jan 13, 2013 at 10:57 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Sun, Jan 13, 2013 at 2:52 PM, Benson Margulies bimargul...@gmail.com wrote: What do people think of making the podling reporting deadline be a full week before the board's deadline? That's what it used to be. Did it change? BR, Jukka Zitting - 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
Using the incubator space to release new languages
OpenOffice 3.4.1, released in 20 languages when it was still undergoing incubation in 2012, will be released in 8 more languages later this month. We will keep the version number at 3.4.1 and release a patch to the current 3.4.1 sources that contains just the language support for the new languages. So we plan to use the incubator space again, and add new files to http://www.apache.org/dist/incubator/ooo/files/stable/3.4.1/ http://www.apache.org/dist/incubator/ooo/files/localized/ With version 4.0, scheduled for April 2013, we will clean up our incubator files. Note that this has no impact on end-user downloads, that are served from the SourceForge network. But still, since this is probably unusual for other projects, I preferred to send you this warning in advance. Best regards, Andrea Pescetti - Apache OpenOffice PMC. - 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 Sun, Jan 13, 2013 at 4:45 AM, Benson Margulies bimargul...@gmail.com wrote: 1. Why are podlings having so much trouble getting the legal metadata correct? * Our documentation on legal metadata is ill-organized, voluminous, and ultimately overwhelming. * The NOTICE construct is fundamentally confusing. * Few software developers have the patience, the temperament, and more than anything else the raw hours to acquire a lot of expertise about licensing. Adding all of this up, I've got a very modest proposal. Let's create a checklist, put it prominently at the top of the relevant doc, and then see if we can't improve the visibility of this. I am skeptical that the information necessary to build LICENSE and NOTICE can be expressed in a checklist. The problem is that LICENSE and NOTICE still start as blank pages, and filling them in from scratch requires expertise which is costly to acquire. I suspect that a LICENSE-o-matic approach will yield better results, because it relieves the developer from having to conceive of a basic structure for LICENSE and NOTICE. Here is some sample pseudocode for appending dependency information to NOTICE: SUBROUTINE append_to_notice(notice, dependency): # Only bundled dependencies get considered for NOTICE! IF NOT dependency.bundled: RETURN IF dependency.license IS MIT_X11: PASS # No NOTICE requirement ELIF dependency.license IS THREE_CLAUSE_BSD: PASS # No NOTICE requirement ELIF dependency.license IS APACHE_LICENSE_V2: IF has_notice_file(dependency): IF is_apache_product(dependency): ... ELSE ... ELIF dependency.license IS FOUR_CLAUSE_BSD: ... ... # Recurse for nested dependencies. FOR nested_dependency IN dependency.nested_dependencies: append_to_notice(notice, nested_dependency) For the beginning of such a document, see... How-to guide for Assembling LICENSE and NOTICE https://issues.apache.org/jira/browse/INCUBATOR-125 PS: This thread was originally about how our hyper-focus on LICENSE and NOTICE distracts us from more important concerns, both legal and social. I agree with that assessment and regret contributing to the diversion once more. Marvin Humphrey - 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 Sun, Jan 13, 2013 at 12:51 PM, Marvin Humphrey mar...@rectangular.com wrote: On Sun, Jan 13, 2013 at 4:45 AM, Benson Margulies bimargul...@gmail.com wrote: 1. Why are podlings having so much trouble getting the legal metadata correct? * Our documentation on legal metadata is ill-organized, voluminous, and ultimately overwhelming. * The NOTICE construct is fundamentally confusing. * Few software developers have the patience, the temperament, and more than anything else the raw hours to acquire a lot of expertise about licensing. Adding all of this up, I've got a very modest proposal. Let's create a checklist, put it prominently at the top of the relevant doc, and then see if we can't improve the visibility of this. I am skeptical that the information necessary to build LICENSE and NOTICE can be expressed in a checklist. The problem is that LICENSE and NOTICE still start as blank pages, and filling them in from scratch requires expertise which is costly to acquire. I suspect that a LICENSE-o-matic approach will yield better results, because it relieves the developer from having to conceive of a basic structure for LICENSE and NOTICE. Here is some sample pseudocode for appending dependency information to NOTICE: SUBROUTINE append_to_notice(notice, dependency): # Only bundled dependencies get considered for NOTICE! IF NOT dependency.bundled: RETURN IF dependency.license IS MIT_X11: PASS # No NOTICE requirement ELIF dependency.license IS THREE_CLAUSE_BSD: PASS # No NOTICE requirement ELIF dependency.license IS APACHE_LICENSE_V2: IF has_notice_file(dependency): IF is_apache_product(dependency): ... ELSE ... ELIF dependency.license IS FOUR_CLAUSE_BSD: ... ... # Recurse for nested dependencies. FOR nested_dependency IN dependency.nested_dependencies: append_to_notice(notice, nested_dependency) For the beginning of such a document, see... How-to guide for Assembling LICENSE and NOTICE https://issues.apache.org/jira/browse/INCUBATOR-125 PS: This thread was originally about how our hyper-focus on LICENSE and NOTICE distracts us from more important concerns, both legal and social. I agree with that assessment and regret contributing to the diversion once more. Let me start from the p.s.. I agree that we currently seem to spend a depressingly large amount of time on these. However, I don't see how to fix that by just telling ourselves that they are not very important. I think we need to fix this by finding a way to make it much easier to get them right. I'm all ears as to all possible ways to accomplish this. In terms of the other possible areas of attention, I sadly think that this becomes the same old discussion about mentors. The people who are supposed to be ensuring adequate supervision for what gets committed are the mentors. If we continue to be unable to maintain adequate levels of mentor involvement, we have a bigger problem. Sebb's critique's of NOTICE and LICENSE are rarely at the level of 'hey, this would be the right license in the right file but it's an MIT license so you don't need to bother.' More of the time, as I see it, the critique is that one or both is missing altogether, or that completely backwards contents are present in them. I will add some comments to the JIRA. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Commented] (INCUBATOR-125) How-to guide for Assembling LICENSE and NOTICE
[ https://issues.apache.org/jira/browse/INCUBATOR-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552284#comment-13552284 ] Benson Margulies commented on INCUBATOR-125: I have some questions / suggestion here. 1. I want to start by noting that ** Apache Releases Are Source Releases **. So I'm somewhat unclear on how convenience binaries fit in. 2. This document would benefit from a brief definition of what the files are at the top. I am going to try to stir up assistance from legal. How-to guide for Assembling LICENSE and NOTICE Key: INCUBATOR-125 URL: https://issues.apache.org/jira/browse/INCUBATOR-125 Project: Incubator Issue Type: Improvement Components: site Reporter: Marvin Humphrey Attachments: licensing_howto.mdtext While the ASF provides reference documentation for LICENSE and NOTICE, confusion persists and existing versions vary widely in quality. To address these problems, we should augment the reference documentation with a how-to guide which provides formulaic instructions for assembling LICENSE and NOTICE under common conditions. One key feature of this how-to should be a mapping of approved licenses to what they require as far as NOTICE. This mapping will help PMCs determine when the licensing information of a dependency contains a required third party notice which must be added to NOTICE. There are at least four possible locations where this how-to might live: * www.apache.org/dev/licensing_howto.html -- probably the best location, considering the intended audience. * www.apache.org/legal/licensing_howto.html -- if legal wants it. * incubator.apache.org/guides/licensing_howto.html -- probably not ideal, because the information applies to TLPs as well as podlings and we have a problem with duplication. * Somewhere on community.apache.org -- in theory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - 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
We can also add a checklist item to the top level checklists, to be done as part of the source migration: Add LICENSE and NOTICE files to the top level repository directory. [I don't know if there is anything more specific than that, because where a project is using project/trunk, project/site, project/branches style it would go into the project/trunk directory and thence propagated to branches etc.] Craig On Jan 13, 2013, at 7:51 AM, Andy Seaborne wrote: On 13/01/13 12:45, Benson Margulies wrote: ... 3. Most of the reviewing in this area is done by sebb. We're lucky to have him paying attention to this at all, because it sure seems sometimes as if no one else does. Adding all of this up, I've got a very modest proposal. Let's create a checklist, put it prominently at the top of the relevant doc, and then see if we can't improve the visibility of this. Sebb, could I ask you to dump your checklist into this email thread? +1 We need to clone sebb's reviewing process as good practice and it would pull together the knowledge about NL. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@oracle.com P.S. A good JDO? O, Gasp! - 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
There have been many opinions expressed over the last few years about what constitutes a release. At least one opinion was that having the source in SCM that is freely available constitutes release and therefore best practice is to mark the source directory with the appropriate source LICENSE and NOTICE. Obviously, the LICENSE and NOTICE might be different for binary releases that include some dependencies that are distributed only with convenience binary releases. But many of the incubator release issues I've seen could have been avoided simply by including the LICENSE and NOTICE files in the source root, making it very difficult to release source without these files. Craig On Jan 13, 2013, at 2:14 PM, Benson Margulies wrote: Is it actually required to have these files in SCM in any particular location, or just to have a build/packaging process that delivers them in the package? On Sun, Jan 13, 2013 at 3:30 PM, Craig L Russell craig.russ...@oracle.com wrote: We can also add a checklist item to the top level checklists, to be done as part of the source migration: Add LICENSE and NOTICE files to the top level repository directory. [I don't know if there is anything more specific than that, because where a project is using project/trunk, project/site, project/branches style it would go into the project/trunk directory and thence propagated to branches etc.] Craig On Jan 13, 2013, at 7:51 AM, Andy Seaborne wrote: On 13/01/13 12:45, Benson Margulies wrote: ... 3. Most of the reviewing in this area is done by sebb. We're lucky to have him paying attention to this at all, because it sure seems sometimes as if no one else does. Adding all of this up, I've got a very modest proposal. Let's create a checklist, put it prominently at the top of the relevant doc, and then see if we can't improve the visibility of this. Sebb, could I ask you to dump your checklist into this email thread? +1 We need to clone sebb's reviewing process as good practice and it would pull together the knowledge about NL. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@oracle.com P.S. A good JDO? O, Gasp! - 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 Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@oracle.com P.S. A good JDO? O, Gasp! - 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 Sun, Jan 13, 2013 at 5:34 PM, Craig L Russell craig.russ...@oracle.com wrote: There have been many opinions expressed over the last few years about what constitutes a release. At least one opinion was that having the source in SCM that is freely available constitutes release and therefore best practice is to mark the source directory with the appropriate source LICENSE and NOTICE. Obviously, the LICENSE and NOTICE might be different for binary releases that include some dependencies that are distributed only with convenience binary releases. But many of the incubator release issues I've seen could have been avoided simply by including the LICENSE and NOTICE files in the source root, making it very difficult to release source without these files. I'm happy to state a best practice here. At the same time, I'd like to establish a firm basis of actual requirements that we can refer to, which I why I opened LEGAL-155. Craig On Jan 13, 2013, at 2:14 PM, Benson Margulies wrote: Is it actually required to have these files in SCM in any particular location, or just to have a build/packaging process that delivers them in the package? On Sun, Jan 13, 2013 at 3:30 PM, Craig L Russell craig.russ...@oracle.com wrote: We can also add a checklist item to the top level checklists, to be done as part of the source migration: Add LICENSE and NOTICE files to the top level repository directory. [I don't know if there is anything more specific than that, because where a project is using project/trunk, project/site, project/branches style it would go into the project/trunk directory and thence propagated to branches etc.] Craig On Jan 13, 2013, at 7:51 AM, Andy Seaborne wrote: On 13/01/13 12:45, Benson Margulies wrote: ... 3. Most of the reviewing in this area is done by sebb. We're lucky to have him paying attention to this at all, because it sure seems sometimes as if no one else does. Adding all of this up, I've got a very modest proposal. Let's create a checklist, put it prominently at the top of the relevant doc, and then see if we can't improve the visibility of this. Sebb, could I ask you to dump your checklist into this email thread? +1 We need to clone sebb's reviewing process as good practice and it would pull together the knowledge about NL. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@oracle.com P.S. A good JDO? O, Gasp! - 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 Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@oracle.com P.S. A good JDO? O, Gasp! - 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: The report/review cycle
Hi Benson, + 1 for this time line, it really helps to have shepherds a day or two. I am sorry I couldn't get my shepherd reports in this time with post-holiday catchup and sickness. I do not want to add too much to the process, but want to understand the buffer between shepherd comments and your consolidated summary to the board. Working backwards: * Friday (before the board meeting week) VP IPMC submits the consolidated report to the board. * Shepherds review the mentor signed off reports and other activity and add comments - Tentatively Due by ? * Podling's draft the report and mentors sign off by Wednesday (a week before the board meets). I do think we have to leave it to each podling how they work through the reporting process, but having a suggested timeline and workflow at [1] might help the new podlings understand how the report funnels to the board. Something like... PPMC drafts the reports in the dev list - Mentors iterate any comments and sign off - Shepherds review and provide any kudos external advice/comments - IPMC chair compiles the report with a over all summary (with an appendix of all podling reports) - Added to the board agenda - Board members shepherd through the IPMC report - (feedback follows back?) It might be also helpful to explain in the same document, once the project graduates how the process cuts short into ...TLP PMC chair drafts the report (with feedback from PMC) - Added to the board agenda - Board members shepherd the PMC report - feedback is sent to PMC private list Cheers, Suresh [1] - http://incubator.apache.org/guides/ppmc.html On Jan 13, 2013, at 7:52 AM, Benson Margulies bimargul...@gmail.com wrote: This time around, the timing was as follows: Wed 09-01-2013: Deadline for podling reports Friday 11-01-2013: Practical board deadline Wed 16-01-2013: Board meeting In other words, we had a two day window for shepherds to digest reports, then go dig around to fill in their picture. Now, maybe things were unusually bad because of folks out for the new year until 07-01-2013. But, still, I feel as if we don't have enough time to react to reports (or the lack of reports) before we need to have the board report in place. What do people think of making the podling reporting deadline be a full week before the board's deadline? The board wants a weekend to review reports before they meet; I'd like a weekend for us to review reports before we need to get them delivered to the board. - 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: The report/review cycle
On Sun, Jan 13, 2013 at 4:52 AM, Benson Margulies bimargul...@gmail.com wrote: What do people think of making the podling reporting deadline be a full week before the board's deadline? I think this would be extremely helpful. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: The report/review cycle
On Sun, Jan 13, 2013 at 6:34 PM, Suresh Marru sma...@apache.org wrote: Hi Benson, + 1 for this time line, it really helps to have shepherds a day or two. I am sorry I couldn't get my shepherd reports in this time with post-holiday catchup and sickness. I do not want to add too much to the process, but want to understand the buffer between shepherd comments and your consolidated summary to the board. Working backwards: * Friday (before the board meeting week) VP IPMC submits the consolidated report to the board. * Shepherds review the mentor signed off reports and other activity and add comments - Tentatively Due by ? * Podling's draft the report and mentors sign off by Wednesday (a week before the board meets). I do think we have to leave it to each podling how they work through the reporting process, but having a suggested timeline and workflow at [1] might help the new podlings understand how the report funnels to the board. I don't think that shepherds need to wait around for mentors. Try this timeline: T1 T2T3 T4 || | | friday beforewedfriday before wed friday before board meeting board meeting board meeting T1: podlings deliver report content T1-T2: mentors and shepherds review, comment, signoff T2-T3: chair summarizes, IPMC reviews T3-T4: chair makes small repairs in case of last minute comments or input As you write below, how projects get their reports together, and whether they anticipate the need for mentor signoff, is up to them. Something like... PPMC drafts the reports in the dev list - Mentors iterate any comments and sign off - Shepherds review and provide any kudos external advice/comments - IPMC chair compiles the report with a over all summary (with an appendix of all podling reports) - Added to the board agenda - Board members shepherd through the IPMC report - (feedback follows back?) It might be also helpful to explain in the same document, once the project graduates how the process cuts short into ...TLP PMC chair drafts the report (with feedback from PMC) - Added to the board agenda - Board members shepherd the PMC report - feedback is sent to PMC private list Cheers, Suresh [1] - http://incubator.apache.org/guides/ppmc.html On Jan 13, 2013, at 7:52 AM, Benson Margulies bimargul...@gmail.com wrote: This time around, the timing was as follows: Wed 09-01-2013: Deadline for podling reports Friday 11-01-2013: Practical board deadline Wed 16-01-2013: Board meeting In other words, we had a two day window for shepherds to digest reports, then go dig around to fill in their picture. Now, maybe things were unusually bad because of folks out for the new year until 07-01-2013. But, still, I feel as if we don't have enough time to react to reports (or the lack of reports) before we need to have the board report in place. What do people think of making the podling reporting deadline be a full week before the board's deadline? The board wants a weekend to review reports before they meet; I'd like a weekend for us to review reports before we need to get them delivered to the board. - 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: The report/review cycle
Maybe this version fits? T1 T2T3 T4 || | | friday beforewedfriday beforewed friday before board meeting board meeting board meeting On Sun, Jan 13, 2013 at 6:47 PM, Roman Shaposhnik r...@apache.org wrote: On Sun, Jan 13, 2013 at 4:52 AM, Benson Margulies bimargul...@gmail.com wrote: What do people think of making the podling reporting deadline be a full week before the board's deadline? I think this would be extremely helpful. Thanks, Roman. - 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] Expressing priorities about release reviews
On Sat, Jan 12, 2013 at 9:07 AM, Joe Schaefer joe_schae...@yahoo.com wrote: Just think about this for a second, what's more likely for people to start suing us over, some bug in the NOTICE file or an undetected backdoor in one of our programs? I am personally far more concerned about the current state of the actual review going on in our podlings than I am about NOTICE minutia. I agree with your general concern of us missing the forest for the trees. Yet, I have no silver bullet for how to visualize the forest either except for trying to infuse the sense of urgency around these issues into the incubating PMCs. Thus I view us being pedantic when it comes to licensing minutia as a double edge sword. On one hand, we should never forget that this is but the simplest way of us harping on one of the most important issue for the foundation and NOT a end in and of itself. On the other hand, if we stop using licensing nits as a forcing function to make PMC aware, I'm not sure we are left with too many chance of having that type of a conversation with the project. Thanks, Roman. P.S. I know this could be difficult for the veterans to appreciate, but I constantly come across fresh grads not understanding licensing implication *at all*. This is especially true for those who by the luck of a draw ended up interning/etc for the service-oriented companies like Google/Twitter/Facebook/Yahoo (cue RMS with AGPL ;-)). - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Thoughts about formalizing the role of shepherd
On Sun, Jan 13, 2013 at 8:46 AM, Benson Margulies bimargul...@gmail.com wrote: Right now, a shepherd assignment is a temporary job. It starts as the reports for a cycle begin to come in, and it ends when the shepherd feels that he or she has done what makes sense in terms of reporting to the community and, in some cases, delivering some constructive nudges to the projects. I've been thinking about an alternative, but it may not be popular. Let me ask you this: what is this trying to achieve? What is our definition of success here? I guess the 'ideal world' of the incubator I'm picturing is the one where the structure is flat -- everybody's a mentor and there's also an 'Incubator VP' who acts just like a VP of any other project. Theoretically you could say that there needs to be an 'Incubator PMC' equivalent and that's what shepherds are -- but I'm not convinced this distinction is a useful one. Of course, this is coming from a guy who also believes that most of the time committers == PMC -- so perhaps it is the same bias talking. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Commented] (INCUBATOR-125) How-to guide for Assembling LICENSE and NOTICE
[ https://issues.apache.org/jira/browse/INCUBATOR-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552464#comment-13552464 ] Marvin Humphrey commented on INCUBATOR-125: --- 1. I want to start by noting that ** Apache Releases Are Source Releases **. So I'm somewhat unclear on how convenience binaries fit in. I regret opening that can of worms by mentioning binaries at all. I hope that by deleting everything the document has to say on the subject we can save it from being talked to death. 2. This document would benefit from a brief definition of what the files are at the top. I've added an svn branch to track mods to the document: https://svn.apache.org/repos/asf/incubator/public/branches/license_howto/ Thanks for the suggestion, which I implemented here: https://svn.apache.org/viewvc/incubator/public/branches/license_howto/licensing_howto.mdtext?r1=1432804r2=1432812 How-to guide for Assembling LICENSE and NOTICE Key: INCUBATOR-125 URL: https://issues.apache.org/jira/browse/INCUBATOR-125 Project: Incubator Issue Type: Improvement Components: site Reporter: Marvin Humphrey Attachments: licensing_howto.mdtext While the ASF provides reference documentation for LICENSE and NOTICE, confusion persists and existing versions vary widely in quality. To address these problems, we should augment the reference documentation with a how-to guide which provides formulaic instructions for assembling LICENSE and NOTICE under common conditions. One key feature of this how-to should be a mapping of approved licenses to what they require as far as NOTICE. This mapping will help PMCs determine when the licensing information of a dependency contains a required third party notice which must be added to NOTICE. There are at least four possible locations where this how-to might live: * www.apache.org/dev/licensing_howto.html -- probably the best location, considering the intended audience. * www.apache.org/legal/licensing_howto.html -- if legal wants it. * incubator.apache.org/guides/licensing_howto.html -- probably not ideal, because the information applies to TLPs as well as podlings and we have a problem with duplication. * Somewhere on community.apache.org -- in theory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Thoughts about formalizing the role of shepherd
On Jan 13, 2013 11:46 AM, Benson Margulies bimargul...@gmail.com wrote: ... Next down are the 'vice-chairs', currently known as the shepherds. Each of these people is responsible for a group of projects, dispersed across the reporting cycle. The shepherd, at least, tunes into the reports, but also checks in during the three-month reporting period -- particularly if we have identified issues that the project needs to address. When I came up with the shepherd process for the Board, I specifically made the assignments random. This was to prevent a Director from becoming accustomed/lazy with their assignment, and to ensure that Directors eventually get detailed insight to *all* projects. It also ensured that Directors *had* to engage at some level with report reviewing (I felt some Directors attended meetings without any reviewing; the shepherding helped to involve them more fully). Now, I'm not saying the two are the same. They share a name, and some general concepts, but the Incubator operates very differently. I do think the Incubator can reuse the idea of somebody assigned to review in detail rather than a normal cursory review. Anyway, I hope this background helps. Cheers, -g ps. of course, randomization also meant some sucker wasn't saddled with being the Incubator shepherd for life; it's a hard/lengthy review...
