Hi, On 5/17/07, Mark Brouwer <[EMAIL PROTECTED]> wrote:
Jim Hurley wrote: > 1) it seems worthwhile to separate out the starter kit code > contrib from the qa tests contrib. Does that make sense > (to create two separate issues for them)? I don't much care, > so if it's easier just to do them in one issue, I'm happy to > follow that advice. Just looking for input.
I'm fine both ways. Having just a single issue simplifies things procedurally.
I'm fine with one attachment as to me it seems there is no requirement of a one-on-one mapping between the layout of the attachment and the initial check-in of SVN.
Procedurally it's better if the contributed code is initially committed as-is. Simple reorderings are fine, but even they make it harder to later on verify that the committed codebase was actually the one covered by the software grant and voted on by the PPMC. More importantly, svn moves are cheap operations and leave a permanent record of how the codebase was reorganized, so I'd rather do any reorganization only after the code has landed in svn.
> 2) It seems (looking at the Service UI contrib) that we need to > bundle all of the source up and attach to the issue. After it > gets voted on and accepted into the project one of the mentors > will take that bundle and populate the svn tree. Did I get that > right? I should be done by one of the committers who should have write access so no need to wait for the mentors to do that.
Exactly. I did the ServiceUI API commit just because Bill was otherwise occupied at the time. Any one of the committers is free to commit the code once it's been accepted.
Before committing I think it is good to have a discussion about the layout of SVN, but don't let that hinder in starting the vote for accepting the contribution.
I typically find it easier to discuss layout issues if I have something concrete to look at. A source bundle in Jira is OK, but being able to checkout the source tree is (at least for me) much better. See also the above notes on svn moves. BR; Jukka Zitting
