On Tue, 30 Sep 2014 18:26:25 +0200 Ladislav Slezak <lslezak@suse.cz> wrote:

Dne 30.9.2014 v 13:43 Josef Reidinger napsal(a):

...

Hi, I would like to introduce SLE-12 maintainance branch tomorrow on wednesday 1.10. . I also would like to switch internal jenkins for SLE-12 branch to submit to update repository, so it create maintenance updates instead of submissions to SLE:12:GA.

...

...

Any objections?

LGTM ;-)

Just a question: What if we need to release a fix for SLE12? (We might still need to fix something in GMC to the real GM.)

It seems that we will need to submit the packages manually. I think it's OK as there should be as few changes as possible (ideally none).

Well, I see there two possible ways: 1) opensuse one, make fix in SLE-12 branch and release team took package from submit request to Update channel 2) manual one, when you manually submit package

Thanks!

--

Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE

-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On Wed, 01 Oct 2014 09:25:56 +0200 Lukas Ocilka <lukas.ocilka@suse.com> wrote:

On 30.9.2014 13:43, Josef Reidinger wrote:

...

Hi, I would like to introduce SLE-12 maintainance branch tomorrow on wednesday 1.10. . I also would like to switch internal jenkins for SLE-12 branch to submit to update repository, so it create maintenance updates instead of submissions to SLE:12:GA.

Yes, please do.

...

As part of this step I would also like to create merge request of SLE-12-GA branch and master with revert in master for Rakefile change. This will allow us in future to easy do in master `git merge origin/SLE-12-GA` to not forget any fixes made in SLE-12-GA.

To be honest, here I do not 100% understand what do you actually want to do and why.

I want to use same work-flow as in SLMS or some YaST modules for maintainance branches. Some usage is described here https://wiki.duraspace.org/display/VIVO/Git%3A+working+with+the+maintenance+... What I want to achive is easy way how to verify that all fixes in maintainance branch get into master or newer maintenance branch. When I want now see what commits are in Code-11 branch and not in master I can do something like: git log origin/master..origin/Code-11-SP1 # or without origin if your local branches are up to date as you can see it is quite useless as we usually cherry pick differences so it is huge mess and very hard to see if we forgot some fixes. On other hand in bootloader I already use this approach for SLE-12-GA branch ( and also in SLMS we use it ). Result is that git log origin/master..origin/SLE-12-GA is empty as I merge all fixes for SLE-12 in master if you are curious how it will look like, you can check commit before I merge it: git log 85a6de7..origin/SLE-12-GA this shows that I miss three fixes in master, so I need to make git checkout master git pull git merge origin/SLE-12-GA solve conflicts ( usually changes file and version in spec ) and commit it. And time to celebrate, we do not miss any fix made for GA. I think it is very important if we want to use master for SP1 to be sure we do not miss any fix for GA.

...

So to summary changes will be: 1) switch internal jenkins to work on branch SLE-12-GA ( there is currently no clear target for master branch in IBS - so I add new jobs for branch and disable ones for master branch )

IBS / Master => SLE 12 SP1, but we can base it on SUSE:SLE-12:Update now as there is not SP1 yet

Problem is that jenkins try to submit there, which is not good idea :)

...

2) create all packages in https://build.suse.de/project/show/Devel:YaST:SLE-12

What about Devel:YaST:SLE-12:Update to be compatible with SUSE:SLE-12:Update in IBS?

It is possible, but I want to keep it simple and short as sometimes you need to write it :)

...

3) create maintenance branch for all packages + create revert commit in master as described above

Any objections?

Just the "revert commit"

I hope I explained it. We can discuss it in person if something is not clear, as I start with creating branch already ( current status is that river is switched to new branch ). Josef

Thanks Lukas

-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org