Gerrit 'Commit sets' functionality

[petefoth]

Hi

Further to the discussion at http://groups.google.com/group/repo-discuss/browse_thread/thread/ee21d559cbe1813f#
, at Codethink we have started to work on implementing this
functionality. Eventually we would like to see the changes upstreamed
and would welcome any comments on what we propose.

The requirement is to introduce the idea of a 'commit set', consisting
of a number of individual commits that are to be treated as a unit in
all following operations:
- Review
- Approval/Verification
- Integration/pushing to upstream repos
If any single commit fails any stage, the whole set must be rejected.

Edwin has pointed out that it's already possible to group changes by
topics/tags, and our intention is to build on that functionality.

During development we are hosting our work at github
https://github.com/petefoth/gerrit-commit-sets, where anyone
interested can find pages describing requirements and UI along with
the source git repository.

If no-one objects we would like to use this group for discussions,
although we could set up a dedicated group if people prefer.

Regards

--
Pete Fotheringham
Codethink Ltd

[Nasser Grainawi]

Hey Pete,

We would love to have you help get these features into Gerrit!

Not only should you use this group for discussions, but you should also just use the tools/gerrit.git project on review.source.android.com for your development. Why would you need to fork over to github for it? I think that would likely be much more productive and result in a better final product for everyone to use (changes come in incrementally, group is involved in design, etc).

Nasser

> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

[Pete Fotheringham]

Hi Nasser

Thanks for your welcoming reply. We would be very happy to use the
tools/gerrit.git project to host our development. The reasons for
forking to githup were

a: to allow creation of personal branches for our developers to work on,
along with a feature branch to hold the main line of our code. As
newcomers to gerrit we didn't like to ask immediately for contributor
rights at on review.source.android.com. If you're happy to let us have
that access then we'll be very happy to use it.

b: I've used the Wiki pages at github to record the outcome of
discussions we've already had on requirements, UI etc. I'm not sure of
the best place to put that information in the tools/gerrit.git. I could
post to the list or put the wiki pages in the repo. Not sure of the best
way to go here. Yopur suggestions are welcome!

Thanks again

Pete

--
Pete Fotheringham
Codethink Ltd
http://codethink.co.uk

[Marcus D. Hanwell]

Hi,

On 23 May 2011 10:56, Pete Fotheringham

<pete.fot...@codethink.co.uk> wrote:
> Hi Nasser
>
> Thanks for your welcoming reply. We would be very happy to use the
> tools/gerrit.git project to host our development. The reasons for forking to
> githup were
>
> a: to allow creation of personal branches for our developers to work on,
> along with a feature branch to hold the main line of our code. As newcomers
> to gerrit we didn't like to ask immediately for contributor rights at on
> review.source.android.com. If you're happy to let us have that access then
> we'll be very happy to use it.

You don't need contributor rights, you just need to push commits for
review when they are ready to be merged. It seems reasonable to me to
also show earlier versions on Github for wider testing before
submitting them for review. It may be preferable to submit patches
early to get comment, but that is something Shawn might want to
comment on.

>
> b: I've used the Wiki pages at github to record the outcome of discussions
> we've already had on requirements, UI etc. I'm not sure of the best place to
> put that information in the tools/gerrit.git. I could post to the list or
> put the wiki pages in the repo. Not sure of the best way to go here. Yopur
> suggestions are welcome!
>

We have a lot of interest in this feature too, and I will actually
have some time (along with a coworker) to start getting these features
ready for testing on our users in a week or two. It would be great to
collaborate on this where it makes sense, I would certainly like to
see where you are at once I begin looking at this.

We already have a public facing Gerrit installation, but Gerrit will
not be adopted by some of our projects until topic branch support is
added.

Marcus

[Ryan Alberts]

Sounds like a nice additional enhancement that would benefit a wide
range of people.

On May 23, 3:29 pm, "Marcus D. Hanwell" <marcus.hanw...@kitware.com>
wrote:

> Hi,
>
> On 23 May 2011 10:56, Pete Fotheringham
>

[Pete Fotheringham]

Thanks for all the positive comments.

We now have a project on GitHub
https://github.com/petefoth/gerrit-topic-reviews, with a git repo, a
Wiki and an Issue List to use for planning and tracking the development.

The Wiki contains Requirements and UI pages, and comments are very welcome.

The UI_PoC branch
https://github.com/petefoth/gerrit-topic-reviews/tree/UI_PoC includes
PDFs of the UI mockups and a proof-of-concept implementation of the
proposed UI.

Our next steps are
- complete the high-level design
- split the work up into sensible work packages
- identify some milestones for submitting our changes to the main
project for review.

Regards

--
Pete Fotheringham
Codethink Ltd

http://codethink.co.uk

[Swindells, Thomas]

This looks good and very useful (Thanks Nokia for pushing this forwards!)

My only concern is with the following requirement:
"if the 'topic' keyword is not used, a new topic is created with a name generated by Gerrit. The commits in the push are added to a new changeSet which becomes the current changeSet for the new topic."

I don't think that this is necessarily desirable behavior. Depending on what I'm working on there are generally two scenarios:
1. I'm working on implementing a large new feature. To make reviewing and traceability easier I split it into multiple commits (step 1 refactor, step 2 implement new base classes etc). In this case an all or nothing approach makes sense.
2. I'm doing a blitz on defects, some of which require previous defects being fixed first hence there is an order to them. In this case the all or nothing approach doesn't make sense, it's perfectly valid for the earlier commits to be merged in without the later ones being merged in.

I think both scenarios are probably equally valid and it's probably up to the community to work out which is most desirable as the default. There are work arounds to support both scenarios
1. If you want a changeset always specify the topic you want it called - (autogenerated names and no descriptions are going to make it hard to work out which topic was the one you were reviewing anyway)
2. Push each commit individually manually working your way up the tree - this is potentially slow and error prone - if you make one mistake then you're stuck with two commits in the same topic that you don't want there and no way to break them out.

A third option is to have the ability on the UI to split a topic in two, probably also with a one click option to totally dissolve the topic into just individual changes.

Thomas

> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en

**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postm...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************

[Pete Fotheringham]

On 26/05/2011 10:03, Swindells, Thomas wrote:
> My only concern is with the following requirement: "if the 'topic'
> keyword is not used, a new topic is created with a name generated by
> Gerrit. The commits in the push are added to a new changeSet which
> becomes the current changeSet for the new topic."
>
> I don't think that this is necessarily desirable behavior.

<lots of good arguments snipped>

I think you are correct, and I think we should change the requirement to say

> "if the topic keyword is not used, then the commits are not grouped
> into a topic."

which is basically your first workaround - if you want the commits
grouped in a topic but forgot to use the 'topic' keyword, then you can
just push them again and include the 'topic' keyword.

Unless anyone screams loudly, I'll make the change in the Wiki.

> A third option is to have the ability on the UI to split a topic in
> two, probably also with a one click option to totally dissolve the
> topic into just individual changes.
>

I would eventually like to have better functionality in the browser UI
for managing topics - giving full Create, Update, Delete functionality -
but that is definitely not in scope for (at least) the first iteration.