On Mon, Jan 21, 2013 at 5:02 AM, Pranav Saxena <[email protected]> wrote: > Hi Dave , > > IP clearance is required only when your feature would have been developed > outside the community intervention and you want to propose that feature to be > merged with the asf/master branch. If you have happened to discuss the > functional spec for your feature with the community and answered the queries > if any one might have in the community and done all your code commits through > review requests , IP clearance would not be required at all . > > For your remaining queries - > See comments below - > [Dave] - * IMO, when pushing back to the repo, the commit should be big > enough that it's worth the reviewer's time - lots of tiny reviews would be a > burden on the reviewer > [Pranav] - I wouldn't comment on the size of the patch .If your code is > self-explanatory and clean , reviewing either small patches or a big one > should not be a big problem . But I would still recommend to send smaller > patches for reviews since it's easier for the people in the community to scan > through them easily and suggest amendments if required. > > [Dave] - * However, if chunks / reviews are too big, is there an issue of > development "appearing" to have happened outside of the ASF repo? > [Pranav] - If you have been sending review requests for all the code which > has gone into your github repo , it should not create an issue since after > all you have done your duty of making all your development in the community . > Just that , there should not be even a small chunk of code which has been > merged without having the community know about it - that's the criteria , I > reckon . > > [Dave] - However, this may not make sense - for example, this plugin is not > aimed for 4.1.0, so commits to it probably shouldn't be sent back to master > * Should there be a separate branch for the plugin in this case? If so, > should I just request that a committer create one? > > [Pranav] - If your plugin is not aimed for 4.1.0 and given that you are not > having committer rights , I believe , then your code won't be merged with > asf/master until the 4.1.0 release is over . Since you would just be > generating the patches and sending them for reviews. The committer would not > merge them with as/master and keep them on hold until that period . > Perhaps someone in the PPMC ( may be David Nalley or Chip or Animesh ) can > better answer your last query . > > Thanks, > Pranav
Dave / Pranav, I don't think that this is as complicated as is may seem at first. Here's what we have discussed previously: 1 - Do your development in a public repo (and share the location so that others can watch / help if they want). 2 - Make all technical discussions on this mailing list (as well as sharing periodic updates to this list about where things stand). Keeping up with master, can be as easy as having two remotes (your public repo and the ASF git repo) and periodically rebasing against ASF master as you develop. That will keep things in sync. We can also consider your public repo as the location of the "feature branch" (regardless of you doing work in your master branch or some other branch name), so we don't have to create a feature branch in the ASF repo for you. As for getting the code into the ASF repo, some thoughts: First, we only want 4.1 code in the master branch until we cut the release branch (at the end of Jan). We can start bringing in 4.2 features right after that. Second, if you are developing publicly, you can get it all ready to go before a final squashing your commits and submitting to review board (you'll want to do that in logical chunks). We don't need to have half-working commit history being brought in via review board (as long as your work in progress is public). Make sense? -chip
