[jira] Created: (HADOOP-6750) UserGroupInformation incompatibility: getCurrentUGI() and setCurrentUser() missing

[Cosmin Lehene (JIRA)]

UserGroupInformation incompatibility: getCurrentUGI() and setCurrentUser() 
missing
--

 Key: HADOOP-6750
 URL: https://issues.apache.org/jira/browse/HADOOP-6750
 Project: Hadoop Common
  Issue Type: Bug
  Components: security
Reporter: Cosmin Lehene
 Fix For: 0.21.0


getCurrentUGI() and setCurrentUser() are missing from the new 0.21 branch

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

Re: [DISCUSSION] Release process

[Cosmin Lehene]

Hi, 

I'm glad we're heading towards a release. We'd like to better understand some 
aspects regarding the release plan.

What would be the tentative release schedule, and what affects particular 
releases? We could either continue with our current version or plan based on 
what's going to be released.

I guess an upgrade decision process is mostly influenced by the amount of work 
required to update and test existing code for  API changes balanced by the 
features benefits from the upgrade, with aspects such as Data Integrity being 
blockers.

Hence,  we'd like to understand how the following things map on, or affect, the 
next releases (0.x, 1.x, 2.x)

* Data Integrity (I guess this should be blocking for any release)
* API compatibility (I understand this is the primary driver for the release 
major numbering)
* High level features(Append, Security, Avro, Rolling upgrades, etc. - this 
would map on a time basis)
 
In our case we have code running on 0.21 and need "Append", with the current 
focus being Data Integrity. We can handle an API change, but really concerned 
about Data Integrity. So, for us, fixing any blocking issues on hdfs-0.21 
(potentially 0.22) and then further maintaining it stable would be the 
priority, regardless whether this will be 0.X, 1.X, or 2.X. Depending on the 
result of this release schedule we might be able to stick with one of them or 
to fork for a while.

Thanks for your help,
Cosmin

On Mar 31, 2010, at 6:22 AM, Owen O'Malley wrote:

> 
> On Mar 30, 2010, at 3:40 PM, Doug Cutting wrote:
> 
>> Another release we might consider is 1.0 based on 0.20.
> 
> It is tempting and I think that 0.20 is *really* our 1.0, but I think  
> re-labeling a release a year after it came out would be confusing.
> 
> I think that we should change the rules so that the remaining 0.X  
> releases are minor releases. That seems a relatively minor change and  
> just means that we can't remove deprecated items until 1.0.
> 
> I'll volunteer to be release manager for a release branched in  
> November, which should be roughly 6 months after Tom's new 0.21 release.
> 
> One possible release numbering would have the November release be 0.99  
> and a matching 1.0 that removes all of the deprecated methods.
> 
> -- Owen
> 

Hadoop coding style guideline

[Cosmin Lehene]

Hi,

I was trying to make a patch and looking over the Hadoop guidelines for code at 
http://wiki.apache.org/hadoop/CodeReviewChecklist, trying to follow the 
conventions.

Looking through code I found a few "patterns", however, these differ even in 
the same class sometimes. Here's a collection of method declaration styles I 
gathered from 2 or 3 files: http://pastie.org/707389

I have to admit Sun's code conventions are a bit unclear too, so maybe a list 
of settings for the IDE like tab size, indent, continuation indent, exceptions 
to the rule, etc. would help.

Cosmin