Looks like I really touch you on a raw spot... In short - I do not argue with what you wrote below and do not totally agree with it...
I'd like to comment something... 2007/10/19, Mark Hindess <[EMAIL PROTECTED]>: > > > Apologies to Vladimir, this is really just a general rant and I have > probably misunderstood what he meant. No problem, really... I did mean "give me a committer role to let me clean up the code"... kidding... sorry... However, I think these points are > worth covering since they come up fairly regularly. > > On 19 October 2007 at 15:22, "Vladimir Beliaev" > <[EMAIL PROTECTED]> wrote: > > > > Yes, code clean up work is really fun especially for one who is able > > to commit it immediately... > > No, if it is fun (!) then it is just as much fun with or without commit > access. Exactly. One day I dropped off ~3'000 lines of code emulating a communication protocol and replaced it with 300 simple lines using a ready tcp/ip wrapper. I was happy for several weeks after this. Recently I've removed ant-based XML parsing with SAX-based java program, about 400 lines of hard-to-support code went away (not too much, agree). This was a fun for me, really. I wish I would stress the word "especially"... Or would not write that sub-sentence right after voting for committers. > I think my JIRA history shows that it is just as easy to contribute > cleanup work without commit access. I can honestly say that having > commit access has made no difference to the amount of personal > contributions I make - other factors certainly have (one of them is > sleeping in his cot as I write this). H-m-m... I heard many times from committers the requests like "please do not format the code - the patch is not readable then"... And I understand such a request. One may think that the applying a patch and use "diff -ub" with an old version of file can produce a "simple patch to understand"... That's not true - clean up is not just correcting white spaces but often it is class members renaming / optimization, dead code removal, data structures changing... Such a cleanup is producing quite a big patch which becomes invalid pretty soon due to other patches were committed for code being cleaned-up. > Of course, the changes make it into the code base more efficiently[0] > because another committer doesn't have to understand the changes[1]. +1. Still the "patch become out-of-date and "rebase time == redo time" is more improtant reason I think. I don't think I'd mind too much if I had my commit access taken away[2]. > It would not make me personally any less productive. +1. A do not see any connection between a person's committer status and his/her technical production for project. To be honest, > I think the main reason I got commit access was because other people > got feed up with doing commits for me. ;-) > > Being a committer brings responsibility and as such is both a curse and > a blessing. If someone submitted a bad fix to JIRA[3], it is still the > committer that has ultimate responsibility for breaking the code. Agree, but I beileve it is an "intention", not a "reality". If we start speaking about this then I would say that sometimes it takes time to prove the committer that his/her patch breaks something. Sometimes it takes time to persuade a committer testing his/her patch on different platforms with different compilers. So > a committer has to understand a fix and think about the consequences > for the project. Producing a fix is often simpler than understand the > result because the result - no matter how thoroughly explained - misses > details of the learning experience you went through to produce it. +1. Some would argue that being as productive without commit access does > necessitate having a few more tools at your disposal[4]. However, > personally I find that > tools to manage my workspaces are just as important now as they were > when I had no commit access. +1 again. Thanks Vladimir Beliaev Regards, > Mark. > > [0] Although my recent history - breaking the windows build - isn't > particularly efficient. Sorry and thanks to everyone for keeping > me inline. > > [1] Though I know that at least Tim is ...err.. conscientious about > reading commits and I hope other committers are paying some > attention too. > > [2] And perhaps if I keep breaking the windows build I might, though > I hope it doesn't come to that. ;-) > > [3] If by now you've glanced at my JIRA history, you will have seen > some examples. > > [4] I used to use quilt but now commonly use both git[5] and cow-shell[6]. > I believe there is a new eclipse tool to help manage this kind of work > flow? Perhaps someone else has tried it and can comment? > > [5] Salikh wrote an excellent description of the use of git for a > non-committer: > > http://article.gmane.org/gmane.comp.java.harmony.devel/21635 > > [6] Copy-on-write shell: > > http://www.netfort.gr.jp/~dancer/software/cowdancer.html.en > > > 2007/10/19, Mark Hindess <[EMAIL PROTECTED]>: > > > > > > > > > For licensing reasons, fetch depends is only executed if you run: > > > > > > ant -Dauto.fetch=true > > > > > > It should work if you do this? > > > > > > Having said that I think there is room for improvement in the > build.xml. > > > For example, these targets: > > > > > > <target name="auto_fetch_jdktools_libs" if="auto.fetch"> > > > <ant target="fetch_jdktools_libs" inheritall="false" > > > > <property name="hy.cfg" value="${hy.cfg}"/> > > > </ant> > > > </target> > > > > > > <target name="fetch_jdktools_libs" if="auto.fetch"> > > > <ant antfile="working_jdktools/build.xml" > target="fetch-depends" > > > inheritall="false" > > > > <property name="hy.cfg" value="${hy.cfg}"/> > > > </ant> > > > </target> > > > > > > seem overly complicated and probably can be replaced by a single > target: > > > > > > <target name="auto_fetch_jdktools_libs" if="auto.fetch"> > > > <ant antfile="working_jdktools/build.xml" > > > target="fetch-depends" inheritall="false" > > > > <property name="hy.cfg" value="${hy.cfg}"/> > > > </ant> > > > </target> > > > > > > Unless I'm missing something? This build.xml really needs some > cleanup. > > > (For example adopting the convention of beginning non-api/-user > targets > > > with hyphen so it is easier to read.) Maybe I'll take a look later. > > > > > > Regards, > > > Mark. > > > > > > On 19 October 2007 at 12:06, "Vladimir Beliaev" < > > > [EMAIL PROTECTED]> wrote: > > > > > > > > Hello, > > > > > > > > I come across the same issue twice - the federated build skips > fetching > > > > dependencies for jdktools. > > > > > > > > I mean I did a build just by simple 'ant' command from the root > > > directory of > > > > federated workspace: > > > > > > > > /tmp/trunk $ pwd > > > > /tmp/trunk > > > > /tmp/trunk $ ls -1 > > > > working_classlib/ > > > > working_jdktools/ > > > > working_vm/ > > > > <skipped> > > > > /tmp/trunk $ ant > > > > <skipped> > > > > BUILD FAILED... > > > > <skipped> > > > > > > > > And this can be fixed by: > > > > > > > > /tmp/trunk $ cd working_jdktools > > > > /tmp/trunk/working_jdktools $ ant fetch-depends > > > > > > > > Is it a known issue? > > > > > > > > I double check trunk/build.xml - looks like all tags for jdttools's > > > > fetch-depends are in place... So it may be my local issue... That's > why > > > I > > > > ask. > > > > > > > > -- > > > > Vladimir Beliaev > > > > Intel Middleware Products Division > > > > > > > ------=_Part_7594_13325979.1192792955206-- > > > > > -- Vladimir Beliaev Intel Middleware Products Division
