[opensuse-cloud] openstack-* package submissions to Factory
I just reviewed and declined a lot of openstack packages since the changes files contained removal of entries and I did not see that those were added anywhere else. What's going on here? The changes are sometimes quite extensive and therefore it's difficult to figure out whether there are some changes lost or not. Let me add the review team so that they are aware of this packages, 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
Hi AJ,
I just reviewed and declined a lot of openstack packages since the changes files contained removal of entries and I did not see that those were added anywhere else.
I'm not sure what you mean by "a lot", I can only see two: https://build.opensuse.org/request/show/172710 https://build.opensuse.org/request/show/172708 For the first, the reason is that we've switched the packages to the Grizzly tree, which means they're from a much newer code branch. That inevitably means that there will be a bit of .changes mismatch. Now looking at your comments in details, the first one is a decline about this changes entry change: -- Changes from version 1.0.5: Note that no actual change has been lost (.spec file is identical and so are all sources), merely the .changes file entry has been cleaned up in the newer code branch. Do you think it is a good idea to decline requests due to that? The second one was declined due to this: - + Use pypi for python-swiftclient dependency. + Use pypi for python-swiftclient dependency. Again, the patch is clearly in the new code branch submission (see line 298 of the .changes file), merely the formatting of the changes file has been confsued. With such a deficient system like the build service, a proper .changes file is not always possible to maintain. Please proceed with the review (unfortunatly I can't seem to be able to reopen the requests in the webui). Thanks, Dirk
What's going on here? The changes are sometimes quite extensive and therefore it's difficult to figure out whether there are some changes lost or not.
Let me add the review team so that they are aware of this packages,
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
-- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
On 04/22/2013 08:39 PM, Dirk Müller wrote:
Hi AJ,
I just reviewed and declined a lot of openstack packages since the changes files contained removal of entries and I did not see that those were added anywhere else.
I'm not sure what you mean by "a lot", I can only see two:
https://build.opensuse.org/request/show/172710 https://build.opensuse.org/request/show/172708
there were some more.
For the first, the reason is that we've switched the packages to the Grizzly tree, which means they're from a much newer code branch. That inevitably means that there will be a bit of .changes mismatch.
Now looking at your comments in details, the first one is a decline about this changes entry change:
-- Changes from version 1.0.5:
Note that no actual change has been lost (.spec file is identical and so are all sources), merely the .changes file entry has been cleaned up in the newer code branch. Do you think it is a good idea to decline requests due to that?
A general review rule is that changes files get added to but not removed. Pretty printing is fine. Let's look again at 172710. My comment was: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Why are you removing content from the changes file? -------------- --- python-django_openstack_auth.changes +++ python-django_openstack_auth.changes @@ -4,4 +4,3 @@ -- Update to version 1.0.6: - + Fix compatibility with keystoneclient v0.2. -- Changes from version 1.0.5: - + Improves error handling; fixes failing test. +- update to 1.0.6: + * Fix compatibility with keystoneclient v0.2. + * Improves error handling; fixes failing test Pretty-printing is fine but removing the 1.0.5 entry loooks wrong. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ So, I complain about these two lines *missing*: - Changes from version 1.0.5: + Improves error handling; fixes failing test.
The second one was declined due to this:
- + Use pypi for python-swiftclient dependency. + Use pypi for python-swiftclient dependency.
Nope, it was not - but let's not discuss The diff is: -Wed Jan 30 07:11:43 UTC 2013 - cloud-devel@suse.de +Tue Apr 2 08:17:21 UTC 2013 - speilicke@suse.com -- Update to version 1.7.4.1+git.1359529903.0ce3e1d: - + Use pypi for python-swiftclient dependency.
Again, the patch is clearly in the new code branch submission (see line 298 of the .changes file), merely the formatting of the changes file has been confsued.
Let's not discuss these single changes, let's discuss the overall way.
With such a deficient system like the build service, a proper .changes file is not always possible to maintain. Please proceed with the review (unfortunatly I can't seem to be able to reopen the requests in the webui).
You can create new request. So, let's come back to the real question: How to handle these submissions? The general rule is that no information should be lost and it could be that some of the Folsom packages contained other changes that were not done to the Grizzly ones. Looking at https://build.opensuse.org/request/show/172713, the Folsom branch contains an extra patch that is not in the Grizzly one. Is this really intended? There are very few projects that develop on two branches at the same time and then switch branches - and seem to remove submissions. What are other reviewers thinking? One proposal would be to resubmit the packages with a comment "These are Grizzly packages from new branch, contains all changes from Folsom but were developed in parallel" - together with a review from the submitter that really everything is in? 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
2013/4/22 Andreas Jaeger <aj@suse.com>:
Why are you removing content from the changes file? Pretty-printing is fine but removing the 1.0.5 entry loooks wrong.
I'm not removing content. The update was done in two steps in one branch (first 1.0.5 and then 1.0.6), and in one step in another branch. Hence the changelog slightly differs.
So, I complain about these two lines *missing*: - Changes from version 1.0.5: + Improves error handling; fixes failing test.
I'm sorry, this 2nd line is clearly there, the first one is missing indeed,b ut there is a reason (see above).
The general rule is that no information should be lost
Where is that rule coming from? The general rule that I remember is that there should be *regressions* and that no *fixes* should be lost, which roughly means "no regressions to bnc#/FATE#, as long as they're applicable"
and it could be that some of the Folsom packages contained other changes that were not done to the Grizzly ones.
I agree, that can happen, but that means we'd need to take a look at the actual diff (e.g. the one outside the .changes file) and not the .changes file. or do you trust that if an entry is in the .changes file that it is actually also in the .spec file?
Looking at https://build.opensuse.org/request/show/172713, the Folsom branch contains an extra patch that is not in the Grizzly one. Is this really intended?
Please check the .changes file diff, it explains it: -Wed Mar 6 14:01:15 UTC 2013 - vuntz@suse.com -- Add compat-newer-requests.patch: take patches from upstream to - allow working with newer versions of python-requests. vs +------------------------------------------------------------------- +Mon Feb 18 09:49:46 UTC 2013 - dmueller@suse.com + +- remove keystoneclient-requests-compat.patch: + * Merged upstream Yes, there is a time difference, but thats because we were working on different branches, and one branch was getting the fix quicker than the other one (it was not clear that the other one actually needs it until our continuous integration system told us about it). Greetings, Dirk -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
On 04/22/2013 02:29 PM, Andreas Jaeger wrote:
I just reviewed and declined a lot of openstack packages since the changes files contained removal of entries and I did not see that those were added anywhere else.
What's going on here? The changes are sometimes quite extensive and therefore it's difficult to figure out whether there are some changes lost or not.
Let me add the review team so that they are aware of this packages,
So it's that time of the year again. But it is still the same thing as was when we pushed Essex to Factory. These packages come from different (git, but doesn't matter) branches which by nature don't necessarily share a common history. They do share a common ancestor though: ----+----- master branch | \----- stable branch with bugfixes It's the same thing with every project following that model by the way, so _yes_ deleted lines in changes files are expected. So what exactly is new here? In fact, I'm going to reopen all requests. -- 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
On Tuesday, April 23, 2013 09:06:38 Sascha Peilicke wrote:
On 04/22/2013 02:29 PM, Andreas Jaeger wrote:
I just reviewed and declined a lot of openstack packages since the changes files contained removal of entries and I did not see that those were added anywhere else.
What's going on here? The changes are sometimes quite extensive and therefore it's difficult to figure out whether there are some changes lost or not.
Let me add the review team so that they are aware of this packages,
So it's that time of the year again. But it is still the same thing as was when we pushed Essex to Factory. These packages come from different (git, but doesn't matter) branches which by nature don't necessarily share a common history. They do share a common ancestor though:
----+----- master branch
\----- stable branch with bugfixes
It's the same thing with every project following that model by the way, so _yes_ deleted lines in changes files are expected. So what exactly is new here?
Communication! It's not obvious that no changes are lost and that this was really intented. This submissions came in via an auto submission script, so I took the save guard. Next time I'll just let them sit and ask... For next time, I would appreciate a word of warning and explanation before you do this.
In fact, I'm going to reopen all requests.
Fine with me ;) I have now the info that I needed... 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 Tue, Apr 23, 2013 at 09:39:37AM +0200, Andreas Jaeger wrote:
On Tuesday, April 23, 2013 09:06:38 Sascha Peilicke wrote:
On 04/22/2013 02:29 PM, Andreas Jaeger wrote:
I just reviewed and declined a lot of openstack packages since the changes files contained removal of entries and I did not see that those were added anywhere else.
What's going on here? The changes are sometimes quite extensive and therefore it's difficult to figure out whether there are some changes lost or not.
Let me add the review team so that they are aware of this packages,
So it's that time of the year again. But it is still the same thing as was when we pushed Essex to Factory. These packages come from different (git, but doesn't matter) branches which by nature don't necessarily share a common history. They do share a common ancestor though:
----+----- master branch
\----- stable branch with bugfixes
It's the same thing with every project following that model by the way, so _yes_ deleted lines in changes files are expected. So what exactly is new here?
Communication! It's not obvious that no changes are lost and that this was really intented.
This submissions came in via an auto submission script, so I took the save guard. Next time I'll just let them sit and ask...
For next time, I would appreciate a word of warning and explanation before you do this.
In fact, I'm going to reopen all requests.
Fine with me ;) I have now the info that I needed...
You are violating your own set rules... And it is sad that you think that they do not apply to you. This sets bad precedence. The same discussion process should be done this way. http://en.opensuse.org/openSUSE:Creating_a_changes_file_%28RPM%29 Ciao, Marcus -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
On 04/23/2013 09:48 AM, Marcus Meissner wrote:
On Tue, Apr 23, 2013 at 09:39:37AM +0200, Andreas Jaeger wrote:
On Tuesday, April 23, 2013 09:06:38 Sascha Peilicke wrote:
On 04/22/2013 02:29 PM, Andreas Jaeger wrote:
I just reviewed and declined a lot of openstack packages since the changes files contained removal of entries and I did not see that those were added anywhere else.
What's going on here? The changes are sometimes quite extensive and therefore it's difficult to figure out whether there are some changes lost or not.
Let me add the review team so that they are aware of this packages,
So it's that time of the year again. But it is still the same thing as was when we pushed Essex to Factory. These packages come from different (git, but doesn't matter) branches which by nature don't necessarily share a common history. They do share a common ancestor though:
----+----- master branch
\----- stable branch with bugfixes
It's the same thing with every project following that model by the way, so _yes_ deleted lines in changes files are expected. So what exactly is new here?
Communication! It's not obvious that no changes are lost and that this was really intented.
This submissions came in via an auto submission script, so I took the save guard. Next time I'll just let them sit and ask...
For next time, I would appreciate a word of warning and explanation before you do this.
In fact, I'm going to reopen all requests.
Fine with me ;) I have now the info that I needed...
You are violating your own set rules... And it is sad that you think that they do not apply to you.
This sets bad precedence.
Can you elaborate more on what the potential issue is? Both changes files (old branch / new branch) have changed entries for about every commit. So the only thing missing is the "Hey, we're changing branches here" notification in the submit request message. So you would prefer revoking the old submit requests and add new ones (potentially superseding) with that message?
The same discussion process should be done this way. http://en.opensuse.org/openSUSE:Creating_a_changes_file_%28RPM%29
Once we have settled this discussion, I'm sure we can distill an new paragraph for that wiki page. Currently, this case doesn't seem covered. -- 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
On Tue, Apr 23, 2013 at 09:53:46AM +0200, Sascha Peilicke wrote:
On 04/23/2013 09:48 AM, Marcus Meissner wrote:
On Tue, Apr 23, 2013 at 09:39:37AM +0200, Andreas Jaeger wrote:
On Tuesday, April 23, 2013 09:06:38 Sascha Peilicke wrote:
On 04/22/2013 02:29 PM, Andreas Jaeger wrote:
I just reviewed and declined a lot of openstack packages since the changes files contained removal of entries and I did not see that those were added anywhere else.
What's going on here? The changes are sometimes quite extensive and therefore it's difficult to figure out whether there are some changes lost or not.
Let me add the review team so that they are aware of this packages,
So it's that time of the year again. But it is still the same thing as was when we pushed Essex to Factory. These packages come from different (git, but doesn't matter) branches which by nature don't necessarily share a common history. They do share a common ancestor though:
----+----- master branch
\----- stable branch with bugfixes
It's the same thing with every project following that model by the way, so _yes_ deleted lines in changes files are expected. So what exactly is new here?
Communication! It's not obvious that no changes are lost and that this was really intented.
This submissions came in via an auto submission script, so I took the save guard. Next time I'll just let them sit and ask...
For next time, I would appreciate a word of warning and explanation before you do this.
In fact, I'm going to reopen all requests.
Fine with me ;) I have now the info that I needed...
You are violating your own set rules... And it is sad that you think that they do not apply to you.
This sets bad precedence.
Can you elaborate more on what the potential issue is? Both changes files (old branch / new branch) have changed entries for about every commit. So the only thing missing is the "Hey, we're changing branches here" notification in the submit request message. So you would prefer revoking the old submit requests and add new ones (potentially superseding) with that message?
This is not about potential problems, this is about agreement to keep the .changes file linear. Your submissions are violating this agreement, regardless of what is happening in the background.
The same discussion process should be done this way. http://en.opensuse.org/openSUSE:Creating_a_changes_file_%28RPM%29
Once we have settled this discussion, I'm sure we can distill an new paragraph for that wiki page. Currently, this case doesn't seem covered.
Yes, this is more about the visible process, which does not fully match the non-linear OSS development processes. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
2013/4/23 Marcus Meissner <meissner@suse.de>:
This is not about potential problems, this is about agreement to keep the .changes file linear.
Hi Marcus, As soon as there is more than one code branch, it is not possible to keep the changes file linear. the _only_ way to do that would be to add all changes from all branches to the .changes file of all branches (which is tiresome), which means that I would get review declines from AJ then that says "your .changes say: add patch folsom-backport-XYZ.diff, but the patch is not in the package!" Could you please explain me how you want to keep the rule of a changes file being only linear and having two code branches at the same time? Greetings, Dirk -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
On Tue, Apr 23, 2013 at 10:47:40AM +0200, Dirk Müller wrote:
2013/4/23 Marcus Meissner <meissner@suse.de>:
This is not about potential problems, this is about agreement to keep the .changes file linear.
Hi Marcus,
As soon as there is more than one code branch, it is not possible to keep the changes file linear. the _only_ way to do that would be to add all changes from all branches to the .changes file of all branches (which is tiresome), which means that I would get review declines from AJ then that says "your .changes say: add patch folsom-backport-XYZ.diff, but the patch is not in the package!"
Could you please explain me how you want to keep the rule of a changes file being only linear and having two code branches at the same time?
I answered this already, but again: Whats actually a part the review team should decide and offer for discussion, as so far the official stated policy apparently conflicts with the status quo. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
On 04/23/2013 10:27 AM, Marcus Meissner wrote:
On Tue, Apr 23, 2013 at 09:53:46AM +0200, Sascha Peilicke wrote:
On 04/23/2013 09:48 AM, Marcus Meissner wrote:
On Tue, Apr 23, 2013 at 09:39:37AM +0200, Andreas Jaeger wrote:
On Tuesday, April 23, 2013 09:06:38 Sascha Peilicke wrote:
On 04/22/2013 02:29 PM, Andreas Jaeger wrote:
I just reviewed and declined a lot of openstack packages since the changes files contained removal of entries and I did not see that those were added anywhere else.
What's going on here? The changes are sometimes quite extensive and therefore it's difficult to figure out whether there are some changes lost or not.
Let me add the review team so that they are aware of this packages,
So it's that time of the year again. But it is still the same thing as was when we pushed Essex to Factory. These packages come from different (git, but doesn't matter) branches which by nature don't necessarily share a common history. They do share a common ancestor though:
----+----- master branch
\----- stable branch with bugfixes
It's the same thing with every project following that model by the way, so _yes_ deleted lines in changes files are expected. So what exactly is new here?
Communication! It's not obvious that no changes are lost and that this was really intented.
This submissions came in via an auto submission script, so I took the save guard. Next time I'll just let them sit and ask...
For next time, I would appreciate a word of warning and explanation before you do this.
In fact, I'm going to reopen all requests.
Fine with me ;) I have now the info that I needed...
You are violating your own set rules... And it is sad that you think that they do not apply to you.
This sets bad precedence.
Can you elaborate more on what the potential issue is? Both changes files (old branch / new branch) have changed entries for about every commit. So the only thing missing is the "Hey, we're changing branches here" notification in the submit request message. So you would prefer revoking the old submit requests and add new ones (potentially superseding) with that message?
This is not about potential problems, this is about agreement to keep the .changes file linear.
Your submissions are violating this agreement, regardless of what is happening in the background.
I am not exactly sure if that agreement is set in stone. Of course it makes a lot of sense in general and usually we use it to blame merge conflicts and sloppy packagers. Changing branches on the other hand is a perfectly fine thing to do. And you also know that some fixes ending up in stable branches never appear in the master (or any other) branch. Thus it is inherently unavoidable to have missing lines in changes files if you take that seriously. Of course we can add all the stuff we did in $STABLE_BRANCh to the changes file of $MASTER_BRANCH, but what do we gain by doing that? It's confusing and explodes the spec file for literally no gain. So I still think we have to add a proper remark to submit requests in the future. But that's it. I don't see any policy violations here.
The same discussion process should be done this way. http://en.opensuse.org/openSUSE:Creating_a_changes_file_%28RPM%29
Once we have settled this discussion, I'm sure we can distill an new paragraph for that wiki page. Currently, this case doesn't seem covered.
Yes, this is more about the visible process, which does not fully match the non-linear OSS development processes.
Ciao, Marcus
-- 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
On Tue, 23 Apr 2013 09:48:17 +0200, Marcus Meissner <meissner@suse.de> wrote :
On Tuesday, April 23, 2013 09:06:38 Sascha Peilicke wrote: So it's that time of the year again. But it is still the same thing as was when we pushed Essex to Factory. These packages come from different (git, but doesn't matter) branches which by nature don't necessarily share a common history. They do share a common ancestor though:
----+----- master branch
\----- stable branch with bugfixes
It's the same thing with every project following that model by the way, so _yes_ deleted lines in changes files are expected. So what exactly is new here? [...] You are violating your own set rules... And it is sad that you think that they do not apply to you.
This sets bad precedence.
The same discussion process should be done this way. http://en.opensuse.org/openSUSE:Creating_a_changes_file_%28RPM%29
Just as a warning: you might change this policy for openSUSE without problems. But at least for SLE we have exactly this as a strict policy covered for our EAL certification: No changes of released/accepted *.changes files! So your package might end up in openSUSE, but you should think about a solution for SLE in your case. Otherwise your packages will be rejected there if there is an older package with a different changes file - and there is no way other than changing our EAL certification to change this. I'm fine if you start doing this - but please be aware that it might need much money and some time to do so. Other projects btw. have either different packages (think about the <packname><version>-<version-<release> schema) or add the changes of their new branch on top of the old changes file. This works for SLE since years... With kind regards, Lars -- Lars Vogdt <Lars.Vogdt@suse.com> - OPS Engineering Services Team Lead - SUSE Linux Products GmbH - GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Maxfeldstraße 5, 90409 Nuernberg, Germany - HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
On 04/25/2013 08:54 PM, Lars Vogdt wrote:
On Tue, 23 Apr 2013 09:48:17 +0200, Marcus Meissner <meissner@suse.de> wrote :
On Tuesday, April 23, 2013 09:06:38 Sascha Peilicke wrote: So it's that time of the year again. But it is still the same thing as was when we pushed Essex to Factory. These packages come from different (git, but doesn't matter) branches which by nature don't necessarily share a common history. They do share a common ancestor though:
----+----- master branch
\----- stable branch with bugfixes
It's the same thing with every project following that model by the way, so _yes_ deleted lines in changes files are expected. So what exactly is new here? [...] You are violating your own set rules... And it is sad that you think that they do not apply to you.
This sets bad precedence.
The same discussion process should be done this way. http://en.opensuse.org/openSUSE:Creating_a_changes_file_%28RPM%29
Just as a warning: you might change this policy for openSUSE without problems. But at least for SLE we have exactly this as a strict policy covered for our EAL certification:
No changes of released/accepted *.changes files!
Which is a clear indication the the EAL certification is absolute nonsense and pure bureaucracy. Which is totally fine with me as long as we are able to sell more.
So your package might end up in openSUSE, but you should think about a solution for SLE in your case. Otherwise your packages will be rejected there if there is an older package with a different changes file - and there is no way other than changing our EAL certification to change this. I'm fine if you start doing this - but please be aware that it might need much money and some time to do so.
Thankfully, it's unlikely that the OpenStack packages will become part of core SLE any time soon. We're a separate product and I don't see PM willing to change this. As long as the packages aren't rejected in openSUSE for SLE reasons anymore, we're totally ignorant to that :-) On the other hand, this happens all the time. Packages moving from pacman or vice versa don't always share history. And during the last two years of my Factory reviews I haven't come across a single Yast update (spanning across multiple packages), that didn't had changes files modified.
Other projects btw. have either different packages (think about the <packname><version>-<version-<release> schema) or add the changes of their new branch on top of the old changes file. This works for SLE since years...
Thinks that work for SLE since years aren't necessarily the right things. So we could argue about the usefullness of this practice forever, but I'm not gonna do this. I prefer to concentrate on more important matters. -- 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
Hi On Fri, 26 Apr 2013 09:12:55 +0200 Sascha Peilicke wrote:
Thinks that work for SLE since years aren't necessarily the right things. So we could argue about the usefullness of this practice forever, but I'm not gonna do this. I prefer to concentrate on more important matters.
Yes, same for me: I also prefer to concentrate on things I feel to be important. What matters for me is trust and consistency. Now I see that I for myself can not give any of them to the current Cloud product. Thanks for this insight. Lars -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
2013/4/23 Andreas Jaeger <aj@suse.com>:
This submissions came in via an auto submission script, so I took the save guard. Next time I'll just let them sit and ask...
For next time, I would appreciate a word of warning and explanation before you do this.
Hi, who is running this "obs-autosubmit" script anyway? it doesn't seem to add privileges for the package maintainer (!) to be revoke, decline, or reopen any of those submitrequests. Is this autosubmit script able to send emails to the review team? Thanks Dirk -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
On Tuesday, April 23, 2013 11:58:53 Dirk Müller wrote:
2013/4/23 Andreas Jaeger <aj@suse.com>:
This submissions came in via an auto submission script, so I took the save guard. Next time I'll just let them sit and ask...
For next time, I would appreciate a word of warning and explanation before you do this.
Hi,
who is running this "obs-autosubmit" script anyway? it doesn't seem to add privileges for the package maintainer (!) to be revoke, decline, or reopen any of those submitrequests.
That's some "coolo"-magic ;)
Is this autosubmit script able to send emails to the review team?
Why should it? It just shows up in the queue... 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
2013/4/23 Andreas Jaeger <aj@suse.com>: Hi,
That's some "coolo"-magic ;)
Is this autosubmit script able to send emails to the review team? Why should it? It just shows up in the queue...
Well, you were asking to get an email once big things happen, and if obs-autosubmit does big things, then you better want to know about it ;-) Greetings, Dirk -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org
participants (5)
-
Andreas Jaeger -
Dirk Müller -
Lars Vogdt -
Marcus Meissner -
Sascha Peilicke