Re: release nearly ready

[Andy Kurth <an...@ncsu.edu>]

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 dev@vcl.apache.org 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 <jo...@ncsu.edu>
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 <jo...@ncsu.edu>
> >
> > 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-----
>
>

Re: release nearly ready

[Andy Kurth <an...@ncsu.edu>]

Oops, Josh pointed out I had closed and resolved backwards.  For the stock
Jira workflow template we are using, issues should be resolved before being
closed.  Closed is the terminal state.  Once an issue is closed, you cannot
create a sub-task without reopening the issue.  If an issue is resolved but
not closed, you can still create a sub-task.  I think we should really be
setting all issues to resolved until a release is nearly ready.  Once
ready, all issues should be reviewed.  If adequately tested and documented,
the issue should be closed.  Thoughts?
[image: Inline image 1]
Thanks,
Andy

On Tue, Mar 10, 2015 at 12:06 PM, Andy Kurth <an...@ncsu.edu> wrote:

> 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 dev@vcl.apache.org 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 <jo...@ncsu.edu>
> 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 <jo...@ncsu.edu>
>> >
>> > 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-----
>>
>>
>