Hello and thank you. So my presentation today will be on evolutionary mismatches and the development of cancer. So to understand this we have to first understand the evolutionary theory of cancer development. So I'll be touching on both topics today. So cancer will affect one in three individuals in the United States currently. Cancer is still classified as a disease of the elderly. It affects mainly predominantly people over 50 years of age. However each year those statistics get lower and lower. There's good news though because cancer treatments since 1991 cancer treatments has that's way better. Since 1991 cancer survival rates have increased by 26 percent. What that means is that we have people living longer after cancer treatment. Now that also means that there is individuals surviving that are at risk for development of secondary recurrences of cancers or primary occurrences of new cancers. So we have to look at how can evolutionary theory help influence influence this. And for one prevention prevent the development of cancer. And two you know one of the goals of evolutionary theory is to then turn cancer into a clinical clinically manageable disease preventing it from turning into like a stage three or four cancer. So this quote was by Dr. Mel Greaves. He's one of the pioneers and leaders in the field of the evolutionary theory of cancer. And this quote really inspired this presentation. So any engineer confronted with a recurring fault in a complex machine or plant would look not only at the immediate source and cause of the fault but its system design. It's compromises and limitations. The engineer will resort to a blueprint. We have evolutionary biology and currently that's not being used in cancer research. So to understand the evolutionary theory of cancer we have to understand Darwinian natural selection. So it's been found that we can take evolution population genetics and apply these to the tumor or clonal perforation of cancer cells. So there's some ground rules for Darwinian natural selection. Number one is survival of the fittest. So selection acts on phenotypes not genotypes. Genotypes are genes. Phenotypes are how they are expressed. So the most fit cell or organism will have a higher advanced or higher possibility of passing on its genes. Another tenant is reproduction above all else. So the goal is to reproduce and pass on your genes. That means that our bodies aren't inherently designed for health and longevity. They're designed for reproduction. And that also means that if we have a deleterious mutation that presents itself after we've reproduced there's not a strong selection pressure to get it out of the gene pool. And this also means that what works best today may not work tomorrow. What that means is that fitness is determined by environmental stressors. So if the environment changes what is fit in one environment may not be fit in another environment. And most of the species that were the fittest on the earth over evolution are now extinct. So basically up here we have a progenitor cell. It gives rise to daughter clones. Now these daughter clones due to carcinogens or just intrinsic variability and mutation rates gain genetic mutations. Now these mutations can be deleterious. They can be neutral or they can be positive. Positive mutations increase an organism's fitness and are passed on. Neutral may or may not and negative they're usually culled out of the gene pool. So this can be seen in cancer cell tumor clonal proliferation. The end result of this selection is the hallmarks of cancer. So what are the hallmarks of cancer? These are the phenotypic traits that all cancer cells express. Now different cancer cells have different mutations but due to shared selection pressures they usually come up with this group of things that are inherent to all cancer cells. So they can evade the immune system. They replicate indefinitely. They also have dysregulated cellular energetics which is known as the Warburg effect. So this is something that's common to all cancer cells. So this begs the question. What is acting to select? What is the unit and what is the unit of selection? So it's been found that cancer stem cells are the unit of selection. So cancer stem cells are just like normal stem cells. Like normal stem cells they can give rise to more cells. With cancer stem cells they have unlimited replicative potential but decreased ability to de-differentiate meaning they can really only just become more tumor cells. They also have a long lifespan meaning they have enough time and they survive long enough to gain deleterious mutations which can potentially become cancer. And they're also highly plastic meaning they can take on multiple different phenotypes that can survive in different environments. And then the tumor microenvironment acts as the selecting agent.  So this diagram kind of sums it up. We have cancer stem cells and there's some intrinsic fallibility and chance which goes into genetic mutations. Those are relatively unchangeable but we'll touch on those in a few minutes. Then we have mismatches and lifestyle factors that can go into cause DNA damaging events cause mutations in those cancer stem cells. Darwinian selection takes place and that's where the tumor microenvironment selects for the fittest cells. And this leads to a cancer cell which then can lead to tumor perforation. Now one thing on the side here is time is a very important factor. Time needs to occur for these mutations to happen to form cancer. That's why we see cancer in the elderly and that's why cancer stem cells long longevity is kind of hypothesized that they're the initial progenitor of cancer. So this is a diagram of the tumor microenvironment. It's very complex. It's basically an ecosystem. You can think of the cancer cell as a seed and the tumor microenvironment as a soil. For the seed to grow and flourish it means the appropriate microenvironment. Now tumor microenvironments are usually classified by hypoxia, inflammation and acidosis. And there's a whole network of cells within here that cancer cells can co-op. They grow their own blood vessels. They recruit immune cells. Then you can think of each different area of this as a different niche within a tumor. These different niches can be populated by different tumor cells and those tumor cells can only survive in those niches. So one thing that Daryl Edwards touched on yesterday and I'll talk about today are tumors are heterogeneous masses of cells. Meaning that you may think that tumors are just one population of cells that grow and divide but due to evolution and the selection pressures of the different microenvironments within the tumor they actually have different populations of tumor cells within a single tumor. Now what this means is that I initially said that tumor cells or most tumor cells had all the phenotype, the hallmarks of cancer. What's actually been being found is that a tumor, the sum of the parts actually needs to display the hallmarks of cancer. So that means that different aspects and different tumor populations within a tumor can actually say provide immunosurveillance. It can actually grow blood vessels. And it's been found that heterogeneous tumor like so one of the main, one of the initial areas where this started was glioblastomas and they are one of the most aggressive forms of cancer. They're also one of the most heterogeneous forms of cancer. They have multiple different cell lines in them. So heterogeneity actually increases aggressiveness of tumor types. And these cells we can use ecological theory to model this where they can compete and cooperate with one another for resources and benefit the whole. What that also means is that so when they're competing with one another they can actually more resistant cells can inhibit the growth of more aggressive cells. And these cells may also construct their own niches as I said in the tumor micro environment which they can also, so tumor cells can secrete factors called cytokines which are inflammatory growth signals and they can basically prepare the way for their metastasis. So, you know, with breast cancer it may metastasize the lung, liver, bones or brain. And those cytokines may prepare the way altering the soil for the seed to flourish. And you can think of metastasis as the pinnacle of evolution. So when it comes to tumors and treatment evolutionary mechanics may be responsible for most treatment failures. So in this diagram we see we have a heterogeneous tumor cell population and one therapy may take care of the main tumor block. That's the main goal of therapy currently is to debalk the tumor decreasing the greatest number of cells. So it can get rid of a large number of cells but due to the heterogeneity of the tumor there may be resistant cells in that population. And these resistant cells are usually more aggressive. They can go on to form, you know, a new tumor which is usually more aggressive and more metastatic. And I was going to touch on some theories that could, you know, evolutionary theory could influence and how we could use these to influence cancer treatment. But there's actually going to be a talk on that tomorrow so I recommend everyone here go watch that. But the implications of this is that there may never be a magic bullet. We never may find one therapy to cure cancer based on the evolutionary dynamics of cancer cells and tumors. So this diagram here basically could sum up this entire presentation but basically we have stressors and these stressors are both internal and external. We can think of external stressors as evolutionary mismatches. So stressors act to increase the heterogeneity basically the different tumor cell populations and change the genetics of these tumors. And heterogeneity can work back and increase the stress of a system which basically leads to the clonal selection of cancer cells. And right now research doesn't look at any of this. There's some evolutionary researchers looking at cancer but we basically look at each individual portion of this and try to target therapies towards that. And so the goal of evolutionary mismatches, the goal of evolutionary theory is to decrease system stress to limit the heterogeneity of these cells. So this brings us to mismatches in cancer. So cancer is not a modern disease. So a paper published in June of 2018 found that there's 274 incidents of cancer in the fossil record dating back to up to 2 million years ago. So we know that cancer is not modern but the cancer rates continue to climb in the 20th century. So we have to change something or look at our past to dictate our future because we know that hunter gatherer populations had lower incidences of cancer. The problem when looking at mismatches is that we have qualitative not quantitative information. What that means is we know that something like immunosuppression or inflammation or they can cause cancer but we don't know the dose and duration needed to cause carcinogenesis or progression or anything like that. So we have to turn to evolutionary theory and look at our ancestors to make some assumptions. So as I said, cancer rates have increased. Humans have the highest rate of cancer of primates, Amanda of mammals in general. Wild animals have lower rates of cancer compared to domesticated and lab-bred animals and there's lower cancer rates in hunter gatherer populations. So this graph was looking at the Achi people of Paraguay. Now we see that in here they had long lives. It was documented that they lived into 65 and 70s. They had lower incidence of cancers and they died generally of infections and other diseases of old age. Now they even gave the benefit of the doubt and they looked at the cancer rate and kind of inflated it for potential cancers. And even then they found that the cancer rate was significantly lower than the average rate of cancer in the UK. So basically what it looks like is time allows us to accrue genetic mutations. Mismatches influence the microenvironment selective pressures to select for cancer cells.  And I'm going to touch on these in a few minutes. So these are some common mismatches that we should all really know about but they're not UV exposure and skin cancer. The one thing I want to note is that infections and cancer. Infections were originally the initial mutagen. They found over in the 1800s that infections lead to chronic inflammation which lead to increased cancer rates. So it was the original carcinogen. Now our ancestors had higher rates of infections and infection-related cancers. But a study published a few months ago by Dr. Greaves that I referenced. He looked at infants and we may have seen this paper in this community that he looked at infants with lack of microorganism interactions in their youth and found that they actually had higher levels of ALL and Hodgkin's lymphoma. Meaning that there's definitely a happy medium there where too much immune stimulation in youth lead to things like autoimmune disorder but too little could also predispose us to cancer because there's a training of the immune system that happens at youth. So I was going to talk about movement but Daryl Edwards had a whole presentation on it yesterday and I think he covered the area excellently. So if you haven't watched that presentation, please go do so. So one thing we like in this community is diet. So what happens when we look at diet and cancer? So we can start with macronutrients.  And many of us have probably looked online, looked at websites, blogs, papers, eat this, don't eat this and you can definitely limit cancer growth. But the fact remains that depending where you look and if you want a cherry pick basically every single macronutrient has been linked to cancer. The development of it, the progression of it. So it's really not a clear area of research yet looking at macronutrient ratios. So then we can look at hunter-gatherer populations in their diets and what they ate since they had lower rates of cancer. So compared to our modern ancestor we have increased processed foods, decreased fiber, increased exposure to toxins such as herbicides and pesticides, higher inflammatory rates due to omega-6 to omega-3 ratio. And then one thing is decreased vitamins, minerals and phytonutrients. Many of those phytonutrients have been found to be antioxidants, anticarcinogenics and affect cancer pathways in multiple different ways. And so the fact that those are decreased in our diet isn't a good thing either. One thing to know is that our hunter-gatherers actually, you know, Boyd Eaton and Lauren Crudain found that they actually ate more calories on average than modern humans because they had higher energetic inputs. So then we can look at diet quantity. So when it comes to obesity and cancer, obesity has been linked to 30 to 40% of all cancers. Obesity leads to chronic inflammation, increased circulating hormone levels, it depresses our immune system and, you know, influences our microbiome. So we can look at Japanese versus Okinawans. Japanese generally eat more calories than the Okinawans, and they have higher incidences of cancer. That's obviously correlation. But then we can look at a population like anorexics. Anorexics actually have lower incidences of cancer. Obviously they're, you know, predisposed to a lot more conditions, but it is striking that they do have lower incidences of cancer. So what the research actually looks like by a paper by Hursting's AL showed that caloric restriction is arguably the most potent, broadly acting dietary regimen for suppressing the carcinogenic process. So it looks like caloric restriction. So the mechanisms behind that is adipose tissue is generally very inflamed. That inflammation can cause genetic mutations. Obese individuals have higher circulating hormone levels, such as leptin, adiponectin, IGF1, glucose. All of these are growth-promoting factors for the development of cancer. So caloric restriction actually limits all of those, decreases inflammation. Now from the anorexia study, we know that prolonged caloric restriction leads to negative health outcomes. So that's where something like the fasting-mimicking diet that Dr. Walter Longo is looking at, or intermittent fasting come into play. So then we can look at the microbiota. Out of all primates, we have the least abundance and the least diversity of microorganisms. In the states, we have lower than those in Venezuela and Malawi. There's multiple factors leading to this, such as decreased fiber intake, antibiotic use. But an ultramicrobiota causes local and distal inflammation. So those microbiota-socrating cytokines that can actually cross the intestinal barrier go into the bloodstream, leading to inflammation systemically. They're also directly mutagenic and can lead to multiple forms of cancer and ultramicrobiome. A Western diet actually predisposes, it changes the bacteroides-fermicutes ratio into a more pathogenic kind of phenotype of our own overall microbiome. So then I'm going to take a little side and talk about life history trade-offs. This is a subspecialty of evolutionary theory. And basically, when organisms take in energy, they have to partition that energy into different aspects of fitness. Basically, the main goal is to take that energy and turn it into viable offspring. They need to offset this with things like somatic maintenance, growth, and then, so you can see here, you can either have cancer defense or reproduction. So in stags, larger horn size is correlated with more offspring. However, stags with larger antlers actually have higher rates of cancer. We can actually see this in humans as well, where in males, an average of three to four millimeters increase in leg length. Increases our cancer risk for over 80%. In females, larger breasts are associated with higher rates of breast cancer. And we're the only mammal with protruding breasts outside of lactation, so clearly there's a trade-off between increased fertility and decreased somatic maintenance, allowing cancer to, obviously, we're choosing reproduction over somatic maintenance.  One in eight women will develop cancer. The risk of breast cancer development may be 10 to 100 times higher in industrialized society, Boyd Eaton found. So then we can look at the different aspects that go into play with this, the mismatches, the life history trade-offs. It looks like calories is one of the main factors, so we're going to make the assumption that calories lead to higher circulating estrogen levels, and circulating estrogens increase the risk of developing breast cancer. Basically, since we have abundant resources, we're channeling it in to reproduce. So obesity, children that are obese and increasing obesity rates, are implicated with early menarche.  So between western women and hunter-gatherers in Africa, western women on average have 400 menstrual cycles, whereas hunter-gatherers in Africa have around 100. We can look at the reproductive life history between hunter-gatherers and modern women. There's definite different patterns. So say in China, oh, and then one note of the early menarche, in Chinese populations, average menarche at 13 years old, versus 17 years old increases your breast cancer risk over 80% as well. So when looking at evolution or hunter-gatherer ancestors in tribes, they usually had, and this can be debated by studies, but they usually had menarche around 17, 18, had their first child around then, on average had five children and lactated for three years. So it looks like, and then there was a study in China showing that for every lactation cycle you have, it decreases your risk of developing breast cancer by 11%. So then there's other factors that go into this, hormone replacement theory and birth control pills, obviously increasing your levels of estrogen. Discontinuing those therapies reduces your risk of cancer in usually two to five years. Xenoestrogens in the environment also increase your risk, such as BPA, endocrine disruptors. And then you may think, well, there's obviously some genetic predisposition to cancer. So when looking at the BRCA2 mutation, it's been found that in 1920, women in Iceland with a BRCA2 mutation had an average risk of around 20% of developing breast cancer. Fast forward to 2002, and they had around a 70% risk of developing breast cancer. So there's definitely some environmental factors that go into play. Then looking at males and prostate cancers. So Western nations have a 6 to 10-volt higher incidence of prostate cancers increased, and that's been linked to increased testosterone levels. So we can, and when eastern populations move west, they begin to develop higher rates of prostate cancers.  Well, in east versus west populations, they do have the same rate as ours, but we somehow, you know, the initiation isn't the problem. It's the promotion of the cancer growth. So between cultures, it looks like increased calories lead to higher testosterone levels. Higher testosterone levels, serum testosterone levels, lead to higher rates of prostate cancer. You may say, well, older gentlemen have the highest risk of developing prostate cancer, but they have the lowest circulating testosterone levels, but it looks like from this graph in other studies have shown that there may be a priming effect in youth where high circulating testosterone levels in youth predisposes prostate cancer growth and predisposes you to developing prostate cancer. Within cultures, calorie consumption, increased calories, increased circulating testosterone, increased prostate cancer. Within cultures, we can look since, you know, we're generally even on the caloric consumption, monogamy versus polygamy. Well, the Hadza versus the D'Toga tribe in Africa, the Hadza are monogamous. They pair bond with a female, reproduce, and then their testosterone levels decrease. In polygamy, the D'Toga society, they pair bond with a female, reproduce, and then they're looking for other mates. So their serum testosterone levels never drop and they have higher rates of prostate cancer versus the Hadza. So within cultures, we can look at socioeconomic factors and we can look at the challenge hypothesis showing that competition and challenge actually increase your testosterone levels because it primes you to reproduce, you know, increased testosterone for aggression. So individuals of low socioeconomic status actually have higher circulating testosterone levels and higher incidences of cancer. Then we can look at genetics where repeats in the androgen receptor making, you know, more receptive to androgens actually increase your fertility, but then it increases your risk of developing prostate cancer further. So there's definitely, you know, mismatches playing with some life history stuff, playing with things that we can and cannot change that lead to the development of cancer. So early exposure to adversity can increase the risk of developing cancer later in life. So children exposed to famine, war, the death of a mother, or abuse all have increased rates of cancer development. There's some debate in the literature whether stressors in adult life can lead to the development of cancer, but studies have found that job instability divorced in the death of a spouse can increase your cancer risk by two times. In fact, police officers who work for every 10 years on the force of police officer works, he's at a 67% increased risk of developing prostate cancer. And then when we look at what's the opposite of that, if we look at, so beta blockers, individuals on beta blockers actually have women with breast cancer on beta blockers actually have increased survival time. So there's a blunting of the stress response with beta blockers. And then if you have increased social networks of cancer, you actually have a 40% decrease risk of increased risk of survival and decreased risk of cancer occurrence. Now there's multiple different mechanisms why this happens. Stress inhibits the immune system, increases inflammation, alters the HP axis and changes DNA methylation patterns. This can all influence, once again, the microenvironment putting selection pressure on these cells to then develop into tumors. There's many confounding variables such as stressed individuals are more likely to abuse substances over E, not sleep. So in all of these studies and in all of these mismatches, there's many different factors and none of them are in isolation. So then we can look at something like sleeping cancer. So human sleep has been selected to be shorter in duration but deeper than other primates. But modern day humans has kind of taken that to the end degree and now we get less and less sleep. So women sleeping less than six hours a night have more aggressive forms of breast cancer we know that night shift workers have increased risk of developing cancer. So some mechanisms behind this, T cells actually move to the lymph nodes during sleep developing immunological memory. So we know that exposure to blue light and brightness dimming melatonin production. Melatonin is the sleep hormone but it also has potent anti-cancer mechanisms. So that could be a possible mechanism behind it. It promotes cancer cell death, inhibits apoptosis, inhibits blood vessel growth so it's a broad spectrum acting anti-cancer. So then with environmental carcinogens and cancer I just wanted to touch on this topic briefly in that there's many different carcinogens many of them we don't know what they do. We know with ionized radiation we know with now recently formaldehyde has been shown to be a carcinogen we know with asbestos all of these things are carcinogens and they have multiple different mechanisms such as DNA mutation, increasing inflammation, decreasing the immune system. But one interesting study showed that environmental carcinogens actually decrease the growth rate of normal cells. So what that means is you're decreasing the growth rate of your normal cells. Well, if there's a cell that has a mutation that allows it to survive and thrive in the microenvironment it can then take off and start dividing and that may be a common mechanism behind environmental carcinogens and cancers. So basically this framework here mismatches lead to genetic instability. They directly and indirectly modify the tumor microenvironment promoting cellular heterogeneity. We've already determined that heterogeneity is a bad thing because it can lead to more fit cells that can lead to development of cancer. And the tumor microenvironment can act as a cancer suppressor and a promoter. You can take a cancer cell and put it in a benign tumor microenvironment and it won't form a cancer. So all these factors go into modifying the microenvironment that lead to selecting for more aggressive cells. So this is Rudolf Virchow. He is the father of modern pathology. He was the first person to discover that chronic inflammation can lead to the development of cancer. And over 100 years ago he said, indeed a great deal of industrious work is being done and the microscope is extensively used, but someone should have another bright idea. And that bright idea I believe is using evolutionary theory of anti-cancer drug development and things like that and guide our lives on how we prevent cancer as well. So prevention is still the best cure. So avoiding mismatches, making those small adjustments in your life can really add up. But due to obviously trade-offs and inherent genetic instability, there's always going to be the risk of developing cancer. Standard of care is still the gold standard, but before during an after treatment there's a lot that can be done to kind of move the needle in your direction. So this is the prescription. And overall, as I said before, reduced systemic stress is the main thing. If you reduce systemic stress you can reduce that heterogeneity. Questions? They don't really look at those studies, but it's looking at, you could look at say like a Caucasian population that lives in the east. They generally have the lower risk of cancer development. Any other questions? Oh, go. Okay, so you mentioned informally to me that breastfeeding your children does have maybe some protective effects. Can you elaborate on that at all? Yeah, so that was the study showing that between modern humans and traditional humans we generally have more men's C cycles. We have less children. And so the increase it's not necessarily the breastfeeding although there's probably some mechanisms there that reduce the risk. But it's the circulating hormones, breastfeeding. When you're breastfeeding you have increased levels of prolactin. Prolactin decreases the production of estrogens in the body. So generally when women are breastfeeding they're in a lower estrogenic state. So that's, you know, I'm not going to say 100%, but that's most likely the mechanism behind that. Okay, quick question. Great presentation by the way. I want to know you were talking about breast size increases risk for cancer. Would that, would either reduction in breast size or even augmentation cause any risks as well? Or would that play into it? I haven't looked at the data on that so I can't speak to that. But if we were to kind of hypothesize I believe just the larger breast means breast tissue just like with the aging theory of this presentation you have more time to develop genetic mutations as you age. With larger breasts you have more breast tissue for genetic mutations to accrue. That would probably be the mechanism behind it. So if we were to hypothesize would, you know, decreasing breast size, decrease the risk of cancer I think the only comparative studies we could look at were women who then decided with, you know, BRCA one or two mutation who decide to undergo a bilateral mastectomy because then they have no breast tissue and they do have reduced risk of cancer development. But, I mean on the positive side the presentation shows that although there's always going to be some genetic factors in there a lot we can reduce that risk exponentially with lifestyle factors. One more quick question. What can you talk, can you speak to HRT therapies with regard to cancers as well and the increase or even decreased risk for those? That's definitely a touchy subject with a lot of people and I mean there's definitely ah so HRT the study I looked at and some studies showed that it looked like estrogen plus progesterone therapy increased the risk of developing breast cancer while estrogen therapy alone didn't but I'm not, I don't do hormone replacement therapy. Dr. Ruiz Duaz and he would know a little better than me but there's definitely an increased risk when using HRT and I think a position paper came out last year what was it where they recommended it was the National Endocrinology Association that recommended that for women going through menopause who wants to do HRT they recommended to do HRT for the shortest amount of time possible with the most minimal dose so just like the recommendations there it looks like we probably want to mimic ancestral hormone levels and not go, I know a lot of we don't want to go super physiological in any of these things and we definitely want to if you're undergoing HRT get your hormone levels checked pretty regularly so can I just I would honestly need to do a deep dive into the research on that it's very conflicted there is not a consensus on this issue and that's it's complicated there's probably many modifiable risk factors that go into that nothing, especially the human physiology, we're not in an enclosed system so looking at these women, were they inflamed what were their diets like were they already predisposed to developing this and then you kind of just they had like I put in the prostate cancer slide, we had the initiation process which we all do I will add that we all at some point have cancer cells in our body so what is it that inhibits those cancer cells from growing and just like with HRT and breast tissue there might be an initiation there but HRT may promote the growth of it I just wanted to a quick remark about the number of children in ancestral populations, there's a lot of variation about that and actually some of the stuff I've been looking at with early modern societies so 16th to the beginning of the 19th century women were typically having about 10 children so I don't know it means you're rarely not that doesn't account but I wanted to know about those the fossil record cancers, are we talking about actual tissue samples or is it just DNA so the problem there's 274 documented cases, the problem with this is that 2 million years tissue doesn't survive so most cancers that form in individuals are epithelial based cancers, within 2 million years that tissue is gone so you would be looking at things like bone metastasis they're looking at so there's 274 documented cases of advanced cancers but that really doesn't negate the fact that there's probably much many more cases of cancers that affected individuals and then they passed away and then that tissue degraded it is a hard but we do know that there was cancer and basically as soon as we hit from unicellular organisms to multicellular organisms the genetic programs were in place for cancer cell development because basically it's looking at ecological and evolutionary theory it's going to promote cheaters and cheaters sometimes thrive in environments


Hello, welcome to the Jenkins governance meeting today is May 5th and we have multiple participants on the call So we are doing the regular session. We've got a lot of items to discuss today Gavin will be taking the meeting notes. Thanks a lot to him for the previous meeting the meeting notes were maybe three times larger than before and Yeah Everyone else is also encouraged to contribute because his document is shared for editing Okay, let's start from use the first big news, which of course we missed is five years since Jenkins to the zero So it happened on April 20 2016 So well Just congrats We didn't do much celebration around that there is still an opportunity to do that someone is willing to take the section item But yeah Just for your information Thank us to the zero was nice. We introduced pipeline by default. We did plug in unbounding. We also Quite a lot of changes here and there and removed agents from the terminology. So yeah There are some things Sorry, we removed slaves from the terminology. So definitely something to celebrate Yeah So if anyone wants to take an action item under it, please do so Otherwise, it will be probably just a tweet Okay Nothing news. You've got two dot two seventy seven dot four release. It was just a few hours ago. Mark. Would you like to summarize it? Released had some infrastructure surprises delighted has a relatively few back ports We'll be discussing I'll be discussing with Darren Pope in a live stream later this week as well So basically everything is already available for downloads, right? It is confirmed available We will upgrade ci dot Jenkins that I owe later later today as it gets a little less busy Yeah, and it's not a security release. So basically if you're affected By the issues and if you want to get a back port just update when you're ready Okay, then she could Africa's summary maybe for you again mark Yeah, so five Five women from Africa were part of a large contingent of people who applied for the opportunity to spend one month Contributing to open source software Jenkins and two other projects were the mentoring organizations five mentors from Jenkins Assisted as these this group of five women contributed pipeline help examples pipeline documentation Project was a great success Plenty of things that we learned from it retrospective will likely happen this Friday with with them we've got a good retrospective document already assembled and We'll gather a little further and then do one final meeting to be sure we capture the things we learned so that we know How to do this better the next time? Is there going to be any Is it I don't know how to ask a question Is the is the retrospective plan to be like are you putting to take your learnings from retrospective and share it to the wider audience? Or is it going to be limited to this event and how are you going to do it? So I'll I intend to do a blog post to Jenkins that I owe highlighting it I'll I'll probably include notes from the retrospective in that blog post the the The participants were also willing to assist in a talk at DevOps world So I'm going to propose a talk at DevOps world for it. We'll do some other things like that I think Oleg had also suggested an online meet-up and again, I think that's a great idea That we should consider as ways to highlight. Hey, it's it's possible to come into the Jenkins project Contribute significantly Even if you have no prior Java experience in less than 30 days, we got these people Ramped up Compiling plug-ins loading those plug-ins working with them. It was it was a good experience I think now lots of lots of things we learned and we'll do better next time It's in it's in the same document it's in the retrospective section there page 14 and beyond So I will just say that So again, eventually the document will be referenced Somewhere from james say, you know, maybe Because here Yeah, that document actually already that the top level of that document is already referenced from jankens.io But we'll we'll do a summary of the retrospective. I think it would be a good part of the blog post Yep, that's for sure. We'll do the same for jsoc Mm-hmm Okay, anything else on chicota africa Then thanks a lot to mark christian angelic and mac mark roberts for running this event and for mentoring there We hope it was a great experience for everyone Of course, thanks for the to the mentees Yeah, thanks to all mentors and august mentees Okay, moving on devops world call for papers So firstly it happens. It was announced. The deadline is May 20. So you have just two weeks left um yesterday together with at least we did a janky's online meetup about the community agenda So at this meetup you basically spend some time to provide a review of what we are doing as janky's community at devops world And also there was a discussion of what to do as a part of CFP. So the recording is already published same for the slides. So we can take a look and yeah If you just want to feel some nostalgia, definitely go to this presentation because I put a few photos there But yeah, so it's a rather overview. So the presentation was relatively short see Sorry, was this was the presentation of that was given at the meetup or is this a presentation for people? Yeah at the meetup. So basically we did it together with Alisa We will be doing another session next week for a park time zone together. We sorry kind of maybe victor martinez But yeah, so yeah, here you can see mark Evelina There was also ulya somewhere Yeah, here's ulya Yep, so nice times. Hopefully you'll be able to repeat it some time MC another for He said another one might be next week for the apoc Hang on So basically we just wanted to provide some overview provide some concepts Because yeah, again devops world is more than just a conference for us We also plan to have contributor summit and other things Many things actually tbd But yeah, hopefully they will be confirmed Just a second Yeah, so what we have confirmed by the moment we will have two community workshops One is about contributing to Jenkins another is likely about Jenkins pipelines Um tbd then there will be community track also There will be continuous delivery foundation track, which will also include some talks about Jenkins Practition your track may include them as well Then community can notice to be decided most likely it will be by the continuous delivery foundation But if you have major funds for shares the Jenkins project welcome Then they will be asked the experts and hopefully contributors summit All to be confirmed and we are not doing Jenkins awards so this time because Jenkins awards will happen at cd con A gentle reminder to everyone We still have some time to submit donations. So it's open until may 14th It might be worth for the keynote to have I know it's a later topic but plug-in deprecation Policy should be a good one to announce there Not sure but it's definitely something to be discussed so Again, I I don't know how much time we would get what would be the scope There were discussions about Jenkins 3 or something like that if we do Jenkins 3 announcement We can just match the plug-in the replication under that But in the current state it feels unlikely that we will be able to announce it in autumn Even if everything goes well Because yeah, the match window will be mid to july. It's just two months from now Yeah, I'm still not allowed to go to the community this full my proposal Okay, so Yeah, anyway There are three limitations for this project Or a quick question regarding the keynote aren't key notes usually good news How would you mean that you think that the plug-in deprecation policy is positive for any users? It's not like we're doing It's not like we're improving the situation there. We're just making it easier for us to make changes but The obvious side effect is that all of those terrible long tail plugins that haven't been updated in years will stop working Rather than limping along as they do today So that really doesn't feel like and Let's get up on stage and proudly big Proclaim that we're breaking everyone's Jenkins kind of topic. I think we're holding a bit here so Yeah, I think you're right, but it's something to be discussed and Yeah, I think there's a positive way to phrase it as long as indeed we can show that we have done other things and saying this is a way for us to Focus our energy on what he's actually, you know Making Jenkins go, you know Forward rather than focusing on making nine years old plugins that nobody really uses like 60 times or something installed more wild to keep to keep those ones working. I think people would prefer the community to work on Making I don't know pipeline shine even more or something We're already not keeping them running As evidenced by tables to divs. So I really oh well, we have a lot of topics. So Let's discuss. Yeah, it's just a two more one because right now we don't even have consensus of what we do Not everywhere But yeah, let's see So what else? Again, the nations. I just put the link What is important topic there that there are only three limitations listed in our blog post But there are the limitations where Jenkins contributors may be potentially eligible. So there are also Global cdf limitations like top cdf ambassador top cdf contributor github's evangelist We I guess we already have Jenkins contributors in all categories But if you think about someone just put them here and there will also Two new awards just announced the last week. It's top cdf and user and Top github's and user So basically it would be just a company or from other user. Let's say one of the Jenkins projects That's for example And again, if you have A company which would be big highlight think about that Maybe it's also an opportunity to meet someone moving on Yeah, so just a quick update Just a few hours ago. We've got information about number of slots we get So announcement that yeah, we will have Jenkins projects this year And the number of projects is to be announced and the projects are also to be announced The announcement will happen on May 17th. So it's two weeks from now But yeah, I think you will like the announced projects Yeah, basically, let's say about jsoc. We're still in the Dark mode until the projects are announced You wanted to ask something I was just going to note that we are in dark mode. So no comment should be made by us, right because That's google's thing to announce not ours, right? Oh, like that's the the way it is. It's We will do an announcement as well, but firstly it should be official on the google side Because firstly decisions may change. Some students may appear to be not eligible. There might be other organizations reaching out and discussing Uh duplications, so we are not ready to do announcements by now because it may change Yeah, so who yeah, some people on this call are in the mentor channel. So you will be able to see the summary by the end of the day Okay So moving on Confirm grace they have talked project representative so For those who are not following this threat They can easily definition announced elections for the talk members They were there were changes Because this year they will be actually electing for representatives amongst six projects But the each of six projects I expected to make an elimination And what it means that we as a jinx project should also nominate someone And the deadline is May 14th. So we still have some time But this is the last governance meeting before the elimination happens So unless we change the process we should sign off some The elimination today though if Anyone wants we can extend it, but we will need to agree what would be the process after that And yeah currently basically it's only me nominated if someone Wants to eliminate themselves or eliminate someone it's a great time to speak up I'm not getting out of this I don't see any reason to extend it Yeah, full support from me for you being the nominee. Oh, like thank you for being willing Yes, thank you Thank you Yeah, I was I was showing a thumbs up, but then I realized that probably you have the browser full screen or something So I have several faces, but uh, you want to on the screen at this time? Yep, you have too many people this week No, I'm happy I'm happy with you being our candidate definitely Okay, then I think it's confirmed Thanks, everyone They will be still elections ahead. I have no idea how these elections will happen But you will figure out as we go And yeah other projects also are for election. So Jenkins x will be like making the elimination same particular tone Same for spinnaker and now the results to driver are still yours. So they will also make nominations Okay So anything else on the f-talk representative And the topic from but he's about removing common register from the core Yep so For anybody who didn't have the time to read the developer need the developers many least I sent and heads up there to About this removal. So we are working to update Jenkins. So In short, you may have seen or you may be aware that Jenkins has a common register 2.1 in its dependency tree, which is the dependency that was released in 2010 So it's even older than guava. So after many discussions with various people in Including especially in that thread. We got feedback from some people I think jc mostly said something like digester is not even fixable really. We should just get rid of it So instead of trying to you know, date it to commons digester 3, which anyways has a different fqn We decided to just remove it all together But then it would have the second step would be to it was to decide, you know, whether we would create a depth plugin and then again, I think What we've done is partly based on the feedback of JC's one, which I remember I think team said something similar that, you know We should be creating a detached plugin unless we can fix the ecosystem, which is what we're doing So we pursue just the latter because, you know, also we don't think When I say we it's it's I I'm trying to speak for the Jenkins project, but obviously that's more my opinion at this point um That removing it is a is a more The cleaner thing to do obviously this has the big and obvious caveat that I think Danielle pointed out On the pr itself at some point before we we fixed a more few more things and on the the thread on the dev list So We filed a pr for every single plugin we could find was using it, but Many many plugins have been abandoned for years. So I guess we have to decide as a community whether we You know release those old things that that are not even installed a lot of times in the world Maybe sending an ambiguous You know message to the world that those plugins are maintained somehow, which they are not really Or we have to accept that this is uh one of the One of the first or at least one occurrence of 15 years That that was you know posted a Jenkins i website already almost three years ago about the fact that you know To move the the Jenkins project forward. We need to break a few things Again, we filed a pr for everything that is impacted, but again, I don't think Money of those will just find somebody willing to just you know Own this maintain it merge it release it basically Um, so I got two questions. Um one There's probably a lot of people like me that have no idea what this does and why we want to keep it versus why we want to remove it Um, yeah, actually it's just the one question. So what does it do? Digester is a library for parsing xml at least. Uh, I I think it's only what it does um The the big thing is that even if some people could be still using the library per se Uh, it has wrong defaults. I would say I'm just repeating my understanding, especially from people like daniel Who uh insisted that you know, we make sure that the the the way that your series is Insuntiated is using the the the non default settings to be secure And uh, I think just he said something like on this on the pr that you know, there's no way No easy way to make this secure really, uh, and more importantly the the the fully qualified package names Of this library anyways changed between the the version that we're removing in the the version three So effectively upgrading would mean anyways upgrading the ecosystem like we're doing So, you know, it's that's why removing it from the core because again It's a library from 2010, which is the fact to you know, not a great thing in in 2020 21 11 years old library, uh, which is stuffed with with um, non cv is most if not all of them are um Unreachable normally, but could could be someday or uh, basically also making the security posture of Jenkins in the world Not great. Uh, when companies basically scan, uh Jenkins they find a lot of things that you know make them Uh, again, in my opinion in 2021 more and more complex more and more Tricky that the security teams accept this this tool, uh, you know in their toolbox, you know so looking at a leg screen share when you created the prs for other projects did you just, um Looks like you upgraded to digest your three were possible and then We're your plan was to remove it from core entirely Yep, this is what you're seeing right now. Uh, so not not right now. Sorry. This is Emma This is basically one of the plugins that we think we'll we'll never get a release Uh, if if you go back a leg or another tab or something to original pr Uh, you will see that I've I've created To this this table here that's basically pointing to everything that's impacted and when I put on the left side Uh, uh, red red circle. It's basically when when I really believe that we won't see anybody releasing and fixing this So those plugins are de facto, uh, going to be broken from now on um And and and if you look at the diff you will see that on this pr indeed we are removing altogether The digester library from the dependency tree not just upgrading either something Yeah, okay Of course mentioning that when we do such changes, there is always a risk that there would be third party plugins example, uh, there are vendors who provided their plugins outside of the main repository or Let's say sonar We do not scan and analyze these plugins by default And also there are zillions of proprietary plugins developed by companies just for their own use So there is a risk that something else will be broken from Sure, I mean, this is always, you know pros and cons, you know, um For what about what you just said though for open source plugins We didn't do just a scan using the search feature. We also used usages in plugin feature tool that that's if if uh, people here don't know all about this one Basically is a tool that is going to retrieve all hpis from all every every single Jenkins plugins in the ecosystem and scan the bytecode to see where whether there is a usage of a given Class in that And so we did that on on orgs org Apache commerce digester digester the class The one from Jenkins score itself and daniel I think was nice enough to to to to catch our One of the mistakes we did and to scan for the whole All classes from digester basically and this showed as far as I understood what daniel wrote like in the last comments or something on this of this very pr not not Additional hits in terms of findings. So the list at the top of this pr should be still accurate It is deemed to fix the whole ecosystem provided again, which is Not going to happen as far as I think Provided we would murder release every single pr that we have filed Yeah, but we still have an alternative because even if you don't ship it as a detached plugin You can ship it as just the api plugin users can install on demand So we can say that if you have one of these plugins Available without a fix you just install this additional plugin and everything starts working It was that the api plugin wouldn't be on the class path of this plugin Yeah, we can do is detaching and not bundling it Which is an option, but apparently jesse somewhere said that this isn't great I'm to be honest. I'm a bit confused by the approach chosen here because what is this you said, um We had the option going for a detached plugin or fixing up at the ecosystem and you said, yeah Let's fix up the ecosystem and immediately afterwards. You said, oh, look at all of these plugins. We cannot fix Isn't that Yeah, that's what you're saying. So what I mean is that we do I think the diligence to file, you know, every single pr But then I'm saying I don't think as a Jenkins as a project as an open source community We should be you know releasing. I mean understand. Okay, right. It's a bit confusing or ambiguous Um, I'm saying we yeah, we I mean, yeah, we filed a pr that would fix every single plugin that is impacted, but we I mean our personally at least I'm not very eager on getting and becoming a maintainer on on The SS GeneXus Java test report blames the version I think those plugins are not used enough to be to mandating to be mandating that basically. So yes We have done To show that we we value that but on the other hand, I think it's it's an example of shifting gears and yes accepting that breaking some things is A choice that we can do I think we could do we maybe should do Just to move forward and keep things simple basically Yeah, I guess we would need a job anyway taking the conversation on the mailing list Maybe before the job is filed. It makes sense to build the consensus of What pass we choose? Because if Daniel has a reservations about the chosen approach, maybe we need to resolve it before we spend time on jabs Yeah, I mean, so Daniel pointed rightfully on the compatibility matters of the Governors document, but indeed as was pointed out by Liam Maybe you you can open this one if you know what I mean Oleg, but so that just people don't not not as knowledgeable about that Can see Watching this record as a recording later Could see what we talked about but this this phrasing also talks about being very careful. I think we are very careful here You know this phrasing doesn't mean that we don't break anything I think it's it's we know that as professional in software that breaking nothing ever is also something to keep you, you know Is an impediment to to to innovate and to move forward sometimes This might be a good reason and kind of Catalyst and candidate for a jankin 3.0, right? This is something that will break It's a major version a lot of people complain that we release Non-major versions that are breaking changes even though our definition of breaking is different So that would be a good excuse and something and we're like, okay We've released a new we've changed the behavior Some plugins are gonna break that's 3.0 Yeah, and we just start collecting a bunch of these changes that we want to do for 3.0 release Yeah, but I mean I I like the Rational the only big caveat that I see with that rationale is that then Do you bump the major version each time you have something like this and because I know for instance guava is coming we are working on guava too and so But we bump to four then when we reach guava stage and so on, you know I I'm honestly okay with that as well, but I mean there's no reason we can't you can't wait to merge this for guava as well Right that both of those could be a 3.0 release Yeah, guava is going to take more time. There are 300 plugins inspected as far as our analysis is only But I mean chrome is now on 87 or a 99 or something like that like they're releasing major versions all the time And that's totally fine as well Yeah Changing the version in schema is was one Proposals for jinkers 3 So as long as I'm clear to publish my proposal. Hello mark. I will be happy to do that I think as long as we're clear with users. I don't think I think to dino's point and to your point Breaking something is not Something we want to do often, but it's not a problem to do as long as we're good at communicating it I'm not necessarily sure we're good at communicating it and a major version would be a Key to users that there will be something breaking We've never had somewhere so starting now seems kind of weird plus If we if we go the route and I and I hope we continue Don't get me wrong I think it's it's good that we look at all of those outdated dependencies. I mean extreme spring security Was a great step forward That might have made the 3.0 Or perhaps tables to diffs would have been the 3.0 and we would now be at 4 point something because both of them would deserve a major version bum but we've never had somewhere and If we start now, we really should Apply it in the way it is intended And I mean only is on the call and warnings and g is that major version 9 or something By now And he's really doing it and he got there in less than a year. So look forward to Jenkins 20 Next year or something and at that point we can go the browser route and say Everything's a major version or just you know ubuntu. This was released in 2021. So that's the version number we're using for it Yeah, but you know so that if we do that, there will be You know what i'm going to call a major version fatigue That people will start caring that is a major version update and just or maybe not update anymore and move away from Jenkins You know, uh, if if we if we make this like looking like we're going to break everything each time Which is not the case here, you know, there's definitely a balancer, right? Yeah Because you don't want to do a new major version each week. Otherwise, that doesn't mean it's a major version But if you never do a major version then people complain that the weekly is different than the previous So you got to find a way down and I don't have an answer right now So homo has strong opinions. You're welcome to start a discussion on the developer melon priest For this particular topic. I think that we are definitely not ready to vote for the pass So I suggest we continue the discussion and the developer melon priest You know, you know, I mean If I were going to create a jet anyways, but you know If if we think that is going to be a compromise to create a Detached plugin why I mean, I don't really I'm not going to to to fight for it I don't want to have on that on this hill I'm just thinking that it's time to kind of bite the bullet I would say if you look at the numbers those plugins are installed like the biggest one is installed Not even 500 times my my personal plugin. That's a very very small one is installed 4k times Most of the spriggy's are installed like 60 times or 100 times 160 times in the world So I'm like, yeah it's not Probably most of those instances are just having those plugins installed and they forgot about them I mean Emma seems 3.2 clover 2.8 Am I stat since 10 years? I'm wonder if someone's really use my tool or my format Because this plugin publishes a report in a particular format That means that you have to use Emma tool for that I mean, I mean, I think I think we can move on But is that thing correct me if I'm wrong? There will be a jab And I think the key part of that jab should be Explaining Which of the alternatives was chosen and why because I see Sure ones and the detached plugin perhaps even without bundling If we want to get rid of the dependent of the plugin as part of the what we deliver sort of Taking basal's approach and just you know accelerating it by a few years might actually be viable alternative And if not, if you think that's not a good Good solution, I would just like to know why Sure, we'll create a jab. Definitely. I think it makes sense to get aside the process and so on I'm fine for everybody attending here or people watching this recording later I encourage you to you know, watch the list of plugins that are remarked theme that's to be Broke a breaking when this is released and and voice your opinion if you think that none of these plugins make sense anymore Like like we were saying about Emma typically I'm interested. We are interested to hear your opinion and yeah, there will be a jab. Thank you very much Thank you John Okay, then moving on So for This might be another one where you might want to email the User's list and be like we're potentially doing a breaking change through these plugins Don't say it's a core change, but the plugins work to see how many active users there are as opposed to just people who's installed them Good point I mean maybe I could still point to the core pr, but yeah Yeah, sure. I can do that Thank you So technically it's possible to do some things like that is the telemetry engine in Jenkins But yeah, it would record Yeah, same thing to ask again. What? So there is jump to 15 if I recall correctly then Of the analytics Yeah So technically it would be possible to collect metrics like that from the Jenkins side I know not to 14 But yeah, it would require change in the weekly release So you wouldn't get information from LCS and I guess that the majority of such Less adopted plugins are rather on LCS versions Yeah, suspect also that, you know, this thing will never be really used because it would mean that we wait for some time No to percolate through the versions and I guess many many people are using the null version of Jenkins using a low version of plugins That actually would never see just such a Change in the core itself So we can telemetry we've previously backported into LTS because of the timing aspect to it So we could do that here I think I think we even backported broken stuff. Um, so I would recommend you write better code than me um, and in terms of Understanding the version Combinations that users of these plugins are using we have the usage statistics Um Site that has a matrix of core versions and plug-in versions Yeah For example, if the pattern is that everyone on Emma plug-in Is still on Jenkins 1.x that would tell us that they are and we can say well, they're never going to update anyway So we can stop caring about this particular plug-in Okay Yes, now you can move on. Sorry, Oleg Yeah, no worries. So the next topic for us is terminology So for terminology, we regard this topic. There is a threat where we are trying to agree at least on some terms and Yes, they made a call for terms where we seem to have a consensus So, yeah, basically These are the terms are listed here and I am going to exclude a few terms right now Uh, what did they do? You're fine Oh, yeah Uh, yeah, so here for example, um, yeah, what we have Um right now. So master node built-in node master label master branch agent to master security Jenkins master container Um, so for port It doesn't seem that we have a consensus right now because there is still an ongoing discussion of how we should call it whether it should be a broader port causes conflicts in Kubernetes terminology So I guess this topic I will exclude from the list for now We need to keep discussing that and civilization White list Will be now civilization allow list. It's for JEP 200 because it's also quite deeply integrated into our documentation and the core code base so this is these are the terms I would suggest to vote on Unless there are concerns about any of this term and we need to keep discussing them I mean, I already mentioned on the main list. I'm happy with the list Especially now that it's switched from allow to sorry permit to allow Yes Likewise for me. I think the list looks good. Do we expect potential Readability issues with English as a second language with built-in Now it's quite a common word Well, so so is there would there be an objection to hyphenating it? I think built-in Was that hyphenated labels? Oh weird. I think oh they are. Okay. So that's All right, then then I retract. Thank you. Daniel wasn't aware I think you may even be a Grammatical non-determinism in the antler Yeah, for this oh Oh, then absolutely retract. Thank you I don't know whether a hyphen is enough to get there. I don't think so, but it should be just alphanumeric Okay, so we are talking about this built-in or about this or both Well, the label is second Yeah, the label And I guess an underscore would work, but it would be a bit uglier event. Yes I mean a self would be an option, but I still like built-in better Yeah built-in built-in gives the right message and I think we should accept Yes, English is a second language may wrestle with it for a while Okay, then that's fine with me. It's just something looking at the term It looks like tin the metal So so I generally a plus one from me too, but I like yeah, this this label Looks weird and so I'm sorry.  The label is used in logical expressions and I think the parser that we have for those May have problems with certain Special characters And I've also in the past trouble with the auto completion Code for labels now. Obviously all of that is something That we can probably work on but it would Increase the scope there a bit Okay, there are some merits because if we make using controller label as difficult as possible those people will use it but Yes, we can seriously That's actually a good point Well, and I can confirm that I do use labels with hyphens in them all over my installation um, I haven't detected any problems yet with free bsd-12 or AMD 64 dash free bsd that are provided by the platform labor look plug-in. So But I mean, I think maybe that's what I'm not sure that's what you meant Oleg, but you nailed it We don't want people to use built-in label anyways You should have for majority of cases They explicitly want that so we cannot delete this feature Yeah To delete support for master due to compatibility Uh, but yeah using Hipfam is not a problem for me Yeah, that's actually a good point. I mean one of the suggestions that we discussed for for the replacement term might have been marks was um Reserved to indicate Do not use this do not build here um, and we recently also added a more visible warning message to the jinkans ui A few weeks ago that basically said do not configure jinkans to run builds on the built-in node so, um I I would like to retract my Concern here So we take built-in. We say hyphen because nobody wants to consider this option, right? also found about that I depends what label I think the series hyphens I think if it's messy, it's fine because a we're not recommending people do it and b It's pretty easy to type it sticks with the convention lowercase and like labels So I I mean I can see why built-in is looking like built-in but I I think for a label that we don't encourage. I think it's fine and it's Yeah, or that So to clarify you're saying no hyphen I hate punctuation. I never use it. So Yeah Okay, and I'm I'm still the other direction. I think the hyphen would be a real help. So We have no ejections hyphen. So I think we can On top of that, you know, we're talking about jinking itself, but you know now we have I mean yamal Configuration as code things everywhere movie scripts and sometimes things like these Yeah, uh, it might be weird or or broken somewhere. We were talking about compatibility a few minutes ago, right? So So my suggestion for a response here would be that we agree on built-in note and the built-in label And we will attempt to hyphenate it unless we discover specific real and not trivially addressed technical problems with that In that case, we fall back to not having a hyphen in the label Yeah, I'm uh, so so two comments When you put a hyphen in there, then it doesn't look weird anymore. So we can get rid of that But I do use hyphens in my Labels too. So Honestly, there's no reason we couldn't support both and just document one Actually Well, we're gonna have to support master anyway Actually, we don't if you look at my poll request as I suggested on the dev list You will see there is migration code an administrator who's updating from earlier versions of Jenkins Needs to click a shiny button to switch from master to built-in And only folks who start Jenkins for the first time in whatever release of Jenkins includes this change Will have the built-in label by default. But what about any Pipelines that use node master Well, you can explicitly configure additional labels if you need that to work But there can only be one what is called internally a self label. It is kind of a light label That usually corresponds to the node name except for the built-in node where it is currently master and Would be something else in the future Okay, then I retract. I'm good with built with the dash So too long didn't reach me to meet an upgrade guide for that It should be automatic. But yes I mean the thing is if you upgrade Jenkins nothing will change except there will be an admin monitor that says Click here to get the new behavior with a link to documentation We already agreed that the configuration of Scotios cases might be affected and configuration of Scotios cases become default ones In 2021 So I think that upgrade guide will be necessary And probably most of the people who are using that node label are not the ones that are upgrading anytime soon So it's good to have the docs Okay, so Uh Yeah, one of the options we can still Continue discussion for this term. So basically the only consequence that we are working Daniel for another For some time until we build the consensus But yeah I'm happy specifically So there is comment from Baptiste in the chat that uh, he prefers self. I know I think we were joking around Okay Yeah, I I feel like this this dash is my first contribution to the the jenkins governance board meeting So we we have to keep it at least for until another meeting. Yeah I mean as much as I do like self. I think built-in is way clearer So Okay, so yeah anything to discuss on terminology Because yeah, we have one important topic I would like to close Uh today So so we have closure already on the all the other topics on terminology. We're we're settled, right? Yeah, that's what I'm asking Okay, so yeah next question is about jenkins About securing delivery pipelines for jenkins So one of follow-ups we discussed at the governance meeting that we would like to adopt security tools And one of the tools we had in the list was lfx security, which is basically a source version of sneak provided by the linux foundation And yeah after the contributor summit, I started this exploring it. Basically, we already have a profile Well, it doesn't quite work because we discussed one of the previous board meetings because Yeah, because of too many dependency issues and the sneak is not good at passing How our dependency trees work because well none of the existing tools Have any idea about how dependency management works. So we end up with something like two hundred seven issues mostly false positives And yeah as a follow-up I reached out to our fact security team asked whether we could Basically fix it somehow in a way which would be scalable for the jenkins project. The answer is no Then we agreed to talk to sneak directly. We started the conversation with sneak And as a part of this conversation we discovered that there is a new lfx security to do zero under works And basically in this version they intend to provide administrative console for users As well as apis including configuration management apis and apis for triggering scans So all the things you get in classic sneak which would allow us to submit ignore lists for cvs. We don't like to see And yeah, basically they invited us to participate in the discovery project And I asked for formal permission to accept this invitation So what it means for us and yeah, basically we agreed to participate No commitment, but yeah once there is a pilot version ready. We invited to try it out And adopt if the project is successful. We would make a joint announcement together with sneak and the Linux foundation And the jinx will be basically listed as one of the first projects adopting lfx security tool with Maybe some testimonials to testimonials, etc. Like it usually happens And what we get out of that we would get direct support from sneak and lfx security while adopting that Because most likely in the pilot we will experience some issues So we provide feedback and we get help and hopefully with this mode we will be able to roll out support for sneak soon So currently we have All of you are interested in the security organization There are also some clarification questions from Daniel Well, I guess Daniel is interested as a security officer that is being informed about this project And yeah, my question is whether we want to accept it As a project for the jinkers Yes Definitely, I really see no downside here Worst case we try it and cannot get it to work the way we need and best case we have We have a dependency scanner that actually works for the crazy ways in which we Use maven and Has useful results And since it has an api, I think I watched the the recording That might actually be interesting Uh, if we if we would consider exposing this showing you as a say by the way, um There's a bunch of old stuff in this plugin. You may not want to install anymore Which sort of feeds into this plug-in deprecation topic as well Now, obviously this isn't quite as straightforward. Um, but I see I really see no downside here. So plus one Yeah, any objections? That's one for me. That's one for me as well Yeah, and Another topic we are looking for maintainers who are interested to participate in the pilot pilot program So the idea that we would start from a limited number of repositories like the jinkers core some libraries and some plugins And we would be rolling out LFX security for the entire organization only after that If someone is interested, please comment in the mailing list Okay So I think we can consider it is approved Okay, so quick update on the hosting team. We intend to do a meeting Today for onboarding new contributors Even though we had a few contributors who accepted the invitation. They didn't show up So basically the meeting was cancelled while we still had another discussion with Daniel and Alex So and we created slides which I posted in the thread So if you're interested, you can just take a look and once we have Somebody who is committed to participate, we will Reorganize the meeting and create recording for these slides The slide deck is basically enough to understand the idea and to get all the links So it should be okay even in a synchronous way Okay, so we have a bunch of topics here One topic I want to discuss is job project process updates So it can be done later when we have Pull request and there is quite a active discussion So we can just build consensus even without governance meeting there And yeah for the rest Yeah, I wanted to discuss using GitHub issues for open governance But yeah, one question to both members If you could provide feedback on that in the board committee, I would appreciate that Yeah, I'm Kind of leaning towards calling in here because it's been a long day meetings and we're over time. Yep I'm also wrapping up. So no intention to discuss now. I'm just highlighting that these topics is where it will be great Have a synchronous discussion Yeah So I'll move everything to the next thing Okay, anything else for today? Okay, I'm off. Bye Okay, thanks everyone. Have a great day Thanks Yeah, I'll publish a recording tomorrow because it's 10 p.m on my time zone Thank you. Thank you. Thanks all


Graves Avenue was located in central Florida between Orlando and Daytona Beach. It's the fastest growing region in the state, and the Graves Avenue Bridge crosses over Interstate 4 in an area that sees an average of 70,000 cars a day. The bridge was built in 1958 when this was the land of citrus, but the population explosion and subsequent widening of I-4 from 4 to 6 lanes in the area meant the old bridge had to go. Officials from the Florida Department of Transportation had seen an innovative bridge building technique in use overseas. There, crews used self-propelled modular transporters or SPMTs to lift old bridges out of the way and then replace them with pre-constructed bridge spans in a short amount of time. We do a lot of this over in Europe. In Europe, it's a definite need to do bridges quickly because when you pay up traffic, you literally affect countries. We've done several presentations to various DOTs in Florida. It was one of the first ones to say, yeah, this is a good idea. The Graves Avenue project is the first time SPMTs have been used in the construction of a bridge over an Interstate highway in the United States. As work on the project began, the Graves Avenue Bridge was closed to traffic in December of last year and crews began tearing away the outer spans. For several weeks, this is what drivers saw as they traveled underneath the old Graves Avenue Bridge simply perched atop its support piers. Then less than a month later in early January, the SPMTs arrived in Florida and it was time to remove the old spans of the bridge. During rolling roadblocks on I-4, it took only about 20 minutes during the overnight hours of two non-consecutive nights to remove the spans. The wow factor of the project was not lost on the local media. Tonight, transportation workers are going to roll out an amazing piece of construction equipment that'll practically eliminate any traffic delays. It is an amazing feat. Demolition crews moved an entire bridge from over I-4 overnight. A massive lift removed the span over the westbound lanes and because of that state-of-the-art equipment, the lanes were only shut down for about 25 minutes. New from overnight road construction crews have finished removing the second span of the Graves Avenue Overpass on I-4 in Volusia County. A heavy lifting piece of machinery carried the overpass from its foundation to the side of the road. DOT says this method of removal cost more money but saves months of construction time. A new bridge is being built on the side of the road and then will be lifted and put right into place. Even people close to the project were impressed. It's one of the most unique things I've seen happen. But to see that bridge section at 260 tons lift so easily and walk away so smoothly, it was impressive. After the two old spans of the Graves Avenue Bridge were demolished in a matter of days instead of weeks, work immediately began on the two new spans in the construction yard along the side of I-4 instead of over I-4. Then in June the SPMTs were back for an even bigger job, the installation of the new spans. The first step involved lifting the spans to setting height, a process that took several days. Then overnight on a weekend when traffic volume is lowest, detours on I-4 rerouted traffic and a curious crowd watched as the SPMTs moved the first span into place. One week later there was a different crowd. These were transportation officials from all over the United States and beyond who came to witness history in the making as the second span of the Graves Avenue Bridge was installed. Crews had less than one inch clearance on each end to slide the second span into place. We're very excited to be here and we're really thankful that FDOT has allowed us to be here. I think it was really impressive. Everything went smoothly without a hitch. We're going to definitely be using this technology in Canada. Florida Department of Transportation officials were pleased with this new process and plan to investigate the use of SPMTs in other projects. This won't be an application that you use everywhere but we'll try to bracket where you'd use it for what kind of projects you use it on and then the engineers will have to make a judgment. We certainly have a lot of hopes and we think that there are projects in constrained areas that will benefit from this technology. As we mark the 50th anniversary of the interstate system transportation engineers are looking for innovative construction techniques that allow them to upgrade the aging system with minimal disruption for drivers. The Federal Highway Administration hopes the use of self-propelled modular transporters will do just that.