[opensuse-buildservice] osc submitreq tries to send a submission to the wrong project
Yo I'm trying to use osc branch and osc submitreq and am running into problems. osc branch appears to do the right thing: osc branch openSUSE:Factory <gnome package> tells me that <gnome package>'s development happens in GNOME:Factory, and I end up with home:maw:branches:GNOME:Factory/<gnome package>, just as expected. I change and commit <gnome package>. When I do a submitreq , and then try to do a submitreq, I see the following: Sorry, but a different project, GNOME:UNSTABLE, is defined as the place where development of the package gconf2 primarily takes place. Please submit there instead, or use --nodevelproject to force direct submission. Exactly what I did is in the attachment. Now, GNOME:UNSTABLE was where development took place, until a few days ago. I made what I believe were the adequate and correct changes in the internal pdb to change this, and the fact that osc branch works correctly implies that I did. So, what's the deal? Is there anything I missed? Thanks, Michael.
On Fri, Jul 11, 2008 at 03:59:22PM -0500, Michael Wolf wrote:
Yo
I'm trying to use osc branch and osc submitreq and am running into problems.
osc branch appears to do the right thing:
osc branch openSUSE:Factory <gnome package>
tells me that <gnome package>'s development happens in GNOME:Factory, and I end up with home:maw:branches:GNOME:Factory/<gnome package>, just as expected.
I change and commit <gnome package>. When I do a submitreq , and then try to do a submitreq, I see the following:
Sorry, but a different project, GNOME:UNSTABLE, is defined as the place where development of the package gconf2 primarily takes place. Please submit there instead, or use --nodevelproject to force direct submission.
Exactly what I did is in the attachment.
Now, GNOME:UNSTABLE was where development took place, until a few days ago. I made what I believe were the adequate and correct changes in the internal pdb to change this, and the fact that osc branch works correctly implies that I did.
So, what's the deal? Is there anything I missed?
First, a little explanation: osc help says: "For "create", there are two ways to use it. Either with a working copy or without. If called with no arguments, osc will guess what to submit where. If you don't have a working copy, you can give the respective arguments on the commandline (see below for an example)." With "will guess" it means that it will follow the link target if (and only if) the package is a source link. If the package is not a source link, the place where you wanna submit it can't be guessed, so the arguments need to be given on the command line. I hope this sheds some light. Then, I see the following: % osc meta pkg openSUSE:Factory gconf2 | grep devel <devel project="GNOME:Factory"/> % osc meta pkg GNOME:Factory gconf2 | grep devel <devel project="GNOME:UNSTABLE"/> osc looks up in openSUSE:Factory that gconf2's develproject is set to GNOME:Factory. But it doesn't look there if there is (even) another develproject. Gee... I am not sure if this is intended in this way :-) Either osc needs to follow until the end, or the devel project should be set where it belongs, and not chained. Peter -- Contact: admin@opensuse.org (a.k.a. ftpadmin@suse.com) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development
Am Samstag, 12. Juli 2008 01:01:55 schrieb Peter Poeml: Hi,
Then, I see the following:
% osc meta pkg openSUSE:Factory gconf2 | grep devel <devel project="GNOME:Factory"/> % osc meta pkg GNOME:Factory gconf2 | grep devel <devel project="GNOME:UNSTABLE"/>
osc looks up in openSUSE:Factory that gconf2's develproject is set to GNOME:Factory. But it doesn't look there if there is (even) another develproject. One or two or three other chained devel projects? Hmm. And finally the nightmare case devel project 5 again points to project 1 :-(
Gee... I am not sure if this is intended in this way :-) I do not see a reason atm why chaining should not be allowed from a technical POV as long as we successfully avoid circles. However, the question is if we get a benefit from really using it - a benefit that is bigger than the confusion that might arise from that. Not sure atm. What do others think?
Klaas -- Klaas Freitag Architect OPS/IPD SUSE LINUX Products GmbH - Nuernberg --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Sat, Jul 12, 2008 at 04:35:28PM +0200, Klaas Freitag wrote:
Am Samstag, 12. Juli 2008 01:01:55 schrieb Peter Poeml: Hi,
Then, I see the following:
% osc meta pkg openSUSE:Factory gconf2 | grep devel <devel project="GNOME:Factory"/> % osc meta pkg GNOME:Factory gconf2 | grep devel <devel project="GNOME:UNSTABLE"/>
osc looks up in openSUSE:Factory that gconf2's develproject is set to GNOME:Factory. But it doesn't look there if there is (even) another develproject. One or two or three other chained devel projects? Hmm. And finally the nightmare case devel project 5 again points to project 1 :-(
Gee... I am not sure if this is intended in this way :-) I do not see a reason atm why chaining should not be allowed from a technical POV as long as we successfully avoid circles. However, the question is if we get a benefit from really using it - a benefit that is bigger than the confusion that might arise from that. Not sure atm. What do others think?
Klaas
I have the following thoughts about it right now: This is clearly not how we designed this attribute. It were meant as THE primary place where development takes place. A place of which, by definition, there can only be one. Now, I see it can be desirable for users to have a defined path where changes are moved from A to B to C and then to Factory. For instance, it might be desirable that changes always first go to foo:KAPUTT first, then to foo:UNSTABLE, foo:STABLE, then to openSUSE:Factory. However, I consider it misuse of the devel project attribute to use it to define this path (Albeit a good idea ;). This is because it defeats the purpose of defining the place where changes shall go _first_. That's what it meant for, and it's actually (more) important to have an attribute for this, because its (original) purpose is to avoid submissions to some other place in the path. Peter -- Contact: admin@opensuse.org (a.k.a. ftpadmin@suse.com) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development
Am Montag, 14. Juli 2008 09:39:56 schrieb Peter Poeml:
On Sat, Jul 12, 2008 at 04:35:28PM +0200, Klaas Freitag wrote:
Am Samstag, 12. Juli 2008 01:01:55 schrieb Peter Poeml:
Hi,
I do not see a reason atm why chaining should not be allowed from a technical POV as long as we successfully avoid circles. However, the question is if we get a benefit from really using it - a benefit that is bigger than the confusion that might arise from that. Not sure atm. What do others think?
Klaas
I have the following thoughts about it right now:
This is clearly not how we designed this attribute. It were meant as THE primary place where development takes place. A place of which, by definition, there can only be one. Very valid thought.
Now, I see it can be desirable for users to have a defined path where changes are moved from A to B to C and then to Factory. For instance, it might be desirable that changes always first go to foo:KAPUTT first, then to foo:UNSTABLE, foo:STABLE, then to openSUSE:Factory. But all foo:* are usually owned by the same people - so the submit request is somehow useless here (it _is_ of course usefull because of documentation reasons). Having for example foo:KAPUTT, bar:FORTHEBRAVE and baz:UNSTABLE before we end up in openSUSE:Factory we have the case. However, I wonder if thats really a practical case ;)
However, I consider it misuse of the devel project attribute to use it to define this path (Albeit a good idea ;). This is because it defeats the purpose of defining the place where changes shall go _first_. That's what it meant for, and it's actually (more) important to have an attribute for this, because its (original) purpose is to avoid submissions to some other place in the path. Also valid, but what is your conclusion from that?
Klaas -- Klaas Freitag Architect OPS/IPD SUSE LINUX Products GmbH - Nuernberg --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Monday 14 July 2008 10:05:07 Klaas Freitag wrote:
Am Montag, 14. Juli 2008 09:39:56 schrieb Peter Poeml:
On Sat, Jul 12, 2008 at 04:35:28PM +0200, Klaas Freitag wrote:
Am Samstag, 12. Juli 2008 01:01:55 schrieb Peter Poeml:
Hi,
I do not see a reason atm why chaining should not be allowed from a technical POV as long as we successfully avoid circles. However, the question is if we get a benefit from really using it - a benefit that is bigger than the confusion that might arise from that. Not sure atm. What do others think?
Klaas
I have the following thoughts about it right now:
This is clearly not how we designed this attribute. It were meant as THE primary place where development takes place. A place of which, by definition, there can only be one.
Very valid thought.
Now, I see it can be desirable for users to have a defined path where changes are moved from A to B to C and then to Factory. For instance, it might be desirable that changes always first go to foo:KAPUTT first, then to foo:UNSTABLE, foo:STABLE, then to openSUSE:Factory.
That just means that the "devel project" definition should be stackable, so that the just follows on branch request, as long as a devel project is defined (with a max limit). So this could be setup by every project/package owner already if needed. I dunno if the api branch call is already implemented like this. 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, Jul 14, 2008 at 10:05:07AM +0200, Klaas Freitag wrote:
Am Montag, 14. Juli 2008 09:39:56 schrieb Peter Poeml:
On Sat, Jul 12, 2008 at 04:35:28PM +0200, Klaas Freitag wrote:
Am Samstag, 12. Juli 2008 01:01:55 schrieb Peter Poeml:
Hi,
I do not see a reason atm why chaining should not be allowed from a technical POV as long as we successfully avoid circles. However, the question is if we get a benefit from really using it - a benefit that is bigger than the confusion that might arise from that. Not sure atm. What do others think?
Klaas
I have the following thoughts about it right now:
This is clearly not how we designed this attribute. It were meant as THE primary place where development takes place. A place of which, by definition, there can only be one. Very valid thought.
Now, I see it can be desirable for users to have a defined path where changes are moved from A to B to C and then to Factory. For instance, it might be desirable that changes always first go to foo:KAPUTT first, then to foo:UNSTABLE, foo:STABLE, then to openSUSE:Factory. But all foo:* are usually owned by the same people - so the submit request is somehow useless here (it _is_ of course usefull because of documentation reasons). Having for example foo:KAPUTT, bar:FORTHEBRAVE and baz:UNSTABLE before we end up in openSUSE:Factory we have the case. However, I wonder if thats really a practical case ;)
However, I consider it misuse of the devel project attribute to use it to define this path (Albeit a good idea ;). This is because it defeats the purpose of defining the place where changes shall go _first_. That's what it meant for, and it's actually (more) important to have an attribute for this, because its (original) purpose is to avoid submissions to some other place in the path. Also valid, but what is your conclusion from that?
Oh, I left that part for you ;-) I think any chaining is project-internal policy and there is no flag needed for that. Well, I don't know if it's needed, but it can be handled without, since it is a matter of policy. But what _is_ needed is a flag to make sure the beginning of the chain is known - which we have. I assume it'd be technically possible to chain them, at the expense of a lot of lookups to be done each time they are used. I'm personally not if favour of complexity like this. If finding out where to submit a change to is so complicated, it defeats the purpuse. If at all, the api should also be able to resolve this right away, because it'd be quicker, and it's what a user wants to know. (Or what we thought they wanna know?) Peter -- Contact: admin@opensuse.org (a.k.a. ftpadmin@suse.com) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development
Peter Poeml <poeml@suse.de> writes:
This is clearly not how we designed this attribute. It were meant as THE primary place where development takes place. A place of which, by definition, there can only be one.
Now, I see it can be desirable for users to have a defined path where changes are moved from A to B to C and then to Factory. For instance, it might be desirable that changes always first go to foo:KAPUTT first, then to foo:UNSTABLE, foo:STABLE, then to openSUSE:Factory.
However, I consider it misuse of the devel project attribute to use it to define this path (Albeit a good idea ;). This is because it defeats the purpose of defining the place where changes shall go _first_. That's what it meant for, and it's actually (more) important to have an attribute for this, because its (original) purpose is to avoid submissions to some other place in the path.
So all submissions by default should go right to the root project instead of bubbling up from leaves to branches to the trunk? Maybe the 'Good default' depends on the timing in the development cycle: Submissions always go to the maintainer first, right? During alpha, the maintainer then passes the fix on right into factory. During early betas, they go into the subsystem instead, (so it gets review from the subsystem owner who then submits to factory) and maybe sometimes it even makes sense to have three stages for large subsystems with components, when it late betas approach. I have tried to understand from http://en.opensuse.org/Build_Service/Concepts/Submit_Request how the overall development process shall look like and I wonder where else I should look? S. -- Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business OPS Engineering Maxfeldstraße 5 Processes and Infrastructure Nürnberg SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Mon, Jul 14, 2008 at 12:57:55PM +0200, Susanne Oberhauser wrote:
I have tried to understand from http://en.opensuse.org/Build_Service/Concepts/Submit_Request how the overall development process shall look like and I wonder where else I should look?
http://en.opensuse.org/Build_Service/Collaboration would be the resource to look at I guess, it describes the entire workflow as we picture it. Peter -- Contact: admin@opensuse.org (a.k.a. ftpadmin@suse.com) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development
On Sat, 2008-07-12 at 01:01 +0200, Peter Poeml wrote:
On Fri, Jul 11, 2008 at 03:59:22PM -0500, Michael Wolf wrote:
Yo
I'm trying to use osc branch and osc submitreq and am running into problems.
osc branch appears to do the right thing:
osc branch openSUSE:Factory <gnome package>
tells me that <gnome package>'s development happens in GNOME:Factory, and I end up with home:maw:branches:GNOME:Factory/<gnome package>, just as expected.
I change and commit <gnome package>. When I do a submitreq , and then try to do a submitreq, I see the following:
Sorry, but a different project, GNOME:UNSTABLE, is defined as the place where development of the package gconf2 primarily takes place. Please submit there instead, or use --nodevelproject to force direct submission.
Exactly what I did is in the attachment.
Now, GNOME:UNSTABLE was where development took place, until a few days ago. I made what I believe were the adequate and correct changes in the internal pdb to change this, and the fact that osc branch works correctly implies that I did.
So, what's the deal? Is there anything I missed?
First, a little explanation:
osc help says: "For "create", there are two ways to use it. Either with a working copy or without. If called with no arguments, osc will guess what to submit where. If you don't have a working copy, you can give the respective arguments on the commandline (see below for an example)."
With "will guess" it means that it will follow the link target if (and only if) the package is a source link.
If the package is not a source link, the place where you wanna submit it can't be guessed, so the arguments need to be given on the command line.
I hope this sheds some light.
Then, I see the following:
% osc meta pkg openSUSE:Factory gconf2 | grep devel <devel project="GNOME:Factory"/> % osc meta pkg GNOME:Factory gconf2 | grep devel <devel project="GNOME:UNSTABLE"/>
OK, I assume this was an artifact of doing "osc copypac" when the devel project was still GNOME:UNSTABLE. Anyway, what's TRT here? Remove the devel project attribute from GNOME:Factory/gconf2, or to change it to GNOME:Factory? Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Mon, Jul 14, 2008 at 01:41:49PM -0500, Michael Wolf wrote:
On Sat, 2008-07-12 at 01:01 +0200, Peter Poeml wrote:
On Fri, Jul 11, 2008 at 03:59:22PM -0500, Michael Wolf wrote:
Yo
I'm trying to use osc branch and osc submitreq and am running into problems.
osc branch appears to do the right thing:
osc branch openSUSE:Factory <gnome package>
tells me that <gnome package>'s development happens in GNOME:Factory, and I end up with home:maw:branches:GNOME:Factory/<gnome package>, just as expected.
I change and commit <gnome package>. When I do a submitreq , and then try to do a submitreq, I see the following:
Sorry, but a different project, GNOME:UNSTABLE, is defined as the place where development of the package gconf2 primarily takes place. Please submit there instead, or use --nodevelproject to force direct submission.
Exactly what I did is in the attachment.
Now, GNOME:UNSTABLE was where development took place, until a few days ago. I made what I believe were the adequate and correct changes in the internal pdb to change this, and the fact that osc branch works correctly implies that I did.
So, what's the deal? Is there anything I missed?
First, a little explanation:
osc help says: "For "create", there are two ways to use it. Either with a working copy or without. If called with no arguments, osc will guess what to submit where. If you don't have a working copy, you can give the respective arguments on the commandline (see below for an example)."
With "will guess" it means that it will follow the link target if (and only if) the package is a source link.
If the package is not a source link, the place where you wanna submit it can't be guessed, so the arguments need to be given on the command line.
I hope this sheds some light.
Then, I see the following:
% osc meta pkg openSUSE:Factory gconf2 | grep devel <devel project="GNOME:Factory"/> % osc meta pkg GNOME:Factory gconf2 | grep devel <devel project="GNOME:UNSTABLE"/>
OK, I assume this was an artifact of doing "osc copypac" when the devel project was still GNOME:UNSTABLE.
Ah, even better -- then I suppose we can just clean this up and simplify.
Anyway, what's TRT here? Remove the devel project attribute from GNOME:Factory/gconf2, or to change it to GNOME:Factory?
The devel project attribute of both openSUSE:Factory/gconf2 and GNOME:Factory/gconf2 should point to GNOME:UNSTABLE I'd say. Peter -- Contact: admin@opensuse.org (a.k.a. ftpadmin@suse.com) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development
On Tue, 2008-07-15 at 12:38 +0200, Peter Poeml wrote:
Then, I see the following:
% osc meta pkg openSUSE:Factory gconf2 | grep devel <devel project="GNOME:Factory"/> % osc meta pkg GNOME:Factory gconf2 | grep devel <devel project="GNOME:UNSTABLE"/>
OK, I assume this was an artifact of doing "osc copypac" when the devel project was still GNOME:UNSTABLE.
Ah, even better -- then I suppose we can just clean this up and simplify.
how can we clean this up? Can I do it via osc?
The devel project attribute of both openSUSE:Factory/gconf2 and GNOME:Factory/gconf2 should point to GNOME:UNSTABLE I'd say.
we have decided to use GNOME:Factory as the devel project for all GNOME packages, so why should it point to G:U? -- Rodrigo Moya <rodrigo@novell.com> --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, 2008-07-17 at 13:59 +0200, Rodrigo Moya wrote:
On Tue, 2008-07-15 at 12:38 +0200, Peter Poeml wrote:
Then, I see the following:
% osc meta pkg openSUSE:Factory gconf2 | grep devel <devel project="GNOME:Factory"/> % osc meta pkg GNOME:Factory gconf2 | grep devel <devel project="GNOME:UNSTABLE"/>
OK, I assume this was an artifact of doing "osc copypac" when the devel project was still GNOME:UNSTABLE.
Ah, even better -- then I suppose we can just clean this up and simplify.
how can we clean this up? Can I do it via osc?
I cleaned it up yesterday. And yes, via osc :) Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (6)
-
Adrian Schröter -
Klaas Freitag -
Michael Wolf -
Peter Poeml -
Rodrigo Moya -
Susanne Oberhauser