Mailinglist Archive: opensuse-packaging (100 mails)

[Andreas Gruenbacher <agruen@xxxxxxx>]

So now, hopefully armed with a deeper understanding of what the build service 
is trying to do and what it actually does, let me reply to the other things 
you said:

On Friday, 17 April 2009 13:12:56 Adrian Schröter wrote:
> I do not think it is a good idea to checkout out something different than
> to build against on the server.

Let me ask you a few questions:

 * Do you think it is a good idea that a checkout gives a result different
   from what you have checked in, with no easy or obvious way for you to see
   what has actually happened behind you back?

 * How sure can you be that what a checkout gives you matches what was built?
   (How about changes in the target project that happened after the build?)

 * Can you easily reproduce what was built when necessary?

 * How reasonable can a system be that can end up in a state where you cannot
   even check out what you have checked in anymore?

> And your "really, really" indicates that you still not accept that our main
> goal is to show up changes and conflicts as soon as possible. But this is
> the approach of the OBS. We trigger builds automatically when something
> below changes, so we need also show conflicting source changes immediatly
> to all parties.

I don't know what you think it is that I'm proposing, but certainly not that.  
I'm not trying to take away source links from you.  I'm not trying to stop 
the propagation of changes at build time.

Source links as implemented today are broken.  It is also clear to me by now 
that what there is a lack of understanding of what source links are acually 
supposed to do.  Please let's think this all through together and fix it.  
It's not far from where we are today to something that actually works 
reliably, and makes sense too.

> [...] we desperately need the server side merge for automatic package
> building from my point of view. And no, I am not aware how to do this with
> some other SVC systems (except you build code which is doing this on top).

All version control systems support branching and merging, albeit under 
different names.  Version control in the build service is based on the very 
same operations.  Even source links, except that they are not implemented 
right.  Fixing the implementation is not rocket science either, we only need 
to get the concepts right first.

Here is what I would like the build service client and server to do:

 * Checking out the current revision of a package, or any previous revision,
   should produce exactly that revision as it was checked in.  If the package
   links to another package, the client should check if the current revision
   of the package checked out is based on the most recent version of the
   target package.  If not, an obvious enough message should be printed to
   tell the user to perform a merge.

 * When the user decides to do a merge, a proper three-way merge should be
   done.  The result is committed to the build service, resulting in a new
   revision of the link package.

 * When the build service builds a link package, it *also* does a proper
   three-way merge.  (If there are merge conflicts, it gives up, of course.)
   This merge result is only used for that specific build, and thrown away
   at the end.  (I trust that the build log contains the revisions of all
   packages involved.)  This is almost the same as expanding a source link
   as done now, except that a three-way merge is more robust against mis-
   merges.  Using the identical operation on the server as on the client
   ensures that users can easily reproduce the exact state of the sources
   of a package.

   Until we get there, we can keep expanding source links as we do now.  The
   difference will be that it will be more difficult to reproduce the exact
   sources that a build was using.  This is no different from the current
   state, though.

 * There will be cases when a user wants to merge with a more recent version
   of the target package, but not with the most recent version.  Users will
   need that when trying to reproduce the sources that a package was built
   with, for example.  This is not difficult to implement, but it needs to
   be supported.

All of this requires to store which revision of the target package a link was 
generated against, and then a little bit of coding.  (Not much actually, this 
looks more complex than it actually is.)

> Otherwise we will not scale for getting stuff merged into Factory from
> multiple sides (so far the small autobuild group had to fix other peoples
> way too often. This will not work with even larger world wide groups. So we
> need to report this back automatically to let the submitter fix their stuff
> first).

What kind of reporting do you have in mind?  When a change in a target package 
causes a merge conflict in a link package, this will result in a build 
failure, and hopefully the user will notice quickly enough.  When the user 
checks out a package or updates his working copy, the client will warn if the 
target package has changed and ask the user to perform a merge.  Nothing can 
be done about package maintainers who ignores build failures, and do not sync 
with the build service either.

Thanks,
Andreas
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx