On Wed, Jun 30, 2021 at 2:41 PM Martin Fick <
mf...@codeaurora.org> wrote:
>
> On Wednesday, June 30, 2021 3:10:34 PM MDT Martin Fick wrote:
> > On Wednesday, June 30, 2021 10:23:06 PM MDT 'Christian Aistleitner' via Repo
> > and Gerrit Discussion wrote:
> > > On Wed, Jun 30, 2021 at 12:54:28PM -0700, Kaushik Lingarkar wrote:
> > > > This plugin is
> > > > designed for groups using the 'Depends-on:' change comment to manage
> > > > inter-project change dependencies.
> > >
> > > At first, I thought that this description matches exactly what the
> > > `zuul` plugin [1] is trying to do.
> > >
> > > But then I realized that you wrote that your plugin is looking for the
> > > `Depends-on` in the *change comment*, while the `zuul` plugin is looking
> > > for `Depends-On` in the *commit message*.
>
> I would chalk the difference you mention above (commit message vs. comment
> message) up to a policy decision that is best left to a specific project, or CI
> system to decide whether it wants to support either of these formats, I
> envision other ways to indicate them even: #hashtags, topics (as Gerrit does
> today)...,. Despite different ways to annotate dependencies, a common way to
> expose them and work with them would be great.
>
> I would say the same about circular dependencies, it appears that the Zuul
> plugin has a policy to not support them, however that could easily be made
> into something that a specific CI system, or a specific config would enable or
> disable.
For a long time Zuul the CI tool did not support circular
dependencies, but that changed semi recently. I don't think there
would be any problem with having the Zuul plugin (or a common plugin)
support them now as a result.
>
> Just to clarify my point of view. While the plugin may not have the same
> policies that we are currently looking for, it doesn't mean that I think these
> policy differences merit a separate plugin. I would support by a common, more
> featureful plugin.
I think this is reasonable as long as the overlap in behavior for
Depends-On is compatible (and I think having compatible behaviors as
much as possible is desireable). As you mention this isn't Zuul
specific and being able to express dependencies when you have no CI
system or a Zuul seems like a reasonable thing. Then Zuul users can
simply use the common behavior supporting plugin.
>
> > > But since it's at least related ... do you think there is a way to
> > > merge the `zuul` plugin code into your plugin or the other way round?
> >
> > I think that the current Zuul plugin seems similar to what we are trying to
> > do, i.e. its concepts and approach appear generic, and not Zuul specific. I
> > do think it would make sense to potentially "join" code and implementations
> > between the two plugins. I don't know that it makes sense to put generic
> > dependency code into a plugin named Zuul though. How would you suggest we
> > proceed?
>
> -Martin
>
> --
> The Qualcomm Innovation Center, Inc. is a member of Code
> Aurora Forum, hosted by The Linux Foundation
>
> --
> --
> To unsubscribe, email
repo-discuss...@googlegroups.com
> More info at
http://groups.google.com/group/repo-discuss?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
repo-discuss...@googlegroups.com.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/repo-discuss/2832207.97xSXj01f4%40mfick-lnx.