[opensuse-cloud] Re: OBS Cloud:OpenStack:Master/openstack-neutron r28 commited
Hi Christian,
-------------------------------------------------------------------- +Fri Jul 19 07:15:49 UTC 2013 - berendt@b1-systems.de + +- adding openstack-neutron.rpmlintrc +
Sorry, I had to revert this commit for two reasons: a) there is already a rpmlintrc, you shouldn't add a 2nd one b) you're hiding a packaging bug. I've fixed the packaging bug instead. I would really appreciate if you could send submitrequests for things where you're not 100% sure of. Thanks a lot in advance, Greetings, Dirk -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
On 07/19/2013 12:35 PM, Dirk Müller wrote:
I've fixed the packaging bug instead. I would really appreciate if you could send submitrequests for things where you're not 100% sure of.
It's a development project. I need a working C:O:M in the moment I'm submitting a change and I don't want to wait for a review. Is it really a problem to revert or fix commits if you're not satisfied with them? Simply drop me a line what to do and I'll change it. Christian. -- Christian Berendt Cloud Computing Solution Architect Mail: berendt@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
Christian Berendt (berendt@b1-systems.de) wrote:
On 07/19/2013 12:35 PM, Dirk Müller wrote:
I've fixed the packaging bug instead. I would really appreciate if you could send submitrequests for things where you're not 100% sure of.
It's a development project. I need a working C:O:M in the moment I'm submitting a change and I don't want to wait for a review.
That's what home:$USER branch projects are for.
Is it really a problem to revert or fix commits if you're not satisfied with them?
Yes, because it creates unnecessary extra work and pollutes the change history. submitrequests were designed specifically to avoid this, so it would be great if you could use them. Thanks! -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
On 07/19/2013 01:10 PM, Christian Berendt wrote:
On 07/19/2013 12:35 PM, Dirk Müller wrote:
I've fixed the packaging bug instead. I would really appreciate if you could send submitrequests for things where you're not 100% sure of.
It's a development project. I need a working C:O:M in the moment I'm submitting a change and I don't want to wait for a review. Is it really a problem to revert or fix commits if you're not satisfied with them? Simply drop me a line what to do and I'll change it.
Christian, what is your workflow? Are you branching packages or checking out? Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
On 07/19/2013 01:35 PM, Andreas Jaeger wrote:
Christian, what is your workflow? Are you branching packages or checking out?
I'm checking them out and committing changes afterwards. I never saw a submit request on C:O:M. So I think that's the normal workflow on C:O:M? Christian. -- Christian Berendt Cloud Computing Solution Architect Mail: berendt@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
On 07/19/2013 01:39 PM, Christian Berendt wrote:
On 07/19/2013 01:35 PM, Andreas Jaeger wrote:
Christian, what is your workflow? Are you branching packages or checking out?
I'm checking them out and committing changes afterwards. I never saw a submit request on C:O:M. So I think that's the normal workflow on C:O:M?
You said before: I need changes directly in C:O:M. Using a home project, you can change all packages together at a time, test them - and then submit the result. So, no need to commit something that is needed for something else. Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
On 07/19/2013 01:45 PM, Andreas Jaeger wrote:
You said before: I need changes directly in C:O:M. Using a home project, you can change all packages together at a time, test them - and then submit the result. So, no need to commit something that is needed for something else.
To reduce further problems I'll now work with submit requests in the future. Christian. -- Christian Berendt Cloud Computing Solution Architect Mail: berendt@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
Am 19.07.2013 13:58, schrieb Christian Berendt:
On 07/19/2013 01:45 PM, Andreas Jaeger wrote:
You said before: I need changes directly in C:O:M. Using a home project, you can change all packages together at a time, test them - and then submit the result. So, no need to commit something that is needed for something else.
To reduce further problems I'll now work with submit requests in the future.
To be fair, Christian is right about our current ways. We usually directly commit into Master. As long as the change isn't disruptive (or unavoidable), it won't create issues and let's us moving fast. However, in case there's any doubt, I'd suggest we _all_ use submit requests in the future. Having a second pair of eyes looked at a fix won't ever hurt I guess. It's also clear that we can (still) improve the communication. I guess Christian deserves a lot of credit not only for sparking discussions (:-) but also for pointing out many issues. Let's keep it that way. -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
Le lundi 22 juillet 2013, à 08:59 +0200, Sascha Peilicke a écrit :
Am 19.07.2013 13:58, schrieb Christian Berendt:
On 07/19/2013 01:45 PM, Andreas Jaeger wrote:
You said before: I need changes directly in C:O:M. Using a home project, you can change all packages together at a time, test them - and then submit the result. So, no need to commit something that is needed for something else.
To reduce further problems I'll now work with submit requests in the future.
To be fair, Christian is right about our current ways. We usually directly commit into Master. As long as the change isn't disruptive (or unavoidable), it won't create issues and let's us moving fast. However, in case there's any doubt, I'd suggest we _all_ use submit requests in the future. Having a second pair of eyes looked at a fix won't ever hurt I guess.
+1. Same for C:O:*:Staging: if we're unsure, we should simply use submit requests. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
Hi Christian,
submitting a change and I don't want to wait for a review.
This way you're spending my time on figuring out why C:O:M is broken in Jenkins and then need to figure out what you tried to do and fix it properly. This costs me a lot more time than looking at a review and commenting on it. We even work in the same timezone ;-)
Is it really a problem to revert or fix commits if you're not satisfied with them?
I consider reverting changes difficult when it is not really obvious what you were trying to fix, besides that it is an obviously rude behavior that I would like to avoid. I trust you that there is a bug you're facing, and I would appreciate if you'd help me / us understanding how to fix it, especially when the commit is wrong. You're pushing the problem on to me who is _also_ trying to have working packages and test suites that pass, and I consider that not well balanced. Thanks, Dirk -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
On 07/19/2013 01:39 PM, Dirk Müller wrote:
This way you're spending my time on figuring out why C:O:M is broken in Jenkins and then need to figure out what you tried to do and fix it properly. This costs me a lot more time than looking at a review and commenting on it. We even work in the same timezone ;-)
Just ask me. Normally I'm in #opensuse-cloud.
I consider reverting changes difficult when it is not really obvious what you were trying to fix, besides that it is an obviously rude behavior that I would like to avoid.
Ack.
I trust you that there is a bug you're facing, and I would appreciate if you'd help me / us understanding how to fix it, especially when the commit is wrong. You're pushing the problem on to me who is _also_ trying to have working packages and test suites that pass, and I consider that not well balanced.
The package is called openstack-neutron and it provides openstack-quantum? I think that's just wrong so I changed every openstack-quantum to openstack-neutron and also added obsoletes for openstack-quantum to get rid of existing installed openstack-quantum packages. I thought that's the expected behaviour of the openstack-neutron packages. Or do I have a wrong understanding of the Provides keyword? Example: Why does the package openstack-neutron-dhcp-agent provides the package openstack-quantum-dhcp-agent? Christian. -- Christian Berendt Cloud Computing Solution Architect Mail: berendt@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
Hi Christian,
The package is called openstack-neutron and it provides openstack-quantum?
Yes, but in a fixed version. That is for both compatibility as well as in order to trigger the package rename on update. (a package is only updated if there is a provide (!) with a newer (!) EVR).
I think that's just wrong so I changed every openstack-quantum to openstack-neutron
Which is wrong on two levels. First for the reason above (breaking update) and second because %name = %version is an autoprovide, it must not be added manually.
and also added obsoletes for openstack-quantum to get rid of existing installed openstack-quantum packages.
Which is also in this particular case wrong. (obsolete without a provide).
expected behaviour of the openstack-neutron packages. Or do I have a wrong understanding of the Provides keyword?
Yes, apparently. http://en.opensuse.org/openSUSE:Package_dependencies#Renaming_a_package
Example: Why does the package openstack-neutron-dhcp-agent provides the package openstack-quantum-dhcp-agent?
a) for compatibility b) for fixing upgrade. c) in order to create the rename pattern together with the Obsolete line below. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
Am 19.07.2013 13:39, schrieb Dirk Müller:
Hi Christian,
submitting a change and I don't want to wait for a review.
This way you're spending my time on figuring out why C:O:M is broken in Jenkins and then need to figure out what you tried to do and fix it properly. This costs me a lot more time than looking at a review and commenting on it. We even work in the same timezone ;-)
Let's not be so harsh. Both you and me also broke Master in the past. I think we're spending far too much time on fixing Jenkins (which translated to fixing openSUSE / SLES issues upstream isn't aware of) rather than developing features. In the past, it was decided to very closely track upstream, which creates much more breakage than Christian (me / you) could ever create.
Is it really a problem to revert or fix commits if you're not satisfied with them?
I consider reverting changes difficult when it is not really obvious what you were trying to fix, besides that it is an obviously rude behavior that I would like to avoid.
I trust you that there is a bug you're facing, and I would appreciate if you'd help me / us understanding how to fix it, especially when the commit is wrong. You're pushing the problem on to me who is _also_ trying to have working packages and test suites that pass, and I consider that not well balanced.
I could argue that you also submit stuff sometimes which isn't obvious or even optimal. I guess if you (me/everybody) would spend more time on providing proper changes entries or a comment / NOTE in the spec file, we all would have to spend less time reasoning about commits of others. However, this wasn't received very well the last time I brought it up, so let's at least try to better notify each other (as Dirk suggests). -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
participants (6)
-
Adam Spiers -
Andreas Jaeger -
Christian Berendt -
Dirk Müller -
Sascha Peilicke -
Vincent Untz