harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject [general] (lack of) commit access (was: Re: [build] jdktools skips a fetch-depends for federated build)
Date Fri, 19 Oct 2007 15:02:07 GMT

Apologies to Vladimir, this is really just a general rant and I have
probably misunderstood what he meant.  However, I think these points are
worth covering since they come up fairly regularly.

On 19 October 2007 at 15:22, "Vladimir Beliaev"
<vladimir.k.beliaev@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.

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).

Of course, the changes make it into the code base more efficiently[0]
because another committer doesn't have to understand the changes[1].

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.  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.  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.

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.

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 <mark.hindess@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--
> 



Mime
View raw message