On Jan 13, 2011, at 3:34 PM, Todd Lipcon wrote:

On Thu, Jan 13, 2011 at 3:05 PM, Arun C Murthy <a...@yahoo-inc.com> wrote:

Since this could be applied as a linear set of patches instead of a big
lump, would there be interest in using this as the 0.20.>100 Apache
release?
I can take the time to remove any patches that are cloudera specific or
not
yet applied upstream.


Interesting discussion, thanks.

I'm sure it took you a fair amount of work to squash patches (which I tried
too, btw).


Yep, I had a great summer ;-)


That, plus the fact that we would need to do a similar amount of work for
the 10 or so releases we have done after 0.20.100.3 scares me.


Sorry, I actually meant 0.20.104.3. Have there been many releases since then? That's the last version available on the Yahoo github, and that's the
version we incorporated/linearized.

Yep. I had a great summer! ;-)


As we Nigel and I discussed here, the jumbo  patch and an up-to-date
CHANGES.txt provides almost all of the benefits we seek and allows all of us
to get this done very quickly to focus on hadoop-0.22 and beyond.


In my opinion here are the downsides to this plan:


I agree there are downsides, I think I did point them out at the outset! :)

- a mondo "merge" patch is a big pain when trying to do debugging. It may be
sufficient for a user to look at CHANGES.txt, but I find myself using
blame/log/etc on individual files to understand code lineage on a daily basis. If all of the merge shows up as a big patch it will be very difficult (at least the way I work with code) to help users debug issues or understand
which JIRA a certain regression may have come from.


Right, no question. Which is why I offered to do this as a background activity right after... this ensures that the source of truth is *always* a branch in Apache subversion.

I feel that we could get a usable release out of door quickly for our users. Also, please remember that almost every patch we have committed is available on relevant jiras. I understand the devs have a problem and I feel we can bear with it for a little while. Again, I agree this isn't an ideal solution, I'm just trying to expedite the release for the users.


To clarify my position a bit here - I definitely appreciate your
volunteering to do the work, and wouldn't *block* the proposal as you've put it forth. I just think it will have limited utility for the community by being opaque (if contributed as a giant patch) and by not including the sync
feature which is critical for a large segment of users. Given those
downsides I'd rather see the effort diverted towards making a killer 0.22
release that we can all jump on.


Thanks for understanding.

Again, I completely agree this isn't an ideal situation, but I do hope it has a bit more than *limited utility* for our end-users. Who knows, I maybe hopelessly deluded! *smile*

Also, I'm trying to do exactly what you suggested - spend very little time on this so that everyone, including me, can focus on the future.

thanks,
Arun


Reply via email to