Re: [discuss] graduation: what is the 'hand over'?
On May 3, 2007, at 5:56 PM, Martijn Dashorst wrote: I am in the process of going through the graduation guide (graduation.xml in the guides directory of the incubator website), wow, that's pretty detailed. It's also not linked from the main menu. and I came across a TODO: section and didn't know what to do with it (no pun intended). What is the post-graduation 'Hand Over'? No idea. Heh. I think we don't really have one. The board@ tries to notify us almost immediately after they vote on any resolution; usually via an e-mail to board@ as well as the relevant private@ PMC list if that applies. I guess the Chairman is always supposed to do that, but he's a busy man, so others help out. Sometimes they all forget, and the way to work around that is to nag your favorite board member into sending an email after you don't hear anything (say, 72 hours) after the board meeting (I recommend people pick Henri for nagging, since he's often most responsive for these kinds of questions) so they remember. After such a board resolution, apache will have a new PMC with an associated new chair/VP, who can then act on their own behalf (like requesting infra resources). We assume (given that they're all graduated and stuff), they'll know what to do next. In practice it's not that great of an assumption. So a pattern that has worked pretty well in the past is that the most active/ experienced/gullible mentor becomes the PMC chair initially, and then optionally that person can help groom someone else from within the community to take over after a few months. To me the process for a TLP is in a simplified form: - make sure status files and the like are up-to-date and completed - create graduation proposal - vote on the proposal by the ppmc - vote on the proposal by the ipmc - vote on the proposal by the board instant karma Heh. The new PMC has the power to ask for karma, at least, but response times from infrastructure may vary :-). Follow procedures http://www.apache.org/dev/ for interacting with [EMAIL PROTECTED] - move podling resources to TLP resources There's a checklist at http://incubator.apache.org/incubation/Incubation_Policy.html#Post- Graduation+Check+List That checklist is missing at least * new chair subscribes to board@ mailing list * new chair subscribes to infrastructure@ mailing list * new chair gets self added to pmc chairs group in svnauth * entire PMC reviews (add salt since process docs are permanently out-of-date) ** http://www.apache.org/dev/pmc.html ** http://www.apache.org/dev/#pmc * chair reviews (add salt since process docs are permanently out-of-date) ** http://wiki.apache.org/jakarta/RoleOfChair ** http://www.apache.org/dev/pmc.html#chair ** http://incubator.apache.org/guides/chair.html (no idea why the tidbits on that page live over there, most of it should be at www.a.o/dev/) ** http://www.apache.org/foundation/board/calendar.html (to figure out how to write reports for the board@) * for the first 3 months after graduation, chair submits a report to the board every month. After that, slot into the quarterly reporting schedule. Work with [EMAIL PROTECTED] * stick around the incubator and help future projects have an easier time than you did The graduation guide says that there are two things following the move of the resources: * The Hand Over I guess I sort-of gave an answer, above. * solving Remaining Obstacles No idea what those would be. It depends. Perhaps the IPMC can shed a light on this question? In general, the amount of documentation for how to be a PMC is a lot less than we have for how to incubate. PMCs are supposed to be self-managing, which means each PMC figures out what their obstacles are all by themselves. Usually by the time a project graduates it knows what to expect in terms of handholding (i.e.: not much) or extensive and correct policy documentation (i.e.: not much). So obstacles can include things such as we need a unix group on people.a.o to own our releases or we need a solaris zone on the zone server to host a demo version of our software or I need to figure out how to make Marvin (a mailbot) send me those you-need-to-send-your-board-report reminders. cheers, - Leo the process weenie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[suggestion] making documentation management more lightweight
Jo! The whole jira-patch-commit workflow for the documentation seems annoying. At least it annoys me -- in particular the patches don't show up in my email so I have to visit jira which I try and avoid as much as possible :-). Suggestions: 1) create http://svn.apache.org/repos/asf/incubator/public/staging writeable by *all* committers svn cp http://svn.apache.org/repos/asf/incubator/public/trunk \ http://svn.apache.org/repos/asf/incubator/public/staging vi infrastructure/trunk/subversion/authorization/asf-authorization svn commit infrastructure/trunk/subversion/authorization/asf- authorization 2) create an svn:externals on http://svn.apache.org/repos/asf/incubator/public/trunk/site- publish like this website-staging http://svn.apache.org/repos/asf/incubator/ public/staging/site-publish so that you can see the work-in-progress at http://incubator.apache.org/website-staging/ 3) instead of sending documentation patches, people who are helping with the documentation work on the staging branch 4) set up svnmerge.py for staging/ and trunk/ * see http://www.orcaware.com/svn/wiki/Svnmerge.py * make sure to block the revision from step #2! 5) propose documentation changes on the mailing list * get diffs cd incubator/trunk svnmerge.py --bidirectional diff ~/staging-diffs.txt # or use -r to get only a few revisions * send diff to mailing list for discussion and lazy consensus approval 6) merge cd incubator/trunk svnmerge.py --bidirectional avail svnmerge.py --bidirectional # or use -r12345,... svn commit -F svnmerge-commit-message.txt cd ../staging svnmerge.py svn commit -F svnmerge-commit-message.txt 7) rejoice at the lightweight workflow, which also survives Robert's laptop sinking to the bottom of the sea! cheers, Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [suggestion] making documentation management more lightweight
Leo Simons wrote: Jo! The whole jira-patch-commit workflow for the documentation seems annoying. At least it annoys me -- in particular the patches don't show up in my email so I have to visit jira which I try and avoid as much as possible :-). Suggestions: 1) create http://svn.apache.org/repos/asf/incubator/public/staging writeable by *all* committers svn cp http://svn.apache.org/repos/asf/incubator/public/trunk \ http://svn.apache.org/repos/asf/incubator/public/staging vi infrastructure/trunk/subversion/authorization/asf-authorization svn commit infrastructure/trunk/subversion/authorization/asf- authorization 2) create an svn:externals on http://svn.apache.org/repos/asf/incubator/public/trunk/site- publish like this website-staging http://svn.apache.org/repos/asf/incubator/ public/staging/site-publish so that you can see the work-in-progress at http://incubator.apache.org/website-staging/ 3) instead of sending documentation patches, people who are helping with the documentation work on the staging branch 4) set up svnmerge.py for staging/ and trunk/ * see http://www.orcaware.com/svn/wiki/Svnmerge.py * make sure to block the revision from step #2! 5) propose documentation changes on the mailing list * get diffs cd incubator/trunk svnmerge.py --bidirectional diff ~/staging-diffs.txt # or use -r to get only a few revisions * send diff to mailing list for discussion and lazy consensus approval 6) merge cd incubator/trunk svnmerge.py --bidirectional avail svnmerge.py --bidirectional # or use -r12345,... svn commit -F svnmerge-commit-message.txt cd ../staging svnmerge.py svn commit -F svnmerge-commit-message.txt 7) rejoice at the lightweight workflow, which also survives Robert's laptop sinking to the bottom of the sea! what about a CMS with a workflow, which would sit on top SVN accessing both branches (staging resp. draft and live) and hence would allow devs still accessing it through other SVN clients and also allow updating the live site as static SVN update? We have implemented versioning and workflow into Yulup (http://www.yulup.org), which is available within the recent trunk version or next week's release. Yulup does decouple this functionality from the actual server implementation. I would be happy to help to set something up in case this would make sense for the incubator folks. Cheers Michael cheers, Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED] +41 44 272 91 61 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [suggestion] making documentation management more lightweight
On May 5, 2007, at 7:55 PM, Michael Wechner wrote: what about a CMS with a workflow, which would sit on top SVN accessing both branches (staging resp. draft and live) and hence would allow devs still accessing it through other SVN clients and also allow updating the live site as static SVN update? Ah, that's an old subject! Several people have done prototypes along these lines (I've done about one and a half in python, but in python the most promising codebase is probably (still) SubWiki), and I'll argue something like this (edit this page links backed by subversion) is what we really really want. Mozilla has (or had) it for their site. [EMAIL PROTECTED] was set up with this in mind, ages ago, and there's still some requirements/designs lying around for how it would work. David Crossley is a good person to ask about it. I think one of the problems why this effort has stalled has been that apache has so many CMS or CMS-ish tools that it is really hard to come up with a common way to do things that satisfies enough people to make setting it up worthwhile, so you get into loads of arguing. We have implemented versioning and workflow into Yulup (http:// www.yulup.org), which is available within the recent trunk version or next week's release. Yulup does decouple this functionality from the actual server implementation. I would be happy to help to set something up in case this would make sense for the incubator folks. I'd rather not see a tool like this for a project-specific setup -- anything that writes to SVN needs to be very carefully evaluated for security and stability reasons and be maintained and supported by [EMAIL PROTECTED] If you're interested in signing up for the bigger job, please work with site-dev@ (and infrastructure@). I can tell you right now that something off of trunk of a non- Apache project that's in a 0.x release series, doesn't document how it uses SVN, and is licensed under the GPL is not that likely to receive a warm welcome immediately. I could set something up will also probably receive a healthy amount of scepticism; I wrote a blog post about why that is ages ago: http://www.jroller.com/page/lsd/20050717#why_we_say_no_to all that said, don't let me discourage you (too much)! We could definitely use this, but you'll have to volunteer for (quite) a bit more work and get some others to help out ;-) cheers, Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [suggestion] making documentation management more lightweight
Leo Simons wrote: On May 5, 2007, at 7:55 PM, Michael Wechner wrote: what about a CMS with a workflow, which would sit on top SVN accessing both branches (staging resp. draft and live) and hence would allow devs still accessing it through other SVN clients and also allow updating the live site as static SVN update? Ah, that's an old subject! Several people have done prototypes along these lines (I've done about one and a half in python, but in python the most promising codebase is probably (still) SubWiki), and I'll argue something like this (edit this page links backed by subversion) is what we really really want. Mozilla has (or had) it for their site. [EMAIL PROTECTED] was set up with this in mind, ages ago, and there's still some requirements/designs lying around for how it would work. David Crossley is a good person to ask about it. I think one of the problems why this effort has stalled has been that apache has so many CMS or CMS-ish tools that it is really hard to come up with a common way to do things that satisfies enough people to make setting it up worthwhile, so you get into loads of arguing. well, it seems to me that SVN is the common denominator at the ASF and only a tool which is able to connect to SVN will satisfy enough people within the ASF. That's one of the reasons I have spent time how a CMS can use SVN as a data repo. We have implemented versioning and workflow into Yulup (http:// www.yulup.org), which is available within the recent trunk version or next week's release. Yulup does decouple this functionality from the actual server implementation. I would be happy to help to set something up in case this would make sense for the incubator folks. I'd rather not see a tool like this for a project-specific setup -- anything that writes to SVN needs to be very carefully evaluated for security and stability reasons and be maintained and supported by [EMAIL PROTECTED] I understand, but I would assume writing to draft/staging SVN on a dedicated zone would be less an issue and then allow dedicated people to merge from there into the live SVN as you describe it above. If you're interested in signing up for the bigger job, please work with site-dev@ (and infrastructure@). I can tell you right now that something off of trunk of a non- Apache project that's in a 0.x release series, doesn't document how it uses SVN, and is licensed under the GPL is not that likely to receive a warm welcome immediately. I could set something up will also probably receive a healthy amount of scepticism; I wrote a blog post about why that is ages ago: http://www.jroller.com/page/lsd/20050717#why_we_say_no_to all that said, don't let me discourage you (too much)! We could definitely use this, but you'll have to volunteer for (quite) a bit more work and get some others to help out ;-) I very well understand what you are saying ;-) and I don't want to impose anything, but I believe that I finally have the tools at hand to do this and I am currently working on this for my own needs. Hence I wanted to ask and see how big the skepticism is and I don't mean this cynical, but just would like to be constructive. Anyway I will start with http://incubator.apache.org/guides/website.html and will see how far I will get and will hopefully come back within reasonable time :-) Cheers Michael cheers, Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED] +41 44 272 91 61 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: counting downloads
Noel J. Bergman wrote: Garrett Rooney wrote: The mirror system makes this an essentially unsolvable problem. And in addition to all of your other valid points, there is the problem of having a a farm of caching proxies on the ISP side of the net, leading to the seemingly odd case that the more popular a download, the less likely you are to get a good count, because the more likely it is to be served from the caching proxies. --- Noel One confusion I have: If we count clicks on the download link, it seems that even if that link led to a mirror page, it would count pretty accurately (except of course if a person clicked to download, and then didn't bother going through with it). I guess it would also miss the case where people somehow found their way to a download mirror *without* going through the project download page. Did I miss something, or would this give a reasonable estimate of downloads? -Marshall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: counting downloads
On 5/5/07, Marshall Schor [EMAIL PROTECTED] wrote: One confusion I have: If we count clicks on the download link, it seems that even if that link led to a mirror page, it would count pretty accurately (except of course if a person clicked to download, and then didn't bother going through with it). I guess it would also miss the case where people somehow found their way to a download mirror *without* going through the project download page. Did I miss something, or would this give a reasonable estimate of downloads? Unless they don't download it via your link, or they download more than once (getting copies on multiple machines?), or any number of other things that can throw your numbers off. It's a losing battle for statistics that IMO aren't very useful anyway. All download counts are good for is ego stroking, there are better ways to spend time and energy. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: counting downloads
Unless they don't download it via your link, or they download more than once (getting copies on multiple machines?), or any number of other things that can throw your numbers off. It's a losing battle for statistics that IMO aren't very useful anyway. All download counts are good for is ego stroking, there are better ways to spend time and energy. I agree with most of the comments here. But one thing download statistic imho *are* useful for is measuring progress. Even if the absolute numbers aren't useful, and trends are not reliable, it definitively gives an idea of whether a project is gaining attention or not. Another thing is that even if statistics aren't reliable, people still often want to have them. Matt Raible's talk on ApacheCon listed job counts per framework on Dice for instance. Completely useless, but people seem to love to hear it, even at Apache. Or there is my publisher asking me for download statistics of the project I'm involved in and using Amazon's ranking of a competing book to 'determine' the market potential for the topic. Imho, it's enough to say that we/ Apache doesn't want to spend energy on something that is technically hard or impossible and that in the opinion of the people who have to support it serves little value. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
