Development Flow Improvements

Development Flow Improvements

[Jason]

Hey folks,

I wanted to update you on a conversation a few of us have been having
off-list. In order to hasten the speed of development, we're making
some changes to the way things are done.

All submitted patch series will now live in feature branches. Each
feature branch will be owned by either me (jd), John (jk), Christian
(ch), Ferry (fh), Lukas (lf), or Lars (lh), and will be titled
something like "jk/add-links-to-header". After enough review, and the
feature is ready to land, it will be put into the owner's "for-jason"
branch -- such as "ch/for-jason". Then, when I'm ready, I'll review
and sweep up all the various */for-jason branches (including my own!)
into master, and sometime after that cut a release.

This should pick up the pace a little bit, because it enables any of
us to more easily review a patch series and get it ready for final
inclusion. So, if you submit a patch series, and you get a reply from
me, John, Christian, Ferry, Lukas, or Lars, saying something like,
"I'll review this," it means it should shortly after wind up in a
feature branch on <https://git.zx2c4.com/cgit/>.

I think this will work out well. Looking forward to finally see some
patches land.

Regards,
Jason

Development Flow Improvements

[jamie.couture]

I'm curious whether there is a merge policy in place for those *for-jason
branches. Will they be fast forward only or reasonable they may be reset
since it's really just a contract for you and the person providing the
series, rather than something others should be following.

For example. In git.git it is understood that special topics 'pu' are reset
often.

On Tuesday, 27 September 2016, Jason A. Donenfeld <Jason at zx2c4.com> wrote:

> Hey folks,
>
> I wanted to update you on a conversation a few of us have been having
> off-list. In order to hasten the speed of development, we're making
> some changes to the way things are done.
>
> All submitted patch series will now live in feature branches. Each
> feature branch will be owned by either me (jd), John (jk), Christian
> (ch), Ferry (fh), Lukas (lf), or Lars (lh), and will be titled
> something like "jk/add-links-to-header". After enough review, and the
> feature is ready to land, it will be put into the owner's "for-jason"
> branch -- such as "ch/for-jason". Then, when I'm ready, I'll review
> and sweep up all the various */for-jason branches (including my own!)
> into master, and sometime after that cut a release.
>
> This should pick up the pace a little bit, because it enables any of
> us to more easily review a patch series and get it ready for final
> inclusion. So, if you submit a patch series, and you get a reply from
> me, John, Christian, Ferry, Lukas, or Lars, saying something like,
> "I'll review this," it means it should shortly after wind up in a
> feature branch on <https://git.zx2c4.com/cgit/>.
>
> I think this will work out well. Looking forward to finally see some
> patches land.
>
> Regards,
> Jason
> _______________________________________________
> CGit mailing list
> CGit at lists.zx2c4.com <javascript:;>
> http://lists.zx2c4.com/mailman/listinfo/cgit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/cgit/attachments/20160927/ea693ef3/attachment.html>

Development Flow Improvements

[Jason]

Hi Jamie,

I won't force commit on master, obviously (well, I've violated this in
the past, but don't intend to in the future). But I'd likely rebase
for-jason branches when merging if that makes the merge strategy
easier. The for-jason branches will be ephemeral; after I merge to
master, they'll be deleted. Here's the output from this process I
carried out earlier today, to give a better impression.

Does that seem reasonable, or is there some common edge case I'm neglecting?

Regards,
Jason

zx2c4 at thinkpad ~/Projects/cgit $ git pull
remote: Counting objects: 23, done.
remote: Compressing objects: 100% (23/23), done.
remote: Total 23 (delta 18), reused 0 (delta 0)
Unpacking objects: 100% (23/23), done.
From ssh://git.zx2c4.com/cgit
* [new branch]      ch/css-highlight-table-rows ->
origin/ch/css-highlight-table-rows
* [new branch]      ch/for-jason                -> origin/ch/for-jason
* [new branch]      ch/git-2-10-0               -> origin/ch/git-2-10-0
zx2c4 at thinkpad ~/Projects/cgit $ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
zx2c4 at thinkpad ~/Projects/cgit $ git merge origin/ch/for-jason
Updating ff9893a..11695a5
Fast-forward
Makefile    |  2 +-
cgit.c      |  2 +-
cgit.h      |  8 ++++----
git         |  2 +-
shared.c    | 28 ++++++++++++++--------------
ui-diff.c   | 74
+++++++++++++++++++++++++++++++++++++-------------------------------------
ui-diff.h   |  4 ++--
ui-log.c    |  2 +-
ui-ssdiff.c |  4 ++--
9 files changed, 63 insertions(+), 63 deletions(-)
zx2c4 at thinkpad ~/Projects/cgit $ git push
Total 0 (delta 0), reused 0 (delta 0)
To ssh://git.zx2c4.com/cgit
  ff9893a..11695a5  master -> master
zx2c4 at thinkpad ~/Projects/cgit $ git push origin :ch/for-jason
To ssh://git.zx2c4.com/cgit
- [deleted]         ch/for-jason

Development Flow Improvements

[mailings]

On 28/09/16 01:27, Jason A. Donenfeld wrote:
> Hi Jamie,
>
> I won't force commit on master, obviously (well, I've violated this in
> the past, but don't intend to in the future). But I'd likely rebase
> for-jason branches when merging if that makes the merge strategy


THis should preferably avoided; let the owner of the branch do that 
rebase or let him merge master into his branch first. That way the guy 
that knows what is going on the branch will handle the conflicts.

Then you can merge to master.
These merges should always be without conflict.

> easier. The for-jason branches will be ephemeral; after I merge to
> master, they'll be deleted. Here's the output from this process I
> carried out earlier today, to give a better impression.
>
> Does that seem reasonable, or is there some common edge case I'm neglecting?
>
> Regards,
> Jason
>
> zx2c4 at thinkpad ~/Projects/cgit $ git pull
> remote: Counting objects: 23, done.
> remote: Compressing objects: 100% (23/23), done.
> remote: Total 23 (delta 18), reused 0 (delta 0)
> Unpacking objects: 100% (23/23), done.
> From ssh://git.zx2c4.com/cgit
> * [new branch]      ch/css-highlight-table-rows ->
> origin/ch/css-highlight-table-rows
> * [new branch]      ch/for-jason                -> origin/ch/for-jason
> * [new branch]      ch/git-2-10-0               -> origin/ch/git-2-10-0
> zx2c4 at thinkpad ~/Projects/cgit $ git checkout master
> Switched to branch 'master'
> Your branch is up-to-date with 'origin/master'.
> zx2c4 at thinkpad ~/Projects/cgit $ git merge origin/ch/for-jason
> Updating ff9893a..11695a5
> Fast-forward
> Makefile    |  2 +-
> cgit.c      |  2 +-
> cgit.h      |  8 ++++----
> git         |  2 +-
> shared.c    | 28 ++++++++++++++--------------
> ui-diff.c   | 74
> +++++++++++++++++++++++++++++++++++++-------------------------------------
> ui-diff.h   |  4 ++--
> ui-log.c    |  2 +-
> ui-ssdiff.c |  4 ++--
> 9 files changed, 63 insertions(+), 63 deletions(-)
> zx2c4 at thinkpad ~/Projects/cgit $ git push
> Total 0 (delta 0), reused 0 (delta 0)
> To ssh://git.zx2c4.com/cgit
>   ff9893a..11695a5  master -> master
> zx2c4 at thinkpad ~/Projects/cgit $ git push origin :ch/for-jason
> To ssh://git.zx2c4.com/cgit
> - [deleted]         ch/for-jason
> _______________________________________________
> CGit mailing list
> CGit at lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/cgit
>

-- 
Ferry Huberts

Development Flow Improvements

[peter]

Hi Jason,

Thanks for tagging the new release!

On Wed, Sep 28, 2016 at 01:27:38AM +0200, Jason A. Donenfeld wrote:
> zx2c4 at thinkpad ~/Projects/cgit $ git push
> Total 0 (delta 0), reused 0 (delta 0)
> To ssh://git.zx2c4.com/cgit
>   ff9893a..11695a5  master -> master

May I suggest a minor improvement to the work flow?

Before pushing to "master" you can simulate pushing for a final review:

# git push -n
# git log -p -c -M --stat --decorate --pretty=fuller ff9893a..11695a5

(I use a git alias "review" for the latter.)

This allows one to catch things like an accidental revert of a submodule.

Peter