please close these issues

[Karan Malhi <ka...@gmail.com>]

Can somebody close OPENEJB-29 and OPENEJB-20 ? I went through the list
of open issues and looks like some of them are pretty old and are
already taken care of.

-- 
Karan Singh Malhi

Re: No, thank you (Re: please close these issues)

[Karan Malhi <ka...@gmail.com>]

>It isn't having the patches in svn in a timely manner that's the
>biggest help (though definitely nice), it's getting the immediate
>feedback and growing the code organically as a team ensuring all work
>is relevant that's the real magic.
Absolutely, in a Patch > Review > Commit cycle , review is definitely
a nice opportunity for a new contributor to learn about the project. I
think what is really helping me here is to understand whats going on
in the "committers head".

> it's very easy to bounce ideas back and forth, try stuff
> out in code, see how it looks, learn from it and add more ideas on
> top of it.  We can tweak it here and there and all the while we're
> working on the same code *in svn*.  I'm just thrilled.
I cannot agree more. It is so much fun working this way, and I guess
thats what kept me going on this issue and improving it.

> Everyone who wants to contribute to open source should take a page from your >book.
Wow!!, A statement like this coming from a person like you is a big
thing for me. Thanks!!
>
> The shorter the time between proposal, patch, and commit the better.
Totally agree
BTW, as hungry as I am for documentation at this moment, I am thinking
of putting your thoughts in the contributors guide :)

> -David
>
>


-- 
Karan Singh Malhi

Re: No, thank you (Re: please close these issues)

[David Blevins <da...@visi.com>]

On Aug 12, 2007, at 2:54 PM, Karan Malhi wrote:

>> But generally if there's a jira assigned to you and you don't know
>> when you'll get time to work on it, after a few weeks of no activity
>> you should put it back in the pool
> And how would I do this ...
>> -- very easy to grab it again
> and this....

If you're a committer you can just assign it to "Unassigned".  For  
contributors, just shoot the list a note or make a comment on the  
issue (and hope someone notices :).

And I suppose it'd even be cool just to say on the issue "won't be  
able to look at this for a while, if someone else can get to it, feel  
free to take it."

-David

Re: No, thank you (Re: please close these issues)

[Karan Malhi <ka...@gmail.com>]

> But generally if there's a jira assigned to you and you don't know
> when you'll get time to work on it, after a few weeks of no activity
> you should put it back in the pool
And how would I do this ...
> -- very easy to grab it again
and this....

> -David
>
>
>
>


-- 
Karan Singh Malhi

Re: No, thank you (Re: please close these issues)

[David Blevins <da...@visi.com>]

On Aug 12, 2007, at 10:57 AM, Karan Malhi wrote:

>> Whenever I know someone is
>> working on some big changes and aren't letting them out for weeks on
>> end, I get very nervous about the pending train wreak.
>
> So, how would I notify the list that I am currently not working on the
> issue I am assigned to , because maybe I am busy . For example, I
> cannot work on the logging issue till this Friday, because of an
> assignment which will pretty much take up my whole day every day this
> week. However, you might think that I am currently working on the
> Logging issue (which I am not). So, how would I let you know of that ?
> Is there a procedure I need to follow for this, or do I just send you
> an email saying, "I cannot work on it for a week". I would hate to sit
> quiet and let you think I am working on it.
>

I usually assume someone is not working on something unless they say  
otherwise, even if there's a jira assigned to them.  That's the most  
typical case anyway :)

But generally if there's a jira assigned to you and you don't know  
when you'll get time to work on it, after a few weeks of no activity  
you should put it back in the pool -- very easy to grab it again  
should you find the time one day.  Not a hard rule, just a good  
goal :)   I only clean out jiras assigned to me once every couple of  
months -- I should do it much more than that.

-David

Re: No, thank you (Re: please close these issues)

[Karan Malhi <ka...@gmail.com>]

>Whenever I know someone is
> working on some big changes and aren't letting them out for weeks on
> end, I get very nervous about the pending train wreak.

So, how would I notify the list that I am currently not working on the
issue I am assigned to , because maybe I am busy . For example, I
cannot work on the logging issue till this Friday, because of an
assignment which will pretty much take up my whole day every day this
week. However, you might think that I am currently working on the
Logging issue (which I am not). So, how would I let you know of that ?
Is there a procedure I need to follow for this, or do I just send you
an email saying, "I cannot work on it for a week". I would hate to sit
quiet and let you think I am working on it.

Any suggestions?
-- 
Karan Singh Malhi

No, thank you (Re: please close these issues)

[David Blevins <da...@visi.com>]

On Aug 8, 2007, at 4:18 AM, Karan Malhi wrote:

> Thanks a lot for committing the patches. Timely commits are such a
> great help to me, otherwise i have to constantly check to make sure
> that the current change I am making does not conflict with any pending
> patches , which is a big PITA.

Definitely a PITA.  I did big amout of work for XStream last year and  
they weren't able to look at that first patch and I kept going..   
then they were still too busy for that second patch.. and the third  
patch... and the fourth patch.  It just didn't work out mostly  
because we weren't connecting early in the process and my work  
ultimately didn't line up with how they would have wanted the  
features implemented.

It isn't having the patches in svn in a timely manner that's the  
biggest help (though definitely nice), it's getting the immediate  
feedback and growing the code organically as a team ensuring all work  
is relevant that's the real magic.

On the other end of the spectrum, often times people want to hold  
changes till they "get them right" and weeks go by and suddenly one  
big code drop happens.  By that point things are way beyond the  
opportunity for iterative (collaborative) development and it's often  
very difficult to absorb the changes -- usually an all or nothing  
situation.  It can be much worse too if there was a lot of high level  
talk/discussion from the person doing the "in a corner" development  
as they feel like there's an agreement and the code will be accepted  
with no significant changes; "i spent all this time doing it this way  
cause you said that's what you wanted!"  Talking with other people  
yet still keeping the code to yourself (either because you're afraid  
of judgment, don't want to bother people with too many patches, or  
because you don't want people messing with "your stuff") ultimately  
*is not* collaborative development.  This issue can happen with  
contributors and committers alike.  Whenever I know someone is  
working on some big changes and aren't letting them out for weeks on  
end, I get very nervous about the pending train wreak.

You've been utterly fantastic about submitting small, manageable  
patches and it's very easy to bounce ideas back and forth, try stuff  
out in code, see how it looks, learn from it and add more ideas on  
top of it.  We can tweak it here and there and all the while we're  
working on the same code *in svn*.  I'm just thrilled.  Everyone who  
wants to contribute to open source should take a page from your book.

The shorter the time between proposal, patch, and commit the better.

-David

Re: please close these issues

[Karan Malhi <ka...@gmail.com>]

Thanks a lot for committing the patches. Timely commits are such a
great help to me, otherwise i have to constantly check to make sure
that the current change I am making does not conflict with any pending
patches , which is a big PITA.

OPENEJB-625 is also waiting to get committed :) . Here is a gist of
what issue this patch solves. Currently RedeployTest is invoked during
the build, but simply returns. This gives "an impression" that the
test passed, but the test code was not invoked at all because of
1. ** itests-beans.jar**  being improperly named
2. Test is not looking in all possible maven repository for the above file.

So, if time permits, I would request you to please apply the patch

On 8/8/07, David Blevins <da...@visi.com> wrote:
>
> On Aug 6, 2007, at 8:11 PM, Karan Malhi wrote:
>
> > Can somebody close OPENEJB-29 and OPENEJB-20 ? I went through the list
> > of open issues and looks like some of them are pretty old and are
> > already taken care of.
>
> Closed OPENEJB-20 and added a small unhelpful comment to
> OPENEJB-29 :)  More details in the logging thread.
>
> -David
>
>


-- 
Karan Singh Malhi

Re: please close these issues

[David Blevins <da...@visi.com>]

On Aug 6, 2007, at 8:11 PM, Karan Malhi wrote:

> Can somebody close OPENEJB-29 and OPENEJB-20 ? I went through the list
> of open issues and looks like some of them are pretty old and are
> already taken care of.

Closed OPENEJB-20 and added a small unhelpful comment to  
OPENEJB-29 :)  More details in the logging thread.

-David