public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] u-boot gerrit server
Date: Tue, 12 Nov 2013 19:28:17 +0100	[thread overview]
Message-ID: <20131112192817.79c6a07b@lilith> (raw)
In-Reply-To: <CAP9ODKr2fHZ+vHOAi-XKSqqH95P7qQy=utThKdyh84ageX=giQ@mail.gmail.com>

Hi Otavio,

On Tue, 12 Nov 2013 16:07:41 -0200, Otavio Salvador
<otavio@ossystems.com.br> wrote:

> On Tue, Nov 12, 2013 at 3:30 PM, Albert ARIBAUD
> <albert.u.boot@aribaud.net> wrote:
> > Hi Otavio,
> >
> > On Tue, 12 Nov 2013 15:16:15 -0200, Otavio Salvador
> > <otavio@ossystems.com.br> wrote:
> >
> >> Hello Albert,
> >>
> >> On Tue, Nov 12, 2013 at 3:13 PM, Albert ARIBAUD
> >> <albert.u.boot@aribaud.net> wrote:
> >> > On Tue, 12 Nov 2013 15:00:06 -0200, Otavio Salvador
> >> > <otavio@ossystems.com.br> wrote:
> >> >
> >> >> On Tue, Nov 12, 2013 at 2:55 PM, Vadim Bendebury (??)
> >> >> <vbendeb@google.com> wrote:
> >> >> > On Tue, Nov 12, 2013 at 8:47 AM, Otavio Salvador
> >> >> > <otavio@ossystems.com.br> wrote:
> >> >> >> Besides, how people will 'transfer' one patch from one tree to
> >> >> >> another? This will happen quite often as someone mistakenly sending a
> >> >> >> patch for the wrong tree or custodians wanting the set to go together
> >> >> >> in a single merge...
> >> >> >>
> >> >> >
> >> >> > How is it handled today? Gerrit is after all just a means of keeping
> >> >> > track of patches in a more efficient way, the rest could be similar to
> >> >> > what is in use now, or enhanced using gerrit's features.
> >> >>
> >> >> Currently it is just reassigned in Patchwork; using multiple trees
> >> >> will complicate this.
> >> >
> >> > How about one branch per custodian? At my previous job we had a couple
> >> > branches, one per distinct "product".
> >>
> >> I am not aware of a way to 'transfer' a patch from one branch to another.
> >
> > There would not be such transfers -- we don't do this right now with
> > our trees. We do merge requests, which means pulling two custodian repos
> > into the same working repo, doing a merge between what are now two
> > custodian branches, and pushing the result back onto one of the
> > custodian trees.
> >
> > So here, if there is one branch per custodian, what we would need
> > is the ability to merge one custodian branch into another.
> 
> Right but currently you are not 'denied' to review a patch someone
> didn't put for you. The custodians as done 'on-the-fly' as each
> custodian takes his duties and process the patches and apply them,
> later updating patchwork.

IIRC, gerrit roles are orthogonal to branches, or can be made so at
least, so custodians would not be barred from reviewing patches on
other branches. The problem would be information: how does a custodian
learn that a change set ( gerritspeak coming back :) ) on another
branch requires his/her attention?

> On the 'new Gerrit' workflow, if it is assigned for a branch/tree and
> this is mistakenly done, how it will be done?

If you're asking how we would make sure the patches go to the right
branch... I have no idea.

Amicalement,
-- 
Albert.

  parent reply	other threads:[~2013-11-12 18:28 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-12  5:21 [U-Boot] u-boot gerrit server Vadim Bendebury (вб)
2013-11-12  5:36 ` Simon Glass
2013-11-12 10:42 ` Albert ARIBAUD
2013-11-12 16:33   ` Vadim Bendebury (вб)
2013-11-12 17:11     ` Albert ARIBAUD
2013-11-12 18:05       ` Vadim Bendebury (вб)
2013-11-12 11:07 ` Otavio Salvador
2013-11-12 16:36   ` Vadim Bendebury (вб)
2013-11-12 16:47     ` Otavio Salvador
2013-11-12 16:55       ` Vadim Bendebury (вб)
2013-11-12 17:00         ` Otavio Salvador
2013-11-12 17:07           ` Vadim Bendebury (вб)
2013-11-12 17:14             ` Otavio Salvador
2013-11-14 19:27               ` Tom Rini
2013-11-14 20:06                 ` Otavio Salvador
2013-11-14 20:17                   ` Tom Rini
2013-11-14 20:30                     ` Otavio Salvador
2013-11-14 20:58                       ` Tom Rini
2013-11-14 21:00                         ` Otavio Salvador
2013-11-14 21:20                           ` Tom Rini
2013-11-14 21:13                     ` Vadim Bendebury (вб)
2013-11-14 21:18                       ` Otavio Salvador
2013-11-14 21:23                       ` Tom Rini
2013-11-12 17:13           ` Albert ARIBAUD
2013-11-12 17:16             ` Otavio Salvador
2013-11-12 17:30               ` Albert ARIBAUD
2013-11-12 18:07                 ` Otavio Salvador
2013-11-12 18:24                   ` Vadim Bendebury
2013-11-13 22:39                     ` Scott Wood
2013-11-12 18:28                   ` Albert ARIBAUD [this message]
2013-11-12 19:29             ` Wolfgang Denk
2013-11-12 19:26 ` Wolfgang Denk
2013-11-12 19:46   ` Vadim Bendebury (вб)
2013-11-14 19:54     ` Tom Rini
2013-11-14 20:59       ` Vadim Bendebury (вб)
2013-11-14 21:17         ` Tom Rini
2013-11-14 21:22           ` Otavio Salvador
2013-11-15 19:41             ` Tom Rini
2013-11-14 23:43           ` Vadim Bendebury (вб)
2013-11-15 13:55             ` James Chargin
2013-11-15 14:12               ` Oliver Schinagl
2013-11-15 14:29                 ` Luca Ellero
2013-11-15 20:08             ` Tom Rini
2013-11-15 21:00               ` Michal Suchanek
2013-11-15 21:34                 ` Tom Rini
2013-11-15 23:21                   ` Wolfgang Denk
2013-11-15 23:24                     ` Otavio Salvador
2013-11-17 16:51                       ` Wolfgang Denk
2013-11-17 19:41                         ` Tom Rini
2013-11-18  0:07                           ` Graeme Russ
2013-11-18 16:00                             ` Tom Rini
2013-11-19  4:29                               ` Heiko Schocher
2013-11-19  7:12                                 ` Wolfgang Denk
2013-11-19 18:08                                   ` Heiko Schocher
2013-11-19 15:10                                 ` Tom Rini
2013-11-19 18:12                                   ` Heiko Schocher
2013-11-15 23:20                 ` Wolfgang Denk
2013-11-16 23:45                   ` Michal Suchanek
2013-11-15 19:18         ` Wolfgang Denk
2013-11-15 19:40           ` Tom Rini
2013-11-15 23:16             ` Wolfgang Denk
2013-11-16  1:39               ` Tom Rini
2013-11-17 19:31                 ` Wolfgang Denk
2013-11-18  9:35                   ` Michal Suchanek
2013-11-18 16:13                     ` Wolfgang Denk
2013-11-18 16:28                       ` Tom Rini
2013-11-19 17:21                   ` Vadim Bendebury (вб)
2013-11-20  7:42                     ` Graeme Russ
2013-11-20 20:11                       ` Vadim Bendebury (вб)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131112192817.79c6a07b@lilith \
    --to=albert.u.boot@aribaud.net \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox