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.
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
