Better working conditions (was: Re: Questions about using 1.5.2-SNAPSHOT)

[Alex Karasulu <ak...@apache.org>]

Hey Jorg,

I just changed the subject.  More inline ...

On Dec 20, 2007 12:33 PM, Jörg Henne <j....@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

Re: Better working conditions (was: Re: Questions about using 1.5.2-SNAPSHOT)

[Alex Karasulu <ak...@apache.org>]

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 <ak...@apache.org> wrote:

> Hey Jorg,
>
> I just changed the subject.  More inline ...
>
> On Dec 20, 2007 12:33 PM, Jörg Henne <j....@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
>
>

Re: Better working conditions (was: Re: Questions about using 1.5.2-SNAPSHOT)

[Alex Karasulu <ak...@apache.org>]

On Dec 21, 2007 9:23 AM, Jörg Henne <j....@levigo.de> wrote:

...


>
> > 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 :).
> I'll talk to them and introduce them to the list. But we probably won't
> make it this year, though :-)


Heh np :).

>     - A conflict of interests: wearing the openthinclient.org
> >     <http://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 <http://openthinclient.org>.
> Thanks, sounds great! There are so many areas in which we can cooperate
> (in addition to the ones we already discussed, the SAR and OSGi
> packaging come to mind), it would be a waste if we didn't.
>

Indeed! Looking forward to working with you guys.

Happy Holidays,
Alex

Re: Better working conditions (was: Re: Questions about using 1.5.2-SNAPSHOT)

[Jörg Henne <j....@levigo.de>]

Alex,

Alex Karasulu wrote:
> 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.
thanks for the encouragement. In fact, I've always found the atmosphere 
on this list exceptionally encouraging. My commit reluctance, I guess, 
was less related to a lack of confidence in my changes but more of a 
process thing (just do it). I'll fix this, promised :-)
>
>
>     - 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 :).
I'll talk to them and introduce them to the list. But we probably won't 
make it this year, though :-)
>
>
>     - A conflict of interests: wearing the openthinclient.org
>     <http://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 <http://openthinclient.org>.
Thanks, sounds great! There are so many areas in which we can cooperate 
(in addition to the ones we already discussed, the SAR and OSGi 
packaging come to mind), it would be a waste if we didn't.

Joerg Henne