Attention is currently required from: Felix Singer, Thomas Heijligen, Shreeyash , Alexander Goncharov.

View Change

1 comment:

File stlinkv3_spi.c:
- Patch Set #1, Line 501: stlinkv3_handle = usb_dev_get_by_vid_pid_serial(usb_ctx,
  Hi Shreeyash,
  @Angel Pons, Since I made this commit to understand the process of submitting a patch from start to finish, I would like to update my change. What exactly is the process though?
  The Process (i.e. the contribution/review process) is basically an infinite loop, and its main purpose is to improve things. It's not just about improving the code, as code reviews are (or should be) learning experiences for both the authors and the reviewers. Even people who aren't actively involved in the process can learn from reading Gerrit comments.
  Sorry if the pseudocode below is rather confusing. This is the general flow, with variations depending on the involved people. The usual process to getting changes submitted is, roughly:
```
```
  void contribute_a_thing(idea_t idea)
  {
  	/* The `idea` is what inspires one to change something. */
  	commit_t commit = create_new_commit_from(idea);
  	change_t change = create_new_change_from(commit);
```
```
  	/*
  	 * Review process starts, and will end once the
  	 * change is either submitted or abandoned.
  	 */
  	while (!is_submitted(change)) {
  		/* Do something else while waiting for reviews. */
  		thread_sleep();
  	
  		/* Read review comments and build bot results. */
  		feedback_t feedback = get_new_feedback_from(change);
  		
  		/*
  		 * No updates? Nothing to do but wait. It might be a good
  		 * idea to ping reviewers with a comment if a significant
  		 * amount of time has passed since last update.
  		 */
  		if (!have_new(feedback))
  			continue;
```
```
  		/* Update (local) commit with received feedback. */
  		commit_t new_commit = update_commit_with(commit, feedback);
  		
  		/*
  		 * If feedback indicates that a change is not needed, then
  		 * it should be abandoned. For example, duplicated changes
  		 * and changes that are fundamentally wrong. It is rare.
  		 */
  		if (is_empty(new_commit)) {
  			abandon(change);
  			return;
  		}
```
```
  		/* Update change with new commit, if it's not the same. */
  		if (new_commit != commit) {
  			upload_new_patchset(change, new_commit);
  			commit = new_commit;
  		}
```
```
  		/* Respond to review comments. */
  		reply_to_review(change, feedback);
  	}
  }
```
```
  In the case of this change, the situation is a bit messy because there's CB:67700 that does the same. But the current feedback is "do what CB:67700 does in your commit, and push it here".
  This is what I have to do:
  1. fetch current master
  2. rebase my branch
  3. this would result in merge conflicts, fix them.
  4. commit with a proper commit msg that reflects that this is not a bug fix
  5. push the changes
  Correct?
  Yes, something like this. To update a change (i.e. upload a new patchset), you'd amend the old commit with the feedback, while preserving the `Change-Id` line in the commit message. Gerrit uses the `Change-Id` to associate commits with changes.
  The exact procedure depends on how you organize yourself, e.g. do you use git branches, or are your commits on top of master? In any case, note that Gerrit does not use any merge commits: instead, commits are rebased, cherry-picked and amended.
  Sorry for the long-winded reply, hopefully it should answer your questions. If you have more questions, please don't hesitate to ask. 😊

To view, visit change 66225. To unsubscribe, or for help writing mail filters, visit settings.