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.
I just changed the subject. More inline ...On Dec 20, 2007 12:33 PM, Jörg Henne <firstname.lastname@example.org> wrote:
Alex Karasulu wrote:You are absolutely right in that bulk contributions like this are
> 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.
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.