[yast-devel] Branching, Leap, SP2...
As discussed in the call, I want to release this fix for bug#954143 and bug#1002417. It's all about correct handling of rpm files with sw_single in KDE. XFCE is not affected and I assume GNOME neither. It's relatively important for Leap 42.2, which is in beta phase so moderately open to changes. On the other hand, is not that relevant for SP2 which is in RC phase, meaning that only really critical stuff should get in. In our SLE-12-SP2 branch we have yast2-packager 3.1.117 In the master branch we already have yast2-packager 3.1.118 (btw, when will we jump to 3.2.x?) In the past we used to have a merge_after_SP2_release branch that we used to accumulate fixes that we wanted to release as maintenance update the same day of the release. Where should my fix go and how should it be versioned? I can create the merge_after_SP2_release branch and submit stuff from there to Leap 42.2. But there is a problem. In order to submit the stuff I have to put a version number to it. Assuming it would be 3.1.117.1. What happens if we need to fix a critical issue in the SLE-12-SP2 branch? We have no version number to do that (317.X would already be taken for the merge_after_SP2_release branch and 318 is already in master). My suggestion, start using 3.2.X for master. We can correct the already released packages not using that versioning schema. They shouldn't be many. So the solution would look like this(for the yast2-packager example) SLE-12-SP2 (SP2 in OBS) -> 3.1.118, 3.1.119... master (TW in OBS) -> 3.2.1, 3.2.2... merge_after_release (Leap and SP2:Update) -> 3.1.117.1, 3.1.117.2... Changes introduced in SLE-12-SP2 should also be merged in merge_after_release (producing a new number there) and the final merge after release should bump the number to follow the SLE-12-SP2 series. What do you think? I would like to discuss this in tomorrow's call to unblock the situation. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, 4 Oct 2016 12:19:47 +0200 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
As discussed in the call, I want to release this fix for bug#954143 and bug#1002417. It's all about correct handling of rpm files with sw_single in KDE. XFCE is not affected and I assume GNOME neither.
It's relatively important for Leap 42.2, which is in beta phase so moderately open to changes.
On the other hand, is not that relevant for SP2 which is in RC phase, meaning that only really critical stuff should get in.
In our SLE-12-SP2 branch we have yast2-packager 3.1.117
In the master branch we already have yast2-packager 3.1.118 (btw, when will we jump to 3.2.x?)
In the past we used to have a merge_after_SP2_release branch that we used to accumulate fixes that we wanted to release as maintenance update the same day of the release.
Where should my fix go and how should it be versioned?
I can create the merge_after_SP2_release branch and submit stuff from there to Leap 42.2. But there is a problem. In order to submit the stuff I have to put a version number to it. Assuming it would be 3.1.117.1. What happens if we need to fix a critical issue in the SLE-12-SP2 branch? We have no version number to do that (317.X would already be taken for the merge_after_SP2_release branch and 318 is already in master).
My suggestion, start using 3.2.X for master. We can correct the already released packages not using that versioning schema. They shouldn't be many.
So the solution would look like this(for the yast2-packager example)
SLE-12-SP2 (SP2 in OBS) -> 3.1.118, 3.1.119... master (TW in OBS) -> 3.2.1, 3.2.2... merge_after_release (Leap and SP2:Update) -> 3.1.117.1, 3.1.117.2...
this is wrong, as SP2 have higher number then merge_after_release. What abou 3.1.117.1 reserved for SP2 and 3.1.118 for merge_after_release? in general I agree with 3.2.* versioning jump. ( just keep it in mind when dumping master )
Changes introduced in SLE-12-SP2 should also be merged in merge_after_release (producing a new number there) and the final merge after release should bump the number to follow the SLE-12-SP2 series.
I think that better way is to merge merge_after_release to SP2 branch and use its new higher number. Also I expect that all fixes in SP2 will be in Leap, so all changes in SP2 have to be in merge_after_release.
What do you think?
I would like to discuss this in tomorrow's call to unblock the situation.
Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 10/04/2016 12:50 PM, Josef Reidinger wrote:
On Tue, 4 Oct 2016 12:19:47 +0200 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
[...]
My suggestion, start using 3.2.X for master. We can correct the already released packages not using that versioning schema. They shouldn't be many.
So the solution would look like this(for the yast2-packager example)
SLE-12-SP2 (SP2 in OBS) -> 3.1.118, 3.1.119... master (TW in OBS) -> 3.2.1, 3.2.2... merge_after_release (Leap and SP2:Update) -> 3.1.117.1, 3.1.117.2...
this is wrong, as SP2 have higher number then merge_after_release. What abou 3.1.117.1 reserved for SP2 and 3.1.118 for merge_after_release?
Yes, that obviously makes much more sense. I was just writing from the top of my mind, without thinking it twice.
in general I agree with 3.2.* versioning jump. ( just keep it in mind when dumping master )
Changes introduced in SLE-12-SP2 should also be merged in merge_after_release (producing a new number there) and the final merge after release should bump the number to follow the SLE-12-SP2 series.
I think that better way is to merge merge_after_release to SP2 branch and use its new higher number. Also I expect that all fixes in SP2 will be in Leap, so all changes in SP2 have to be in merge_after_release.
Yes, as said. Makes more sense. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 10/04/2016 01:02 PM, Ancor Gonzalez Sosa wrote:
On 10/04/2016 12:50 PM, Josef Reidinger wrote:
On Tue, 4 Oct 2016 12:19:47 +0200 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
[...]
My suggestion, start using 3.2.X for master. We can correct the already released packages not using that versioning schema. They shouldn't be many.
So the solution would look like this(for the yast2-packager example)
SLE-12-SP2 (SP2 in OBS) -> 3.1.118, 3.1.119... master (TW in OBS) -> 3.2.1, 3.2.2... merge_after_release (Leap and SP2:Update) -> 3.1.117.1, 3.1.117.2...
this is wrong, as SP2 have higher number then merge_after_release. What abou 3.1.117.1 reserved for SP2 and 3.1.118 for merge_after_release?
Yes, that obviously makes much more sense. I was just writing from the top of my mind, without thinking it twice.
in general I agree with 3.2.* versioning jump. ( just keep it in mind when dumping master )
Changes introduced in SLE-12-SP2 should also be merged in merge_after_release (producing a new number there) and the final merge after release should bump the number to follow the SLE-12-SP2 series.
I think that better way is to merge merge_after_release to SP2 branch and use its new higher number. Also I expect that all fixes in SP2 will be in Leap, so all changes in SP2 have to be in merge_after_release.
Yes, as said. Makes more sense.
And next question is, what will be release through self-update? Everything from the merge_after_release branches will be published in the self-update repo? Just asking, I don't see a reason to not do it. For example, I already have a trivial fix for this yast-bootloader bug https://bugzilla.suse.com/show_bug.cgi?id=1000629 I plan to merge it in merge_after_release and master... and it looks exactly as the kind of things we created self-update for. Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, 4 Oct 2016 13:58:30 +0200 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
On 10/04/2016 01:02 PM, Ancor Gonzalez Sosa wrote:
On 10/04/2016 12:50 PM, Josef Reidinger wrote:
On Tue, 4 Oct 2016 12:19:47 +0200 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
[...]
My suggestion, start using 3.2.X for master. We can correct the already released packages not using that versioning schema. They shouldn't be many.
So the solution would look like this(for the yast2-packager example)
SLE-12-SP2 (SP2 in OBS) -> 3.1.118, 3.1.119... master (TW in OBS) -> 3.2.1, 3.2.2... merge_after_release (Leap and SP2:Update) -> 3.1.117.1, 3.1.117.2...
this is wrong, as SP2 have higher number then merge_after_release. What abou 3.1.117.1 reserved for SP2 and 3.1.118 for merge_after_release?
Yes, that obviously makes much more sense. I was just writing from the top of my mind, without thinking it twice.
in general I agree with 3.2.* versioning jump. ( just keep it in mind when dumping master )
Changes introduced in SLE-12-SP2 should also be merged in merge_after_release (producing a new number there) and the final merge after release should bump the number to follow the SLE-12-SP2 series.
I think that better way is to merge merge_after_release to SP2 branch and use its new higher number. Also I expect that all fixes in SP2 will be in Leap, so all changes in SP2 have to be in merge_after_release.
Yes, as said. Makes more sense.
And next question is, what will be release through self-update? Everything from the merge_after_release branches will be published in the self-update repo? Just asking, I don't see a reason to not do it.
For example, I already have a trivial fix for this yast-bootloader bug https://bugzilla.suse.com/show_bug.cgi?id=1000629 I plan to merge it in merge_after_release and master... and it looks exactly as the kind of things we created self-update for.
Cheers.
Well, self update will require quite intensive QA testing, so I am not sure how often we want to run such procedure. Question for release manager or maintenance ones? Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 4.10.2016 v 14:11 Josef Reidinger napsal(a):
On Tue, 4 Oct 2016 13:58:30 +0200 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
And next question is, what will be release through self-update? Everything from the merge_after_release branches will be published in the self-update repo? Just asking, I don't see a reason to not do it.
That's actually a good question how to handle the self-update fixes. I guess that testing the self-update patches will be quite difficult (think about all test cases like autoinstallation/autoupgrade...). On the other hand IIRC some openQA tests already include the self update. That should help a bit. My assumption is that we should not release every SP2 update also as a self-update fix as building and testing is not trivial. But it actually depends on the QA and the maintenance teams how much work they can reserve for the self-updates.
For example, I already have a trivial fix for this yast-bootloader bug https://bugzilla.suse.com/show_bug.cgi?id=1000629 I plan to merge it in merge_after_release and master... and it looks exactly as the kind of things we created self-update for.
Yes, a fix for a crash looks like a good candidate for a self-update. For self-updates I'd suggest using a separate branch, e.g. "SLE-12-SP2-self-update". Another self-update related thing: The self-update overrides the original files from the inst-sys by the files from the self-update RPM. But many fixes will be located in a single file, we do not need to package the unchanged files which would override the files with the very same content. So for self-updates I'd suggest to edit the *.spec files to package only the changed files and use some suffix in the package version so it's obvious it's not a full package. (The version actually does not matter, the installer downloads and applies *all* packages regardless the version or the package dependencies.) And this is easier with a separate self-update branch. -- Best Regards Ladislav Slezák Yast Developer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 4.10.2016 v 13:02 Ancor Gonzalez Sosa napsal(a):
SLE-12-SP2 (SP2 in OBS) -> 3.1.118, 3.1.119... master (TW in OBS) -> 3.2.1, 3.2.2... merge_after_release (Leap and SP2:Update) -> 3.1.117.1, 3.1.117.2...
this is wrong, as SP2 have higher number then merge_after_release. What abou 3.1.117.1 reserved for SP2 and 3.1.118 for merge_after_release?
Yes, that obviously makes much more sense. I was just writing from the top of my mind, without thinking it twice.
To summarize it, the current proposal is: SLE-12-SP2 (SP2 in OBS) -> 3.1.117.1, 3.1.117.2, ... master (TW in OBS) -> 3.2.1, 3.2.2... merge_after_release (Leap42.2 and SP2:Update in OBS) -> 3.1.118, 3.1.119... (later this will be merged to SLE-12-SP2) This looks OK to me. -- Best Regards Ladislav Slezák Yast Developer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (3)
-
Ancor Gonzalez Sosa -
Josef Reidinger -
Ladislav Slezak