Message ID | 20210520221359.75615-5-lenaic@lhuard.fr (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | maintenance: use systemd timers on Linux | expand |
On 21/05/21 05.13, Lénaïc Huard wrote: > The existing mechanism for scheduling background maintenance is done > through cron. On Linux systems managed by systemd, systemd provides an > alternative to schedule recurring tasks: systemd timers. > > The main motivations to implement systemd timers in addition to cron > are: > * cron is optional and Linux systems running systemd might not have it > installed. > * The execution of `crontab -l` can tell us if cron is installed but not > if the daemon is actually running. > * With systemd, each service is run in its own cgroup and its logs are > tagged by the service inside journald. With cron, all scheduled tasks > are running in the cron daemon cgroup and all the logs of the > user-scheduled tasks are pretended to belong to the system cron > service. > Concretely, a user that doesn’t have access to the system logs won’t > have access to the log of its own tasks scheduled by cron whereas he > will have access to the log of its own tasks scheduled by systemd > timer. For gender neutrality, we can use he/she instead. > Although `cron` attempts to send email, that email may go unseen by > the user because these days, local mailboxes are not heavily used > anymore. > > In order to schedule git maintenance, we need two unit template files: > * ~/.config/systemd/user/git-maintenance@.service > to define the command to be started by systemd and > * ~/.config/systemd/user/git-maintenance@.timer > to define the schedule at which the command should be run. > > Those units are templates that are parameterized by the frequency. > > Based on those templates, 3 timers are started: > * git-maintenance@hourly.timer > * git-maintenance@daily.timer > * git-maintenance@weekly.timer > > The command launched by those three timers are the same as with the > other scheduling methods: > > git for-each-repo --config=maintenance.repo maintenance run > --schedule=%i > > with the full path for git to ensure that the version of git launched > for the scheduled maintenance is the same as the one used to run > `maintenance start`. > Wouldn't it be `/path/to/git for-each-repo <options>...`? > The timer unit contains `Persistent=true` so that, if the computer is > powered down when a maintenance task should run, the task will be run > when the computer is back powered on. > The title for this patch implied that users running Linux can choose between classic crontab or systemd timers. However, the intent of this patch is we add support for systemd timers. So let's say the title should be "maintenance: add support for systemd timers on Linux".
On 5/21/2021 5:59 AM, Bagas Sanjaya wrote: > On 21/05/21 05.13, Lénaïc Huard wrote: >> The existing mechanism for scheduling background maintenance is done >> through cron. On Linux systems managed by systemd, systemd provides an >> alternative to schedule recurring tasks: systemd timers. >> >> The main motivations to implement systemd timers in addition to cron >> are: >> * cron is optional and Linux systems running systemd might not have it >> installed. >> * The execution of `crontab -l` can tell us if cron is installed but not >> if the daemon is actually running. >> * With systemd, each service is run in its own cgroup and its logs are >> tagged by the service inside journald. With cron, all scheduled tasks >> are running in the cron daemon cgroup and all the logs of the >> user-scheduled tasks are pretended to belong to the system cron >> service. >> Concretely, a user that doesn’t have access to the system logs won’t >> have access to the log of its own tasks scheduled by cron whereas he >> will have access to the log of its own tasks scheduled by systemd >> timer. > > For gender neutrality, we can use he/she instead. Singular "they" is better. Fully accurate and less awkward. Thanks, -Stolee
Hi, On Fri, 21 May 2021, Derrick Stolee wrote: > On 5/21/2021 5:59 AM, Bagas Sanjaya wrote: > > On 21/05/21 05.13, Lénaïc Huard wrote: > >> The existing mechanism for scheduling background maintenance is done > >> through cron. On Linux systems managed by systemd, systemd provides an > >> alternative to schedule recurring tasks: systemd timers. > >> > >> The main motivations to implement systemd timers in addition to cron > >> are: > >> * cron is optional and Linux systems running systemd might not have it > >> installed. > >> * The execution of `crontab -l` can tell us if cron is installed but not > >> if the daemon is actually running. > >> * With systemd, each service is run in its own cgroup and its logs are > >> tagged by the service inside journald. With cron, all scheduled tasks > >> are running in the cron daemon cgroup and all the logs of the > >> user-scheduled tasks are pretended to belong to the system cron > >> service. > >> Concretely, a user that doesn’t have access to the system logs won’t > >> have access to the log of its own tasks scheduled by cron whereas he > >> will have access to the log of its own tasks scheduled by systemd > >> timer. > > > > For gender neutrality, we can use he/she instead. > > Singular "they" is better. Fully accurate and less awkward. I agree. If the singular they was good enough for Shakespeare, it is good enough for anyone. See for yourself: http://itre.cis.upenn.edu/~myl/languagelog/archives/002748.html Ciao, Dscho
Johannes Schindelin wrote: > On Fri, 21 May 2021, Derrick Stolee wrote: > > > On 5/21/2021 5:59 AM, Bagas Sanjaya wrote: > > > On 21/05/21 05.13, Lénaïc Huard wrote: > > >> The existing mechanism for scheduling background maintenance is done > > >> through cron. On Linux systems managed by systemd, systemd provides an > > >> alternative to schedule recurring tasks: systemd timers. > > >> > > >> The main motivations to implement systemd timers in addition to cron > > >> are: > > >> * cron is optional and Linux systems running systemd might not have it > > >> installed. > > >> * The execution of `crontab -l` can tell us if cron is installed but not > > >> if the daemon is actually running. > > >> * With systemd, each service is run in its own cgroup and its logs are > > >> tagged by the service inside journald. With cron, all scheduled tasks > > >> are running in the cron daemon cgroup and all the logs of the > > >> user-scheduled tasks are pretended to belong to the system cron > > >> service. > > >> Concretely, a user that doesn’t have access to the system logs won’t > > >> have access to the log of its own tasks scheduled by cron whereas he > > >> will have access to the log of its own tasks scheduled by systemd > > >> timer. > > > > > > For gender neutrality, we can use he/she instead. > > > > Singular "they" is better. Fully accurate and less awkward. > > I agree. I disagree. > If the singular they was good enough for Shakespeare, Shakespeare: 1. Did not know gammar 2. Invented words as we went along 3. Was no writing prose This is not the kind of English we wish to replicate: "This was the most unkindest cut of all." > See for yourself: > http://itre.cis.upenn.edu/~myl/languagelog/archives/002748.html I do not see a single instance of a singular antecedent there. Not that it matters, because unlike Shakespeare we are wriing classic prose style. The styles could not be more different. The singular they is a controversial topic[1][2], even among linguists. This is a software project, we must not make decrees about proper use of English language, especially when linguists themselves have not yet fully decided. If you want to use "they", go ahead, other people want to use "he/she". The git project should steer cleer of value judgements that one is _better_ than the other. Not to mention that these kinds of promulgations invite the culture war. Cheers. [1] https://time.com/5748649/word-of-year-they-merriam-webster/ [2] https://www.theatlantic.com/culture/archive/2013/01/singular-their-affront-good-writing/319329/
On 2021-05-23 at 18:36:10, Felipe Contreras wrote: > Johannes Schindelin wrote: > > On Fri, 21 May 2021, Derrick Stolee wrote: > > > > > On 5/21/2021 5:59 AM, Bagas Sanjaya wrote: > > > > On 21/05/21 05.13, Lénaïc Huard wrote: > > > >> The existing mechanism for scheduling background maintenance is done > > > >> through cron. On Linux systems managed by systemd, systemd provides an > > > >> alternative to schedule recurring tasks: systemd timers. > > > >> > > > >> The main motivations to implement systemd timers in addition to cron > > > >> are: > > > >> * cron is optional and Linux systems running systemd might not have it > > > >> installed. > > > >> * The execution of `crontab -l` can tell us if cron is installed but not > > > >> if the daemon is actually running. > > > >> * With systemd, each service is run in its own cgroup and its logs are > > > >> tagged by the service inside journald. With cron, all scheduled tasks > > > >> are running in the cron daemon cgroup and all the logs of the > > > >> user-scheduled tasks are pretended to belong to the system cron > > > >> service. > > > >> Concretely, a user that doesn’t have access to the system logs won’t > > > >> have access to the log of its own tasks scheduled by cron whereas he > > > >> will have access to the log of its own tasks scheduled by systemd > > > >> timer. > > > > > > > > For gender neutrality, we can use he/she instead. > > > > > > Singular "they" is better. Fully accurate and less awkward. > > > > I agree. > > I disagree. I'm fully in support of singular "they". It provides a useful pronoun to use in this context, is widely understood and used, is less awkward than "he/she," and is less sexist than the indefinite "he." > > If the singular they was good enough for Shakespeare, > > Shakespeare: > > 1. Did not know gammar > 2. Invented words as we went along > 3. Was no writing prose The point is that it has been used by native English speakers as part of the language for over half a millennium and is widely used and understood. This usage is specified in Merriam Webster[0]: The use of they, their, them, and themselves as pronouns of indefinite gender and indefinite number is well established in speech and writing, even in literary and formal contexts. Wiktionary notes[1] (references omitted): Usage of they as a singular pronoun began in the 1300s and has been common ever since, despite attempts by some grammarians, beginning in 1795, to condemn it as a violation of traditional (Latinate) agreement rules. Some other grammarians have countered that criticism since at least 1896. Fowler's Modern English Usage (third edition) notes that it "is being left unaltered by copy editors" and is "not widely felt to lie in a prohibited zone." Some authors compare use of singular they to widespread use of singular you instead of thou. > The singular they is a controversial topic[1][2], even among linguists. > This is a software project, we must not make decrees about proper use of > English language, especially when linguists themselves have not yet > fully decided. Linguists fit roughly into two camps: prescriptive and descriptive. The former specify rules for people to use, and the latter document language as it is actually used without forming a judgment. While I am not a linguist, I have a B.A. in English, and my views fit firmly into the descriptivist camp. Some prescriptivists think it is acceptable, and some do not. But descriptivists will rightly note that it is and has been commonly used in English across countries, cultures, and contexts for an extended period of time and is therefore generally accepted by most English speakers as a normal part of the language. Since we are writing text for an English language audience who are mostly not linguists, we should probably consider using the language that most people will use in this context. > If you want to use "they", go ahead, other people want to use "he/she". > The git project should steer cleer of value judgements that one is > _better_ than the other. Any time we provide a suggestion in a code review, we are proposing that we have an idea that may be better than the existing one. It may or may not actually be so, but we are proposing it in an effort to make the code and documentation better. No good-faith contributor would propose a suggestion to make the project _worse_. It's completely fine for a contributor to propose that they think an idea is better provided that they do so in a respectful and considerate way, which I think happened here. As with all matters of opinion, whether a thing is truly better or not is unknowable, and the best we can do is to adopt an approach that seems to be the most widely accepted and most provident. In this case, given the fact that singular they is accepted in a wide variety of contexts, including many literary and formal contexts, and even the relatively stalwart Chicago "recognizes that such usage is gaining [further] acceptance," I think it should be fine to use singular they here. You are, of course, free to feel differently. [0] https://www.merriam-webster.com/dictionary/they [1] https://en.wiktionary.org/wiki/they
brian m. carlson wrote: > On 2021-05-23 at 18:36:10, Felipe Contreras wrote: > > Johannes Schindelin wrote: > > > On Fri, 21 May 2021, Derrick Stolee wrote: > > > > On 5/21/2021 5:59 AM, Bagas Sanjaya wrote: > > > > > On 21/05/21 05.13, Lénaïc Huard wrote: > > > > >> The existing mechanism for scheduling background maintenance is done > > > > >> through cron. On Linux systems managed by systemd, systemd provides an > > > > >> alternative to schedule recurring tasks: systemd timers. > > > > >> > > > > >> The main motivations to implement systemd timers in addition to cron > > > > >> are: > > > > >> * cron is optional and Linux systems running systemd might not have it > > > > >> installed. > > > > >> * The execution of `crontab -l` can tell us if cron is installed but not > > > > >> if the daemon is actually running. > > > > >> * With systemd, each service is run in its own cgroup and its logs are > > > > >> tagged by the service inside journald. With cron, all scheduled tasks > > > > >> are running in the cron daemon cgroup and all the logs of the > > > > >> user-scheduled tasks are pretended to belong to the system cron > > > > >> service. > > > > >> Concretely, a user that doesn’t have access to the system logs won’t > > > > >> have access to the log of its own tasks scheduled by cron whereas he > > > > >> will have access to the log of its own tasks scheduled by systemd > > > > >> timer. > > > > > > > > > > For gender neutrality, we can use he/she instead. > > > > > > > > Singular "they" is better. Fully accurate and less awkward. > > > > > > I agree. > > > > I disagree. > > I'm fully in support of singular "they". To each her/his own. > It provides a useful pronoun to use in this context, is widely > understood and used, is less awkward than "he/she," and is less sexist > than the indefinite "he." I disagree. But I wouldn't presume to dictate how other people speak. If you like it, use it. > > > If the singular they was good enough for Shakespeare, > > > > Shakespeare: > > > > 1. Did not know gammar > > 2. Invented words as we went along > > 3. Was no writing prose > > The point is that it has been used by native English speakers as part of > the language for over half a millennium and is widely used and > understood. A similar thing happens with the word "nucular" [1]; it is used by native English speakers as part of the language for many decades and is widely used and understood. Does that mean it's a valid word? Maybe. But does that make "nuclear" invalid? No. You can use "nucular" if you want (many people do). I will use "nuclear". Both can be valid. > This usage is specified in Merriam Webster[0]: Merriam-Webster is not infallible. But fine: let's say they are correct. Where does it say "they" is *better*? Or worse: where does it say "his/her" is discouraged? > > The singular they is a controversial topic[1][2], even among linguists. > > This is a software project, we must not make decrees about proper use of > > English language, especially when linguists themselves have not yet > > fully decided. > > Linguists fit roughly into two camps: prescriptive and descriptive. I am perfectly aware of the two camps, and I have written about it. > While I am not a linguist, I have a B.A. in English, and my views fit > firmly into the descriptivist camp. If you are a descriptivist (as am I), then you must acknowledge that people use "his/her" *today*. As a descriptivist you shouldn't dare to _prescribe_ how people use words. Therefore, if I use "his/her" (as many people do), you should not prescribe otherwise. > Since we are writing text for an English language audience who are > mostly not linguists, we should probably consider using the language > that most people will use in this context. Consider, yes. Dictate? No. And you don't know how *most* most people speak. Your guess is as good as mine. > It's completely fine for a contributor to propose that they think an > idea is better provided that they do so in a respectful and considerate > way, which I think happened here. If you say you think **in your personal opinion** that A is better than B, that's fine. What was stated here was "A is better". So that's not what happened. > I think it should be fine to use singular they here. You are, of > course, free to feel differently. I do feel differently, but I would not presume to dictate that B is better; I argue both A and B are fine. A. he/she B. they To be perfectly clear; I'm not saying you shouldn't use B; I'm saying A is fine. Cheers. [1] https://en.wikipedia.org/wiki/Nucular
On Sun, May 23 2021, brian m. carlson wrote: > [[PGP Signed Part:Undecided]] > On 2021-05-23 at 18:36:10, Felipe Contreras wrote: >> Johannes Schindelin wrote: >> > On Fri, 21 May 2021, Derrick Stolee wrote: >> > >> > > On 5/21/2021 5:59 AM, Bagas Sanjaya wrote: >> > > > On 21/05/21 05.13, Lénaïc Huard wrote: >> > > >> The existing mechanism for scheduling background maintenance is done >> > > >> through cron. On Linux systems managed by systemd, systemd provides an >> > > >> alternative to schedule recurring tasks: systemd timers. >> > > >> >> > > >> The main motivations to implement systemd timers in addition to cron >> > > >> are: >> > > >> * cron is optional and Linux systems running systemd might not have it >> > > >> installed. >> > > >> * The execution of `crontab -l` can tell us if cron is installed but not >> > > >> if the daemon is actually running. >> > > >> * With systemd, each service is run in its own cgroup and its logs are >> > > >> tagged by the service inside journald. With cron, all scheduled tasks >> > > >> are running in the cron daemon cgroup and all the logs of the >> > > >> user-scheduled tasks are pretended to belong to the system cron >> > > >> service. >> > > >> Concretely, a user that doesn’t have access to the system logs won’t >> > > >> have access to the log of its own tasks scheduled by cron whereas he >> > > >> will have access to the log of its own tasks scheduled by systemd >> > > >> timer. >> > > > >> > > > For gender neutrality, we can use he/she instead. >> > > >> > > Singular "they" is better. Fully accurate and less awkward. >> > >> > I agree. >> >> I disagree. > > I'm fully in support of singular "they". It provides a useful pronoun > to use in this context, is widely understood and used, is less awkward > than "he/she," and is less sexist than the indefinite "he." I think we should be the most concerned about the lack of inclusivity and chilling effect in us being overly picky about the minute details of commit message wording, long past the point of practical utility. In this particular case the context is a discussion about "a user" on a *nix system and what they do and don't have access to. I think it's a particularly misguided distraction to argue about he/she/they here, since the most accurate thing would really be "it". At least on my *nix systems most users are system users, and don't map to any particular human being, but I digress. I would like to encourage people in this thread who are calling for a change in wording here to consider whether this sort of discussion is a good use of the ML's time, and the chilling effect of being overly picky when many contributors are working in their second, third etc. language. Personally I don't care whether someone submits a patch where their commit message discusses an example of "he", "she", "they", "it" or whatever. It's just meant as an example, and not some statement about what the gender (or lack thereof) of such a user *should* be. It's immediately obvious what the author meant in this case, and that the particular wording is arbitrary. For the purposes of discussing the contribution it matters whether it's unclear or ambiguous, which it's not.
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: > Personally I don't care whether someone submits a patch where their > commit message discusses an example of "he", "she", "they", "it" or > whatever. It's just meant as an example, and not some statement about > what the gender (or lack thereof) of such a user *should* be. > > It's immediately obvious what the author meant in this case, and that > the particular wording is arbitrary. For the purposes of discussing the > contribution it matters whether it's unclear or ambiguous, which it's > not. Nicely put. Thanks.
Ævar Arnfjörð Bjarmason wrote: > I would like to encourage people in this thread who are calling for a > change in wording here to consider whether this sort of discussion is a > good use of the ML's time, and the chilling effect of being overly picky > when many contributors are working in their second, third etc. language. I completely agree. However, there's a difference between calling for a change, and expressing one's personal taste. The later can be useful feedback, the former tramples the progress of a patch series. > Personally I don't care whether someone submits a patch where their > commit message discusses an example of "he", "she", "they", "it" or > whatever. It's just meant as an example, and not some statement about > what the gender (or lack thereof) of such a user *should* be. Agreed. My only concern is readability, nonetheless a poorly readable commit message is not a road-blocker. What should not be debatable is that this is a software project, it should not concern itself with linguistic debates. The proper use of language is a matter for others to decide. If a member of the community expresses her/his personal taste that Y is a better word than X, that's fine. But to *demand* a word change is something else. Cheers.
Hi, On Tue, 25 May 2021, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: > > > Personally I don't care whether someone submits a patch where their > > commit message discusses an example of "he", "she", "they", "it" or > > whatever. It's just meant as an example, and not some statement about > > what the gender (or lack thereof) of such a user *should* be. > > > > It's immediately obvious what the author meant in this case, and that > > the particular wording is arbitrary. For the purposes of discussing the > > contribution it matters whether it's unclear or ambiguous, which it's > > not. > > Nicely put. Thanks. _Personally_ I don't care either. Because I am exactly in that group of young, Caucasian male developers that are so highly overrepresented in our community already. I will never have a problem thinking that I don't belong here. I never had that problem. And I believe that you, Ævar, are very much in the same boat. You will never feel as if you don't belong in tech. You're Caucasian, male, and like me, come with an abundance of confidence. Now, let's go for a little thought experiment. Let's pretend for a moment that we lacked that confidence. That we were trying to enter a community with almost no male members at all. Where an email thread was going on about inviting us to join, using no male pronouns, or putting them last. And remember: no confidence, no representation. Now, would you dare chiming in, offering myself as a target? I know I wouldn't. Yet that's exactly the atmosphere we're fostering here. What you say, matters. _How_ you say it, matters. In other words, I think that the _personal_ opinions of everybody who spoke up in this mail thread (you might have noticed that all of us are male, you could even call it a "male thread") are not the problem we are discussing. Personal opinions are kind of missing the point here. By a mile. And then some. The actual point is that we want to avoid giving the impression that only people who feel included by the pronoun "he" are invited. That we only really care about male users and developers, and pay only scant tribute to the rest. And yes, even "he/she", or "(s)he" would give that impression, by emphasizing a priority order. And "they" simply would not do that. And if it makes a few male readers slightly uncomfortable, it might present a fine opportunity to exercise some empathy with those who feel uncomfortable and excluded all the time. Thank you, Johannes
Johannes Schindelin wrote: > Where an email thread was going on about inviting us to join, using no > male pronouns, or putting them last. This is totally and completely missing the point. Nobody objected to using a female pronoun, nor using she/he. I for one would have no problem using a female pronoun, and in fact I often do [1]. This has absolutely nothing to do the issue at hand. > I know I wouldn't. Yet that's exactly the atmosphere we're fostering > here. Except this is disconnected from reality. 1. I know female colleagues who don't want to be treated more delicately than their male counterparts. And they certainly don't want unsolicited help, especially regarding hypothetical feelings they might have towards the use of a pronoun. 2. On the other hand I do know people that lurk the mailing list and are afraid of expressing their opinions because of fear of reprisals in this PC-culture climate. If anybody needs consideration I would side with the real, rather than hypothetical, people. [1] https://lore.kernel.org/git/60a66b11d6ffd_2448320885@natae.notmuch/
On Tue, May 25 2021, Johannes Schindelin wrote: > Hi, > > On Tue, 25 May 2021, Junio C Hamano wrote: > >> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: >> >> > Personally I don't care whether someone submits a patch where their >> > commit message discusses an example of "he", "she", "they", "it" or >> > whatever. It's just meant as an example, and not some statement about >> > what the gender (or lack thereof) of such a user *should* be. >> > >> > It's immediately obvious what the author meant in this case, and that >> > the particular wording is arbitrary. For the purposes of discussing the >> > contribution it matters whether it's unclear or ambiguous, which it's >> > not. >> >> Nicely put. Thanks. > > _Personally_ I don't care either. Because I am exactly in that group of > young, Caucasian male developers that are so highly overrepresented in our > community already. I will never have a problem thinking that I don't > belong here. I never had that problem. > > And I believe that you, Ævar, are very much in the same boat. You will > never feel as if you don't belong in tech. You're Caucasian, male, and > like me, come with an abundance of confidence. > > Now, let's go for a little thought experiment. Let's pretend for a moment > that we lacked that confidence. That we were trying to enter a community > with almost no male members at all. Where an email thread was going on > about inviting us to join, using no male pronouns, or putting them last. > And remember: no confidence, no representation. Now, would you dare > chiming in, offering myself as a target? I know I wouldn't. Yet that's > exactly the atmosphere we're fostering here. > > What you say, matters. _How_ you say it, matters. > > In other words, I think that the _personal_ opinions of everybody who > spoke up in this mail thread (you might have noticed that all of us are > male, you could even call it a "male thread") are not the problem we are > discussing. Personal opinions are kind of missing the point here. By a > mile. And then some. > > The actual point is that we want to avoid giving the impression that > only people who feel included by the pronoun "he" are invited. That we > only really care about male users and developers, and pay only scant > tribute to the rest. > > And yes, even "he/she", or "(s)he" would give that impression, by > emphasizing a priority order. And "they" simply would not do that. And if > it makes a few male readers slightly uncomfortable, it might present a > fine opportunity to exercise some empathy with those who feel > uncomfortable and excluded all the time. > > Thank you, I don't think it's helpful or in the spirit of our CoC to characterize discussion in terms of the genders or nationalities of its participants. I'm not accusing you of some CoC violation, just suggesting that it makes more better conversation to take participants at their word and assume good faith. You can't say based on some superficial piece of information what a project participant might be dealing with, e.g. perhaps they're anxious about screwing up some trivial thing on a public ML, feel that they're inexperienced and/or have some "impostor syndrome" etc. The reason I chimed in on this thread was that I thought concern over one such topic had started to negatively impact another. We've got a lot of people trying to contribute who aren't comfortable contributing in English, or whose proficiency doesn't extend to the latest linguistic trends. I'm suggesting that it's more helpful to leave certain things be than to pounce on contributors about things that are ultimately not integral to their work, and which can be readily understood. E.g. if someone's clearly a speaker of a Slavic language and it shows in their grammar I don't think we should be aiming to have them massage their patch until it's indistinguishable from that of a native speaker of English. We should make sure we understand what's being said[1], but I think anything past that point is starting to bring us negative value. At some point it's good enough that we can understand the intent, and by assuming good faith we're better off letting things like "he" v.s. "she" v.s. "they" slide. To not do so is to needlessly create a barrier to participation in this project. I think the side discussion about Merriam Webster[2] somewhat misses the mark here. The question isn't whether what's being suggested would be a valid sentence according to a dictionary, but whether e.g. someone who's learned English from a commonly available textbook (I daresay most "Beginner English" textbooks have more "he" and "she" examples than "they") is going to inadvertently run afoul of other people's preferences. If they do it's more work for them (partially because they're a non-native speaker), and ultimately more things we need to cover in Documentation/SubmittingPatches etc. All of that's more barriers of entry to project participation. 1. https://lore.kernel.org/git/87wns6u8pc.fsf@evledraar.gmail.com/ 2. https://lore.kernel.org/git/YKrk4dEjEm6+48ji@camp.crustytoothpaste.net/
Ævar Arnfjörð Bjarmason wrote: > On Tue, May 25 2021, Johannes Schindelin wrote: > > _Personally_ I don't care either. Because I am exactly in that group of > > young, Caucasian male developers that are so highly overrepresented in our > > community already. I will never have a problem thinking that I don't > > belong here. I never had that problem. > > > > And I believe that you, Ævar, are very much in the same boat. You will > > never feel as if you don't belong in tech. You're Caucasian, male, and > > like me, come with an abundance of confidence. > > I don't think it's helpful or in the spirit of our CoC to characterize > discussion in terms of the genders or nationalities of its participants. Not to mention that it's worryingly close to implying "if you are a straight white cis male, your opinion doesn't matter". I don't think the Git project should be assigning weight to the opinions of community members based on gender, or race.
On Wed, May 26, 2021 at 12:29:01PM +0200, Ævar Arnfjörð Bjarmason wrote: > The reason I chimed in on this thread was that I thought concern over > one such topic had started to negatively impact another. We've got a lot > of people trying to contribute who aren't comfortable contributing in > English, or whose proficiency doesn't extend to the latest linguistic > trends. > > I'm suggesting that it's more helpful to leave certain things be than to > pounce on contributors about things that are ultimately not integral to > their work, and which can be readily understood. Yes, I want to express my support of this point, and not just for this particular issue. If you're a new contributor (or even an old one), it can be frustrating to spend a lot of time working on and polishing up an improvement to the software, to be met with feedback that mostly consists of "there's a typo in your commit message". Whether that's true or not, or whether it improves the commit message or not, it can feel like reviewers are missing the point of the patch, which will discourage contributors. As reviewers, I think we can do a few things to encourage people, especially new contributors: - let little errors slide if they're not important. I think sometimes we get into a mentality that the commit message is baked into history, and thus needs to be revised and perfected. But commit messages are also just a conversation that's happening and being recorded. There will be hiccups, and polishing them forever has diminishing returns. (Of course this requires judgement; some commit messages really are just hard to follow, and I think you made that distinction with the phrase "make sure understand what's being said"). - temper small corrections with positive feedback. Especially for new contributors, being told explicitly "yes, what you're trying to do here overall is welcome, and it all looks good except for this..." is much more encouraging than "this part is wrong". In the latter, they're left to guess if anybody even values the rest of the work at all. - likewise, I think it helps to give feedback on expectations for the process. Saying explicitly "this looks good; I think with this style change, it would be ready to get picked up" helps them understand that the fix will get them across the finish line (as opposed to just getting another round of fix requests). I would even extend some of those into the code itself. Obviously we don't want to lower the bar and take incorrect code, or even typos in error messages. But I think we could stand to relax sometimes on issues of style or "I would do it like this" (and at the very least, the "temper small corrections" advice may apply). I'm not really targeting anybody in particular in this thread (and Lénaïc seems to have taken it all in stride in this case). It's more just a reminder that it's easy to forget to do these kinds of things, and keep this kind of perspective. I know I have not always done it perfectly at times. -Peff
Jeff King wrote: > On Wed, May 26, 2021 at 12:29:01PM +0200, Ævar Arnfjörð Bjarmason wrote: > > > The reason I chimed in on this thread was that I thought concern over > > one such topic had started to negatively impact another. We've got a lot > > of people trying to contribute who aren't comfortable contributing in > > English, or whose proficiency doesn't extend to the latest linguistic > > trends. > > > > I'm suggesting that it's more helpful to leave certain things be than to > > pounce on contributors about things that are ultimately not integral to > > their work, and which can be readily understood. > > Yes, I want to express my support of this point, and not just for this > particular issue. > > If you're a new contributor (or even an old one), it can be frustrating > to spend a lot of time working on and polishing up an improvement to the > software, to be met with feedback that mostly consists of "there's a > typo in your commit message". Whether that's true or not, or whether it > improves the commit message or not, it can feel like reviewers are > missing the point of the patch, which will discourage contributors. > > As reviewers, I think we can do a few things to encourage people, > especially new contributors: > > - let little errors slide if they're not important. I think sometimes > we get into a mentality that the commit message is baked into > history, and thus needs to be revised and perfected. But commit > messages are also just a conversation that's happening and being > recorded. There will be hiccups, and polishing them forever has > diminishing returns. Yes, polishing forever has diminishing returns, but that's not really the hard problem here; the problem is when two people (or more) can't agree on what "polishing" means. That's a more eternal forever. Fortunately we do have a dictator, and he can make determinations to end the eternal debate. He can simply fix the commit message--or any other minor details--himself. Sure, that doesn't scale, and ideally we would want the patch contributors to do these tasks themselves, and not burden the maintainer. But if the task of herding the cats is taken forever, why keep insisting? Just fix the commit message and move on. > I would even extend some of those into the code itself. Obviously we > don't want to lower the bar and take incorrect code, or even typos in > error messages. But I think we could stand to relax sometimes on issues > of style or "I would do it like this" (and at the very least, the > "temper small corrections" advice may apply). Plus code can be fixed later. If as a reviewer you really dislike one aspect of a patch, you don't necessarily need to convince the author to change it. You can propose a separate patch later on. Sometimes good is good enough. Don't let perfect be the enemy of good. Cheers.
Jeff King <peff@peff.net> writes: > I'm not really targeting anybody in particular in this thread (and > Lénaïc seems to have taken it all in stride in this case). It's more > just a reminder that it's easy to forget to do these kinds of things, > and keep this kind of perspective. I know I have not always done it > perfectly at times. Thanks.
Jeff King writes: > - temper small corrections with positive feedback. Especially for new > contributors, being told explicitly "yes, what you're trying to do > here overall is welcome, and it all looks good except for this..." > is much more encouraging than "this part is wrong". In the latter, > they're left to guess if anybody even values the rest of the work at > all. When I see only a minor nit like that I assume that by default, that means there are no more serious issues, fix the typo, and resubmit. If a new contributor thinks that means they aren't welcome then I think they have an expectation mismatch. > - likewise, I think it helps to give feedback on expectations for the > process. Saying explicitly "this looks good; I think with this style > change, it would be ready to get picked up" helps them understand > that the fix will get them across the finish line (as opposed to > just getting another round of fix requests). That would be nice, but such comments can really only come from a maintainer that plans on pushing the patch. Most comments come from bystanders and so nessesarily only consist of pointing out flaws, and don't really need to be bloated with a bunch of fluff. I prefer short, and to the point communication. > I would even extend some of those into the code itself. Obviously we > don't want to lower the bar and take incorrect code, or even typos in > error messages. But I think we could stand to relax sometimes on issues > of style or "I would do it like this" (and at the very least, the > "temper small corrections" advice may apply). Isn't saying "I would do it like this" already a tempering statement? I take that as meaning there isn't anything neccesarily wrong with what you did, but you might consider this advice.
On Fri, May 28, 2021 at 10:44:25AM -0400, Phillip Susi wrote: > > - temper small corrections with positive feedback. Especially for new > > contributors, being told explicitly "yes, what you're trying to do > > here overall is welcome, and it all looks good except for this..." > > is much more encouraging than "this part is wrong". In the latter, > > they're left to guess if anybody even values the rest of the work at > > all. > > When I see only a minor nit like that I assume that by default, that > means there are no more serious issues, fix the typo, and resubmit. If > a new contributor thinks that means they aren't welcome then I think > they have an expectation mismatch. Sure, that may be your intent as a reviewer. My point was that the recipient of the review does not always know that. Helping them understand those expectations is part of welcoming them into the community. And even as somebody who has been part of the community for a long time and understands that, it is still comforting to get actual positive feedback, rather than an assumed "if I did not complain, it is OK". > > - likewise, I think it helps to give feedback on expectations for the > > process. Saying explicitly "this looks good; I think with this style > > change, it would be ready to get picked up" helps them understand > > that the fix will get them across the finish line (as opposed to > > just getting another round of fix requests). > > That would be nice, but such comments can really only come from a > maintainer that plans on pushing the patch. Most comments come from > bystanders and so nessesarily only consist of pointing out flaws, and > don't really need to be bloated with a bunch of fluff. I prefer short, > and to the point communication. Yes, I hesitated a little bit on this advice for that reason: it may be even worse to mislead people about the state of a patch series, if you the reviewer and the maintainer do not agree. IMHO it is still good for reviewers to try to help manage newcomers through the process, but it does make sense for them to be careful not to over-promise. > > I would even extend some of those into the code itself. Obviously we > > don't want to lower the bar and take incorrect code, or even typos in > > error messages. But I think we could stand to relax sometimes on issues > > of style or "I would do it like this" (and at the very least, the > > "temper small corrections" advice may apply). > > Isn't saying "I would do it like this" already a tempering statement? I > take that as meaning there isn't anything neccesarily wrong with what > you did, but you might consider this advice. Here I more meant cases where the two approaches have about the same value. If your "I would do it like this" can be backed up with reasons why it might be better (more efficient, more maintainable, and so on), then that's probably helpful review to give. If it can't, then I'd question whether it is worth the time to even bring up. There's a big gray area, of course. Saying "it would be more readable like this..." is sometimes a nuisance, and sometimes great advice. One extra complication is that new contributors are often unsure how strong the request is (e.g., if they disagree, do they _need_ to change it for the patch to be accepted, or is it OK). I'll often qualify comments with an explicit "I'm OK with doing it this way, but in case you really like this other direction, I thought I'd mention it...". Another complication with all of this advice is that sometimes new contributors are in a mentoring relationship with one or more reviewers (e.g., GSoC, Outreachy, or just people who have asked for help). And there the cost/benefit tradeoff is different between frustrating a new contributor and teaching them our style, norms, etc. -Peff
diff --git a/Documentation/git-maintenance.txt b/Documentation/git-maintenance.txt index 7c4bb38a2f..50179e010f 100644 --- a/Documentation/git-maintenance.txt +++ b/Documentation/git-maintenance.txt @@ -181,16 +181,19 @@ OPTIONS `maintenance.<task>.enabled` configured as `true` are considered. See the 'TASKS' section for the list of accepted `<task>` values. ---scheduler=auto|crontab|launchctl|schtasks:: +--scheduler=auto|crontab|systemd-timer|launchctl|schtasks:: When combined with the `start` subcommand, specify the scheduler to use to run the hourly, daily and weekly executions of `git maintenance run`. The possible values for `<scheduler>` depend on the system: `crontab` - is available on POSIX systems, `launchctl` is available on - MacOS and `schtasks` is available on Windows. + is available on POSIX systems, `systemd-timer` is available on Linux + systems, `launchctl` is available on MacOS and `schtasks` is available + on Windows. By default or when `auto` is specified, a suitable scheduler for the system is used. On MacOS, `launchctl` is used. On Windows, - `schtasks` is used. On all other systems, `crontab` is used. + `schtasks` is used. On Linux, `systemd-timer` is used if user systemd + timers are available, otherwise, `crontab` is used. On all other systems, + `crontab` is used. TROUBLESHOOTING @@ -290,6 +293,52 @@ schedule to ensure you are executing the correct binaries in your schedule. +BACKGROUND MAINTENANCE ON LINUX SYSTEMD SYSTEMS +----------------------------------------------- + +While Linux supports `cron`, depending on the distribution, `cron` may +be an optional package not necessarily installed. On modern Linux +distributions, systemd timers are superseding it. + +If user systemd timers are available, they will be used as a replacement +of `cron`. + +In this case, `git maintenance start` will create user systemd timer units +and start the timers. The current list of user-scheduled tasks can be found +by running `systemctl --user list-timers`. The timers written by `git +maintenance start` are similar to this: + +----------------------------------------------------------------------- +$ systemctl --user list-timers +NEXT LEFT LAST PASSED UNIT ACTIVATES +Thu 2021-04-29 19:00:00 CEST 42min left Thu 2021-04-29 18:00:11 CEST 17min ago git-maintenance@hourly.timer git-maintenance@hourly.service +Fri 2021-04-30 00:00:00 CEST 5h 42min left Thu 2021-04-29 00:00:11 CEST 18h ago git-maintenance@daily.timer git-maintenance@daily.service +Mon 2021-05-03 00:00:00 CEST 3 days left Mon 2021-04-26 00:00:11 CEST 3 days ago git-maintenance@weekly.timer git-maintenance@weekly.service +----------------------------------------------------------------------- + +One timer is registered for each `--schedule=<frequency>` option. + +The definition of the systemd units can be inspected in the following files: + +----------------------------------------------------------------------- +~/.config/systemd/user/git-maintenance@.timer +~/.config/systemd/user/git-maintenance@.service +~/.config/systemd/user/timers.target.wants/git-maintenance@hourly.timer +~/.config/systemd/user/timers.target.wants/git-maintenance@daily.timer +~/.config/systemd/user/timers.target.wants/git-maintenance@weekly.timer +----------------------------------------------------------------------- + +`git maintenance start` will overwrite these files and start the timer +again with `systemctl --user`, so any customization should be done by +creating a drop-in file, i.e. a `.conf` suffixed file in the +`~/.config/systemd/user/git-maintenance@.service.d` directory. + +`git maintenance stop` will stop the user systemd timers and delete +the above mentioned files. + +For more details, see `systemd.timer(5)`. + + BACKGROUND MAINTENANCE ON MACOS SYSTEMS --------------------------------------- diff --git a/builtin/gc.c b/builtin/gc.c index bf21cec059..d2432ee04f 100644 --- a/builtin/gc.c +++ b/builtin/gc.c @@ -2079,10 +2079,174 @@ static int crontab_update_schedule(enum enable_or_disable run_maintenance, return result; } +static int is_systemd_timer_available(void) +{ + const char *cmd = "systemctl"; + int is_available; + static int cached_result = -1; +#ifdef __linux__ + struct child_process child = CHILD_PROCESS_INIT; +#endif + + if (cached_result != -1) + return cached_result; + + if (get_schedule_cmd(&cmd, &is_available)) + return is_available; + +#ifdef __linux__ + strvec_split(&child.args, cmd); + strvec_pushl(&child.args, "--user", "list-timers", NULL); + child.no_stdin = 1; + child.no_stdout = 1; + child.no_stderr = 1; + child.silent_exec_failure = 1; + + if (start_command(&child)) { + cached_result = 0; + return cached_result; + } + if (finish_command(&child)) { + cached_result = 0; + return cached_result; + } + cached_result = 1; + return cached_result; +#else + return 0; +#endif +} + +static char *xdg_config_home_systemd(const char *filename) +{ + assert(filename); + return xdg_config_home("systemd/user/%s", filename); +} + +static int systemd_timer_enable_unit(int enable, + enum schedule_priority schedule) +{ + const char *cmd = "systemctl"; + struct child_process child = CHILD_PROCESS_INIT; + const char *frequency = get_frequency(schedule); + + get_schedule_cmd(&cmd, NULL); + strvec_split(&child.args, cmd); + strvec_pushl(&child.args, "--user", enable ? "enable" : "disable", + "--now", NULL); + strvec_pushf(&child.args, "git-maintenance@%s.timer", frequency); + + if (start_command(&child)) + die(_("failed to run systemctl")); + return finish_command(&child); +} + +static int systemd_timer_delete_unit_templates(void) +{ + char *filename = xdg_config_home_systemd("git-maintenance@.timer"); + unlink(filename); + free(filename); + + filename = xdg_config_home_systemd("git-maintenance@.service"); + unlink(filename); + free(filename); + + return 0; +} + +static int systemd_timer_delete_units(void) +{ + return systemd_timer_enable_unit(DISABLE, SCHEDULE_HOURLY) || + systemd_timer_enable_unit(DISABLE, SCHEDULE_DAILY) || + systemd_timer_enable_unit(DISABLE, SCHEDULE_WEEKLY) || + systemd_timer_delete_unit_templates(); +} + +static int systemd_timer_write_unit_templates(const char *exec_path) +{ + char *filename; + FILE *file; + const char *unit; + + filename = xdg_config_home_systemd("git-maintenance@.timer"); + if (safe_create_leading_directories(filename)) + die(_("failed to create directories for '%s'"), filename); + file = xfopen(filename, "w"); + FREE_AND_NULL(filename); + + unit = "# This file was created and is maintained by Git.\n" + "# Any edits made in this file might be replaced in the future\n" + "# by a Git command.\n" + "\n" + "[Unit]\n" + "Description=Optimize Git repositories data\n" + "\n" + "[Timer]\n" + "OnCalendar=%i\n" + "Persistent=true\n" + "\n" + "[Install]\n" + "WantedBy=timers.target\n"; + fputs(unit, file); + fclose(file); + + filename = xdg_config_home_systemd("git-maintenance@.service"); + file = xfopen(filename, "w"); + free(filename); + + unit = "# This file was created and is maintained by Git.\n" + "# Any edits made in this file might be replaced in the future\n" + "# by a Git command.\n" + "\n" + "[Unit]\n" + "Description=Optimize Git repositories data\n" + "\n" + "[Service]\n" + "Type=oneshot\n" + "ExecStart=\"%s/git\" --exec-path=\"%s\" for-each-repo --config=maintenance.repo maintenance run --schedule=%%i\n" + "LockPersonality=yes\n" + "MemoryDenyWriteExecute=yes\n" + "NoNewPrivileges=yes\n" + "RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6\n" + "RestrictNamespaces=yes\n" + "RestrictRealtime=yes\n" + "RestrictSUIDSGID=yes\n" + "SystemCallArchitectures=native\n" + "SystemCallFilter=@system-service\n"; + fprintf(file, unit, exec_path, exec_path); + fclose(file); + + return 0; +} + +static int systemd_timer_setup_units(void) +{ + const char *exec_path = git_exec_path(); + + return systemd_timer_write_unit_templates(exec_path) || + systemd_timer_enable_unit(ENABLE, SCHEDULE_HOURLY) || + systemd_timer_enable_unit(ENABLE, SCHEDULE_DAILY) || + systemd_timer_enable_unit(ENABLE, SCHEDULE_WEEKLY); +} + +static int systemd_timer_update_schedule(enum enable_or_disable run_maintenance, + int fd) +{ + switch (run_maintenance) { + case ENABLE: + return systemd_timer_setup_units(); + case DISABLE: + return systemd_timer_delete_units(); + default: + BUG("invalid enable_or_disable value"); + } +} + enum scheduler { SCHEDULER_INVALID = -1, SCHEDULER_AUTO, SCHEDULER_CRON, + SCHEDULER_SYSTEMD, SCHEDULER_LAUNCHCTL, SCHEDULER_SCHTASKS, }; @@ -2097,6 +2261,11 @@ static const struct { .is_available = is_crontab_available, .update_schedule = crontab_update_schedule, }, + [SCHEDULER_SYSTEMD] = { + .name = "systemctl", + .is_available = is_systemd_timer_available, + .update_schedule = systemd_timer_update_schedule, + }, [SCHEDULER_LAUNCHCTL] = { .name = "launchctl", .is_available = is_launchctl_available, @@ -2117,6 +2286,9 @@ static enum scheduler parse_scheduler(const char *value) return SCHEDULER_AUTO; else if (!strcasecmp(value, "cron") || !strcasecmp(value, "crontab")) return SCHEDULER_CRON; + else if (!strcasecmp(value, "systemd") || + !strcasecmp(value, "systemd-timer")) + return SCHEDULER_SYSTEMD; else if (!strcasecmp(value, "launchctl")) return SCHEDULER_LAUNCHCTL; else if (!strcasecmp(value, "schtasks")) @@ -2155,6 +2327,15 @@ static void resolve_auto_scheduler(enum scheduler *scheduler) *scheduler = SCHEDULER_SCHTASKS; return; +#elif defined(__linux__) + if (is_systemd_timer_available()) + *scheduler = SCHEDULER_SYSTEMD; + else if (is_crontab_available()) + *scheduler = SCHEDULER_CRON; + else + die(_("neither systemd timers nor crontab are available")); + return; + #else *scheduler = SCHEDULER_CRON; return; diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh index 9eac260307..c8a6f19ebc 100755 --- a/t/t7900-maintenance.sh +++ b/t/t7900-maintenance.sh @@ -20,6 +20,18 @@ test_xmllint () { fi } +test_lazy_prereq SYSTEMD_ANALYZE ' + systemd-analyze --help >out && + grep verify out +' + +test_systemd_analyze_verify () { + if test_have_prereq SYSTEMD_ANALYZE + then + systemd-analyze verify "$@" + fi +} + test_expect_success 'help text' ' test_expect_code 129 git maintenance -h 2>err && test_i18ngrep "usage: git maintenance <subcommand>" err && @@ -628,14 +640,54 @@ test_expect_success 'start and stop Windows maintenance' ' test_cmp expect args ' +test_expect_success 'start and stop Linux/systemd maintenance' ' + write_script print-args <<-\EOF && + printf "%s\n" "$*" >>args + EOF + + XDG_CONFIG_HOME="$PWD" && + export XDG_CONFIG_HOME && + rm -f args && + GIT_TEST_MAINT_SCHEDULER="systemctl:./print-args" git maintenance start --scheduler=systemd-timer && + + # start registers the repo + git config --get --global --fixed-value maintenance.repo "$(pwd)" && + + test_systemd_analyze_verify "systemd/user/git-maintenance@.service" && + + printf -- "--user enable --now git-maintenance@%s.timer\n" hourly daily weekly >expect && + test_cmp expect args && + + rm -f args && + GIT_TEST_MAINT_SCHEDULER="systemctl:./print-args" git maintenance stop && + + # stop does not unregister the repo + git config --get --global --fixed-value maintenance.repo "$(pwd)" && + + test_path_is_missing "systemd/user/git-maintenance@.timer" && + test_path_is_missing "systemd/user/git-maintenance@.service" && + + printf -- "--user disable --now git-maintenance@%s.timer\n" hourly daily weekly >expect && + test_cmp expect args +' + test_expect_success 'start and stop when several schedulers are available' ' write_script print-args <<-\EOF && printf "%s\n" "$*" | sed "s:gui/[0-9][0-9]*:gui/[UID]:; s:\(schtasks /create .* /xml\).*:\1:;" >>args EOF rm -f args && - GIT_TEST_MAINT_SCHEDULER="launchctl:./print-args launchctl,schtasks:./print-args schtasks" git maintenance start --scheduler=launchctl && - rm -f expect && + GIT_TEST_MAINT_SCHEDULER="systemctl:./print-args systemctl,launchctl:./print-args launchctl,schtasks:./print-args schtasks" git maintenance start --scheduler=systemd-timer && + printf -- "systemctl --user enable --now git-maintenance@%s.timer\n" hourly daily weekly >expect && + printf "launchctl bootout gui/[UID] $pfx/Library/LaunchAgents/org.git-scm.git.%s.plist\n" \ + hourly daily weekly >>expect && + printf "schtasks /delete /tn Git Maintenance (%s) /f\n" \ + hourly daily weekly >>expect && + test_cmp expect args && + + rm -f args && + GIT_TEST_MAINT_SCHEDULER="systemctl:./print-args systemctl,launchctl:./print-args launchctl,schtasks:./print-args schtasks" git maintenance start --scheduler=launchctl && + printf -- "systemctl --user disable --now git-maintenance@%s.timer\n" hourly daily weekly >expect && for frequency in hourly daily weekly do PLIST="$pfx/Library/LaunchAgents/org.git-scm.git.$frequency.plist" && @@ -647,17 +699,19 @@ test_expect_success 'start and stop when several schedulers are available' ' test_cmp expect args && rm -f args && - GIT_TEST_MAINT_SCHEDULER="launchctl:./print-args launchctl,schtasks:./print-args schtasks" git maintenance start --scheduler=schtasks && + GIT_TEST_MAINT_SCHEDULER="systemctl:./print-args systemctl,launchctl:./print-args launchctl,schtasks:./print-args schtasks" git maintenance start --scheduler=schtasks && + printf -- "systemctl --user disable --now git-maintenance@%s.timer\n" hourly daily weekly >expect && printf "launchctl bootout gui/[UID] $pfx/Library/LaunchAgents/org.git-scm.git.%s.plist\n" \ - hourly daily weekly >expect && + hourly daily weekly >>expect && printf "schtasks /create /tn Git Maintenance (%s) /f /xml\n" \ hourly daily weekly >>expect && test_cmp expect args && rm -f args && - GIT_TEST_MAINT_SCHEDULER="launchctl:./print-args launchctl,schtasks:./print-args schtasks" git maintenance stop && + GIT_TEST_MAINT_SCHEDULER="systemctl:./print-args systemctl,launchctl:./print-args launchctl,schtasks:./print-args schtasks" git maintenance stop && + printf -- "systemctl --user disable --now git-maintenance@%s.timer\n" hourly daily weekly >expect && printf "launchctl bootout gui/[UID] $pfx/Library/LaunchAgents/org.git-scm.git.%s.plist\n" \ - hourly daily weekly >expect && + hourly daily weekly >>expect && printf "schtasks /delete /tn Git Maintenance (%s) /f\n" \ hourly daily weekly >>expect && test_cmp expect args
The existing mechanism for scheduling background maintenance is done through cron. On Linux systems managed by systemd, systemd provides an alternative to schedule recurring tasks: systemd timers. The main motivations to implement systemd timers in addition to cron are: * cron is optional and Linux systems running systemd might not have it installed. * The execution of `crontab -l` can tell us if cron is installed but not if the daemon is actually running. * With systemd, each service is run in its own cgroup and its logs are tagged by the service inside journald. With cron, all scheduled tasks are running in the cron daemon cgroup and all the logs of the user-scheduled tasks are pretended to belong to the system cron service. Concretely, a user that doesn’t have access to the system logs won’t have access to the log of its own tasks scheduled by cron whereas he will have access to the log of its own tasks scheduled by systemd timer. Although `cron` attempts to send email, that email may go unseen by the user because these days, local mailboxes are not heavily used anymore. In order to schedule git maintenance, we need two unit template files: * ~/.config/systemd/user/git-maintenance@.service to define the command to be started by systemd and * ~/.config/systemd/user/git-maintenance@.timer to define the schedule at which the command should be run. Those units are templates that are parameterized by the frequency. Based on those templates, 3 timers are started: * git-maintenance@hourly.timer * git-maintenance@daily.timer * git-maintenance@weekly.timer The command launched by those three timers are the same as with the other scheduling methods: git for-each-repo --config=maintenance.repo maintenance run --schedule=%i with the full path for git to ensure that the version of git launched for the scheduled maintenance is the same as the one used to run `maintenance start`. The timer unit contains `Persistent=true` so that, if the computer is powered down when a maintenance task should run, the task will be run when the computer is back powered on. Signed-off-by: Lénaïc Huard <lenaic@lhuard.fr> --- Documentation/git-maintenance.txt | 57 +++++++++- builtin/gc.c | 181 ++++++++++++++++++++++++++++++ t/t7900-maintenance.sh | 66 ++++++++++- 3 files changed, 294 insertions(+), 10 deletions(-)