Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Flume >> mail # dev >> Guidance on Creating JIRA Issues for FLUME Javadocs


Copy link to this message
-
Re: Guidance on Creating JIRA Issues for FLUME Javadocs
Hi Israel,
I'd lean towards something between 2 and 3 depending on your judgment of
related stuff. Less noise on the dev list makes it easier to follow.

Regards,
Mike
On Mon, Apr 1, 2013 at 12:18 PM, Israel Ekpo <[EMAIL PROTECTED]> wrote:

> Hello Everyone,
>
> I am in the process of adding/modifying the javadocs for several of
> classes, interfaces and enums in the source code.
>
> There are some identifiers that could benefit from the addition or updates
> of the javadocs at the class, method and paramater levels.
>
> This could improve the API Documentation especially for new comers looking
> through the code to figure out what is going on.
>
> I would like to know what is the better approach towards creating JIRA
> issues for these javadoc changes.
>
> (1) Create one JIRA issue for each .java file (class, interface or enum).
> (2) Create one JIRA issue for a group of classes, interfaces or enums
> within the same package.
> (3) Create one JIRA issue for a group of packages within the same module
> (flume-ng-core, flume-ng-sources, flume-ng-channels etc)
> (4) Create one JIRA and use it for all javadoc patches
>
> I am leaning towards (1) but I would like to know what others think?
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB