[RFC] changes to CommitPolicy

[Deepak Bhole]

* Jiri Vanek <jvanek at redhat.com> [2011-08-04 06:22]:
> Hi!
> I would like to modify commit policies on wiky - http://icedtea.classpath.org/wiki/CommitPolicy.
> Especially is going for this line:
> 
> "In IcedTea-Web the code changes/new features should be delivered with proper test and (or) reproducers to cough future changes and track behavior if possible. If non test is delivered, then should be explained why this particular commit should be untested."
> 

I think there is a typo there. "cough future changes"? Did you mean
cover?

I think it is slightly confusing. What are your thoughts about something
like:

"IcedTea-Web code changes/new feature should be accompanied with
appropriate tests. If no tests are added/modified, changes should be
accompanied with an explanation as to why."

Cheers,
Deepak

> Icedtea-web is quite young, but still very untested. Every test inside can help in future to track bugs, and can always track a little bit also old behaviours. This effort can help to increase tested parts of icedtea-web.
> 
> 
> Regards J.

> --- icedTeaPolicies1	2011-08-04 11:50:22.461840769 +0200
> +++ icedTeaPolicies2	2011-08-04 12:05:56.954839372 +0200
> @@ -45,34 +45,36 @@
>  The ChangeLog should take the following format and be as detailed as possible, concerning the changes made, as this serves as a record for future maintenance.
>  
>  (date in YYYY-MM-DD format)  (name)  (e-mail enclosed in '<' and '>')
>  
>         * (filename):
>         (change to file)
>         etc.
>  
>  Please note that all lines except the first one should be indented by <tab> character, not by spaces, so the format is following:
>  
>  (date in YYYY-MM-DD format)  (name)  (e-mail enclosed in '<' and '>')
>  
>  <tab>* (filename):
>  <tab>(change to file)
>  <tab>etc.
>  
>  GNU Emacs provides a mode for editing ChangeLog entries and Vim also contains autocommands for ChangeLog files (syntax highlighting + indenting rules).
>  
>  It is expected that all patches have been applied and the resulting codebase built. With regard to HotSpot patches, builds should be conducted with both supported versions of HotSpot (see ReleasePolicy). We don't expect every niche option (there are many) to be tested and other developers should be aware of this, and be responsible for maintaining those which interest them.
>  
>  Below, we list specific criteria which applies to a subset of patches for IcedTea.
>  OpenJDK Patches
>  
>  Many patches to IcedTea will actually be patches to patch OpenJDK. With IcedTea6, this involves a patch which includes a further patch to be applied to the OpenJDK source at build time. With IcedTea7 onwards, patches are applied to our own forest.
>  
>  In IcedTea6, patches for OpenJDK should be stored in the patches subdirectory. If the patch is a direct backport of a fix from OpenJDK7, it should be placed in patches/openjdk and named using the following format: (bug-id)-(summary).patch, where summary is a (appropriately shortened) version of the summary field from the patch. Discretion may be applied in naming the patch if the summary field is unhelpful; this is something to be discussed in the review process. Please 'do not significantly alter backported patches or add additional changes to them as the patches in patches/openjdk are used as an effective TODO list for patches to be upstreamed and will be removed when the corresponding bug ID is available upstream.
>  
>  In IcedTea7, patches for OpenJDK are applied directly to our OpenJDK forest. Again, when conducting backports, use exact patches (via hg export/import) and do not mix in additional changes.
>  Security Patches
>  
> +In IcedTea-Web the code changes/new features should be delivered with proper test and (or) reproducers to cough future changes and track behavior if possible. If non test is delivered, then should be explained why this particular commit should be untested.
> +
>  An inevitable issue with dealing with security issues is that patches have to be applied in secret and then only released post-embargo. This means that they will not undergo the same rigorous review process as normal patches. Please be accepting of this and don't flame the person who releases the security patches if something breaks as a result. Extensive testing is performed for security patches, but it will not cover niche options (Zero, Shark, CACAO, JamVM).
>  Freeze Periods
>  
>  The HEAD or trunk branches are always open for business. Release branches are closed for very brief periods (hours rather than days) to allow the designated maintainer (see ReleasePolicy) to perform the release. During the freeze, the maintainer and only the maintainer is allowed to make basic commits (updating configure.ac and NEWS, tagging) to perform the release.