[yast-devel] SLE12 GIT branch?
Hi all I'd like to start a discussion about creating the SLE12 branch in Git repositories. The basic questions are: - When should we create the branch? Do you need it already now? - Should we create the branches globally or should we leave that on the respective maintainers? -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, 28 Aug 2014 08:53:49 +0200
Ladislav Slezak
Hi all
I'd like to start a discussion about creating the SLE12 branch in Git repositories.
thanks for it.
The basic questions are:
- When should we create the branch? Do you need it already now?
Sometimes I need it. Especially for bootloader, where I plan to implement opensuse feature to drop grub1 support. Now I also have in queue fix for yast2-core to make .target.yast2 working in switched SCR.
- Should we create the branches globally or should we leave that on the respective maintainers?
I do not have strong opinion, just respective maintainer need to ping me, so I can create maintenance job on internal jenkins ( so it build two different branches ). I would like to also remind, that we need small modification in just branch in Rakefile where we need to specify correct target project and IBS usage ( it is easy two lines change, but it is same for all git repositories ). Josef
--
Best Regards
Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
The basic questions are:
- When should we create the branch? Do you need it already now?
In my POV when SLE12 is released. I don't need it now.
- Should we create the branches globally or should we leave that on the respective maintainers?
globally. To guarantee that all repos are in same "shape" Michal -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 28.8.2014 09:10, Michal Filka wrote:
The basic questions are:
- When should we create the branch? Do you need it already now?
In my POV when SLE12 is released. I don't need it now.
The same applies to my needs.
- Should we create the branches globally or should we leave that on the respective maintainers?
globally. To guarantee that all repos are in same "shape"
How I see it, we should make sure that such a branch contains everything that made it to SLE 12, but nothing more. I've seen in the past, that branch did not contain everything or contained more commits than got to a particular product. Thanks Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader Cloud & Systems Management Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, Aug 28, 2014 at 09:58:40AM +0200, Lukas Ocilka wrote:
- Should we create the branches globally or should we leave that on the respective maintainers?
globally. To guarantee that all repos are in same "shape"
How I see it, we should make sure that such a branch contains everything that made it to SLE 12, but nothing more. I've seen in the past, that branch did not contain everything or contained more commits than got to a particular product.
Do you have examples of mismatches, to remind us of the pitfalls to avoid? So far I interpret this as "remember to submit from the right branch" which Jenkins should automate just fine. A stronger requirement is "distinguish SLE12-GA from maintenance", which would be implemented by tags. Automatict tagging is not working now. -- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
On 2.9.2014 10:47, Martin Vidner wrote:
On Thu, Aug 28, 2014 at 09:58:40AM +0200, Lukas Ocilka wrote:
- Should we create the branches globally or should we leave that on the respective maintainers?
globally. To guarantee that all repos are in same "shape"
How I see it, we should make sure that such a branch contains everything that made it to SLE 12, but nothing more. I've seen in the past, that branch did not contain everything or contained more commits than got to a particular product.
Do you have examples of mismatches, to remind us of the pitfalls to avoid? So far I interpret this as "remember to submit from the right branch" which Jenkins should automate just fine.
No I don't have any. These were deep in the past and I don't remember the details anymore. This would need a real detective and lots of time, that we don't have right now.
A stronger requirement is "distinguish SLE12-GA from maintenance", which would be implemented by tags. Automatict tagging is not working now.
If I understand it correctly, the branch for SLE12-GA and maintenance will be the same. Then tagging is the only way. PLS, also remember that I'd like to branch SLE12-SP1 maintenance from "master" to keep the development of master/openSUSE/SLE12-SP1 as close as possible - as long as possible. Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader Cloud & Systems Management Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, Sep 02, 2014 at 11:09:15AM +0200, Lukas Ocilka wrote:
PLS, also remember that I'd like to branch SLE12-SP1 maintenance from "master" to keep the development of master/openSUSE/SLE12-SP1 as close as possible - as long as possible.
Do I understand this right: You want to base YaST on SLE12 SP1 on
"master in about a year" instead of SLE12?
Regards,
Arvin
--
Arvin Schnell,
On 2.9.2014 11:20, Arvin Schnell wrote:
On Tue, Sep 02, 2014 at 11:09:15AM +0200, Lukas Ocilka wrote:
PLS, also remember that I'd like to branch SLE12-SP1 maintenance from "master" to keep the development of master/openSUSE/SLE12-SP1 as close as possible - as long as possible.
Do I understand this right: You want to base YaST on SLE12 SP1 on "master in about a year" instead of SLE12?
Yes, I already wrote about it a few ... hmm, months ago. There will be a lot of refactoring in master, but we are going to maintain SLE 12 for many years, so the same refactoring should go to SLE 12 SP1. In fact, there are plans for having SLE and openSUSE much closer than before. More to be announced soon, hopefully. Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader Cloud & Systems Management Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, Sep 02, 2014 at 11:24:41AM +0200, Lukas Ocilka wrote:
On 2.9.2014 11:20, Arvin Schnell wrote:
On Tue, Sep 02, 2014 at 11:09:15AM +0200, Lukas Ocilka wrote:
PLS, also remember that I'd like to branch SLE12-SP1 maintenance from "master" to keep the development of master/openSUSE/SLE12-SP1 as close as possible - as long as possible.
Do I understand this right: You want to base YaST on SLE12 SP1 on "master in about a year" instead of SLE12?
Yes, I already wrote about it a few ... hmm, months ago. There will be a lot of refactoring in master, but we are going to maintain SLE 12 for many years, so the same refactoring should go to SLE 12 SP1.
In fact, there are plans for having SLE and openSUSE much closer than before. More to be announced soon, hopefully.
An announcement is a requirement since your proposal does not
match the current maintenance model.
Regards,
Arvin
--
Arvin Schnell,
Dne 2.9.2014 10:47, Martin Vidner napsal(a): [...]
Do you have examples of mismatches, to remind us of the pitfalls to avoid? So far I interpret this as "remember to submit from the right branch" which Jenkins should automate just fine.
The problem is that just before the GM release the build service team might reject a submit request. Then you have a different state in GIT/Devel:YaST:Head/Jenkins and the final product. So at the last minute we should fix only the bugs confirmed by PMs or release managers to avoid this and we should watch for "rejected" SRs and either fix them and resubmit or revert in GIT to be consistent. -- 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 Tue, Sep 02, 2014 at 12:44:08PM +0200, Ladislav Slezak wrote:
Dne 2.9.2014 10:47, Martin Vidner napsal(a): [...]
Do you have examples of mismatches, to remind us of the pitfalls to avoid? So far I interpret this as "remember to submit from the right branch" which Jenkins should automate just fine.
The problem is that just before the GM release the build service team might reject a submit request. Then you have a different state in GIT/Devel:YaST:Head/Jenkins and the final product.
So at the last minute we should fix only the bugs confirmed by PMs or release managers to avoid this and we should watch for "rejected" SRs and either fix them and resubmit or revert in GIT to be consistent.
Or the build service team should be included in the GitHub review
process.
That reminds me of a problem I have with SLE11 SP development:
Sometimes a patch/package is requested for e.g. SP3 but then the
package is simply copied to SP2. Thus the branches in the
repository and the build service state get completely messed up.
Regards,
Arvin
--
Arvin Schnell,
On 2.9.2014 12:44, Ladislav Slezak wrote:
Dne 2.9.2014 10:47, Martin Vidner napsal(a): [...]
Do you have examples of mismatches, to remind us of the pitfalls to avoid? So far I interpret this as "remember to submit from the right branch" which Jenkins should automate just fine.
The problem is that just before the GM release the build service team might reject a submit request. Then you have a different state in GIT/Devel:YaST:Head/Jenkins and the final product.
So at the last minute we should fix only the bugs confirmed by PMs or release managers to avoid this and we should watch for "rejected" SRs and either fix them and resubmit or revert in GIT to be consistent.
Yes, that's one of those cases. Thank you! -- Lukas Ocilka, Systems Management (Yast) Team Leader Cloud & Systems Management Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 28.8.2014 08:53, Ladislav Slezak napsal(a):
I'd like to start a discussion about creating the SLE12 branch in Git repositories.
The basic questions are:
- When should we create the branch? Do you need it already now?
As for me, I do not need SLE12 branch now, I'm still working on SLE12 fixes and I'll very likely continue until GMC :-) Note: Keep in mind that Jenkins currently automatically submits from master to SLE-12:GA, if we create a SLE12 branch then we need to change it...
- Should we create the branches globally or should we leave that on the respective maintainers?
I'd leave that on the maintainers (resp. create on demand), but it would be nice to create the missing branches for the remaining repositories automatically at some point to not miss it. In the past we forgot to create 12.2 and 12.3 branches for many packages, see my mail [1]. Last time I created 13.1 branches so I volunteer for creating the SLE12 branches. [1] http://lists.opensuse.org/yast-devel/2013-09/msg00048.html -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, Aug 28, 2014 at 08:53:49AM +0200, Ladislav Slezak wrote:
I'd like to start a discussion about creating the SLE12 branch in Git repositories.
The basic questions are:
- When should we create the branch? Do you need it already now?
Michal, Lada, and Lukas don't need it. Pepa mentioned yast2-core, but more importantly yast2-bootloader: openSUSE has a freeze before the SLE release!
- Should we create the branches globally or should we leave that on the respective maintainers?
It's not that simple. I think that waiting for a global switch is not possible because of openSUSE requirements, and leaving switches to individuals means we end up with a mess. Current policy, for all packages: The internal Jenkins submits master to SLE12, for all packages. We should pick one or a couple of packages as pilots for the new policy: The internal Jenkins submits $BRANCH to SLE12, and does not care(?) about master". Then announce which packages are in the pilot, implement that, fix bugs. Later, clearly communicate when other individual packages adopt the policy as needed, and when all the rest do (SLE release). What will the branch name be? I propose Code-12. -- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
On Tue, 2 Sep 2014 10:46:05 +0200
Martin Vidner
On Thu, Aug 28, 2014 at 08:53:49AM +0200, Ladislav Slezak wrote:
I'd like to start a discussion about creating the SLE12 branch in Git repositories.
The basic questions are:
- When should we create the branch? Do you need it already now?
Michal, Lada, and Lukas don't need it.
Pepa mentioned yast2-core, but more importantly yast2-bootloader: openSUSE has a freeze before the SLE release!
- Should we create the branches globally or should we leave that on the respective maintainers?
It's not that simple. I think that waiting for a global switch is not possible because of openSUSE requirements, and leaving switches to individuals means we end up with a mess.
I think reasonable solution is to create script to do such switch on individual branch and who need it can use it and who do not, then can wait for global, that run it on everything. Is this reasonable solution?
Current policy, for all packages:
The internal Jenkins submits master to SLE12, for all packages.
Unless it is explicitelly overwritten in Rakefile, which is what I plan to do in given branches.
We should pick one or a couple of packages as pilots for the new policy:
The internal Jenkins submits $BRANCH to SLE12, and does not care(?) about master".
It is quite simple switch on which branch jenkins operate, nothing more. Ideally it copy previous task and just change branch tag.
Then announce which packages are in the pilot, implement that, fix bugs. Later, clearly communicate when other individual packages adopt the policy as needed, and when all the rest do (SLE release).
agree.
What will the branch name be? I propose Code-12.
I do not agree, as it is in fact not base for Code-12 as Lukas mentioned above. It is just branch for maintenance of SLE-12-GA, so not whole Code-12...so I propose SLE-12-GA branch name. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, 2 Sep 2014 10:46:05 +0200
Martin Vidner
On Thu, Aug 28, 2014 at 08:53:49AM +0200, Ladislav Slezak wrote:
I'd like to start a discussion about creating the SLE12 branch in Git repositories.
The basic questions are:
- When should we create the branch? Do you need it already now?
Michal, Lada, and Lukas don't need it.
Pepa mentioned yast2-core, but more importantly yast2-bootloader: openSUSE has a freeze before the SLE release!
So just reminder, now is time when I need it as I finish my grub1 drop and want to continue with other improvements in bootlaoder code like switch from automake to rake tasks, improved test suite and refactoring of some really ugly methods which is used. https://github.com/yast/yast-bootloader/pull/149 So if noone have against, I can create script that do all stuff for SLE-12-GA maintenance branch + create task on internal jenkins. Josef
On Thu, 4 Sep 2014 08:45:27 +0200
Josef Reidinger
On Tue, 2 Sep 2014 10:46:05 +0200 Martin Vidner
wrote: On Thu, Aug 28, 2014 at 08:53:49AM +0200, Ladislav Slezak wrote:
I'd like to start a discussion about creating the SLE12 branch in Git repositories.
The basic questions are:
- When should we create the branch? Do you need it already now?
Michal, Lada, and Lukas don't need it.
Pepa mentioned yast2-core, but more importantly yast2-bootloader: openSUSE has a freeze before the SLE release!
So just reminder, now is time when I need it as I finish my grub1 drop and want to continue with other improvements in bootlaoder code like switch from automake to rake tasks, improved test suite and refactoring of some really ugly methods which is used. https://github.com/yast/yast-bootloader/pull/149
So if noone have against, I can create script that do all stuff for SLE-12-GA maintenance branch + create task on internal jenkins.
Josef
I create such script and already test it on yast2-bootloader. You can find it in devtools - https://github.com/yast/yast-devtools/blob/master/ytools/yast2/create_mainte... I try to follow KISS so configuration is inside and code is I hope readable. Welcome any comments Josef
Guys, As we are working on our workshop projects now, please keep in mind that what you do should not get into SLE 12 GA (no big changes, almost no little changes). So, you have basically two options: - Work in a branch now and do not merge into master yet - Branch SLE 12 now In case of branching, contact Pepa to a.) help you with creating the branch if needed (see other e-mail at yast-devel) b.) to switch SLE Jenkins to the new branch! Thanks in advance Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader Cloud & Systems Management Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (6)
-
Arvin Schnell
-
Josef Reidinger
-
Ladislav Slezak
-
Lukas Ocilka
-
Martin Vidner
-
Michal Filka