2013/4/22 Andreas Jaeger :

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 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 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

2013/4/23 Marcus Meissner :

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 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 04/25/2013 08:54 PM, Lars Vogdt wrote:

On Tue, 23 Apr 2013 09:48:17 +0200, Marcus Meissner 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>-

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

2013/4/23 Andreas Jaeger :

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

2013/4/23 Andreas Jaeger : 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