[VOTE] Release RC3 as Log4PHP 2.0.0
Dear Incubator PMC, the Log4PHP has voted with 3x +1 for releasing RC3 as Log4PHP 2.0.0 (please see below). The original vote message can be found: http://mail-archives.apache.org/mod_mbox/logging-log4php-dev/200911.mbox/%3cded132f10911262256j12c0cfej21e7e5dbdcf18...@mail.gmail.com%3e Message ID is: ded132f10911262256j12c0cfej21e7e5dbdcf18bf7 We kindly ask the incubator PMC to vote on our artifacts too: [ ] +1 Yes go ahead and release the artifacts [ ] -1 No, because... Thanks, Christian -- Forwarded message -- From: Christian Grobmeier grobme...@gmail.com Date: Fri, Nov 27, 2009 at 7:56 AM Subject: [VOTE] Release RC3 as Log4PHP 2.0.0 To: Log4PHP Dev log4php-...@logging.apache.org Dear all, please vote to release the following artifacts as version 2.0.0: [ ] +1 Yes go ahead and release the artifacts [ ] -1 No, because... Log4PHP 2.0.0 artifacts are available for review here: * http://people.apache.org/builds/logging/log4php/2.0.0/RC3/ The release plan used for the creation of the packages is here: * http://wiki.apache.org/logging/Log4PHP/Log4PHPReleasePlan The tag for this release is available here: * http://svn.apache.org/viewvc/incubator/log4php/tags/apache-log4php-2.0.0-incubating/ Differences to the last RC: - licensing issues - move api to docs folder - renamed assembly descriptor to src.xml (indstead of bin.xml) Please also help with checking signatures, md5 files and about all license stuff. A short help can be found on the release plan page. Thanks, Christian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
How documentation != code, and how to do policy (was: Re: Publishing api docs for Subversion)
Hey hey, I wasn't going to say anything but since this is dragging on... On Sat, Dec 5, 2009 at 1:08 AM, Doug Cutting cutt...@apache.org wrote: Would we permit someone to mirror other files from trunk on the website? Yes, definitely. Most projects publish their websites by pushing files into SVN. Many projects automate this - commit an xml file, its turned into html and published online. That is in fact the encouraged process, though we do allow other mechanisms (like a plugin which takes confluence content and pushes that out automatically). What's special about documentation? Less legal risk, less risk that anyone puts a bug in docs that crashes a users computer or corrupts their data or takes down the internet, generally not subject to patent concern, less desire for the general public to fork and redistribute, and much more. Like, barriers to working on it have to be as low as possible or no-one will do it, people inclined to work on docs are often less technical, etc etc. Perhaps it helps to flip the question around: what is special about (source) code? And the answer is: lots :) its changes are subject to vetos, etc. Not on most of the projects I work on! Most projects use lazy consensus for documentation. I don't think I have *ever* seen someone veto a documentation patch. snip/ It's otherwise treated just like code. Well, in some ways (that you pointed out) docs are treated a lot like code, and in many other ways they aren't. Publication release are two different things - thats the point. I don't see that yet. Can you tell me more about the difference? I use publish, distribute and release more or less synonymously when referring to project content. I'd say we don't really have precise definitions that will provide you with a model explaining exactly what is and isn't ok in the general case, and I think it won't help to look for it either. Instead, judgement should be applied to the specific case. Subversion contains only working drafts. And stable branches and release tags and documentation and websites and quickbooks and contact info and meeting minutes and ... We use subversion for nearly everything that needs to be auditable and be backed up and be collaboratively edited. We don't always particularly care about the versioning bit :) But, for the sake of illustration, let's do a mental exercise. The ASF does creation and distribution of software to the general public. When we say software we mostly mean source code (and some binaries for convenience). Pretty much everything around here is structured to support this creation and distribution of software. There's a variety of supporting things, like websites, incubators, an org structure, various committees, conferences, etc. All of it supports creation and distribution of our software. What constitutes the software that a project releases to the public depends on that project. Subversion is one project, it has a website and it creates software which it distributes. Subversion releases a single tarball of (mostly C) source code with some build scripts and whatnot. Running the build produces an apache module, a server program, a client program and some utilities. Subversion's users then install this software on their system and use it. Most subversion users probably get a pre-built binary from a third party. The subversion project provides a manual for how to install and use svn on its website, but I suspect most users will actually use the svn book. There is a relatively small side activity for subversion which involves using its libraries and APIs to build custom client software that interacts with a subversion server (or perhaps even extend the server though I think very few people do that). For this activity, you need the API docs we're talking about here. Of course, the subversion developers themselves need those API docs too. It's a fair assumption that the expert developer people using these API docs know *quite a lot* about subversion already, including about its versioning and compatibility policies, how to download releases and code out of svn, etc etc. It's also a fair assumption that the most important API to develop against is in fact the SVN trunk API. So, subversion publishes their trunk API docs nightly, for the convenience of their own developers and the surrounding tool developer community. All those people mostly want trunk API docs, and they want them mostly so they don't have to run doxygen themselves. There's really no need to protect the normal users of the subversion website from bad API docs, they won't be using those docs at all. Now, the point of this long story: subversion as a community has thought about all this and are evidently doing a pretty good job at keeping users and wider developer community (well perhaps not the java dev community who are afraid of native code :-D ) happy. Within all this context, one of the subversion developers (or this I assume) asked a
Re: Publishing api docs for Subversion
Doug Cutting wrote: Niall Pemberton wrote: I would prefer what I say isn't distorted by selective editing. Sorry, that was not my intent. I'm not talking about the website in general. I'm talking specifically about publishing content primarily intended for inclusion in releases. Would Publication release are two different things - thats the point. I don't see that yet. Can you tell me more about the difference? I use publish, distribute and release more or less synonymously when referring to project content. Subversion contains only working drafts. we permit someone to mirror other files from trunk on the website? What's Yes and I bet every project provides a link to browse subversion which itself is just another web site. Yes, but such links are meant to be confined to developer-oriented pages. We specifically do not encourage anyone but developers to use code in subversion. We provide extra diligence for releases, and that only makes sense if we don't otherwise distribute their content to the general public. Subversion is a service for our developers. The ViewVC pages are publicly accessible. Therefore they are a service for the whole world, not just for our developers; just like the project web sites. I find myself quite often looking at sources and mainline documentation for projects where I'm not a developer. Most of the time, such resources are marked as unstable in some way, and not just in Apache-hosted projects. That's as it should be. So I'm not too clear on what your objections are. * Do you object to publishing non-released documentation on the project Web pages? Then you should start by cleaning up the existing ASF TLPs; begin with HTTPD, for example. * Do you object to publishing the link and not marking it as development or unstable or whatever? AFAICS nobody suggested that. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Publishing api docs for Subversion
sebb wrote: On 03/12/2009, Paul Querna p...@querna.org wrote: On Wed, Dec 2, 2009 at 10:17 AM, Doug Cutting cutt...@apache.org wrote: Bhuvaneswaran A wrote: We tend to update the api docs generated using doxygen and java doc on a nightly basis. Unreleased artifacts should be linked only from the developer portion of the site and should not be hosted on the official project site. You might, e.g., just link to them on the Hudson server rather than copy them to people.apache.org. Documentation should only be published to the official website after it's been included in an Apache release. This is for legal reasons: we work hard to ensure that releases have licensing in order, but do not in general guarantee that licensing is correct at all times in source code repositories. I'm sorry what? httpd and apr have published doxygen of their trunks periodically, they aren't based on any release. And large parts of the ASF website (which can be considered as documentation) are not subject to formal release votes. Doug's comments seem OK if they refer to code releases, but surely documentation is not subject to release votes? Actually, we're talking about API documentation which in Subversion's case is generated from the sources, so yes, it is subject to release votes. But only for actual releases. Restricting the publishing of generated API documentation would imply that we should restrict access to ViewVC, too, because anyone can browse that exact same documentation through that, albeit formatted a bit differently. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release RC3 as Log4PHP 2.0.0
The log4php PPMC vote was opened on log4php-dev at Nov 27, 2009 and closed at Dec 4, 2009. Binding +1 votes were received from Christian Grobmeier, Christian Hammers and Curt Arnold. No other votes were received. The link in the original thread ends at the end of November. The PPMC release vote thread continues http://mail-archives.apache.org/mod_mbox/incubator-general/200912.mbox/%3cded132f10912050048u695e1353ta29b54a39e620...@mail.gmail.com%3e I did raise a concern on a previous RC that the phpdoc generated documentation does not have an ASF source header notice, but http://incubator.apache.org/guides/releasemanagement.html#notes-license-headers implied that it may not be a hard requirement. I would encourage any PHP developers to double check the PEAR packaging and particularly in terms of consistency with other Apache PHP projects. On Dec 5, 2009, at 2:48 AM, Christian Grobmeier wrote: Dear Incubator PMC, the Log4PHP has voted with 3x +1 for releasing RC3 as Log4PHP 2.0.0 (please see below). The original vote message can be found: http://mail-archives.apache.org/mod_mbox/logging-log4php-dev/200911.mbox/%3cded132f10911262256j12c0cfej21e7e5dbdcf18...@mail.gmail.com%3e Message ID is: ded132f10911262256j12c0cfej21e7e5dbdcf18bf7 We kindly ask the incubator PMC to vote on our artifacts too: [ ] +1 Yes go ahead and release the artifacts [ ] -1 No, because... Thanks, Christian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: How to put droids into the snapshot rep
-Original Message- From: Thorsten Scherler [mailto:thorsten.scherler@juntadeandalucia.es] Sent: Friday, 4 December 2009 10:35 PM To: general@incubator.apache.org Subject: How to put droids into the snapshot rep Hi all, https://issues.apache.org/jira/browse/DROIDS-65 I am looking into adding droids to the public apache maven rep. I did some research but could not really find a extend how to. Can somebody point me in the right direction? Here's a slightly different direction. Buildbot currently builds Droids and does your rat reports [1], your website [2] and various API docs [3]. The ASF buildbot has the feature to also deploy snapshots to the Nexus Repository snapshots area. If you are interested in using this feature to autodeploy your new snapshots then let me know. Cheers Gav... [1] - http://ci.apache.org/projects/droids/rat-output.html [2] - http://ci.apache.org/projects/droids/index.html [3] - http://ci.apache.org/projects/droids/api/droids-core/index.html salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions Sociedad Andaluza para el Desarrollo de la Sociedad de la Información, S.A.U. (SADESI) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.708 / Virus Database: 270.14.87/2536 - Release Date: 11/30/09 17:31:00 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
