Re: [general] (lack of) commit access (was: Re: [build] jdktools skips a fetch-depends for federated build)

[Vladimir Beliaev <vl...@gmail.com>]

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 <ma...@googlemail.com>:
>
>
> 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"
> <vl...@gmail.com> 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 <ma...@googlemail.com>:
> > >
> > >
> > > 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" <
> > > vladimir.k.beliaev@gmail.com> 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