Marcin Okraszewski wrote:
I can say something from a contributor point of view. I've contributed two
rather trivial patches and ... I'm discouraged. Simply the process was far too
long. Actually I had to ask that someone takes a look for it. Once someone
invest his time to create patch, write a Jira entry, etc., you rather expect it
to be reviewed and possibly committed. If there is at least one person who
needs it that much that is willing to develop it, it may mean there might be
others who would need it as well.
Some of the committers have also discussed adding something like a
"pending review" workflow to Nutch JIRA for just these cases. Although
was leaving that for another discussion. maybe now is the time to discuss.
Just to add. I've done some several contributions to some other projects, but
this is first time I have a feeling like this.
As looking for perfection, it must be balanced in my opinion. If there is
something trivial which is not done perfect, which does not break architecture
... well, it might be acceptable. But if something would make a spaghetti code,
I wouldn't be so much for it. So my rule of thumb would be - once it breaks
well design, introduces too big complexity, it shouldn't be accepted. If it
doesn't influence those, but does what it should, maybe in a bit clumsy way -
why not. It still solves someone's problem or need.
I agree. Quality is still a necessity. Including bad code isn't
progress IMHO.
Dennis
Regards,
Marcin
Dnia 16 listopada 2007 18:45 Dennis Kubes <[EMAIL PROTECTED]> napisał(a):
So a few years ago I started a dating site called oneforever.com. Good
technology, but it took us 9 months to develop the first version.
Mostly because we wanted everything to be perfect. So we would work on
something, if it was not perfect change it, and so on. We never did get
it perfect, we just got it to the point where we had to launch it.
A few months ago a started a different project focused around social
networking and search. With this project I took the viewpoint of
consistent progress every day. I would make some improvement to it
everyday, no matter how small. No such thing as perfect, just better.
This project developed much quicker and I think is actually a better
code base. And what was more it was fun to work on.
All of this is to say that I don't think there is any such thing as
perfection. I do think there is better, continuously better. And since
we all enjoy programming (I hope), the making something better (not
perfect or best) is the fun part (or at least should be). I can only
talk from my experience but I think the best part of programming is when
I have found the solution to the problem and it just works.
So as we are developing this *standard* for committers I agree with
Chris that we should make this fun and casual and not be worried about
breaking the trunk. After all, it's only code (I know, to some people
that is heresy :)) I actually think we are all in agreement about this.
I would love to hear from some of the other committers or members of
the community before we put these thoughts down on a wiki.
Oh, and I am ok with minor issues having a longer wait time or 1 or more +1.
Dennis Kubes
Chris Mattmann wrote:
Hi Guys,
I'd like to chime in here on this one. My +1 for shortening the time to
commit for issues. I fear that development effort on Nutch has teetered on
the dwindling side of things for the last year or so, and there (in my
opinion, so feel free to disagree) is certainly a stigma to the trunk and
its "sacred" nature that discourages people (including myself) from
introducing new code there.
I would like to propose even extending Dennis's idea below and developing a
new philosophy towards the Nutch CM. To me, the big picture change is the
following statement: "the trunk is something that can be broke." Let's just
accept that it's possible. If it's broke, someone will report it. Nutch has
a big enough user base now that plays around with new builds and revisions
that this will get caught. Guess what. If the trunk is broke, then it can be
fixed.
I'll tell you guys a story of one of my bosses here at JPL. He used to work
for a civil defense contractor in the U.S., with very rigorous design and
software development process. Unit tests for each line of code type of
place. In any case, my boss used to break his company's equivalent of the
"trunk" daily build process all the time. Well one day he gets called in to
speak with the vice president of engineering at the company, who proceeds to
tell him: "You're really good at breaking the code, eh?". My boss
immediately jumps up to defend himself, citing the fact that it wasn't a big
problem and that he has fixed it already, but the vice president cuts him
off and says, "You probably think I'm mad. Well let me tell you: I'm not.
You can break the code all you want because you know what it tells me? That
you're actually *DOING WORK* unlike the rest of these people who work here
and do very little."
The above story has stuck with me and made me feel a lot better about
situations such as those in that it gives me the belief that waiting until
everything is perfect before acting in a situation isn't always the best
thing to do because you may end up waiting forever. It's better to make
incremental progress (even falter while doing so), because what you end up
with may be just as good (or even better) as if you tried to be a
perfectionist and only made progress/did work when you felt everything was
"right".
My 2 cents,
Chris
On 11/15/07 1:37 PM, "Dennis Kubes" wrote:
So I have been talking with some of the other committers and I wanted to
layout a suggestion for standardizing some of the nutch committer
workflow processes in the hope of speeding up nutch development.
The first one I was hoping to tackle is time to commit. At least for me
it has been hard to know when to commit something, especially when it
was trivial or no one commented on the issue. Here is what is being
proposed:
Trivial changes = immediate, this at the discretion of the committers
Minor changes = 24 hours from latest patch or 1 or more +1 from committers
Major and blocker changes = 4 days from latest patch or 2 or more +1
from committers
This way if an issue has been active for some time but no one has taken
a look at it, and it has passed all unit tests, then we can go ahead and
commit it. Also this should allow more of the smaller changes to be
handled faster.
So these of course are just some suggestions would love to hear from
others in the community. What I think would be best is to come to a
consensus on this and then have a wiki page describing this and other
processes for committers.
Dennis Kubes
______________________________________________
Chris Mattmann, Ph.D.
[EMAIL PROTECTED]
Cognizant Development Engineer
Early Detection Research Network Project
_________________________________________________
Jet Propulsion Laboratory Pasadena, CA
Office: 171-266B Mailstop: 171-246
_______________________________________________________
Disclaimer: The opinions presented within are my own and do not reflect
those of either NASA, JPL, or the California Institute of Technology.
