It looks like the code development is just about done. I'd be comfortable creating a release candidate. We are not ready to create a release at this point due to documentation that needs to be completed but creating a candidate now would allow testing of the final code. If everyone agrees, Josh, as release manager, could you please start this process?
Regarding documentation, I'd be willing to help manage this. There are some obvious things we need to complete before a release can officially be created. We need to go through the issues for 2.4 and identify items which need to be documented prior to the release. This is something that anyone in the community can help with. Please help out! I propose the following (any additional ideas and comments are extremely welcome): Rather than reopen issues for which the development has been done, create a sub-task for each issue with missing or inadequate documentation. Start by going through all of the issued tagged for 2.4: https://issues.apache.org/jira/issues/?filter=12329344 Some issues don't require any additional documentation such as a behind-the-scenes bug fix. Anything that a user or administrator will interact with or configure needs to be documented. If this is the case, try to locate the documentation. If the documentation exists and is adequate, please add a comment to the Jira issue saying you reviewed it with a link to the documentation. If the documentation does not exist, is too difficult to find, or is inadequate: * Click "More" --> "Create Sub-Task" * Select Component: documentation * If the documentation is obviously required prior to the release of 2.4, select "Fix Version": 2.4 * If you aren't sure if the documentation is required prior to the release of 2.4, ask the [email protected] list * If the documentation is not required prior to the release of 2.4, leave "Fix Version" blank For anyone working on any of the documentation sub-tasks: * Choose an issue needing work: https://issues.apache.org/jira/issues/?filter=12330732 * Begin by clicking "Start Progress" * Be sure to include a link to the documentation in the issue comments so that others can easily review it * When you as the original documentation creator feel it is done, click "Close Issue". DO NOT click "Resolve Issue"!!! The sub-task should be closed first, then resolved when someone else reviews it. All documentation should be reviewed. The person who implemented the code may make assumptions or rely on personal knowledge not known to the users of the documentation so it is beneficial to have at least one other person review the work before resolving the issue. It's also beneficial to have at least one other set of eyes review the documentation to check the grammar/spelling and general quality. To review the documentation: * Choose an issue with documentation needing review: https://issues.apache.org/jira/issues/?filter=12330730 * Review the documentation. If you have access to edit it directly, do so but be sure to explain the changes by adding a comment to the Jira issue. If you don't have access, list the changes that need to be made either in a Jira issue comment or in a comment on the related Confluence page. Either way, add a Jira comment. * Once the documentation is satisfactory, click "Resolve Issue" on the Jira documentation sub-task. Don't resolve any issues unless you are confident that the documentation is adequate. If you are unsure, ask the dev list. If anyone finds a documentation issue that has been resolved but thinks it still needs to be improved, reopen the issue and add a Jira comment. The procedures to review the documentation should be repeated. The people responsible for initially resolving the issue should view and respond to the comments. This really shouldn't happen very often. If it becomes a pattern that issues have to be reopened, the problems with the process or with how people are handling things should be brought up on the dev list. Thoughts, comments, questions? I plan to work on some of the issues I primarily implemented starting today, beginning with the NAT support: https://issues.apache.org/jira/browse/VCL-174 Thank You, Andy On Mon, Feb 9, 2015 at 2:52 PM, Josh Thompson <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Andy, > > Thanks for pointing this out. I've been forgetting to update the web/.ht- > inc/xmlrpcdocs when cutting a release. I'll add that to the list of tasks > to > be done for each release. > > I thought I had a page explaining the XMLRPC API, but I can't seem to find > it > now. I'll work on creating one. > > Josh > > On Monday, February 09, 2015 1:16:13 PM Andy Kurth wrote: > > I was looking for some information about some of the XML-RPC functions > and > > noticed there are functions in the web code such as XMLRPCdeployServer > not > > described in web/.ht-inc/xmlrpcdocs/xmlrpcWrappers_8php.html. I couldn't > > find anything in the release notes related to updating the files in > > xmlrpcdocs and it doesn't look like xmlrpcdocs was updated for a while. > > Should a step be added to regenerate this file with Doxygen? > > > > As a side note, I don't see much information on the website or wiki > related > > to the RPC-XML API. The information contained in > xmlrpcWrappers_8php.html > > is not presented nor are instructions telling people to look at the file > in > > the code. Am I missing something? If not, we need to document this. > > > > -Andy > > > > > > > > -Andy > > > > On Tue, Feb 3, 2015 at 2:59 PM, Josh Thompson <[email protected]> > > > > wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Just as an update - the 2.4 release is almost ready. There are a few > JIRA > > > issues left to be closed. After that, we can generate the change log > for > > > the > > > release. We have an installation script and upgrade script as well as > web > > > pages listing out the steps for both in case people need/want to > manually > > > do > > > installs and upgrades. > > > > > > Dmitri's OpenNebula stuff still needs to be committed, but he's having > > > some > > > account problems that we're trying to get worked out. If we can't sort > > > things > > > out in the next day or two, one of the other committers can commit > things > > > for > > > him. > > > > > > Thanks to everyone for all the hard work so far! Keep it up, we're > almost > > > there! > > > > > > Josh > > > - -- > > > - ------------------------------- > > > Josh Thompson > > > VCL Developer > > > North Carolina State University > > > > > > my GPG/PGP key can be found at pgp.mit.edu > > > > > > All electronic mail messages in connection with State business which > > > are sent to or received by this account are subject to the NC Public > > > Records Law and may be disclosed to third parties. > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v2 > > > > > > iEYEARECAAYFAlTRKK4ACgkQV/LQcNdtPQPYCwCeIbgDnEeRMBIMO2DCvOgGbAtR > > > WSMAnRXsPpHpplWNpX/8Rl8vQdOdDWKC > > > =RpJQ > > > -----END PGP SIGNATURE----- > - -- > - ------------------------------- > Josh Thompson > VCL Developer > North Carolina State University > > my GPG/PGP key can be found at pgp.mit.edu > > All electronic mail messages in connection with State business which > are sent to or received by this account are subject to the NC Public > Records Law and may be disclosed to third parties. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iEYEARECAAYFAlTZECoACgkQV/LQcNdtPQOxDACeO/UG0IHD7lnruDwzVZaNC5Cx > wQkAn21DL+Y8gF0hNtF4qJy15wuALLux > =sDPW > -----END PGP SIGNATURE----- > >
