[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616567#action_12616567
 ] 

chirino edited comment on ZOOKEEPER-78 at 7/24/08 11:30 AM:
------------------------------------------------------------------

Hi Patrick,

The "Notice on the "attach patch" JIRA page that it has the " Grant license to 
ASF for inclusion in ASF works .... " option. This has to be checked for us to 
consider a patch for inclusion. " is not accurate in this case.

James and I are are both Apache committers and Members, and as such, when we 
commit code to the ASF repository  a license is granted to the ASF.  The jira 
feature is really only there to be able to accept code from folks who have not 
filed an ICLA with the ASF.

Another way to view this development model is as if we were ZooKeeper 
committers who do not commit to trunk but which develop new features and bug 
fixes in development branches.  This model of development is use extensively in 
projects who are adverse to destabilizing the trunk.  They develop and test new 
features in a branch and then merge back once folks are happy with it.

This model is also outlined at [Rules for 
Revolutionaries|http://incubator.apache.org/learn/rules-for-revolutionaries.html]

      was (Author: chirino):
    Hi Patrick,

The "Notice on the "attach patch" JIRA page that it has the " Grant license to 
ASF for inclusion in ASF works .... " option. This has to be checked for us to 
consider a patch for inclusion. " is not accurate in this case.

James and I are are bother Apache committers and Members, and as such, when we 
commit code to the ASF repository  a license is granted to the ASF.  The jira 
feature is really only there to be able to accept code from folks who have not 
filed an ICLA with the ASF.

Another way to view this development model is as if we were ZooKeeper 
committers who do not commit to trunk but which develop new features and bug 
fixes in development branches.  This model of development is use extensively in 
projects who are adverse to destabilizing the trunk.  They develop and test new 
features in a branch and then merge back once folks are happy with it.

This model is also outlined at [Rules for 
Revolutionaries|http://incubator.apache.org/learn/rules-for-revolutionaries.html]
  
> added a high level protocol/feature - for easy Leader Election or exclusive 
> Write Lock creation
> -----------------------------------------------------------------------------------------------
>
>                 Key: ZOOKEEPER-78
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78
>             Project: Zookeeper
>          Issue Type: New Feature
>          Components: java client
>    Affects Versions: 3.0.0
>            Reporter: james strachan
>         Attachments: patch_with_including_Benjamin's_fix.patch, 
> using_zookeeper_facade.patch
>
>
> Here's a patch which adds a little WriteLock helper class for performing 
> leader elections or creating exclusive locks in some directory znode. Note 
> its an early cut; am sure we can improve it over time. The aim is to avoid 
> folks having to use the low level ZK stuff but provide a simpler high level 
> abstraction.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to