Mailinglist Archive: opensuse-buildservice (339 mails)

< Previous Next >
Re: [opensuse-buildservice] concept for osc handling merge requests
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Mon, 10 Mar 2008 18:15:47 +0100
  • Message-id: <200803101815.48855.adrian@xxxxxxx>
On Monday 10 March 2008 16:38:55 wrote Dr. Peter Poeml:
On Mon, Mar 10, 2008 at 04:00:10PM +0100, Adrian Schröter wrote:
On Monday 10 March 2008 14:37:23 wrote Dr. Peter Poeml:
On Mon, Mar 10, 2008 at 02:27:32PM +0100, Adrian Schröter wrote:
On Monday 10 March 2008 13:39:25 wrote Dr. Peter Poeml:
On Mon, Mar 10, 2008 at 01:32:03PM +0100, Adrian Schröter wrote:
On Monday 10 March 2008 13:28:46 wrote Dr. Peter Poeml:
On Thu, Mar 06, 2008 at 01:25:23PM -0500, JP Rosevear wrote:
On Tue, 2008-03-04 at 12:37 +0100, Dr. Peter Poeml wrote:


How are multiple mergereq's for the same
package handled? (Maybe we should try to apply all the

There is no plan for that. As far as I see, a second request
could be a) a new one from a previous submitter, or
b) from someone else, and another source package.

In a), the first request is probably obsoleted by the second
one (if it comes from the same source). Thus, it would be good
from my perspective of a packager to attach a "obsoletes XY"
note. Or I could probably go ahead and delete the request that
I created earlier.

In b), the request recipient will probably choose one of the
two requests, or try to apply them subsequently.

In any case, the first submit could conflict with the other one.
So it is IMHO always better to accept them one after one to see,
if it does still apply.

As far as I understand the current draft of how the "apply" step is
going to be implemented, it _always_ applies. Because it is going
to be a simple copy, overwriting what's there, and not a diff which
is applied.

That is not the point, the point is that you may not WANT to merge
the second one, because it may not apply anymore. It is better that
the upstream project does fix it again instead of merge it also and
have broken sources in the target project.

I'm afraid, I can't understand this. Could you explain what you wrote
in a little more detail? What do you mean with "upstream project" and
"fix it again"?

If you followed the thread, you may note that I referred to the
proposition "try to apply all the rdiffs" -- which does not reflect the
planned implementation. What I tried to point out is that there is no
concept of a diff which can either apply, or not apply because it
doesn't 'fit' anymore. Do you have a different view?

For example, there is a project "Factory" with a package "kernel" and
there are multiple submit requests to this project and package from
Project A, B and C.

When the owner of "Factory" decides to accept the merge request from "B",
this change in may break the changes in "A" and "C".

In this case it is better to accept "B" and check back if "A" and "C" can
still apply their changes and maybe you want also want to wait, if they
will still build.

You seem to talk about cases here where there are source packages
_linked_ to the target package. Right?

Well, yes, in other scenarios it does not make any sense at all to approve
multiple merge requests to one package, because it would obsolete the other

Yes, it may make sense to approve multiple request to different package at
once. But the usual workflow is to review one request, check the changes and
results, approve or decline, before looking at the next one. At least this is
the way how it currently happens.

I didn't have only this scenario in mind.

For those I think I can follow your suggestion. Even though "it still
builds" is a very weak criterium for breakage, do you think it would be
possible to
- track the build status? Sounds cumbersome.

track ?, well it should become possible to check the build status of the
source project/package before merging, yes.

If we store also the source release of merged sources, we can check later,
using the build log, which build state they had.

- have the requests indicate whether the source packages are _linked_
packages, to help with the decision to accept or decline?

Well, I think there is no need to have this information in the request, it can
be checked when reviewing the source changes ?

(Thinking this further, this calls for a way to see wether a package has
been built at all. So far, we typicall see "succeeded", but we don't
know whether that's the status from the build before the latest commit,
or from thereafter. So there is no way to see if the package been built
successfully, except by checking the timestamped build history.)

Hm, if the scheduler is fast enough, it would change to scheduled/blocked
after one source merge to the project happened.
I know that this is currenly not always the case, but I would consider this a
different problem.



Adrian Schroeter
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
email: adrian@xxxxxxx

To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >