[opensuse-buildservice] concept for osc handling merge requests
Hi, I'm thinking about how to implement that planned functionality. Would it make sense to use it like this? usage: osc mergereq create SOURCEPRJ SOURCEPAC DESTPRJ [DESTPAC] osc mergereq list PRJ [PKG] osc mergereq user USER osc mergereq show ID osc mergereq refuse ID osc mergereq accept ID Where "show" would call the appropriate rdiff function, I guess. Thanks, Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
Hi, I am currently playing with the following draft for osc handling "submit requests" (note that they were renamed from "merge requests"). Feedback appreciated! poeml@batavia510 ~ % osc-stable help submitreq submitreq: Handle requests to submit a package into another project For "create", the DESTPAC name is optional; the source packages' name will be used if DESTPAC is omitted. "list" lists open requests attached to a project or package. "show" will show the request itself, and generate a diff for review. refuse, accept: Not implemented. Requires more intelligence. usage: osc submitreq create [-m TEXT] SOURCEPRJ SOURCEPAC DESTPRJ [DESTPAC] osc submitreq list PRJ [PKG] osc submitreq show ID osc submitreq refuse ID osc submitreq accept ID options: -h, --help show this help message and exit -m TEXT, --message=TEXT specify message TEXT poeml@batavia510 ~ % osc-stable submitreq list openSUSE:Factory 20 new home:poeml/apachestats -> openSUSE:Factory/apachestats 'a new great package' 21 new home:poeml/apachestats -> openSUSE:Factory/apachestats 'a new great package' 22 new home:poeml/apachestats -> openSUSE:Factory/apachestats 'a new great package' 23 new home:poeml/apachestats -> openSUSE:Factory/apachestats 'a new great package' 24 new home:poeml/apachestats -> openSUSE:Factory/apachestats 'a new great package' 25 new home:poeml/apachestats -> openSUSE:Factory/apachestats 'a new great package' 26 new home:poeml/apachestats -> openSUSE:Factory/apachestats 'a new great package' 27 new home:poeml/apachestats -> openSUSE:Factory/apachestats 'a new great package' 28 new home:poeml/apachestats -> openSUSE:Factory/apachestats 'a new great package' 29 new home:poeml/initviocons -> openSUSE:Factory/initviocons 'I think I have local change here which need to be submitted.' 30 new home:poeml/initviocons -> openSUSE:Factory/initviocons 'now a SUBMIT request' poeml@batavia510 ~ % osc-stable submitreq show 30 Request to submit (id 30): home:poeml/initviocons -> openSUSE:Factory/initviocons Message: 'now a SUBMIT request' State: new (2008-03-05T22:48:17, poeml) changes files: -------------- --- initviocons.changes --- initviocons.changes @@ -20 +20 @@ - which sends a characteristic primary da + which sends a characteristic primary DA new: ---- ready spec files: ----------- --- initviocons.spec --- initviocons.spec @@ -1,5 +1,5 @@ # -# spec file for package initviocons (Version 0.4) +# spec file for package initviocons (Version 0.5) # # Copyright (c) 2007 SUSE LINUX Products GmbH, Nuernberg, Germany. # This file and all modifications and additions to the pristine @@ -11,13 +11,13 @@ # norootforbuild Name: initviocons -URL: http://svn.poeml.de/viewcvs/initviocons/ +Url: http://svn.poeml.de/viewcvs/initviocons/ Version: 0.5 -Release: 1 +Release: 25 Summary: Terminal Initialization, e.g. for the iSeries Virtual Console License: GPL v2 or later Group: System/Console -Autoreqprov: on +AutoReqProv: on BuildRoot: %{_tmppath}/%{name}-%{version}-build Source: initviocons-%{version}.tar.bz2 @@ -59,6 +59,21 @@ /usr/bin/* %changelog +* Mon Dec 10 2007 - poeml@suse.de +- update to r27: + - when using -e, only output the TERM value and don't add + LINES,COLUMNS by default anymore. Discussion in [#184179] (ssh + installation exit abnormally when change terminal window size) + has shown that they are not needed anyway, and they seem to + cause problems in some cases (when used together with ssh). In + order to be able to revert to the previous behaviour, the -s + switch was added. It adds LINES and COLUMNS to the eval output + again. +* Wed Nov 14 2007 - poeml@suse.de +- update to r25: + - recognize WebSM console + https://bugzilla.novell.com/show_bug.cgi?id=256139 + which sends a characteristic primary DA * Thu Jul 19 2007 - poeml@suse.de - update to 0.5 (svn r24) - support for mlterm and Terminal.app other changes: -------------- ++++++ ready (new) --- ready +++ ready poeml@batavia510 ~ % The next step would be, I think, to issue the "accept" or "refuse" command. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
On Tue, 2008-03-04 at 12:37 +0100, Dr. Peter Poeml wrote:
Hi,
I'm thinking about how to implement that planned functionality.
Would it make sense to use it like this?
usage: osc mergereq create SOURCEPRJ SOURCEPAC DESTPRJ [DESTPAC] osc mergereq list PRJ [PKG] osc mergereq user USER osc mergereq show ID osc mergereq refuse ID osc mergereq accept ID
What is ID in this case? How are multiple mergereq's for the same
package handled? (Maybe we should try to apply all the rdiffs?).
-JP
--
JP Rosevear
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:
Hi,
I'm thinking about how to implement that planned functionality.
Would it make sense to use it like this?
usage: osc mergereq create SOURCEPRJ SOURCEPAC DESTPRJ [DESTPAC] osc mergereq list PRJ [PKG] osc mergereq user USER osc mergereq show ID osc mergereq refuse ID osc mergereq accept ID
What is ID in this case?
ID is a unique identifier which the backend choses when a new request is created. The identifiers that I have seen look like simple numbers.
How are multiple mergereq's for the same package handled? (Maybe we should try to apply all the rdiffs?).
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. Having said that, it might be a good thing if the request stores the source and target revision id, which identifies the exact source revision of the time when the request was created. Could come in handy later. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
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 rdiffs?).
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.
Having said that, it might be a good thing if the request stores the source and target revision id, which identifies the exact source revision of the time when the request was created. Could come in handy later.
true -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
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 rdiffs?).
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. Thus, applicability is in the eye of the beholder. It needs a thourough look at the rdiff. (Which is actually the same with the internal submit process we are using; it works the same.) Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
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 rdiffs?).
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. bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
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 rdiffs?).
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? Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
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 rdiffs?).
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. bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
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 rdiffs?).
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? 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. - have the requests indicate whether the source packages are _linked_ packages, to help with the decision to accept or decline? (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.) Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development
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 > > rdiffs?). > > 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 submission. 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. bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (3)
-
Adrian Schröter -
Dr. Peter Poeml -
JP Rosevear