Developing SLE, Factory and Leap distributions at the same time, impossible?
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 55 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/54517 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
openSUSE Conference 201835 / 55
8
9
11
15
17
19
20
21
26
28
30
31
32
34
38
39
42
44
45
47
51
52
54
00:00
Distribution (mathematics)System of linear equationsEnterprise architectureProduct (business)1 (number)Electronic mailing listData managementOpen sourceDistribution (mathematics)Slide ruleServer (computing)Multiplication signStatisticsPoint (geometry)Ring (mathematics)Civil engineeringOffenes KommunikationssystemFactory (trading post)Self-organizationComputer animation
01:30
Server (computing)Enterprise architectureSuSE LINUXSystem of linear equationsFactory (trading post)Distribution (mathematics)Repository (publishing)Moving averageCodeBasis <Mathematik>Latent heatShared memoryCore dumpPoint (geometry)Mixed realityBitMainframe computerCore dumpAdditionSoftware developerIntelligent NetworkTwin primeFactory (trading post)Utility softwareDistribution (mathematics)Computer animationDiagram
03:21
SuSE LINUXEnterprise architectureTwitterDampingBasis <Mathematik>Factory (trading post)Service PackCore dumpComputer animation
03:57
System of linear equationsSynchronizationDivergencePatch (Unix)Point (geometry)DisintegrationMathematicsStreaming mediaTouch typingService (economics)BitInformation securityNumberSoftware bugStudent's t-testMathematicsRevision controlFactory (trading post)Multiplication signAlexander polynomialGroup actionMultilaterationTraffic reportingGoodness of fitMereologyProjective planeData managementWebsiteSound effectDifferent (Kate Ryan album)Forcing (mathematics)Source codeOpen setDistribution (mathematics)Lipschitz-StetigkeitException handlingPatch (Unix)Service PackReverse engineeringTrailRow (database)Linear regressionSystem of linear equationsComputer animation
12:09
DemosceneSystem of linear equationsFactory (trading post)FingerprintSoftware testingSuite (music)Software developerFrequencyBeta functionPhase transitionLipschitz-StetigkeitGroup actionSystem of linear equationsSupersymmetryMedical imagingSubsetLevel (video gaming)Set (mathematics)Software testingProcess (computing)RobotRepository (publishing)Projective planeDistribution (mathematics)Suite (music)Default (computer science)ConsistencyMultiplication signInstallation artMathematicsBootingBranch (computer science)Factory (trading post)Fuzzy logicInformation securityEntire functionSoftware developerInstance (computer science)Normal (geometry)Data managementDirectory servicePunched cardOpen setWebsiteRule of inferencePatch (Unix)Text editorOrder (biology)Forcing (mathematics)Data storage deviceComputer animation
18:35
Factory (trading post)FrequencySystem of linear equationsBeta functionPhase transitionParameter (computer programming)Software bugRevision controlSoftware developerSystem of linear equationsSound effectFactory (trading post)FrictionPhase transitionBeta functionMathematicsEnterprise architectureSinc functionCodeSoftware maintenanceSoftware testingView (database)Arithmetic meanStandard deviationTwin primeOpen setData structureProduct (business)Right angleLattice (order)Data managementSeries (mathematics)Video gameDemosceneWordForm (programming)Distribution (mathematics)Network operating systemProjective planeStreaming mediaMultiplication signKey (cryptography)Limit (category theory)Ideal (ethics)Computer animation
24:37
Factory (trading post)FrequencySystem of linear equationsBeta functionPhase transitionMountain passMathematicsSoftware developerSoftware maintenanceIdentical particlesVotingRobotSoftware developerMathematical analysisBuildingProjective planeSoftware maintenanceMathematicsNumberComputer animationMeeting/Interview
25:40
Factory (trading post)MathematicsSystem of linear equationsSoftware developerSoftware maintenanceIdentical particlesInformationRobotException handlingRule of inferenceTimestampSinc functionSoftware repositoryMultiplication signSoftware bugNumberElectronic mailing listAutomationData managementDifferent (Kate Ryan album)Kernel (computing)Factory (trading post)MathematicsAxiom of choiceLevel (video gaming)2 (number)Patch (Unix)Distribution (mathematics)Projective planeUsabilityContinuum hypothesisVideo gameSet (mathematics)Instance (computer science)Digital photographyGroup actionTraffic reportingKey (cryptography)Extension (kinesiology)Service (economics)WritingSource codeAsynchronous Transfer ModeArithmetic meanOffice suitePhysical systemComputer animation
33:12
Mountain passPerturbation theoryNumberSystem of linear equationsSource codeEquivalence relationIdentical particlesPatch (Unix)Factory (trading post)RootSound effectSoftware developerCellular automatonSinc functionUsabilityMachine visionMereologyBitTotal S.A.Slide ruleNumberNetwork topologyMathematicsGreen's functionSource codeServer (computing)CodeDialectWordStatisticsPoint (geometry)Core dumpDivergenceService PackLine (geometry)Structural loadMultiplication signSpeech synthesisProduct (business)Term (mathematics)TowerTouchscreenSystem of linear equationsGoodness of fitKernel (computing)Expected valueOpen setService (economics)Computer animation
38:58
Source codeFactory (trading post)Process (computing)Multiplication signMereologyRevision controlSource codeLatent heatSystem of linear equationsRow (database)Distribution (mathematics)FeedbackFactory (trading post)Projective planeProcess (computing)MeasurementModule (mathematics)Software developerWhiteboardSoftware maintenanceLibrary (computing)Level (video gaming)Sheaf (mathematics)Bus (computing)Lattice (order)Video gameInstance (computer science)Sound effectStability theoryOffice suiteNumberEndliche ModelltheorieDisk read-and-write headComputer animation
44:21
Process (computing)VideoconferencingHypermediaComputer animation
Transcript: English(auto-generated)
00:06
My name is Frederic Rosa, I'm a release manager at SUSE, working on the SLEE product, initially SLED, the desktop product, these days also I'm helping on the server products SLES.
00:23
And today I will talk about how we manage to develop SLEE and open to the leap, open system, but we then make sure one is not, one distribution is not done against the other,
00:45
but how we manage or we try to manage to develop all those distribution together. So this is a talk I've been doing, I think this is the third time I'm doing it at the open source conference,
01:01
with some statistics evolving from year to year, and I've also done this talk this year as for them, but leap 15 was not out yet at that time, at that point in time, so now it's out, so it's interesting to see where things have improved over one year,
01:22
so since last open source conference. So, some terminology, so this is mostly, I should have killed this slide for open source conference, this is mostly for the people, so quickly, SLEE, you know what it means,
01:43
same for factory, tumbleweed and leap. Then how we develop things all together, again, this is something which is not new to you. One funny fact, I didn't know what Voitech keynote was going to be about,
02:05
so it's a bit like he has been talking two days ago on how SUSE decided at some point to bring together the SLEE development with factory, and this talk is kind of how we try to make it work.
02:25
So, again, briefly, for each leap release, there is a mix of SLEE core packages and then packages from tumbleweed, and for SLEE, of course, there is this mixed shared core
02:49
and additional packages which are not available on leap, usually they are not available because they are not relevant for common usage distributions,
03:02
they are only relevant for, I don't know, mainframe or other things like that. But in the previous leap and SLEE 42 and SLEE 12 releases, we worked with the SLEE 12 packages,
03:27
so the core packages, we kind of retrofit packages from the previous service pack to the new one, and we pull in also packages from tumbleweed, but with SLEE 15, we started over from scratch,
03:43
kind of, with tumbleweed factory as a basis, but let's not go too fast. First, a lesson from the past, to try to not repeat the mistake from the past, but learn from them. So, in SLEE 12, as I said before, I've worked initially on the desktop,
04:08
so I will take the desktop as a good example, and the fact that the release manager of tumbleweed is also part of the OpenSUSE GNOME team, he will be able to shout at me if I say something wrong.
04:23
So, in SLEE 12, so SP0, for SLEE, we picked a GNOME version, 3.10.3, and we did a lot of fixes, we did a lot of feature, and we didn't push our changes to factory.
04:46
So, I hear boo from the audience. You cannot hear that on the recording. And our excuse was, oh, we are too busy to work on making those features working properly
05:03
without bugs, et cetera. We'll push back to factory later. We'll have time later. And so, SLEE 12 SP0 was released, great. And then the next version was service pack one.
05:23
And people were, did they push their bug fix and feature to factory? No, because they were too busy to fix bugs on service pack one. So, the excuse was, oh, we'll do that later.
05:41
Well, we saw that it was not a good idea to keep going on with this burden. And so, we decided that for service pack two, which was also leap 42.2,
06:03
we will push all the changes that we did on the SLEE 12 GNOME to open source. And with the ultimate goal of having the same source RPM on both distribution.
06:21
And we did it. It was 300 packages to sync. There was a lot of initial discussion between the SUSE desktop teams and the open SUSE GNOME teams. Mostly because the styles of changelog were not the same.
06:46
And we on the SUSE side needed to learn to be part of the community. Because it's sometimes very easy when you are working on your own small thing alone. You do whatever you want and nobody or very few people will look at what you did.
07:04
But when you look in the open, when you work in the open, then you have to kind of justify why you did it this way. But no, you can do it in another way, et cetera. So, it was really something that people had to grow with, to improve.
07:27
And we created some tools to be able to check the differences between the packages on the SLEE side and on the open SUSE side.
07:40
And when there were some packages, some features, which were really developed for SLEE customers, we had an agreement that we would not enable those on open SUSE on LIP. Because it might change the behavior of GNOME for LIP user.
08:00
Or it would make things worse for them. So, the agreement was if there is a patch which is kind of controversial, it will be only enabled on SLEE because it originated from SLEE and the open SUSE of GNOME team is not feeling comfortable in having this patch enabled.
08:24
Except that sometimes we also discovered that a patch that we enabled on SLEE, because it was not enabled on LIP, people had bugs on LIP that was fixed on SLEE. So, then we kind of, we said for the future we'll try to do the reverse.
08:44
Try to enable as much patch as possible. Of course upstream them whenever it's possible also. But still use only enable patch on one distro or the other as this solution as last resort.
09:05
So, to summarize, we worked internally and we, so we had a DIVL project on our internal bit service and then we were pushing things to open SUSE. We had to do a lot of work also on change locks
09:24
because something which is very important for SUSE customer is to make sure that we don't regress from one service back to another, from one release to another. They want to be sure that all the bug fixes are in,
09:41
all the security fixes are in, et cetera. And one way we used to track that is we put in change lock fate number, bug number, CV number, which is for most of you as open SUSE user not that useful.
10:02
But for the SUSE people it's very useful and we tracked this way how to make sure that a bug is still fixed when we update the version of a package. So, to make this tracking easy, we made sure that when we retrofit
10:22
all the changes from SLE to open SUSE, sometimes we inserted some dummy change log entry to make sure that yes, this bug, even if it's a new version of a package, this bug is still fixed. So, we could see, okay, somebody has checked that this bug is still fixed even if the package is removed.
10:43
And thanks to open SUSE people at large for accepting this kind of dummy change log entry thing because it helped a lot to have same packages between SLE and open SUSE.
11:02
And also because of the way LIP is created, we made sure that the SLE people have to handle the bug which are reported against LIP for packages which are originating from SLE.
11:24
And sometimes it's easy, sometimes it's less easy because when you get a bug report for a package, whatever in GNOME or whenever else, which is coming from the community and somebody at SUSE has to take care of it
11:45
but it's not coming from a customer, a paying customer and he has a lot of other duties. It can be a bit tricky to make sure that things are processed quickly but we are trying.
12:03
So, that was the past. SLE 12, LIP 42. Now, going to SLE 15, LIP 15 because this is where the action I was going to say is
12:20
but now I should say was. LIP 15 is out. So, let's see how we accept things in SLE because this way you will better understand. So, if you are working at SUSE, you will better understand sometimes why we reject things
12:45
and if you are not working at SUSE, you will understand how some people might be not always happy when we say factory first. And yeah, my drawing is not that great after seeing Jim's beautiful chart
13:04
but yes, it's as fuzzy as it can be. So, the way and for people who are used to OBS, it's kind of similar to what factory is doing but it's still a good exercise to better understand how things are done
13:25
when people want to change something on the distribution, being on SLE, being on factory. So, first you create your changes in a branch in your own directory,
13:40
in your own project. You will create a submit request and this submit request will land for a specific distribution, being open to the factory, being SLE 15, for instance. Then a staging manager, so either a bot or a human, it depends,
14:02
will put that submit request into a staging, what we call a staging project, which is going to generate either a small ISO image or it's going to rebuild the packages and all the packages which would be rebuilt
14:22
if these packages were injected in the distribution. So, for instance, you push a new Qt 5, it will try to rebuild on factory, it will try to rebuild KDE and make sure that KDE can be rebuilt.
14:40
So, the OBS is going to rebuild a small subset of the distribution and OpenQA will then run a set of tests on this small distribution,
15:02
except it will not run the full test suite, because the full test suite is huge, it takes a long time. There it's a set of tests, usually kind of minimal install tests, a default install, some consistent hitch check, secure boot install
15:23
and maybe a creep setup install, I'm not sure, but something around that. And it's going to, you will see on the dashboard, does it install properly, does all the tests are green or not? And then it's in wait.
15:40
In parallel, there will be a lot of bots checking the submit request, I will go on that later, and also some humans. So, there it's mandatory for SLE and also for factory to have two sets of two heights, so basically two humans,
16:05
so four heights, to which we are going to check the submit request and see if it's following the rules, if it's not completely crazy, if it's written properly, if there is no backdoor inserted in the patch,
16:23
for instance, it could happen, et cetera. If sometimes, if the submit request looks good, but then one of the reviewers knows that, yes, but if we take that, it's going to break something else
16:41
because of the experience of the reviewer, it can happen. So, if everybody is in agreement, we get, and if OpenQA is green, we'll accept this submit request,
17:00
and then it will be committed to the distribution itself, so factory on one side or SLE on the other side, then the entire distro will be rebuilt, ISO image will be generated, repository will be generated, and when everything is done, OpenQA will run again on the entire distro
17:23
and we'll see if it's suitable or not for release, and then on the SLE side, it's a human which is going to decide, yes, we will release that or not.
17:40
On factory, is it a, are you manually reviewing the test or if it's to test manager? Okay, so just to repeat, on factory side, there is a bot which is doing some checks and if it's not 100% sure, it's going to say I need to ask my master
18:03
who is then going to press a button. So, you know the process now, but as mentioned in the beginning of my talk and also by Wojtek doing his keynote,
18:24
we wanted to be sure that all the development done on the SLE side is always, or most of the time, contributed back to factory. Why doing that?
18:41
We could say we want to be good contributors, we are members of OpenSUSE, so we want to make sure OpenSUSE stay great, OpenSUSE factory, but you can also see that by being more selfish,
19:04
which is also a good argument. We want to make sure that our next major product, major release will be ready and stable as our previous one. So, we want to make sure that when we release
19:24
the next major version of SLE, so now it will be SLE 16, not 15, but 16, we can take OpenSUSE Tumbleweed and then work on it, but we'll know that all the development which was done during SLE 15 will be in OpenSUSE Tumbleweed,
19:45
which was not what we were doing in the past always. As I gave the example of the Gnome thing, so Gnome was a small subset, but just also the development of SLE 12 initially was very painful, as Wojtej explained already.
20:05
The entire company spent, I don't know, a year just to take factory and make it acceptable by enterprise standards, and we didn't want to have this pain again. So, we have put in effect a policy internally at SUSE,
20:24
which is called Factory First. Maybe we should have renamed it Tumbleweed First, but still, it's still good. So, it's in effect since SLE 12 SP3, and it's also in effect for SLE 15. So, what we ask people at SUSE is
20:43
when they can, they should do their development directly on OBS and then push back their development to SLE 15. So, which means, and best and easiest scenario,
21:01
you'll do your changes, you'll do either a package update or bug fix on a package, whatever, or new code added into package for a new feature. Either you can get it accepted upstream, which is the best way,
21:21
but sometimes you are not able to get it upstream or you cannot wait until upstream reads a new version. So, you push it to the distribution, but the way we ask people to do it is push it to factory. Don't try to push it directly to SLE 15.
21:41
Push it to factory. It will be reviewed by the factory people. It will be reviewed first by the developer, by the maintainer of the development project, then by the factory reviewer, and when it's accepted in factory, then we'll take it in SLE 15.
22:02
And to make that even easier for them, we put in place some bots, which were automatically, when there was a new package change in factory, which was already in SLE 15, it was, when some change were checked in factory,
22:21
it was creating automatically a submit request to SLE 15. So, for people, it was like, okay, I develop on factory, it's accepted, and then it's automatically, I don't even have as a developer to do any work. It's going to be pushed automatically to SLE 15. So, it doesn't have,
22:41
it reduces the burden, the friction of this policy. This way, we smoothed a lot of development between factory and SLE 15.
23:00
And this was in place, so it automatically forward of packages, which was done until RC1 or RC2 of SLE 15. And then we disabled the bot, which was submitted automatically. And we asked people, now you can please cherry-pick
23:22
if you really want to push something for factory, you should still push things, but it won't be automatically forwarded from factory to SLE 15. And when people were submitting directly, internally to SLE 15, the reviewer were checking, is there something which is exactly the same on the OBS side?
23:45
And based on all of this, the release manager, so myself, Hadoop, Stefan Bellot, and all the others, Alex also, decided should it go in or not.
24:03
And also, thanks to that, we made sure that SLE 15 development was always live on OBS. So, starting with the beta phase, SLE 15 was available on OBS. You could see things moving, and it allowed LEAP 15 to be developed also in the open,
24:23
which is normal for open to the LEAP, but it was live when we started the beta phase of SLE 15. So, basically in short words, what is the factory first policy? Your submit request will not pass,
24:46
unless a lot of bots run on it and say it can pass. Those bots are legal bots. So, it's going to check against the legal levy if the license is acceptable,
25:00
or if the legal analysis is similar to previous submit requests, which were accepted in the past. Then there is a maintenance bot, which is checking that the package build in the developer project. Funnily enough, we got a mission
25:22
where the package was not even building on the project of the developer. We have the changelog checker. So, on SLE, each submission must have a bug number,
25:42
or a feature number, or a CV number in the changelog. We have the caveat, or the exception is, we also accept if the change has already been accepted on factory. So, this is also to basically,
26:03
we don't want people to create dummy bug number just because they need to submit something on SLE. If the same change has been accepted on factory, then we consider that it's acceptable on SLE regarding changelog.
26:22
So, because otherwise it would force people to create dummy bugs on factory changelog just to get them in SLE, which is kind of stupid. I forgot a bot in this list because we added it recently.
26:43
It's a factory bot, which kind of checks if patches are properly applied, listed, and a few other checks. And another bot was also added. We added tons of bots since last February.
27:02
We also added a repo checker bot, which checks that basically the packages can be installed because finally also we get submission with packages which cannot be installed at all on the distribution. And then there is the leaper bot.
27:23
Ah, the leaper bot. I think a lot of people in SUSE rant about this bot because this bot is checking if a submission done on SLE is following basically factory first policy,
27:41
which means if the packages had been submitted directly from factory, okay, fine, nothing to check, it's okay. And we have a bot which is kind of doing take care of, doing those submission. But if the packages came initially from factory,
28:04
the bot will check if the same change are in factory or if they have been submitted to factory, not yet accepted, but are on the devol project on OBS.
28:20
And if it's not, the submission is rejected. Directly, without human intervention. And sometimes there are some exceptions to that. There are some packages where we'd say, okay, for those packages we are not following factory anymore
28:44
because of choices like, for instance, for the kernel, we don't have the factory kernel, we have a C15 kernel. So there the bot is being, we told the bot, okay, for those, don't check against factory,
29:02
or at least check against factory, but if the same submission is not on factory, don't reject. Just had a comment to say, this submission is not in factory, and that's it.
29:21
What's the outcome of those bots? We discovered that it's good to use bots because, and it's good to automate things because people are much less emotional if their submission is rejected by a bot
29:40
rather than a human. With a human, they will argue. With a bot, some will argue, but a lot will fix their submission immediately. We also have initially the bot for the changelog
30:02
and it's also now in auto reject mode, and it's extremely efficient. When you do your submission, it's rejected in the one minute later by the bot telling you you forgot to put a bug number. You can see there is a new submission
30:21
two minutes later with a bug number. So, I mean, people, of course, they are pissed or frustrated because they got their submission rejected, but they are way, at least that's off impression, they are way less frustrated when it's coming from a bot
30:43
because it's like, yeah, the bot sets a rule. It's a dummy bot. I'm not going to argue with it, with exception. And we also learn that if the bot can be verbose enough to give explanation on why it rejected the thing,
31:01
it helped. People were made aware of why it was rejected because this submission is not identical on the OBS side. There is a diff, click there to see the diff, and then people can see that, oh, yes, sometimes people are spending time to do exactly the same thing
31:24
on the internal build service, on the external build service, basically writing the change log two times, and the submission was rejected because the timestamp was different. There was two, 30 seconds of difference on the timestamps,
31:41
which shows that they did the work twice, which is awful for them because they have the feeling that basically they are doing the work twice, which is true, and it can be automated and there is a bot which is basically telling them, yeah, you don't have to do your work twice.
32:00
So, as much as possible, use bots and automation for reviews. It saves people time because also when things are rejected early, they can be fixed early, and you don't have to wait until a human sees that, oh, your submission is not acceptable
32:22
because you forgot this or this. Of course, it's also good to have a way to override the tool because it's a bot, it's a dummy bot, so sometimes a bot is stupid, so you have a way to tell it no.
32:40
I'm the staging manager, I'm the release manager. You are going to do what I tell you and you are going to accept this submission. We have to make sure that everybody, every contributor has tools at their disposal that can learn and don't do work two times, three times, four times.
33:06
So, as I said, sometimes a bot would say, you should not pass, and we convince him that, yes, the submission will pass.
33:22
So, it's good that we talked about the factory-first policy, but what are its effects on the development? So, this is the number of original packages.
33:43
So, it's not the total number of packages, but the packages which changed in each service pack, since slit-12-service-pack-1, and where those packages were coming from. So, in slit-12-sp1, compared to slit-12,
34:01
we changed around 500 packages. And factory-first was not in place, so every change was considered a fault compared to factory. In slit-12-sp2, it was a refresh release, so we basically changed 1,000 packages
34:21
compared to slit-12-sp1, and all of them were not coming from factory because, again, factory-first was not in place. In sp3, we started to put in place factory-first. Then we had kind of 500 packages changed compared to sp2,
34:48
and 28% were coming from factory, which means that about one third of the contribution of the work done by the SUSE people on sp3
35:04
was pushed to factory, which is not bad. Then came slit-15. So, slit-15, there's a bit more packages changed because everything changed, of course.
35:21
So, it's 3,800 packages. I have the details number after, but on the screen it's better to have a chart. As you can see, the factory part is a bit higher
35:42
compared to sp3. So, the exact number is 8.4% packages are forked, which are different from factory, which means slit-15, when I checked the number last week,
36:05
we are almost done with slit-15 development. 91.6% of the packages, I am speaking in terms of package number, not line of code, but package number, 91.6% of the source packages
36:23
are identical to factory slash Tangleweed. That's not bad. We cannot expect 100%. There are things which are different and on purpose, slit-15 is shipping with kernel 4.12.
36:43
Factory is not. Tangleweed is not. Slit-15 is shipping with glibc, which is a bit older than the glibc in factory, et cetera. So, 100% it's not possible and it's not possible simply because
37:00
Tangleweed is always rolling. Unless something is broken somewhere, so the divergence will always be increasing over time, but when I did the statistics last Thursday, we were at 91.6%.
37:22
This is kind of good for the factory first policy. No leap because we are on open SUSE conference. It's not SUSE conference. It's not SUSECon. So, on leap, I did the same statistics.
37:44
So, leap42.1 is a bit special. It was the first leap release. So, you could see that a few packages were coming from SLE. So, those are the dark green and most of the packages were coming from factory,
38:02
which was kind of expected. Leap was done with a sleek core and a lot of fresh packages on top. Then, 42.2 and 42.3, there is a green, a new flavor green on top.
38:21
You can see it's basically the packages which are reused from the previous leap release. So, there you can see that I think one third of the packages got refreshed. And then the rest was either coming from SLE
38:40
or from a previous leap release. And the 15. So, there is a bit more packages coming from SLE 15. And the rest is factory. When on this slide I say it's factory, it's packages which are not shipped at all on SLE,
39:02
like KDE and tons of other packages, KDE, LXDE, you name it. So, if I would put, maybe I should have done that. Maybe I will improve my graph next time. The SLE section,
39:20
I should have put the factory part of the SLE in it. So, I think we would have seen a very small percent of packages which are SLE specific and majority of packaging coming from factory. So, yeah.
39:41
So, the row number, 11,600 source packages from LeapGM. 25% coming from SLE 15. And on those 25%, 91% coming from factory. And 8,600 packages coming from factory.
40:05
And 20 packages coming from other repo. So, that's it for my talk. But I welcome your question and your feedback
40:21
because as we discovered, nothing is set in stone. We welcome feedback. We try to improve our process. We try to improve our policies. And we want to make things as smooth as possible.
40:42
Questions? Andrew. Behind you. Why are there 20 packages from develop projects? It's mostly KDE, Fing. Because, yeah.
41:01
Dominik? Yeah. So, that's mostly packages that moved ahead in version in factory already before Leap was frozen. SLE didn't have them, but they still needed fixes. So, it's kind of an artifact of, again, factory being so fast
41:21
that those distribution which are slower or more stable than factory. Of course, we have to take some measure to where the packages are coming from. Other questions, comments?
41:42
Yes. One over there. The microphone is coming. Thank you, Wolfgang. I don't have any experience yet with packaging for SLE 15 or Leap 15.
42:01
But in the past when you packaged a new package for then a lot of libraries were missing for SLE. Is this all for SLE 15? We tried to check
42:23
if development projects on OBS were building properly with SLE 15. Not 100% of them are, but thanks to on one side we have package up
42:40
to try to provide additional packages. And we checked that, for instance, LibreOffice on OBS is able to be rebuilt fully on SLE 15, but with only the packages from SLE 15. Same for the GNOME version we ship on SLE. There is a GNOME Stable 3.26 project.
43:02
On the OBS, which have all the packages needed to be rebuilt on SLE 15. So, we cannot put everything, but we try to put as much as possible. And I have time for one more question, but that will be the last. And after the board will kick me out of stage.
43:24
Yes. Might be a dumb question, but I did not correctly understand if this is only for SLE Core, or if this is also for the process for the modules like PHP and so on. So, this is for everything which was submitted
43:43
to the SLE 15 GA project, which included packages like PHP and stuff like that. Thank you. And we try also to have this process in place for maintenance update, because sometimes we have things
44:01
which are being pushed through maintenance update and we want to make sure they are also made available in the factory. And with that, I want to thank you and we are going to get board on stage. Thank you.