directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: Better working conditions (was: Re: Questions about using 1.5.2-SNAPSHOT)
Date Thu, 20 Dec 2007 18:26:07 GMT
Oh and one more thing - with a better community here others who may be
interested might come on board.  So it's like a snowball effect.

Please feel free to ask for something if you think it might improve your
ability to work here.

Alex

On Dec 20, 2007 1:16 PM, Alex Karasulu <akarasulu@apache.org> wrote:

> Hey Jorg,
>
> I just changed the subject.  More inline ...
>
> On Dec 20, 2007 12:33 PM, Jörg Henne <j.henne@levigo.de> wrote:
>
> > Alex Karasulu wrote:
> > > Why don't you guys just revive the old sar module?  I think Emmanuel
> > > moved it over to the sandbox after a vote since no one was using or
> > > maintaining it.
> > >
> > > We need to learn how to work better together instead of going away for
> > > a while and then coming back with stuff to contribute in bulk.  We
> > > dropped the bar and made several people committers just to facilitate
> > > this.  It's much easier to just keep committing here on relevant
> > > pieces with a slow trickle and using that then having things progress
> > > so much it requires significant time to review and incorporate.
> > You are absolutely right in that bulk contributions like this are
> > sub-optimal. There are several reasons for why we dealt with it in the
> > way I/we (levigo) did, however:
> >
> > - Reluctance to actually commit code. This may be for whatever reasons -
> >
> > it being not really production ready or whatever. I felt more
> > comfortable with bringing the stuff up to a reasonable state within our
> > own code base and then coming back. Though I can see that the other way
> > around it would have been more rational: the current DHCP code within
> > Apache DS, albeit incomplete and non-working, was nevertheless useful
> > for us as a starting point. Well, I guess this can simply be overcome.
> >
>
> You could work in a sandbox here if you like or in a branch if you did not
> want to cause some problems in trunk.  We just want to make sure you feel
> comfortable committing here.  We voted you in as a committer because we saw
> you were competent and did not want you to have to deal with latency on our
> behalf with applying your changes.
>
> Furthermore we can work together and see the trickle of changes as they
> happen rather than dealing with large bulk changes.  People can watch the
> commit messages go by and comment on things even if you work in a sandbox.
> It just makes life easier.  I know this stuff is hard to do while you do a
> day job and deal with life in general.  But really if you just start
> practicing this there is little effort and actually we can save time later
> and generally collaborate better.
>
> I'm sure there were times when you wanted someone to look at something you
> were doing and double check something for you.  It's much easier to do this
> when you're working on the code here with us.  Just ask a friend or the
> whole list to take a look as you try to implement something and ask for
> feedback.
>
>
> > - Practical reasons like the fact that I am not the only one within our
> > team working on the code. In facht, I have not been working on it for
> > quite some time, while others did.
> >
>
> Ahh I see.  Hey help grow the community and bring these folks here.  We
> have a low barrier of entry as you noticed.  They're welcome to work on the
> DHCP code and augment it's community.  If they can submit one or two patches
> and engage the community then karma can be granted quickly.  For us karma is
> not a badge of honor but rather just a security mechanism for protection.
> It takes little to demonstrate that someone is sane and competent :).
>
>
> >
> > - A conflict of interests: wearing the openthinclient.org cap I am
> > interested in a stable version, so it makes sense to work with one as a
> > starting point. With the Apache DS it is obvious that the trunk is the
> > way to go. Keeping both points of view balanced isn't that easy.
> >
> >
> I understand better now.  If there is anything we can do to make it easier
> for you guys to get going here let us know.  I'd like to help make sure
> these complications go away for you and others from openthinclient.org.
>
> Regards,
> Alex
>
>

Mime
View raw message