Browse Source

More links

master
David Larlet 2 years ago
parent
commit
431d573611

+ 289
- 0
cache/2021/3b811b75e116cdc0ac8f6f1b2fa60f12/index.html View File

@@ -0,0 +1,289 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Introduction to SourceHut culture (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://man.sr.ht/staff/culture.md">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>Introduction to SourceHut culture</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://man.sr.ht/staff/culture.md" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<p>Welcome to SourceHut!</p>
<p>SourceHut's mission statement is as follows:</p>
<blockquote>
<p>We are here to make free software better. We will be honest, transparent, and
empathetic. We care for our users, and we will not exploit them, and we hope
that they will reward our care and diligence with success.</p>
</blockquote>
<p>This is the philosophical ethos that underlies our business. This presents
itself in the way we act. Because we are empathetic, we value accessibility,
working to make our UI easy to use for anyone, or prioritizing performance on
low-end hardware and networks, so that access to our software does not depend on
income level. We are transparent, which motivates our public ops, financial
reports, and the fact that this page is on a public wiki. We are honest, by
telling users quickly and frankly when we make mistakes that affect them, and in
explaining our incentives and motivations so they can make informed decisions
about their relationship with us.</p>
<p>This extends to our internal culture as well. When we make mistakes or aren't
sure what to do, we talk to each other about it, as an extension of our
principle of honesty. We are empathetic, which is why we understand and forgive
those mistakes, and care for each other as human beings before anything else.
We have a steadfast commitment to integrity in all of our affairs that we hope
can set an example for the industry as a whole, and it is our hope that you will
keep these principles in mind in all of your work with SourceHut.</p>
<h4 id="in-practical-terms"><a href="#in-practical-terms" rel="nofollow noopener">#</a>In practical terms</h4>
<p>Think of SourceHut's engineering culture as a dynamic, mutual collaboration
between equals, who aim to support each other in achieving our shared ambitions
in free software. We have essentially attempted to reproduce the FOSS
community's collaboration environment, and to some extent, governance model, in
the context of a business.</p>
<h5 id="what-should-i-work-on"><a href="#what-should-i-work-on" rel="nofollow noopener">#</a>What should I work on?</h5>
<p>Most SourceHut engineers choose their own work. You may work on the projects
that you find interesting and important, at your own discretion, including
projects which are not maintained by or in the direct interests of SourceHut.
You can also choose your own tasks and priorities within those projects. The
only caveat is that it must be free and open source software.</p>
<p>You must do this with an attitude that honors and values the feedback and advice
of your peers, and seek to establish mutual trust. For example, junior engineers,
and senior engineers who are junior to a new project or field, will generally be
well-advised to seek the advice of the more experienced peers (be it fellow
SourceHut staff, or the maintainers of a third-party project) regarding what
tasks to work on. And likewise, those maintainers and mentors will honor and
value your growth, experience, feedback, and opinions, to create a healthy
balance of trust between participants.</p>
<h5 id="rely-on-your-peers"><a href="#rely-on-your-peers" rel="nofollow noopener">#</a>Rely on your peers</h5>
<p><strong>Ask questions early</strong>. We are here to support each other. There is no shame in
not being sure of what to do, struggling with a hard problem, or having made a
mistake. The shame is in not trusting your peers to help.</p>
<h5 id="accepting-responsibilities"><a href="#accepting-responsibilities" rel="nofollow noopener">#</a>Accepting responsibilities</h5>
<p>In addition to proactively choosing to work on projects and tasks that you find
important, you may also accept long-term responsibilities that you find
important. A simple example of this is your long-term commitments as the
maintainer of your personal FOSS projects, which you may have already made
before even joining SourceHut. You will have similar opportunities to accept
responsibilities in the future. For example, you may become responsible for
various subsystems of sr.ht software, or in third-party projects, or have
certain responsibilities to your peers and users, such as being on-call for
infrastructure issues.</p>
<p>This is also done at your discretion, according to your wisdom on what
responsibilities are important and suited to your skills. This is also a means
by which you can build trust with your peers and the larger community, by being
someone they can depend on.</p>
<h5 id="communication"><a href="#communication" rel="nofollow noopener">#</a>Communication</h5>
<p>We have a private channel on Libera.Chat at #sr.ht.staff, which you will be
invited to. We also have the #sr.ht and #sr.ht.watercooler channels, which are
open to the public and respectively handle forge support and SourceHut-adjacent
discussions. Aim to use the right channel: if appropriate, many matters should
be discussed in public, but we needn't bother these spaces with the day-to-day
activities internal to SourceHut.</p>
<p>Also remember that you represent SourceHut when you communicate with the outside
world — something you are expected to do often. Remember to be respectful,
to remember the human, and to avoid flamewars. You are building a relationship
with the community. This is not to say that you shouldn't stand by your
principles, but to be respectful of those who disagree. Give your peers
feedback, but remember to praise in public and criticise in private.</p>
<h5 id="meetings"><a href="#meetings" rel="nofollow noopener">#</a>Meetings</h5>
<p>Everyone has a bi-weekly 1-on-1 meeting with their assigned mentor. This person
is there to help you smooth along your work, lend you their ear when you ask for
advice or are having trouble, and be your advocate to the broader organization.
The scope and goals of these meetings is a matter for you and your mentor to
agree upon, and it can evolve over time. This person is also your first stop for
any formal businessy business, for anything you would talk to a manager about.
They are not, however, a manager in the traditional sense, and don't have
special authority over you.</p>
<p>We also have monthly all-hands meetings where we will discuss our long-term
interests, matters relevant to the whole company, updates on interesting things
that are being worked on, and so on.</p>
<p>Beyond this, meetings are established on an as-needed basis. For example, we may
schedule meetings with consulting clients.</p>
<h5 id="planning"><a href="#planning" rel="nofollow noopener">#</a>Planning</h5>
<p>Informal planning is done in the meetings described above, but formal planning,
such as ticket tracking, agile-style planning, and so on, is minimal at
SourceHut. We find that formal systems are often the product of non-engineers
wanting to boil their engineering teams down to numbers and apersonal measures
of progress, which is not appropriate for an organization built on mutual trust
and communication.</p>
<p>However, it is often <em>useful</em> to have some means of tracking the things on our
mind and communicate our intentions to others. Many of the projects we work on
have bug trackers, and mailing list archives are a good place to put proposals
and RFCs. We leverage planning tools and systems as they are helpful for us to
achieve our goals, and remove them when they are not. Work with your peers to
figure out what works for your projects.</p>
<h5 id="time-off"><a href="#time-off" rel="nofollow noopener">#</a>Time off</h5>
<p>If you need time off, take it. It is important for you to be healthy and happy,
and that means taking time off work sometimes. There are no formal limits on
time off, and no formal process to request it. Let people know when you'll be
away so that they can work around your absence. If you have responsibilities
that you won't be tending to, see to it that they're accounted for first.</p>
<h5 id="how-and-when-do-i-get-paid"><a href="#how-and-when-do-i-get-paid" rel="nofollow noopener">#</a>How and when do I get paid?</h5>
<p>Make sure Drew has your bank information for wire transfers or direct deposit.
We prepare invoices on or near the first of the month to send out to our
clients, and we pay the monthly base to staff on this date as well. We will also
wire you payment for any consulting invoices which were paid over the previous
month at this time.</p>
<h5 id="expenses"><a href="#expenses" rel="nofollow noopener">#</a>Expenses</h5>
<p>If you have reasonable work expenses, for instance on work-related equipment,
books, and so on, ask Drew and he'll comp you. SourceHut will also cover your
travel and accommodations for work-related events, such as conferences, if
agreed upon in advance.</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 122
- 0
cache/2021/3b811b75e116cdc0ac8f6f1b2fa60f12/index.md View File

@@ -0,0 +1,122 @@
title: Introduction to SourceHut culture
url: https://man.sr.ht/staff/culture.md
hash_url: 3b811b75e116cdc0ac8f6f1b2fa60f12

<p>Welcome to SourceHut!</p>
<p>SourceHut's mission statement is as follows:</p>
<blockquote>
<p>We are here to make free software better. We will be honest, transparent, and
empathetic. We care for our users, and we will not exploit them, and we hope
that they will reward our care and diligence with success.</p>
</blockquote>
<p>This is the philosophical ethos that underlies our business. This presents
itself in the way we act. Because we are empathetic, we value accessibility,
working to make our UI easy to use for anyone, or prioritizing performance on
low-end hardware and networks, so that access to our software does not depend on
income level. We are transparent, which motivates our public ops, financial
reports, and the fact that this page is on a public wiki. We are honest, by
telling users quickly and frankly when we make mistakes that affect them, and in
explaining our incentives and motivations so they can make informed decisions
about their relationship with us.</p>
<p>This extends to our internal culture as well. When we make mistakes or aren't
sure what to do, we talk to each other about it, as an extension of our
principle of honesty. We are empathetic, which is why we understand and forgive
those mistakes, and care for each other as human beings before anything else.
We have a steadfast commitment to integrity in all of our affairs that we hope
can set an example for the industry as a whole, and it is our hope that you will
keep these principles in mind in all of your work with SourceHut.</p>
<h4 id="in-practical-terms"><a href="#in-practical-terms" rel="nofollow noopener">#</a>In practical terms</h4>
<p>Think of SourceHut's engineering culture as a dynamic, mutual collaboration
between equals, who aim to support each other in achieving our shared ambitions
in free software. We have essentially attempted to reproduce the FOSS
community's collaboration environment, and to some extent, governance model, in
the context of a business.</p>
<h5 id="what-should-i-work-on"><a href="#what-should-i-work-on" rel="nofollow noopener">#</a>What should I work on?</h5>
<p>Most SourceHut engineers choose their own work. You may work on the projects
that you find interesting and important, at your own discretion, including
projects which are not maintained by or in the direct interests of SourceHut.
You can also choose your own tasks and priorities within those projects. The
only caveat is that it must be free and open source software.</p>
<p>You must do this with an attitude that honors and values the feedback and advice
of your peers, and seek to establish mutual trust. For example, junior engineers,
and senior engineers who are junior to a new project or field, will generally be
well-advised to seek the advice of the more experienced peers (be it fellow
SourceHut staff, or the maintainers of a third-party project) regarding what
tasks to work on. And likewise, those maintainers and mentors will honor and
value your growth, experience, feedback, and opinions, to create a healthy
balance of trust between participants.</p>
<h5 id="rely-on-your-peers"><a href="#rely-on-your-peers" rel="nofollow noopener">#</a>Rely on your peers</h5>
<p><strong>Ask questions early</strong>. We are here to support each other. There is no shame in
not being sure of what to do, struggling with a hard problem, or having made a
mistake. The shame is in not trusting your peers to help.</p>
<h5 id="accepting-responsibilities"><a href="#accepting-responsibilities" rel="nofollow noopener">#</a>Accepting responsibilities</h5>
<p>In addition to proactively choosing to work on projects and tasks that you find
important, you may also accept long-term responsibilities that you find
important. A simple example of this is your long-term commitments as the
maintainer of your personal FOSS projects, which you may have already made
before even joining SourceHut. You will have similar opportunities to accept
responsibilities in the future. For example, you may become responsible for
various subsystems of sr.ht software, or in third-party projects, or have
certain responsibilities to your peers and users, such as being on-call for
infrastructure issues.</p>
<p>This is also done at your discretion, according to your wisdom on what
responsibilities are important and suited to your skills. This is also a means
by which you can build trust with your peers and the larger community, by being
someone they can depend on.</p>
<h5 id="communication"><a href="#communication" rel="nofollow noopener">#</a>Communication</h5>
<p>We have a private channel on Libera.Chat at #sr.ht.staff, which you will be
invited to. We also have the #sr.ht and #sr.ht.watercooler channels, which are
open to the public and respectively handle forge support and SourceHut-adjacent
discussions. Aim to use the right channel: if appropriate, many matters should
be discussed in public, but we needn't bother these spaces with the day-to-day
activities internal to SourceHut.</p>
<p>Also remember that you represent SourceHut when you communicate with the outside
world — something you are expected to do often. Remember to be respectful,
to remember the human, and to avoid flamewars. You are building a relationship
with the community. This is not to say that you shouldn't stand by your
principles, but to be respectful of those who disagree. Give your peers
feedback, but remember to praise in public and criticise in private.</p>
<h5 id="meetings"><a href="#meetings" rel="nofollow noopener">#</a>Meetings</h5>
<p>Everyone has a bi-weekly 1-on-1 meeting with their assigned mentor. This person
is there to help you smooth along your work, lend you their ear when you ask for
advice or are having trouble, and be your advocate to the broader organization.
The scope and goals of these meetings is a matter for you and your mentor to
agree upon, and it can evolve over time. This person is also your first stop for
any formal businessy business, for anything you would talk to a manager about.
They are not, however, a manager in the traditional sense, and don't have
special authority over you.</p>
<p>We also have monthly all-hands meetings where we will discuss our long-term
interests, matters relevant to the whole company, updates on interesting things
that are being worked on, and so on.</p>
<p>Beyond this, meetings are established on an as-needed basis. For example, we may
schedule meetings with consulting clients.</p>
<h5 id="planning"><a href="#planning" rel="nofollow noopener">#</a>Planning</h5>
<p>Informal planning is done in the meetings described above, but formal planning,
such as ticket tracking, agile-style planning, and so on, is minimal at
SourceHut. We find that formal systems are often the product of non-engineers
wanting to boil their engineering teams down to numbers and apersonal measures
of progress, which is not appropriate for an organization built on mutual trust
and communication.</p>
<p>However, it is often <em>useful</em> to have some means of tracking the things on our
mind and communicate our intentions to others. Many of the projects we work on
have bug trackers, and mailing list archives are a good place to put proposals
and RFCs. We leverage planning tools and systems as they are helpful for us to
achieve our goals, and remove them when they are not. Work with your peers to
figure out what works for your projects.</p>
<h5 id="time-off"><a href="#time-off" rel="nofollow noopener">#</a>Time off</h5>
<p>If you need time off, take it. It is important for you to be healthy and happy,
and that means taking time off work sometimes. There are no formal limits on
time off, and no formal process to request it. Let people know when you'll be
away so that they can work around your absence. If you have responsibilities
that you won't be tending to, see to it that they're accounted for first.</p>
<h5 id="how-and-when-do-i-get-paid"><a href="#how-and-when-do-i-get-paid" rel="nofollow noopener">#</a>How and when do I get paid?</h5>
<p>Make sure Drew has your bank information for wire transfers or direct deposit.
We prepare invoices on or near the first of the month to send out to our
clients, and we pay the monthly base to staff on this date as well. We will also
wire you payment for any consulting invoices which were paid over the previous
month at this time.</p>
<h5 id="expenses"><a href="#expenses" rel="nofollow noopener">#</a>Expenses</h5>
<p>If you have reasonable work expenses, for instance on work-related equipment,
books, and so on, ask Drew and he'll comp you. SourceHut will also cover your
travel and accommodations for work-related events, such as conferences, if
agreed upon in advance.</p>

+ 207
- 0
cache/2021/64ee5051fec3060fea59c93823222ca1/index.html View File

@@ -0,0 +1,207 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Une interview dans Le Un en novembre 2021 (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://jancovici.com/publications-et-co/interviews/une-interview-dans-le-un-en-novembre-2021/">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>Une interview dans Le Un en novembre 2021</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://jancovici.com/publications-et-co/interviews/une-interview-dans-le-un-en-novembre-2021/" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<p>Interview parue dans <a href="https://le1hebdo.fr/journal/sobrit-faut-il-s-y-prparer/371/article/nous-ne-vivons-pas-une-crise-mais-le-dbut-d-une-mutation-4969.html" target="_blank" rel="noopener">Le Un du 3 novembre 2021</a>.</p>
<p>Comme d’habitude, le chapô précédent l’interview, que je reproduis ci-dessous, est de la rédaction du journal et non soumis à relecture, tout comme le titre. NB: le chapô aurait tout aussi bien pu dire que parmi les financeurs du Shift Project il y avait 3000 particuliers qui ont donné de quoi mettre en route le plan de transformation de l’économie française, l’Ademe ou la SNCF…</p>
<p>Le texte de l’interview ci-dessous est celui, relu et amendé, que j’ai envoyé au journal. Entretien réalisé par <span class="auteur">Hélène Seingier et Julien Bisson</span>.</p>
<p><em>Associé fondateur du cabinet de conseil Carbone 4 et président fondateur du think tank The Shift Project, qui compte parmi ses financeurs des groupes comme EDF, Bouygues et Vinci, ce polytechnicien est l’un des concepteurs du bilan carbone. Parmi ses publications : <a href="https://jancovici.com/publications-et-co/livres/dormez-tranquilles-jusquen-2100/" target="_blank" rel="noopener">Dormez tranquilles jusqu’en 2100</a> (Odile Jacob,2015) et, avec Christophe Blain, la bande dessinée documentaire <a href="https://jancovici.com/publications-et-co/livres/le-monde-sans-fin/" target="_blank" rel="noopener">Le Monde sans fin</a> (Dargaud, 2021).</em></p>
<hr>
<p><strong>Dans Le Monde sans fin, vous rappelez que chaque humain consomme en moyenne 22.000 kilowatts heure par an, provenant essentiellement du gaz, du pétrole et du charbon. Convertis en énergie humaine, ce serait l’équivalent de 200 esclaves à notre service en permanence, et même 600 pour les Français. Doit-on se résoudre à la fin de cette énergie abondante ?</strong></p>
<p>La réponse est oui, malheureusement : on doit se résoudre à la fin progressive des énergies fossiles, qui <a href="https://jancovici.com/transition-energetique/series-longues/france/" target="_blank" rel="noopener">représentent 80% de notre approvisionnement énergétique</a>, et qui ont fait le 19e et 20e siècle. La première limite est géologique, en amont : pour former des combustibles fossiles, <a href="https://jancovici.com/transition-energetique/petrole/comment-se-forment-petrole-gaz-et-charbon/" target="_blank" rel="noopener">il faut des dizaines ou des centaines de millions d’années</a> – donc on s’en sert un million de fois plus vite qu’elles ne se forment. Se séparer de l’énergie fossile est dès lors inexorable. Ça a même déjà commencé pour le pétrole conventionnel : son extraction mondiale a atteint son maximum en 2008, et depuis l’approvisionnement européen décline. D’ici à 2050, <a href="https://theshiftproject.org/wp-content/uploads/2021/05/Approvisionnement-petrolier-futur-de-lUE_Shift-Project_Mai-2021_RAPPORT-COMPLET.pdf" target="_blank" rel="noopener">il pourrait être divisé par trois</a>, parce que la production mondiale sera elle-même divisée par deux et que les pays producteurs voudront évidemment garder du pétrole pour eux.</p>
<p>En Europe, <a href="https://jancovici.com/transition-energetique/charbon/le-pic-de-production-pour-le-charbon-on-peut-en-voir-quelque-part/" target="_blank" rel="noopener">charbon</a> et <a href="https://jancovici.com/transition-energetique/gaz/le-pic-de-production-il-y-en-aussi-eu-pour-le-gaz/" target="_blank" rel="noopener">gaz</a> sont aussi contraints à la baisse pour des raisons géologiques. Et cette décrue énergétique annonce une contraction de l’activité économique, car <a href="https://jancovici.com/transition-energetique/l-energie-et-nous/lenergie-de-quoi-sagit-il-exactement/" target="_blank" rel="noopener">l’énergie, c’est les machines, qui sont indispensables pour faire fonctionner l’économie</a>. Si vous manquez d’énergie, la production baisse. Roosevelt comptait les trains pour savoir si l’économie allait bien. Si on regarde aujourd’hui la quantité de logements construits en Europe ou le nombre d’objets produits, on constate que l’économie n’est plus en croissance depuis le pic pétrolier mondial. Ce que nous vivons n’est pas une crise, mais le début d’une mutation.</p>
<p><strong>Quelle est la seconde limite à la consommation d’énergies fossiles ?</strong></p>
<p>Le climat. C’est la contrainte en aval, mais elle est plus urgente encore. Nous devons diviser par trois nos émissions de gaz à effet de serre d’ici 2050 si on souhaite conserver une planète vivable. Or ces émissions sont en grande partie dues à la consommation d’énergies fossiles.</p>
<p><strong>Que se passe-t-il si on ne fait rien, ou pas grand-chose ?</strong></p>
<p>Nous allons « rôtir ». Nous en sommes à 1,2 degré d’élévation de la température moyenne planétaire par rapport à l’ère pré-industrielle et on constate déjà des vagues de chaleur et des sécheresses qui font mourir une partie de la forêt française, mettent à mal les récoltes, ont tué 15% des coraux, occasionné des inondations monstrueuses… Ces phénomènes ont aussi commencé à engendrer des migrations et des émeutes de la faim. <a href="https://www.youtube.com/watch?v=yiBrP7N9FkA" target="_blank" rel="noopener">Certaines ont conduit aux Printemps arabes</a>. Tout cela illustre ce qui va nous arriver à beaucoup plus grande échelle avec une dérive climatique qui s’amplifie.</p>
<p><strong>Réduire les émissions de gaz à effet de serre de 5% chaque année, ce qui équivaut à une épidémie de Covid de plus tous les ans. Comment peut-on encaisser cela ?</strong></p>
<p>Je ne sais pas, mais je suis preneur de la solution ! Cette image est là pour frapper les esprits. Entre 1942 et 1945, les Etats-Unis ont reconfiguré 30% de leur PIB. On doit viser des bouleversements de cet ordre-là, une forme d’économie de guerre, et pas se demander si on va nommer un directeur du développement durable dans telle entreprise. Nos dirigeants, essentiellement des avocats et des personnes formées en sciences humaines, ne l’ont pas compris. Ils considèrent encore que l’énergie et le climat sont détachables du reste, alors même que c’est ce qui rend tout le reste possible. Ils pensent qu’on peut encore attendre pour rétablir la situation. Or la grosse différence entre agir et subir, c’est que dans un cas, on planifie et on s’organise. Dans l’autre, on ne fait que prendre des baffes.</p>
<p><strong>Si l’énergie fait tourner le monde, comment alors préparer la sobriété ?</strong></p>
<p>La sobriété va nous tomber dessus de toute façon. Il y a trois manières d’économiser de l’énergie. La première, c’est l’efficacité : j’utilise moins d’énergie pour fabriquer un smartphone qui reste identique, et le faire tourner. La deuxième, la sobriété : je choisis délibérément un smartphone plus petit et je le conserve trois fois plus longtemps que mon voisin. La troisième manière, c’est la pauvreté, qui est de la sobriété subie, et qui rend donc très malheureux. La différence entre les deux, c’est uniquement le caractère volontaire : acheter volontairement des vêtements d’occasion rend beaucoup plus heureux qu’y être contraint parce qu’on n’a pas les moyens d’acheter du neuf.</p>
<p><strong>Quelles seraient les priorités pour atteindre cette sobriété ?</strong></p>
<p>Dans le secteur du logement par exemple, il vaudrait mieux rénover que construire. Le deuxième poste est lié à nos achats. Là c’est assez simple : il faut acheter moins de choses. On renouvelle moins souvent le canapé, les chaises ou la machine à laver. On répare. Le troisième poste concerne la manière dont on se déplace. Si on veut utiliser moins d’énergie, il faut que chaque personne utilise un véhicule moins lourd – passer de la grosse à la petite voiture, de la petite voiture au vélo – et se déplace moins vite. On réduit la vitesse sur les routes, on ne prend plus l’avion…</p>
<p>Et le dernier poste, très important, c’est celui de l’alimentation. La première marge de manœuvre consiste à diminuer la taille du cheptel bovin, à cause du méthane qu’il produit et qui est un puissant gaz à effet de serre. Il faut réduire aussi l’utilisation d’engrais azotés, qui émettent du protoxyde d’azote, un autre gaz à effet de serre. Les deux tiers de la surface agricole utile servent à nourrir les animaux, donc si on mange moins d’animaux, et surtout moins de viande rouge, l’agriculture exercera moins de pression. On peut cultiver à la place des pois chiches et des lentilles, des protéines végétales.</p>
<p><strong>Selon vous, les énergies fossiles ont notamment permis l’émergence de la classe moyenne. La fin de l’énergie abondante la condamne-t-elle ?</strong></p>
<p>A terme, ça la remet en question de façon évidente. Avec l’énergie, on a vu l’émergence du confort matériel chez tous, du pouvoir d’achat pour tous. Et la modification du type d’activité avec le développement du secteur tertiaire. Est-ce que la décrue énergétique va permettre de conserver ce genre de travail, de services ? A terme, pas dans les mêmes volumes. La société va devoir se structurer différemment.</p>
<p><strong>Comment vont évoluer les emplois ?</strong></p>
<p>Dans un monde avec moins d’énergie, plus de gens vont devoir travailler avec leurs mains. Il y aura moins d’emplois dans la construction automobile, mais on aura besoin de mettre 300.000 personnes dans ce qu’on appelle le système vélo : les fabriquer, les entretenir, les utiliser pour les livraisons… Ce sont des emplois matériellement moins prédateurs. Il va de même falloir remettre du monde dans l’agriculture. L’énergie abondante a aussi permis d’augmenter la taille des entreprises, la sobriété énergétique va conduire à l’inverse. Quelles multinationales existaient il y a deux siècles ? L’Eglise et les comptoirs liés à la colonisation. L’économie mondialisée est une économie sous perfusion énergétique, ne serait-ce que pour déplacer des porte-containers. Raccourcir les chaînes de valeur va poser un vrai problème à un pays comme le nôtre, qui ne dispose de quasiment aucune matière première. Il faudra qu’on choisisse de quel étranger dépendre.</p>
<p><strong>Pourra-t-on continuer à vivre en ville ?</strong></p>
<p>L’Ile-de-France, avec ses 10 millions d’habitants, est une création de l’énergie abondante. Pour faire survivre une agglomération pareille, où aucun aliment n’est produit sur place, vous avez besoin de transports longue distance, donc d’énergie. Un camion sur trois en France transporte quelque chose qui se mange. Vous avez besoin d’emballages donc de plastique, de métal, de bois… donc d’énergie pour les mettre en forme. Vous avez besoin de transport longue distance pour faire venir vos vêtements, vos meubles, votre électronique, votre tube de dentifrice… Le projet du grand Paris, qui consiste à étaler encore la ville, est totalement anachronique. Il a un siècle de retard.</p>
<p><strong>Que serait un projet avec un siècle d’avance ?</strong></p>
<p>Ce sont des petites villes, dont le rayon de dépendance diminue. Vous continuez à faire venir du sel de la mer quand vous habitez à Strasbourg, mais autour de la ville vous avez des fermes qui produisent de la nourriture et des fabriques qui produisent des meubles. Et si Strasbourg devient trois fois plus petite, vous avez besoin de trois fois moins de transport.</p>
<p><strong>Mais que fait-on des deux tiers des Strasbourgeois qui doivent déménager ?</strong></p>
<p>Je n’ai pas encore la réponse. En revanche, je peux inviter les urbanistes à raisonner avec le bon cahier des charges : puisque l’énergie permet la vascularisation des villes, il va falloir diminuer l’activité urbaine si on ne veut pas risquer la thrombose. Encore une fois, la première étape consiste à organiser la transition.</p>
<p><strong>Va-t-on revenir, comme le craint une partie de la population, à une vie d’avant le pétrole, au monde de la lampe à huile ?</strong></p>
<p>Non, le monde à l’avenir se situera quelque part entre la civilisation pré-industrielle et l’état du monde actuel, avec un niveau de confort qui dépendra de deux critères. Le premier sera la quantité d’énergies décarbonées et pilotables que l’on pourra utiliser : on connaît très bien les énergies diffuses et intermittentes, comme le solaire ou l’éolien, car ce sont celles dont on disposait avant la révolution industrielle. Elles sont plus performantes aujourd’hui, c’est indéniable. Mais serons-nous capables demain de produire, rénover et entretenir un parc mondial entièrement éolien et solaire sans les énergies fossiles d’aujourd’hui ? Ca reste à prouver.</p>
<p>La seule énergie pilotable, décarbonée et dense qui existe s’appelle le nucléaire – et l’hydroélectricité, pour les pays qui ont la chance d’avoir des montagnes. Mais le nucléaire est un parachute ventral, il permet d’atterrir en évitant de se fracasser quand les combustibles fossiles ne seront plus là, mais vous risquez tout de même de vous faire une entorse et de vous casser le nez, ce qui signifie que nous allons devoir faire de gros efforts de toute façon. Le deuxième critère sera notre capacité à produire de façon très sobre. On a accumulé du capital intellectuel depuis la révolution industrielle, on sait produire avec moins. On pourra donc garder une partie de notre confort, mais pas dans les dimensions de gigantisme qu’on connaît aujourd’hui.</p>
<p><strong>Comment réduire la consommation d’énergie sans que ce soit liberticide ?</strong></p>
<p>Les restrictions à la liberté ont toujours existé. Avec la fin des machines triomphantes, on va devoir renoncer à une partie de notre liberté individuelle, comme celle de partir à 3000 km en avion si ça nous chante. Il va falloir trouver l’enchantement du voyage en allant moins loin, ce qui n’est pas gravissime. Mais c’est une liberté pour une autre : en imposant des contraintes énergétiques et climatiques, on va gagner de la sécurité collective pour l’avenir. On va aussi gagner un but. C’est important, un but, c’est mobilisateur. Et la bonne question à se poser c’est de savoir si cela nous rendra plus malheureux. Ce qui dépend en réalité du caractère volontaire ou non de ce changement.</p>
<p><strong>Qui doit donner l’impulsion ? Les citoyens, le secteur privé, les politiques ?</strong></p>
<p>Tout le monde a un rôle à jouer dans cette histoire, sans attendre les autres. Les citoyens peuvent changer leur mode de vie pour montrer aux politiques qu’ils sont prêts à ce que la règle change. C’est en voyant des associations, des petites entreprises, des élus locaux faire des choses que l’étage du dessus va sentir la pression et changer les règles. Sauf à avoir un visionnaire à la tête de l’Etat. Mais ça, ça demande une période de crise. Et nous n’y sommes pas encore suffisamment enfoncés.</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 40
- 0
cache/2021/64ee5051fec3060fea59c93823222ca1/index.md View File

@@ -0,0 +1,40 @@
title: Une interview dans Le Un en novembre 2021
url: https://jancovici.com/publications-et-co/interviews/une-interview-dans-le-un-en-novembre-2021/
hash_url: 64ee5051fec3060fea59c93823222ca1

<p>Interview parue dans <a href="https://le1hebdo.fr/journal/sobrit-faut-il-s-y-prparer/371/article/nous-ne-vivons-pas-une-crise-mais-le-dbut-d-une-mutation-4969.html" target="_blank" rel="noopener">Le Un du 3 novembre 2021</a>.</p>
<p>Comme d’habitude, le chapô précédent l’interview, que je reproduis ci-dessous, est de la rédaction du journal et non soumis à relecture, tout comme le titre. NB: le chapô aurait tout aussi bien pu dire que parmi les financeurs du Shift Project il y avait 3000 particuliers qui ont donné de quoi mettre en route le plan de transformation de l’économie française, l’Ademe ou la SNCF…</p>
<p>Le texte de l’interview ci-dessous est celui, relu et amendé, que j’ai envoyé au journal. Entretien réalisé par <span class="auteur">Hélène Seingier et Julien Bisson</span>.</p>
<p><em>Associé fondateur du cabinet de conseil Carbone 4 et président fondateur du think tank The Shift Project, qui compte parmi ses financeurs des groupes comme EDF, Bouygues et Vinci, ce polytechnicien est l’un des concepteurs du bilan carbone. Parmi ses publications : <a href="https://jancovici.com/publications-et-co/livres/dormez-tranquilles-jusquen-2100/" target="_blank" rel="noopener">Dormez tranquilles jusqu’en 2100</a> (Odile Jacob,2015) et, avec Christophe Blain, la bande dessinée documentaire <a href="https://jancovici.com/publications-et-co/livres/le-monde-sans-fin/" target="_blank" rel="noopener">Le Monde sans fin</a> (Dargaud, 2021).</em></p>
<hr>
<p><strong>Dans Le Monde sans fin, vous rappelez que chaque humain consomme en moyenne 22.000 kilowatts heure par an, provenant essentiellement du gaz, du pétrole et du charbon. Convertis en énergie humaine, ce serait l’équivalent de 200 esclaves à notre service en permanence, et même 600 pour les Français. Doit-on se résoudre à la fin de cette énergie abondante ?</strong></p>
<p>La réponse est oui, malheureusement : on doit se résoudre à la fin progressive des énergies fossiles, qui <a href="https://jancovici.com/transition-energetique/series-longues/france/" target="_blank" rel="noopener">représentent 80% de notre approvisionnement énergétique</a>, et qui ont fait le 19e et 20e siècle. La première limite est géologique, en amont : pour former des combustibles fossiles, <a href="https://jancovici.com/transition-energetique/petrole/comment-se-forment-petrole-gaz-et-charbon/" target="_blank" rel="noopener">il faut des dizaines ou des centaines de millions d’années</a> – donc on s’en sert un million de fois plus vite qu’elles ne se forment. Se séparer de l’énergie fossile est dès lors inexorable. Ça a même déjà commencé pour le pétrole conventionnel : son extraction mondiale a atteint son maximum en 2008, et depuis l’approvisionnement européen décline. D’ici à 2050, <a href="https://theshiftproject.org/wp-content/uploads/2021/05/Approvisionnement-petrolier-futur-de-lUE_Shift-Project_Mai-2021_RAPPORT-COMPLET.pdf" target="_blank" rel="noopener">il pourrait être divisé par trois</a>, parce que la production mondiale sera elle-même divisée par deux et que les pays producteurs voudront évidemment garder du pétrole pour eux.</p>
<p>En Europe, <a href="https://jancovici.com/transition-energetique/charbon/le-pic-de-production-pour-le-charbon-on-peut-en-voir-quelque-part/" target="_blank" rel="noopener">charbon</a> et <a href="https://jancovici.com/transition-energetique/gaz/le-pic-de-production-il-y-en-aussi-eu-pour-le-gaz/" target="_blank" rel="noopener">gaz</a> sont aussi contraints à la baisse pour des raisons géologiques. Et cette décrue énergétique annonce une contraction de l’activité économique, car <a href="https://jancovici.com/transition-energetique/l-energie-et-nous/lenergie-de-quoi-sagit-il-exactement/" target="_blank" rel="noopener">l’énergie, c’est les machines, qui sont indispensables pour faire fonctionner l’économie</a>. Si vous manquez d’énergie, la production baisse. Roosevelt comptait les trains pour savoir si l’économie allait bien. Si on regarde aujourd’hui la quantité de logements construits en Europe ou le nombre d’objets produits, on constate que l’économie n’est plus en croissance depuis le pic pétrolier mondial. Ce que nous vivons n’est pas une crise, mais le début d’une mutation.</p>
<p><strong>Quelle est la seconde limite à la consommation d’énergies fossiles ?</strong></p>
<p>Le climat. C’est la contrainte en aval, mais elle est plus urgente encore. Nous devons diviser par trois nos émissions de gaz à effet de serre d’ici 2050 si on souhaite conserver une planète vivable. Or ces émissions sont en grande partie dues à la consommation d’énergies fossiles.</p>
<p><strong>Que se passe-t-il si on ne fait rien, ou pas grand-chose ?</strong></p>
<p>Nous allons « rôtir ». Nous en sommes à 1,2 degré d’élévation de la température moyenne planétaire par rapport à l’ère pré-industrielle et on constate déjà des vagues de chaleur et des sécheresses qui font mourir une partie de la forêt française, mettent à mal les récoltes, ont tué 15% des coraux, occasionné des inondations monstrueuses… Ces phénomènes ont aussi commencé à engendrer des migrations et des émeutes de la faim. <a href="https://www.youtube.com/watch?v=yiBrP7N9FkA" target="_blank" rel="noopener">Certaines ont conduit aux Printemps arabes</a>. Tout cela illustre ce qui va nous arriver à beaucoup plus grande échelle avec une dérive climatique qui s’amplifie.</p>
<p><strong>Réduire les émissions de gaz à effet de serre de 5% chaque année, ce qui équivaut à une épidémie de Covid de plus tous les ans. Comment peut-on encaisser cela ?</strong></p>
<p>Je ne sais pas, mais je suis preneur de la solution ! Cette image est là pour frapper les esprits. Entre 1942 et 1945, les Etats-Unis ont reconfiguré 30% de leur PIB. On doit viser des bouleversements de cet ordre-là, une forme d’économie de guerre, et pas se demander si on va nommer un directeur du développement durable dans telle entreprise. Nos dirigeants, essentiellement des avocats et des personnes formées en sciences humaines, ne l’ont pas compris. Ils considèrent encore que l’énergie et le climat sont détachables du reste, alors même que c’est ce qui rend tout le reste possible. Ils pensent qu’on peut encore attendre pour rétablir la situation. Or la grosse différence entre agir et subir, c’est que dans un cas, on planifie et on s’organise. Dans l’autre, on ne fait que prendre des baffes.</p>
<p><strong>Si l’énergie fait tourner le monde, comment alors préparer la sobriété ?</strong></p>
<p>La sobriété va nous tomber dessus de toute façon. Il y a trois manières d’économiser de l’énergie. La première, c’est l’efficacité : j’utilise moins d’énergie pour fabriquer un smartphone qui reste identique, et le faire tourner. La deuxième, la sobriété : je choisis délibérément un smartphone plus petit et je le conserve trois fois plus longtemps que mon voisin. La troisième manière, c’est la pauvreté, qui est de la sobriété subie, et qui rend donc très malheureux. La différence entre les deux, c’est uniquement le caractère volontaire : acheter volontairement des vêtements d’occasion rend beaucoup plus heureux qu’y être contraint parce qu’on n’a pas les moyens d’acheter du neuf.</p>
<p><strong>Quelles seraient les priorités pour atteindre cette sobriété ?</strong></p>
<p>Dans le secteur du logement par exemple, il vaudrait mieux rénover que construire. Le deuxième poste est lié à nos achats. Là c’est assez simple : il faut acheter moins de choses. On renouvelle moins souvent le canapé, les chaises ou la machine à laver. On répare. Le troisième poste concerne la manière dont on se déplace. Si on veut utiliser moins d’énergie, il faut que chaque personne utilise un véhicule moins lourd – passer de la grosse à la petite voiture, de la petite voiture au vélo – et se déplace moins vite. On réduit la vitesse sur les routes, on ne prend plus l’avion…</p>
<p>Et le dernier poste, très important, c’est celui de l’alimentation. La première marge de manœuvre consiste à diminuer la taille du cheptel bovin, à cause du méthane qu’il produit et qui est un puissant gaz à effet de serre. Il faut réduire aussi l’utilisation d’engrais azotés, qui émettent du protoxyde d’azote, un autre gaz à effet de serre. Les deux tiers de la surface agricole utile servent à nourrir les animaux, donc si on mange moins d’animaux, et surtout moins de viande rouge, l’agriculture exercera moins de pression. On peut cultiver à la place des pois chiches et des lentilles, des protéines végétales.</p>
<p><strong>Selon vous, les énergies fossiles ont notamment permis l’émergence de la classe moyenne. La fin de l’énergie abondante la condamne-t-elle ?</strong></p>
<p>A terme, ça la remet en question de façon évidente. Avec l’énergie, on a vu l’émergence du confort matériel chez tous, du pouvoir d’achat pour tous. Et la modification du type d’activité avec le développement du secteur tertiaire. Est-ce que la décrue énergétique va permettre de conserver ce genre de travail, de services ? A terme, pas dans les mêmes volumes. La société va devoir se structurer différemment.</p>
<p><strong>Comment vont évoluer les emplois ?</strong></p>
<p>Dans un monde avec moins d’énergie, plus de gens vont devoir travailler avec leurs mains. Il y aura moins d’emplois dans la construction automobile, mais on aura besoin de mettre 300.000 personnes dans ce qu’on appelle le système vélo : les fabriquer, les entretenir, les utiliser pour les livraisons… Ce sont des emplois matériellement moins prédateurs. Il va de même falloir remettre du monde dans l’agriculture. L’énergie abondante a aussi permis d’augmenter la taille des entreprises, la sobriété énergétique va conduire à l’inverse. Quelles multinationales existaient il y a deux siècles ? L’Eglise et les comptoirs liés à la colonisation. L’économie mondialisée est une économie sous perfusion énergétique, ne serait-ce que pour déplacer des porte-containers. Raccourcir les chaînes de valeur va poser un vrai problème à un pays comme le nôtre, qui ne dispose de quasiment aucune matière première. Il faudra qu’on choisisse de quel étranger dépendre.</p>
<p><strong>Pourra-t-on continuer à vivre en ville ?</strong></p>
<p>L’Ile-de-France, avec ses 10 millions d’habitants, est une création de l’énergie abondante. Pour faire survivre une agglomération pareille, où aucun aliment n’est produit sur place, vous avez besoin de transports longue distance, donc d’énergie. Un camion sur trois en France transporte quelque chose qui se mange. Vous avez besoin d’emballages donc de plastique, de métal, de bois… donc d’énergie pour les mettre en forme. Vous avez besoin de transport longue distance pour faire venir vos vêtements, vos meubles, votre électronique, votre tube de dentifrice… Le projet du grand Paris, qui consiste à étaler encore la ville, est totalement anachronique. Il a un siècle de retard.</p>
<p><strong>Que serait un projet avec un siècle d’avance ?</strong></p>
<p>Ce sont des petites villes, dont le rayon de dépendance diminue. Vous continuez à faire venir du sel de la mer quand vous habitez à Strasbourg, mais autour de la ville vous avez des fermes qui produisent de la nourriture et des fabriques qui produisent des meubles. Et si Strasbourg devient trois fois plus petite, vous avez besoin de trois fois moins de transport.</p>
<p><strong>Mais que fait-on des deux tiers des Strasbourgeois qui doivent déménager ?</strong></p>
<p>Je n’ai pas encore la réponse. En revanche, je peux inviter les urbanistes à raisonner avec le bon cahier des charges : puisque l’énergie permet la vascularisation des villes, il va falloir diminuer l’activité urbaine si on ne veut pas risquer la thrombose. Encore une fois, la première étape consiste à organiser la transition.</p>
<p><strong>Va-t-on revenir, comme le craint une partie de la population, à une vie d’avant le pétrole, au monde de la lampe à huile ?</strong></p>
<p>Non, le monde à l’avenir se situera quelque part entre la civilisation pré-industrielle et l’état du monde actuel, avec un niveau de confort qui dépendra de deux critères. Le premier sera la quantité d’énergies décarbonées et pilotables que l’on pourra utiliser : on connaît très bien les énergies diffuses et intermittentes, comme le solaire ou l’éolien, car ce sont celles dont on disposait avant la révolution industrielle. Elles sont plus performantes aujourd’hui, c’est indéniable. Mais serons-nous capables demain de produire, rénover et entretenir un parc mondial entièrement éolien et solaire sans les énergies fossiles d’aujourd’hui ? Ca reste à prouver.</p>
<p>La seule énergie pilotable, décarbonée et dense qui existe s’appelle le nucléaire – et l’hydroélectricité, pour les pays qui ont la chance d’avoir des montagnes. Mais le nucléaire est un parachute ventral, il permet d’atterrir en évitant de se fracasser quand les combustibles fossiles ne seront plus là, mais vous risquez tout de même de vous faire une entorse et de vous casser le nez, ce qui signifie que nous allons devoir faire de gros efforts de toute façon. Le deuxième critère sera notre capacité à produire de façon très sobre. On a accumulé du capital intellectuel depuis la révolution industrielle, on sait produire avec moins. On pourra donc garder une partie de notre confort, mais pas dans les dimensions de gigantisme qu’on connaît aujourd’hui.</p>
<p><strong>Comment réduire la consommation d’énergie sans que ce soit liberticide ?</strong></p>
<p>Les restrictions à la liberté ont toujours existé. Avec la fin des machines triomphantes, on va devoir renoncer à une partie de notre liberté individuelle, comme celle de partir à 3000 km en avion si ça nous chante. Il va falloir trouver l’enchantement du voyage en allant moins loin, ce qui n’est pas gravissime. Mais c’est une liberté pour une autre : en imposant des contraintes énergétiques et climatiques, on va gagner de la sécurité collective pour l’avenir. On va aussi gagner un but. C’est important, un but, c’est mobilisateur. Et la bonne question à se poser c’est de savoir si cela nous rendra plus malheureux. Ce qui dépend en réalité du caractère volontaire ou non de ce changement.</p>
<p><strong>Qui doit donner l’impulsion ? Les citoyens, le secteur privé, les politiques ?</strong></p>
<p>Tout le monde a un rôle à jouer dans cette histoire, sans attendre les autres. Les citoyens peuvent changer leur mode de vie pour montrer aux politiques qu’ils sont prêts à ce que la règle change. C’est en voyant des associations, des petites entreprises, des élus locaux faire des choses que l’étage du dessus va sentir la pression et changer les règles. Sauf à avoir un visionnaire à la tête de l’Etat. Mais ça, ça demande une période de crise. Et nous n’y sommes pas encore suffisamment enfoncés.</p>

+ 218
- 0
cache/2021/68c1cb8256a8472b2711a0ffb5e7921e/index.html View File

@@ -0,0 +1,218 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Git email flow vs Github flow (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://blog.brixit.nl/git-email-flow-versus-github-flow/">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>Git email flow vs Github flow</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://blog.brixit.nl/git-email-flow-versus-github-flow/" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<p>So I've been using the Github flow for some years now from both the maintainer side and contributor side to open source projects. I've also been using the email workflow for git from both sides for about a year now. Using email for git sounded quite horrible before I actually started using it. Now I prefer it so I thought I would document my experience here.</p>
<h2>The Github flow</h2>
<p>This isn't strictly for Github, it's the flow many developers are accustomed to:</p>
<ol>
<li>Fork the project repo</li>
<li>Make a change on your fork</li>
<li>Create a pull request from a branch on your fork to the main repository</li>
<li>Get comments on the pull request</li>
<li>Force-push to the same branch to update the state of the pull request</li>
<li>Somebody clicks merge</li>
</ol>
<p>Basically the same flow is also used on Gitlab and the other smaller git hosting services. This flow works reasonably well. It gets slightly more annoying after the first pull request because you actually have to keep your own local branch up to date.</p>
<p>In theory this also gives some nice discoverability of people working on the project by looking at the forks of the project. In practice this is a bunch of outdated copies of the project by people who have mistaken the fork button for a like button.</p>
<p>From a maintainer point of view this flow also works alright, unless your project starts to grow. For example when postmarketOS was still on Github we ran into the issue that the merge button isn't really useful. Once you have a reasonable volume of pull requests the branches of those pull requests get outdated quickly meaning they have to be rebased before merging or every change will have an extra merge commit in the history.</p>
<p>In the postmarketOS case it was decided that merge commits are extra noise in the git history we'd like to avoid so we'd need to rebase things, and to properly rebase we have to do it from the command line because Github can't deal at all with conflicts. Rebasing from the command line also gives a lot more flexibility with squashing and having a nice commit message.</p>
<p>The only reason that merge button was used on Github was because Github can't seem to mark the pull request as merged if it isn't done by the button.
The all-knowing button from Github</p>
<p>The old workflow documentation postmarketOS had when Github was used can be read in the wiki history: <a href="https://wiki.postmarketos.org/index.php?title=Merge_Workflow&amp;oldid=3441">https://wiki.postmarketos.org/index.php?title=Merge_Workflow&amp;oldid=3441</a></p>
<p>Now we've moved to Gitlab we're basically dealing with the same issue, we have to mess with the commits before merging so we're always force-pushing to the git fork of the author of the pull request (which they have to enable on the merge request, if they don't we first have to tell them to enable that checkbox) and then finally merge them with the button in the web UI so Gitlab doesn't lose track of what happened.</p>
<h2>The git-send-email flow</h2>
<p>The flow for pull requests in github isn't the original way to make pull requests. Since git was originally written for the development of the Linux kernel it has been designed with the workflow of the kernel in mind. The kernel uses mailing lists.</p>
<p>[insert image of horrified developers here]</p>
<p>The first patch I emailed was with the assistence of <a href="https://git-send-email.io/">https://git-send-email.io/</a>, I needed to learn how to use the email flow because at the time I was working on my very first kernel patch. This was quite a daunting task involing triple-checking everything against the <a href="https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html">patch submission documentation</a> for Linux which describes the easy 16 step process.</p>
<p>Then after the final step the email gets sent out and you wait... for response emails.</p>
<p>Since then I've made contributions to projects hosted on Sourcehut, which also uses the email workflow, and now I also maintain some projects on this platform. For example <a href="https://git.sr.ht/~martijnbraam/megapixels">Megapixels</a>.</p>
<p>This is the workflow for submitting a patch to a project using the email flow:</p>
<ol>
<li>Clone the repository locally</li>
<li>Make your changes on your local checkout</li>
<li>Run git send-email with a ref pointing to one or a range of commits</li>
<li>Get comments as response to the patch as emails, mirrored on the webpage of the mailing list</li>
<li>Fix up your previous mistakes, run git send-email again with the -v2 argument to send an updated version</li>
<li>The maintainer applies the patch from the email.</li>
</ol>
<p>As a maintainer getting the patches like this is quite nice since unless there's a conflict you don't have to merge branches or rebase things, the patches is just ... a patch, it only has the changes from the author, not the full git history.</p>
<p>Also, one thing to note about the process above is that, except for receiving the feedback, it will never touch your mail client. Git does SMTP itself and make sure the emails you send out are up-to-spec so maintainers can apply the changes directly by feeding the email into git am</p>
<p>If your main complaint is that email is horrible to work with, the issue is most likely not email, it's probably your mail client.</p>
<p>One of the other main issues with the email workflow is that you can't just see the full state of the "pull request" because there's no nice pull request page to see what's happening. This is one of the main reasons I like the mailing lists on Sourcehut, the patch view fixes most of the visibility issues, for example this simple patch: <a href="https://lists.sr.ht/~martijnbraam/public-inbox/patches/14382">https://lists.sr.ht/~martijnbraam/public-inbox/patches/14382</a>
The overview of a patch submitted to a Sourcehut mailing list</p>
<p>There you see the patch description in the first block, which is in this case didn't have any extra text added in the git send-email stage, so it only shows a summary of the changes in this patch.</p>
<p>Below that is the actual patch, with the subject of the patch as header and then showing the full commit message below that if there were more lines and then the full diff. This patch can also be exported directly as a .patch file using the link right of the subject.</p>
<p>Finally, below the diff is a comment from Eyal who applied this patch to the development branch and thanked the author; the mailing list will generate a nice threaded view here if there's more discussion.</p>
<p>The block on the right will show the status of the patch, APPLIED in this case and gives some extra tools to get a copy of the full patchset that can be applied using git am</p>
<h2>Conclusion</h2>
<p>I personally prefer the e-mail workflow now, it saves me from keeping branches/forks up to date as with this workflow only diffs are sent around. Also after working in Gitlab for most of the things I do on postmarketOS I really like how quickly sourcehut pages load and that I just can get all info from the patch without clicking on tabs to switch between comments, diffs and commit messages with loading times in between.</p>
<p>Also one nice improvement is that instead of doing half the maintainer flow in the browser by clicking things and half by patching stuff up in my local git branch and force pushing that, it just lets me do everything in the shell and then just send an email back telling the author their patch got merged.</p>
<p>All together people are most likely already used to having all the comments and info emailed to them as notifications, it's just that in the gitlab/hub case it will send you a link to continue on their website and in the sourcehut/email flow case the email is everything you need to continue without ever opening the browser.</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 77
- 0
cache/2021/68c1cb8256a8472b2711a0ffb5e7921e/index.md View File

@@ -0,0 +1,77 @@
title: Git email flow vs Github flow
url: https://blog.brixit.nl/git-email-flow-versus-github-flow/
hash_url: 68c1cb8256a8472b2711a0ffb5e7921e

So I've been using the Github flow for some years now from both the maintainer side and contributor side to open source projects. I've also been using the email workflow for git from both sides for about a year now. Using email for git sounded quite horrible before I actually started using it. Now I prefer it so I thought I would document my experience here.

## The Github flow

This isn't strictly for Github, it's the flow many developers are accustomed to:

1. Fork the project repo
2. Make a change on your fork
3. Create a pull request from a branch on your fork to the main repository
4. Get comments on the pull request
5. Force-push to the same branch to update the state of the pull request
6. Somebody clicks merge

Basically the same flow is also used on Gitlab and the other smaller git hosting services. This flow works reasonably well. It gets slightly more annoying after the first pull request because you actually have to keep your own local branch up to date.

In theory this also gives some nice discoverability of people working on the project by looking at the forks of the project. In practice this is a bunch of outdated copies of the project by people who have mistaken the fork button for a like button.

From a maintainer point of view this flow also works alright, unless your project starts to grow. For example when postmarketOS was still on Github we ran into the issue that the merge button isn't really useful. Once you have a reasonable volume of pull requests the branches of those pull requests get outdated quickly meaning they have to be rebased before merging or every change will have an extra merge commit in the history.

In the postmarketOS case it was decided that merge commits are extra noise in the git history we'd like to avoid so we'd need to rebase things, and to properly rebase we have to do it from the command line because Github can't deal at all with conflicts. Rebasing from the command line also gives a lot more flexibility with squashing and having a nice commit message.

The only reason that merge button was used on Github was because Github can't seem to mark the pull request as merged if it isn't done by the button.
The all-knowing button from Github

The old workflow documentation postmarketOS had when Github was used can be read in the wiki history: [https://wiki.postmarketos.org/index.php?title=Merge_Workflow&oldid=3441](https://wiki.postmarketos.org/index.php?title=Merge_Workflow&oldid=3441)

Now we've moved to Gitlab we're basically dealing with the same issue, we have to mess with the commits before merging so we're always force-pushing to the git fork of the author of the pull request (which they have to enable on the merge request, if they don't we first have to tell them to enable that checkbox) and then finally merge them with the button in the web UI so Gitlab doesn't lose track of what happened.

## The git-send-email flow

The flow for pull requests in github isn't the original way to make pull requests. Since git was originally written for the development of the Linux kernel it has been designed with the workflow of the kernel in mind. The kernel uses mailing lists.

[insert image of horrified developers here]

The first patch I emailed was with the assistence of [https://git-send-email.io/](https://git-send-email.io/), I needed to learn how to use the email flow because at the time I was working on my very first kernel patch. This was quite a daunting task involing triple-checking everything against the [patch submission documentation](https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html) for Linux which describes the easy 16 step process.

Then after the final step the email gets sent out and you wait... for response emails.

Since then I've made contributions to projects hosted on Sourcehut, which also uses the email workflow, and now I also maintain some projects on this platform. For example [Megapixels](https://git.sr.ht/~martijnbraam/megapixels).

This is the workflow for submitting a patch to a project using the email flow:

1. Clone the repository locally
2. Make your changes on your local checkout
3. Run git send-email with a ref pointing to one or a range of commits
4. Get comments as response to the patch as emails, mirrored on the webpage of the mailing list
5. Fix up your previous mistakes, run git send-email again with the -v2 argument to send an updated version
6. The maintainer applies the patch from the email.

As a maintainer getting the patches like this is quite nice since unless there's a conflict you don't have to merge branches or rebase things, the patches is just ... a patch, it only has the changes from the author, not the full git history.

Also, one thing to note about the process above is that, except for receiving the feedback, it will never touch your mail client. Git does SMTP itself and make sure the emails you send out are up-to-spec so maintainers can apply the changes directly by feeding the email into git am

If your main complaint is that email is horrible to work with, the issue is most likely not email, it's probably your mail client.

One of the other main issues with the email workflow is that you can't just see the full state of the "pull request" because there's no nice pull request page to see what's happening. This is one of the main reasons I like the mailing lists on Sourcehut, the patch view fixes most of the visibility issues, for example this simple patch: [https://lists.sr.ht/~martijnbraam/public-inbox/patches/14382](https://lists.sr.ht/~martijnbraam/public-inbox/patches/14382)
The overview of a patch submitted to a Sourcehut mailing list

There you see the patch description in the first block, which is in this case didn't have any extra text added in the git send-email stage, so it only shows a summary of the changes in this patch.

Below that is the actual patch, with the subject of the patch as header and then showing the full commit message below that if there were more lines and then the full diff. This patch can also be exported directly as a .patch file using the link right of the subject.

Finally, below the diff is a comment from Eyal who applied this patch to the development branch and thanked the author; the mailing list will generate a nice threaded view here if there's more discussion.

The block on the right will show the status of the patch, APPLIED in this case and gives some extra tools to get a copy of the full patchset that can be applied using git am

## Conclusion

I personally prefer the e-mail workflow now, it saves me from keeping branches/forks up to date as with this workflow only diffs are sent around. Also after working in Gitlab for most of the things I do on postmarketOS I really like how quickly sourcehut pages load and that I just can get all info from the patch without clicking on tabs to switch between comments, diffs and commit messages with loading times in between.

Also one nice improvement is that instead of doing half the maintainer flow in the browser by clicking things and half by patching stuff up in my local git branch and force pushing that, it just lets me do everything in the shell and then just send an email back telling the author their patch got merged.

All together people are most likely already used to having all the comments and info emailed to them as notifications, it's just that in the gitlab/hub case it will send you a link to continue on their website and in the sourcehut/email flow case the email is everything you need to continue without ever opening the browser.

+ 363
- 0
cache/2021/ea19b309a39227f6b370ec83e6c63028/index.html View File

@@ -0,0 +1,363 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>The advantages of an email-driven git workflow (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://drewdevault.com/2018/07/02/Email-driven-git.html">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>The advantages of an email-driven git workflow</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://drewdevault.com/2018/07/02/Email-driven-git.html" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<p><a href="https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.18.0.txt">git 2.18.0</a> has been released, and with it my first contribution to
git has shipped! My patch was for a git feature which remains disappointingly
obscure: <a href="https://git-scm.com/docs/git-send-email">git send-email</a>. I want to
introduce my readers to this feature and speak to the benefits of using an
email-driven git workflow - the workflow git was originally designed for.</p>
<p>Email isn’t as sexy as GitHub (and its imitators), but it has several
advantages over the latter. Email is standardized, federated, well-understood,
and venerable. A very large body of email-related software exists and is equally
reliable and well-understood. You can interact with email using only open source
software and customize your workflow at every level of the stack - filtering,
organizing, forwarding, replying, and so on; in any manner you choose.</p>
<p>Git has several built-in tools for leveraging email. The first one of note is
<a href="https://git-scm.com/docs/git-format-patch">format-patch</a>. This can take a git
commit (or series of commits) and format them as plaintext emails with embedded
diffs. Here’s a small example of its output:</p>
<pre><code class="language-mail" data-lang="mail">From 8f5045c871c3060ff5f5f99ce1ada09f4b4cd105 Mon Sep 17 00:00:00 2001
From: Drew DeVault &lt;sir@cmpwn.com&gt;
Date: Wed, 2 May 2018 08:59:27 -0400
Subject: [PATCH] Silently ignore touch_{motion,up} for unknown ids

---
types/wlr_seat.c | 2 --
1 file changed, 2 deletions(-)

diff --git a/types/wlr_seat.c b/types/wlr_seat.c
index f77a492d..975746db 100644
--- a/types/wlr_seat.c
+++ b/types/wlr_seat.c
@@ -1113,7 +1113,6 @@ void wlr_seat_touch_notify_up(struct wlr_seat *seat, uint32_t time,
struct wlr_seat_touch_grab *grab = seat-&gt;touch_state.grab;
struct wlr_touch_point *point = wlr_seat_touch_get_point(seat, touch_id);
if (!point) {
- wlr_log(L_ERROR, "got touch up for unknown touch point");
return;
}

@@ -1128,7 +1127,6 @@ void wlr_seat_touch_notify_motion(struct wlr_seat *seat, uint32_t time,
struct wlr_seat_touch_grab *grab = seat-&gt;touch_state.grab;
struct wlr_touch_point *point = wlr_seat_touch_get_point(seat, touch_id);
if (!point) {
- wlr_log(L_ERROR, "got touch motion for unknown touch point");
return;
}

--
2.18.0

</code></pre>
<p>git format-patch is at the bottom of git’s stack of outgoing email features. You
can send the emails it generates manually, but usually you’ll use git send-email
instead. It logs into the SMTP server of your choice and sends the email for
you, after running git format-patch for you and giving you an opportunity to
make any edits you like. Given that most popular email clients these days are
awful and can’t handle basic tasks like “sending email” properly, I strongly
recommend this tool over attempting to send format-patch’s output yourself.</p>
<p><img src="https://sr.ht/wmKv.jpg"></p>
<p>
<em>
I put a notch in my keyboard for each person who ignores my advice,
struggles through sending emails manually, and eventually comes around
to letting git send-email do it for them.
</em>
</p>
<p>I recommend a few settings to apply to git send-email to make your workflow a
bit easier. One is <code>git config --global sendemail.verify off</code>, which turns off
a sometimes-annoying and always-confusing validation step which checks for
features only supported by newer SMTP servers - newer, in this case, meaning
more recent than November of 1995. I started a thread on the git mailing list
this week to discuss changing this option to off by default.</p>
<p>You can also set the default recipient for a given repository by using a local
git config: <code>git config sendemail.to admin@example.org</code>. This lets you skip a
step if you send your patches to a consistent destination for that project, like
a mailing list. I also recommend <code>git config --global sendemail.annotate yes</code>,
which will always open the emails in your editor to allow you to make changes
(you can get this with <code>--annotate</code> if you don’t want it every time).</p>
<p>The main edit you’ll want to make when annotating is to provide what some call
“timely commentary” on your patch. Immediately following the <code>---</code> after your
commit message, you can add a summary of your changes which can be seen by the
recipient, but doesn’t appear in the final commit log. This is a useful place to
talk about anything useful regarding the testing, review, or integration of your
changes. You may also want to edit the <code>[PATCH]</code> text in the subject line to
something like <code>[PATCH v2]</code> - this can also be done with the <code>-v</code> flag as well.
I also like to add additional To’s, Cc’s, etc at this time.</p>
<p>Git also provides tools for the recipient of your messages. One such tool is
<a href="https://git-scm.com/docs/git-am">git am</a>, which accepts an email prepared with
format-patch and integrates it into their repository. Several flags are provided
to assist with common integration activities, like signing off on the commit or
attempting a 3-way merge. The difficult part can be getting the email to git am
in the first place. If you simply use the GMail web UI, this can be difficult. I
use <a href="http://www.mutt.org/">mutt</a>, a TUI email client, to manage incoming
patches. This is useful for being able to compose replies with vim rather than
fighting some other mail client to write emails the way I want, but more
importantly it has the <code>|</code> key, which prompts you for a command to pipe the
email into. Other tools like <a href="http://www.offlineimap.org/">OfflineIMAP</a> are also
useful here.</p>
<p>On the subject of composing replies, reviewing patches is quite easy with the
email approach as well. Many bad, yet sadly popular email clients have
popularized the idea that the sender’s message is immutable, encouraging you to
<a href="https://en.wikipedia.org/wiki/Posting_style#Top-posting">top post</a> and leave an endlessly growing chain of replies
underneath your message. A secret these email clients have kept from you is that
you are, in fact, permitted by the mail RFCs to edit the sender’s message as you
please when replying - a style called <a href="https://en.wikipedia.org/wiki/Posting_style#Bottom-posting">bottom posting</a>. I
strongly encourage you to get comfortable doing this in general, but it’s
essential when reviewing patches received over email.</p>
<p>In this manner, you can dissect the patch and respond to specific parts of it
requesting changes or clarifications. It’s just email - you can reply, forward
the message, Cc interested parties, start several chains of discussion, and so
on. I recently sent the following feedback on a patch I received:</p>
<pre><code class="language-mail" data-lang="mail">Date: Mon, 11 Jun 2018 14:19:22 -0400
From: Drew DeVault &lt;sir@cmpwn.com&gt;
To: Gregory Mullen &lt;omitted&gt;
Subject: Re: [PATCH 2/3 todo] Filter private events from events feed

On 2018-06-11 9:14 AM, Gregory Mullen wrote:
&gt; diff --git a/todosrht/alembic/versions/cb9732f3364c_clear_defaults_from_tickets_to_support_.py b/todosrht/alembic/versions/cb9732f3364c_clear_defaults_from_tickets_to_support_.py
&gt; -%&lt;-
&gt; +class FlagType(types.TypeDecorator):

I think you can safely import the srht FlagType here without implicating
the entire sr.ht database support code

&gt; diff --git a/todosrht/blueprints/html.py b/todosrht/blueprints/html.py
&gt; -%&lt;-
&gt; +def collect_events(target, count):
&gt; + events = []
&gt; + for e in EventNotification.query.filter(EventNotification.user_id == target.id).order_by(EventNotification.created.desc()):

80 cols

I suspect this 'collect_events' function can be done entirely in SQL
without having to process permissions in Python and do several SQL
round-trips

&gt; @html.route("/~&lt;username&gt;")
&gt; def user_GET(username):
&gt; - print(username)

Whoops! Nice catch.

&gt; user = User.query.filter(User.username == username.lower()).first()
&gt; if not user:
&gt; abort(404)
&gt; trackers, _ = get_tracker(username, None)
&gt; # TODO: only show public events (or events the current user can see)

Can remove the comment
</code></pre>
<p>Obviously this isn’t the whole patch we’re seeing - I’ve edited it down to just
the parts I want to talk about. I also chose to leave the file names in to aid
in navigating my feedback, with casual <code>-%&lt;-</code> symbols indicating where I had
trimmed out parts of the patch. This approach is common and effective.</p>
<p>The main disadvantage of email driven development is that some people are more
comfortable working with email in clients which are not well-suited to this kind
of work. Popular email clients have caused terrible ideas like HTML email to
proliferate, not only enabling spam, privacy leaks, and security
vulnerabilities, but also making it more difficult for people to write emails
that can be understood by git or tolerated by advanced email users.</p>
<p>I don’t think that the solution to these problems is to leave these powerful
tools hanging in the wind and move to less powerful models like GitHub’s pull
requests. This is why on my own platform, <a href="https://sr.ht">sr.ht</a>, I chose to
embrace git’s email-driven approach, and extend it with new tools that make it
easier to participate without directly using email. For those like me, I still
want the email to be there so you can dig my heels in and do it old-school, but
I appreciate that it’s not for everyone.</p>
<p>I started working on the sr.ht mailing list service a couple of weeks ago, which
is where these goals will be realized with new email-driven code review tools.
My friend <a href="https://emersion.fr">Simon</a> has been helping out with a Python module
named <a href="https://git.sr.ht/~emersion/python-emailthreads/">emailthreads</a> which can
be used to parse email discussions - with a surprising degree of accuracy,
considering the flexibility of email. Once I get these tools into a usable
state, we’ll likely see sr.ht registrations finally opened to the general public
(interested in trying it earlier? <a href="mailto:sir@cmpwn.com">Email me</a>). Of course,
it’s all <a href="https://git.sr.ht/~sircmpwn/?search=sr.ht">open source</a>, so you can
follow along and try it on your own infrastructure if you like.</p>
<p>Using email for git scales extremely well. The canonical project, of course, is
the Linux kernel. A change is made to the Linux kernel an average of 7 times per
hour, constantly. It is maintained by dozens of veritable clans of software
engineers hacking on dozens of modules, and email allows these changes to
efficiently flow code throughout the system. Without email, Linux’s maintenance
model would be impossible. It’s worth noting that git was designed for
maintaining Linux, of course.</p>
<p>With the right setup, it’s well suited to small projects as well. Sending a
patch along for review is a single git command. It lands directly in the
maintainer’s inbox and can be integrated with a handful of keystrokes. All of
this works without any centralization or proprietary software involved. We
should embrace this!</p>
<hr>
<p>Related articles sent in by readers:</p>
<p><a href="https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html">Mailing lists vs Github</a>
by Joe Nelson</p>
<p><a href="https://web.archive.org/web/20180522180815/https://dpc.pw/blog/2017/08/youre-using-git-wrong/">You’re using git wrong</a> by
Dawid Ciężarkiewicz</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 194
- 0
cache/2021/ea19b309a39227f6b370ec83e6c63028/index.md View File

@@ -0,0 +1,194 @@
title: The advantages of an email-driven git workflow
url: https://drewdevault.com/2018/07/02/Email-driven-git.html
hash_url: ea19b309a39227f6b370ec83e6c63028

<p><a href="https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.18.0.txt">git 2.18.0</a> has been released, and with it my first contribution to
git has shipped! My patch was for a git feature which remains disappointingly
obscure: <a href="https://git-scm.com/docs/git-send-email">git send-email</a>. I want to
introduce my readers to this feature and speak to the benefits of using an
email-driven git workflow - the workflow git was originally designed for.</p>
<p>Email isn’t as sexy as GitHub (and its imitators), but it has several
advantages over the latter. Email is standardized, federated, well-understood,
and venerable. A very large body of email-related software exists and is equally
reliable and well-understood. You can interact with email using only open source
software and customize your workflow at every level of the stack - filtering,
organizing, forwarding, replying, and so on; in any manner you choose.</p>
<p>Git has several built-in tools for leveraging email. The first one of note is
<a href="https://git-scm.com/docs/git-format-patch">format-patch</a>. This can take a git
commit (or series of commits) and format them as plaintext emails with embedded
diffs. Here’s a small example of its output:</p>
<pre><code class="language-mail" data-lang="mail">From 8f5045c871c3060ff5f5f99ce1ada09f4b4cd105 Mon Sep 17 00:00:00 2001
From: Drew DeVault &lt;sir@cmpwn.com&gt;
Date: Wed, 2 May 2018 08:59:27 -0400
Subject: [PATCH] Silently ignore touch_{motion,up} for unknown ids

---
types/wlr_seat.c | 2 --
1 file changed, 2 deletions(-)

diff --git a/types/wlr_seat.c b/types/wlr_seat.c
index f77a492d..975746db 100644
--- a/types/wlr_seat.c
+++ b/types/wlr_seat.c
@@ -1113,7 +1113,6 @@ void wlr_seat_touch_notify_up(struct wlr_seat *seat, uint32_t time,
struct wlr_seat_touch_grab *grab = seat-&gt;touch_state.grab;
struct wlr_touch_point *point = wlr_seat_touch_get_point(seat, touch_id);
if (!point) {
- wlr_log(L_ERROR, "got touch up for unknown touch point");
return;
}
@@ -1128,7 +1127,6 @@ void wlr_seat_touch_notify_motion(struct wlr_seat *seat, uint32_t time,
struct wlr_seat_touch_grab *grab = seat-&gt;touch_state.grab;
struct wlr_touch_point *point = wlr_seat_touch_get_point(seat, touch_id);
if (!point) {
- wlr_log(L_ERROR, "got touch motion for unknown touch point");
return;
}
--
2.18.0

</code></pre><p>git format-patch is at the bottom of git’s stack of outgoing email features. You
can send the emails it generates manually, but usually you’ll use git send-email
instead. It logs into the SMTP server of your choice and sends the email for
you, after running git format-patch for you and giving you an opportunity to
make any edits you like. Given that most popular email clients these days are
awful and can’t handle basic tasks like “sending email” properly, I strongly
recommend this tool over attempting to send format-patch’s output yourself.</p>
<p><img src="https://sr.ht/wmKv.jpg"></p>
<p>
<em>
I put a notch in my keyboard for each person who ignores my advice,
struggles through sending emails manually, and eventually comes around
to letting git send-email do it for them.
</em>
</p>
<p>I recommend a few settings to apply to git send-email to make your workflow a
bit easier. One is <code>git config --global sendemail.verify off</code>, which turns off
a sometimes-annoying and always-confusing validation step which checks for
features only supported by newer SMTP servers - newer, in this case, meaning
more recent than November of 1995. I started a thread on the git mailing list
this week to discuss changing this option to off by default.</p>
<p>You can also set the default recipient for a given repository by using a local
git config: <code>git config sendemail.to admin@example.org</code>. This lets you skip a
step if you send your patches to a consistent destination for that project, like
a mailing list. I also recommend <code>git config --global sendemail.annotate yes</code>,
which will always open the emails in your editor to allow you to make changes
(you can get this with <code>--annotate</code> if you don’t want it every time).</p>
<p>The main edit you’ll want to make when annotating is to provide what some call
“timely commentary” on your patch. Immediately following the <code>---</code> after your
commit message, you can add a summary of your changes which can be seen by the
recipient, but doesn’t appear in the final commit log. This is a useful place to
talk about anything useful regarding the testing, review, or integration of your
changes. You may also want to edit the <code>[PATCH]</code> text in the subject line to
something like <code>[PATCH v2]</code> - this can also be done with the <code>-v</code> flag as well.
I also like to add additional To’s, Cc’s, etc at this time.</p>
<p>Git also provides tools for the recipient of your messages. One such tool is
<a href="https://git-scm.com/docs/git-am">git am</a>, which accepts an email prepared with
format-patch and integrates it into their repository. Several flags are provided
to assist with common integration activities, like signing off on the commit or
attempting a 3-way merge. The difficult part can be getting the email to git am
in the first place. If you simply use the GMail web UI, this can be difficult. I
use <a href="http://www.mutt.org/">mutt</a>, a TUI email client, to manage incoming
patches. This is useful for being able to compose replies with vim rather than
fighting some other mail client to write emails the way I want, but more
importantly it has the <code>|</code> key, which prompts you for a command to pipe the
email into. Other tools like <a href="http://www.offlineimap.org/">OfflineIMAP</a> are also
useful here.</p>
<p>On the subject of composing replies, reviewing patches is quite easy with the
email approach as well. Many bad, yet sadly popular email clients have
popularized the idea that the sender’s message is immutable, encouraging you to
<a href="https://en.wikipedia.org/wiki/Posting_style#Top-posting">top post</a> and leave an endlessly growing chain of replies
underneath your message. A secret these email clients have kept from you is that
you are, in fact, permitted by the mail RFCs to edit the sender’s message as you
please when replying - a style called <a href="https://en.wikipedia.org/wiki/Posting_style#Bottom-posting">bottom posting</a>. I
strongly encourage you to get comfortable doing this in general, but it’s
essential when reviewing patches received over email.</p>
<p>In this manner, you can dissect the patch and respond to specific parts of it
requesting changes or clarifications. It’s just email - you can reply, forward
the message, Cc interested parties, start several chains of discussion, and so
on. I recently sent the following feedback on a patch I received:</p>
<pre><code class="language-mail" data-lang="mail">Date: Mon, 11 Jun 2018 14:19:22 -0400
From: Drew DeVault &lt;sir@cmpwn.com&gt;
To: Gregory Mullen &lt;omitted&gt;
Subject: Re: [PATCH 2/3 todo] Filter private events from events feed

On 2018-06-11 9:14 AM, Gregory Mullen wrote:
&gt; diff --git a/todosrht/alembic/versions/cb9732f3364c_clear_defaults_from_tickets_to_support_.py b/todosrht/alembic/versions/cb9732f3364c_clear_defaults_from_tickets_to_support_.py
&gt; -%&lt;-
&gt; +class FlagType(types.TypeDecorator):

I think you can safely import the srht FlagType here without implicating
the entire sr.ht database support code

&gt; diff --git a/todosrht/blueprints/html.py b/todosrht/blueprints/html.py
&gt; -%&lt;-
&gt; +def collect_events(target, count):
&gt; + events = []
&gt; + for e in EventNotification.query.filter(EventNotification.user_id == target.id).order_by(EventNotification.created.desc()):

80 cols

I suspect this 'collect_events' function can be done entirely in SQL
without having to process permissions in Python and do several SQL
round-trips

&gt; @html.route("/~&lt;username&gt;")
&gt; def user_GET(username):
&gt; - print(username)

Whoops! Nice catch.

&gt; user = User.query.filter(User.username == username.lower()).first()
&gt; if not user:
&gt; abort(404)
&gt; trackers, _ = get_tracker(username, None)
&gt; # TODO: only show public events (or events the current user can see)

Can remove the comment
</code></pre><p>Obviously this isn’t the whole patch we’re seeing - I’ve edited it down to just
the parts I want to talk about. I also chose to leave the file names in to aid
in navigating my feedback, with casual <code>-%&lt;-</code> symbols indicating where I had
trimmed out parts of the patch. This approach is common and effective.</p>
<p>The main disadvantage of email driven development is that some people are more
comfortable working with email in clients which are not well-suited to this kind
of work. Popular email clients have caused terrible ideas like HTML email to
proliferate, not only enabling spam, privacy leaks, and security
vulnerabilities, but also making it more difficult for people to write emails
that can be understood by git or tolerated by advanced email users.</p>
<p>I don’t think that the solution to these problems is to leave these powerful
tools hanging in the wind and move to less powerful models like GitHub’s pull
requests. This is why on my own platform, <a href="https://sr.ht">sr.ht</a>, I chose to
embrace git’s email-driven approach, and extend it with new tools that make it
easier to participate without directly using email. For those like me, I still
want the email to be there so you can dig my heels in and do it old-school, but
I appreciate that it’s not for everyone.</p>
<p>I started working on the sr.ht mailing list service a couple of weeks ago, which
is where these goals will be realized with new email-driven code review tools.
My friend <a href="https://emersion.fr">Simon</a> has been helping out with a Python module
named <a href="https://git.sr.ht/~emersion/python-emailthreads/">emailthreads</a> which can
be used to parse email discussions - with a surprising degree of accuracy,
considering the flexibility of email. Once I get these tools into a usable
state, we’ll likely see sr.ht registrations finally opened to the general public
(interested in trying it earlier? <a href="mailto:sir@cmpwn.com">Email me</a>). Of course,
it’s all <a href="https://git.sr.ht/~sircmpwn/?search=sr.ht">open source</a>, so you can
follow along and try it on your own infrastructure if you like.</p>
<p>Using email for git scales extremely well. The canonical project, of course, is
the Linux kernel. A change is made to the Linux kernel an average of 7 times per
hour, constantly. It is maintained by dozens of veritable clans of software
engineers hacking on dozens of modules, and email allows these changes to
efficiently flow code throughout the system. Without email, Linux’s maintenance
model would be impossible. It’s worth noting that git was designed for
maintaining Linux, of course.</p>
<p>With the right setup, it’s well suited to small projects as well. Sending a
patch along for review is a single git command. It lands directly in the
maintainer’s inbox and can be integrated with a handful of keystrokes. All of
this works without any centralization or proprietary software involved. We
should embrace this!</p>
<hr>
<p>Related articles sent in by readers:</p>
<p><a href="https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html">Mailing lists vs Github</a>
by Joe Nelson</p>
<p><a href="https://web.archive.org/web/20180522180815/https://dpc.pw/blog/2017/08/youre-using-git-wrong/">You’re using git wrong</a> by
Dawid Ciężarkiewicz</p>

+ 8
- 0
cache/2021/index.html View File

@@ -217,6 +217,8 @@
<li><a href="/david/cache/2021/13fac7e78342ffd7e5286a6d5519e19e/" title="Accès à l’article dans le cache local : Ils construisaient leurs maisons tous ensemble puis les tiraient au sort : l’histoire des Castors">Ils construisaient leurs maisons tous ensemble puis les tiraient au sort : l’histoire des Castors</a> (<a href="https://www.18h39.fr/articles/ils-construisaient-leurs-maisons-tous-ensemble-puis-les-tiraient-au-sort-lhistoire-des-castors.html" title="Accès à l’article original distant : Ils construisaient leurs maisons tous ensemble puis les tiraient au sort : l’histoire des Castors">original</a>)</li>
<li><a href="/david/cache/2021/3b811b75e116cdc0ac8f6f1b2fa60f12/" title="Accès à l’article dans le cache local : Introduction to SourceHut culture">Introduction to SourceHut culture</a> (<a href="https://man.sr.ht/staff/culture.md" title="Accès à l’article original distant : Introduction to SourceHut culture">original</a>)</li>
<li><a href="/david/cache/2021/059ace3d9bcdbd911d83f1da84ced326/" title="Accès à l’article dans le cache local : Eco-conception, le brouillard à venir">Eco-conception, le brouillard à venir</a> (<a href="https://gauthierroussilhe.com/post/ecoconception-critique.html" title="Accès à l’article original distant : Eco-conception, le brouillard à venir">original</a>)</li>
<li><a href="/david/cache/2021/a9e4daf32281eaee0adaa39e32d28890/" title="Accès à l’article dans le cache local : Dropping Support For IE11 Is Progressive Enhancement">Dropping Support For IE11 Is Progressive Enhancement</a> (<a href="https://blog.carlmjohnson.net/post/2020/time-to-kill-ie11/" title="Accès à l’article original distant : Dropping Support For IE11 Is Progressive Enhancement">original</a>)</li>
@@ -543,6 +545,8 @@
<li><a href="/david/cache/2021/b82c800f728b00d9056b38087e026598/" title="Accès à l’article dans le cache local : How Doctors Die">How Doctors Die</a> (<a href="https://www.saturdayeveningpost.com/2013/03/how-doctors-die/" title="Accès à l’article original distant : How Doctors Die">original</a>)</li>
<li><a href="/david/cache/2021/64ee5051fec3060fea59c93823222ca1/" title="Accès à l’article dans le cache local : Une interview dans Le Un en novembre 2021">Une interview dans Le Un en novembre 2021</a> (<a href="https://jancovici.com/publications-et-co/interviews/une-interview-dans-le-un-en-novembre-2021/" title="Accès à l’article original distant : Une interview dans Le Un en novembre 2021">original</a>)</li>
<li><a href="/david/cache/2021/8e1892fe6c88157b7fd4c2bd8afc79cd/" title="Accès à l’article dans le cache local : It’s time for a healthy tech approach">It’s time for a healthy tech approach</a> (<a href="https://helloanselm.com/writings/its-time-for-a-healthy-tech-approach" title="Accès à l’article original distant : It’s time for a healthy tech approach">original</a>)</li>
<li><a href="/david/cache/2021/55a2cd812fc17423f29937b213fe219b/" title="Accès à l’article dans le cache local : All the Ways Spotify Tracks You-and How to Stop It">All the Ways Spotify Tracks You-and How to Stop It</a> (<a href="https://www.wired.com/story/spotify-tracking-how-to-stop-it/" title="Accès à l’article original distant : All the Ways Spotify Tracks You-and How to Stop It">original</a>)</li>
@@ -625,6 +629,8 @@
<li><a href="/david/cache/2021/74eae1dc26bd4537941491b4e7e201bc/" title="Accès à l’article dans le cache local : Cheating Entropy with Native Web Technologies">Cheating Entropy with Native Web Technologies</a> (<a href="https://blog.jim-nielsen.com/2020/cheating-entropy-with-native-web-tech/" title="Accès à l’article original distant : Cheating Entropy with Native Web Technologies">original</a>)</li>
<li><a href="/david/cache/2021/ea19b309a39227f6b370ec83e6c63028/" title="Accès à l’article dans le cache local : The advantages of an email-driven git workflow">The advantages of an email-driven git workflow</a> (<a href="https://drewdevault.com/2018/07/02/Email-driven-git.html" title="Accès à l’article original distant : The advantages of an email-driven git workflow">original</a>)</li>
<li><a href="/david/cache/2021/9f3a8d345963dac24bef4df547fef72c/" title="Accès à l’article dans le cache local : Why light text on dark background is a bad idea">Why light text on dark background is a bad idea</a> (<a href="https://tatham.blog/2008/10/13/why-light-text-on-dark-background-is-a-bad-idea/" title="Accès à l’article original distant : Why light text on dark background is a bad idea">original</a>)</li>
<li><a href="/david/cache/2021/626841dd876f103a10391b1b841ba5ae/" title="Accès à l’article dans le cache local : Host your own wikipedia backup">Host your own wikipedia backup</a> (<a href="https://dataswamp.org/~solene/2019-11-13-wikimedia-dump.html" title="Accès à l’article original distant : Host your own wikipedia backup">original</a>)</li>
@@ -669,6 +675,8 @@
<li><a href="/david/cache/2021/d46752726e00de301573576176df1f1c/" title="Accès à l’article dans le cache local : Two articles on SPA or SPA-like sites vs alternatives">Two articles on SPA or SPA-like sites vs alternatives</a> (<a href="https://piperhaywood.com/two-articles-on-spa-or-spa-like-sites-vs-alternatives/" title="Accès à l’article original distant : Two articles on SPA or SPA-like sites vs alternatives">original</a>)</li>
<li><a href="/david/cache/2021/68c1cb8256a8472b2711a0ffb5e7921e/" title="Accès à l’article dans le cache local : Git email flow vs Github flow">Git email flow vs Github flow</a> (<a href="https://blog.brixit.nl/git-email-flow-versus-github-flow/" title="Accès à l’article original distant : Git email flow vs Github flow">original</a>)</li>
<li><a href="/david/cache/2021/5c20cd102357c0140e36a902ca400c8f/" title="Accès à l’article dans le cache local : Beginners in a sea of experts">Beginners in a sea of experts</a> (<a href="https://nedbatchelder.com/blog/202103/beginners_in_a_sea_of_experts.html" title="Accès à l’article original distant : Beginners in a sea of experts">original</a>)</li>
<li><a href="/david/cache/2021/33c4c1d859a2d85c1710ea50628a71b1/" title="Accès à l’article dans le cache local : ☕️ Journal : Acheter de la forêt">☕️ Journal : Acheter de la forêt</a> (<a href="https://oncletom.io/2021/03/12/acheter-de-la-foret/" title="Accès à l’article original distant : ☕️ Journal : Acheter de la forêt">original</a>)</li>

Loading…
Cancel
Save