Deckard and multi-project changes
Jean-Baptiste Queru
cross-project capabilities. See e.g. this thread:
https://groups.google.com/group/repo-discuss/browse_thread/thread/609ae520d0634847
The long-term goal is for tools like Deckard to piggy-back on that
same information, so that it only needs to be specified once.
That being said, in the medium-term (i.e. when Deckard runs again),
there might be opportunities to let Deckard know about those
situations. In the simplest form, a keyword would let Deckard know
that it shouldn't even look at those changes. This could go much
further (linear dependencies, cross-dependencies...). I'll let Conley
comment further since Deckard is really his creation.
Even if nothing is done in Deckard itself (or until Deckard runs),
leaving a note explaining how the changes work with one another makes
it much easier for people to know what's going on (i.e. Conley and
myself at a first level, then the actual reviewers).
JBQ
On Thu, Feb 23, 2012 at 10:54 PM, Gergely Kis <gerge...@mattakis.com> wrote:
> Hi JBQ,
>
> However, in the past we had the issue with Deckard that it did not
> handle inter-project dependencies (simply because Gerrit has no notion
> about these dependencies I guess.) What should be the process for such
> changes? Should we just mention this in the comments with links to the
> other changes? Should we use a specific format, which could be parsed
> by the new autoverifiier?
>
> Best Regards,
> Gergely
--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.
Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.
Conley Owens
with these changes is to simply reply to a failed verify and comment
that the change has cross-project dependencies. I read Deckard's mail
(or will when I get it running again), and will be able to handle
things manually for you. That's how we were solving the issues
before.
However, I was thinking that the easiest way of signalling Deckard
about cross-project dependencies would be to append extra lines to the
commit message:
Dependency: project-name commit-sha1
Dependency: project-name commit-sha1
People can comment if you foresee any issues with this method of
signalling deckard. Also, keep in mind that I won't be able to
implement the functionality to read these messages immediately.
Getting deckard running at all is, of course, more urgent.
~cco3
Jean-Baptiste Queru
full circle of commits pointing to one another. Best would be the
Change-Id.
Idea: now that Gerrit supports per-branch Change-Ids, we could simply
use the same Change-Id for changes that need to be submitted together.
It doesn't allow differentiating plain dependencies from atomic
changes, but it might be good enough, and has some advantages (e.g.
searching for the Change-Id in the web UI will return all the related
commits).
JBQ
Conley Owens
> You can't use the SHA-1 directly like that, because you can't create a
> full circle of commits pointing to one another. Best would be the
> Change-Id.
I don't understand why not. Couldn't I have deckard identify the loop
and stop? I also don't see why the Change-Id would fix
that...wouldn't the dependency still be circular?
>
> Idea: now that Gerrit supports per-branch Change-Ids, we could simply
> use the same Change-Id for changes that need to be submitted together.
> It doesn't allow differentiating plain dependencies from atomic
> changes, but it might be good enough, and has some advantages (e.g.
> searching for the Change-Id in the web UI will return all the related
> commits).
I had considered that, but I see a couple problems:
* if someone uploads a new patchset for changeA, dependent on changeB,
deckard will see that changeB exists and is ready to go.
Specifically, the patchset for changeA may be dependent on a new
patchset in changeB that doesn't exist yet (but will soon). Deckard
will pull in the wrong patchset and things won't go according to plan.
Specifying the commit prevents this.
* If two changes are dependent on eachother, the workflow for figuring
out what to write in the dependency line of each might be a little
goofy. Typically change-ids are assigned when you upload, so you
would upload both, then update both to add the dependencies now that
you have the change ids. Alternatively, you coud use draft patchsets
to prevent people from seeing the changes that don't have their
dependencies specified, or we could add some tool to prefetch the
changeids, but it's still added complexity.
Pierre
https://events.linuxfoundation.org/images/stories/pdf/lf_abs12_tardy.pdf
What we do is that we are always asking people to create a bugzilla
request for every change made in our project, and require them to put
the bugzilla ID in the commit comment.
Then the cross dependency is simple.
If the patches are for the same bugzilla ID, then they have to be
build together. There is even a feature in gerrit that allows to match
bug tracking ID, and query tracking ID. (we are actually not using it,
and build our BZ database upon gerrit patchset-created events)
I think this is an elegant solution to resolve both the tracking
problem and cross dependancy problem.
Regards,
Pierre
> >> The long-term goal is for tools like Deckard to piggy-back on that
> >> same information, so that it only needs to be specified once.
>
> >> That being said, in the medium-term (i.e. when Deckard runs again),
> >> there might be opportunities to let Deckard know about those
> >> situations. In the simplest form, a keyword would let Deckard know
> >> that it shouldn't even look at those changes. This could go much
> >> further (linear dependencies, cross-dependencies...). I'll let Conley
> >> comment further since Deckard is really his creation.
>
> >> Even if nothing is done in Deckard itself (or until Deckard runs),
> >> leaving a note explaining how the changes work with one another makes
> >> it much easier for people to know what's going on (i.e. Conley and
> >> myself at a first level, then the actual reviewers).
>
> >> JBQ
>
Conley Owens
> On Fri, Feb 24, 2012 at 9:32 AM, Jean-Baptiste Queru <j...@android.com> wrote:
>> You can't use the SHA-1 directly like that, because you can't create a
>> full circle of commits pointing to one another. Best would be the
>> Change-Id.
>
> I don't understand why not. Couldn't I have deckard identify the loop
> and stop? I also don't see why the Change-Id would fix
> that...wouldn't the dependency still be circular?
JBQ has corrected me on the error of my ways here :)
Magnus Bäck
Pierre <tar...@gmail.com> wrote:
> I presented in ABS part of our solution for that kind of stuff.
> https://events.linuxfoundation.org/images/stories/pdf/lf_abs12_tardy.pdf
>
> What we do is that we are always asking people to create a bugzilla
> request for every change made in our project, and require them to put
> the bugzilla ID in the commit comment.
> Then the cross dependency is simple.
> If the patches are for the same bugzilla ID, then they have to be
> build together. There is even a feature in gerrit that allows to match
> bug tracking ID, and query tracking ID. (we are actually not using it,
> and build our BZ database upon gerrit patchset-created events)
>
> I think this is an elegant solution to resolve both the tracking
> problem and cross dependancy problem.
This approach addresses the CI system problem and makes sure dependent
patches are tested together, but that's it.
It requires all connected patches to be uploaded at the same time (give
or take a few minutes). Otherwise, how is the CI system supposed to know
that all patches that solve a problem have been uploaded and that
they're ready to be tested together?
(That problem gets even more interesting if you allow branches of gits
to be listed in more than one manifest. Then the CI system needs to
figure out which manifests that need to be built and whether all patches
that pertain to a bug correction are available in all manifest contexts.)
The difficult problem that the two Gerrit development initiatives (one
of which mentioned by JBQ) for addressing cross-repository dependencies
try to solve is that you want to achieve atomic commits spanning across
two or more repositories, i.e. you want to make it impossible to submit
only a single change in a series of interdependent patches. This
requires some pretty involved changes in Gerrit.
--
Magnus B�ck
ba...@google.com