> 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?
Perfect sense, thanks Chip. I'll update the fork location in the Jira ticket / Functional Spec once the location is decided, and develop there, keeping it in sync with developments in master and discussing progress on-list. Once 4.1.0 is cut (end of this month), I can start submitting patches to ASF master in sensible (squashed) chunks. Thanks to yourself and Pranav for the input. Thanks, Dave. On Tue, Jan 22, 2013 at 11:12 AM, Chip Childers <[email protected]>wrote: > 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 >
