On Thu, Jul 19, 2018 at 07:11:44PM +0200, Matthieu Huin wrote:
> There shouldn't be that many patches at any given time that syncing
> the document manually would be a hassle. If that time comes, we can
> look into automation. The advantage of the Etherpad over Gerrit for
> this, IMO, is that you can expand on the rationale behind a patch or a
> given topic of patches, and thus explain why we see them as needed.
> Gerrit might not be the place for such a detailed explanation.
> 
I agree, but why not just the zuul-discuss ML over etherpad? I found the list
that TristanC did in this tread to be really helpful.

> On Thu, Jul 19, 2018 at 6:59 PM, Paul Belanger <[email protected]> wrote:
> > On Thu, Jul 19, 2018 at 06:06:32PM +0200, Fabien Boucher wrote:
> >> What about maintaining an etherpad with the list of patches we carry in our
> >> packaging ?
> >>
> > If the data is already in gerrit, moving it to etherpad just duplicates it 
> > IMO.
> > Personally, I like using topics in gerrit to help organize patches, it 
> > worked
> > very well for zuulv3 release, maybe we can start doing that with SF specific
> > review.
> >
> > We also could consider creating a new dashboard in gerrit using
> > gerrit-dash-creator[1] to make it easy via web UI too.
> >
> > [1] http://git.openstack.org/cgit/openstack/gerrit-dash-creator
> >
> >> For instance, each patch line should include:
> >>
> >>    - the upstream review
> >>    - the current in-progress status (-1/0/+1/+2)
> >>    - an explanation about why this patch is needed for us in SF.
> >>    - maybe more ...
> >>
> >> Idea is to use that etherpad as a relay document between upstream and us.
> >> Maybe it can help, as a support,  to promote our patches to be merged
> >> faster.
> >>
> > I like the idea, if we can solve the duplicate data issue from above, I 
> > think
> > that is great. Giving upstream something too look at is the right approach, 
> > I do
> > think a single topic in gerrit might be a great first step.
> >
> > - Paul
> >
> > _______________________________________________
> > Softwarefactory-dev mailing list
> > [email protected]
> > https://www.redhat.com/mailman/listinfo/softwarefactory-dev

_______________________________________________
Softwarefactory-dev mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/softwarefactory-dev

Reply via email to