[systemd-devel] Calling sd_bus_reply_method_return outside method handler
I want to send a reply to a method call outside method_handler. Is it possible? In the method_handler I increase reference count of sd_bus_message and send it to the other thread. From there I want to call sd_bus_reply_method_return to send a reply but get Unknown method or interface error when I invoke method with bussctl --user call. If I call the return method from method_handler everything works as expected. Thank you ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
On Mon, Jan 14, 2019 at 04:48:22PM +0100, Lennart Poettering wrote: > On Mo, 14.01.19 08:43, Dave Reisner (d...@falconindy.com) wrote: > > > On Mon, Jan 14, 2019 at 10:59:06AM +0100, Jan Synacek wrote: > > > Hi, > > > > > > since v240 didn't go too well, I would like to suggest that the next one > > > (preferably two) release(s) are bugfix only. Please, consider it. > > > > systemd needs better release hygiene, not just a smattering of bugfix > > releases. As a rolling release distro, we regularly find release-day > > blockers. That's bad for everyone. v240 was particularly bad as 6 months > > had elapsed since v239 (and over 3100 commits). That's the longest > > timespan and most commits in any systemd release in its nearly 9 year > > history. > > Well, that sounds as if you want to volunteer as release engineer? ;-) > > Thing is, we are understaffed. I too have a wishlist of things I'd > like to see done, but with only two paid full-time upstream engineers > there's only so much we can do. Then, IMO, you have a fundamental misalignment. You're prioritizing feature work over stability, to the detriment of your customers. I really don't think this would be a full time job. There's already a pretty good effort around tagging open issues which provides visibility to someone who might be in charge of cutting releases. And, much of what I'm suggesting is about *not* merging things after a certain point. > If you (or anyone else in the community) would like to step up and > maybe take a position of release engineer, working towards a clearer > release cadence I think everybody would love you for that! I know I > certainly would. > > But additional work is not going to be done without anyone doing it... Like I said, it's a tradeoff. You currently have someone maintaining a stable branch in lieu of making your release snapshots more stable. > > It's my understanding that there were known problems that prevented > > tagging the release of v240 sooner. If that's the case, most other > > development should have *stopped* with focus on fixing those problems. > > However, that doesn't appear to be the case. Looking at commit > > timestamps over time, nearly half the commits were made in the last 2 > > months: > > > > Jun: 86 > > Jul: 276 > > Aug: 241 > > Sep: 317 > > Oct: 812 > > Nov: 882 > > Dec: 560 > > That it slightly misleading though, as a good chunk of those PRs that > good merged late where posted much earlier on, but only entered the > master branch late. So, most development work is definitely done at > the beginning of the cycle than in the end, but it's hard to see that > due to rebases/merges... This is all based on commit date, not merge date. It's not misleading. > > Please bring back a regular release process (as dvdhrm attempted to do) > > like curl which has a 2 month release cycle. They're actually *beating* > > this 2 month period substantially, averaging 40 days between releases > > over the last 30 releases (2+ years). They follow a 30 day period of > > feature work with a 30 day period of bugfixes. > > > > Yes, this is probably more work. But maintaining the systemd-stable repo > > is work, too. Effort put into making releases cut from master more > > stable is ideally offset by the lack of work that will need to go into > > maintaining systemd-stable branches. > > > > Please, let's make all future systemd release better, not just the next > > 1 or 2. > > I certainly see the problem, but quite frankly, I don't see the > additional workforce for implementing a tighter cadence appear > anywhere... :-( It's really unfortunate that you're not willing to make any tradeoffs here. > Lennart > > -- > Lennart Poettering, Red Hat > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] GithHub / private repos
On Fr, 11.01.19 13:57, Alex Dzyoba (a...@dzyoba.com) wrote: > Team plan with unlimited private repos and unlimited collaborators is free > for open source teams. Where do we request that? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
On Mon, Jan 14, 2019 at 10:36 AM Lennart Poettering wrote: > > On Mo, 14.01.19 10:59, Jan Synacek (jsyna...@redhat.com) wrote: > > > Hi, > > > > since v240 didn't go too well, I would like to suggest that the next one > > (preferably two) release(s) are bugfix only. Please, consider it. > > Well, one thing I'd really like to see happen is a bit more feedback > *before* the release from downstreams. Much of the breakage in v240 was > totally avoidable, if downstreams would let us know in advance if > things break. I would be happy to publish release candidates on Gentoo ahead of the official release. I'm much less likely to push out randomly selected snapshots from the master branch. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
Am 14.01.19 um 16:48 schrieb Lennart Poettering: > On Mo, 14.01.19 08:43, Dave Reisner (d...@falconindy.com) wrote: >> systemd needs better release hygiene, not just a smattering of bugfix >> releases. As a rolling release distro, we regularly find release-day >> blockers. That's bad for everyone. v240 was particularly bad as 6 months >> had elapsed since v239 (and over 3100 commits). That's the longest >> timespan and most commits in any systemd release in its nearly 9 year >> history. > > Well, that sounds as if you want to volunteer as release engineer? ;-) > > Thing is, we are understaffed. I too have a wishlist of things I'd > like to see done, but with only two paid full-time upstream engineers > there's only so much we can do. please don't get me wrong again! if i know my ressources and how they are limited that's the limit of new features and big changes i can plan and achieve in a given amount of time without sacrifice quality one problem i don't understand is that most developers are focused on features they can put in a list and point to it and find it boring to optimize and polish the existing codebase while i personally have so much more fun in the stuff i code to optimize it, make it faster, make it bugfree, write tests and overall caress of what is already there sadly system software on that low level is not my world starting with the programming language and my time is limited too because of too much daily stuff i need to care about, but still i don't get why so few developers are not satisfied by polish and caress the codebase without someone writing articles about new shiny things if i stand behind something i don't need shoulder tap and be mentioned somewhere as long as i konw that what i do has undoubtable worth and tap my own shoulder is enough ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
On Mo, 14.01.19 08:43, Dave Reisner (d...@falconindy.com) wrote: > On Mon, Jan 14, 2019 at 10:59:06AM +0100, Jan Synacek wrote: > > Hi, > > > > since v240 didn't go too well, I would like to suggest that the next one > > (preferably two) release(s) are bugfix only. Please, consider it. > > systemd needs better release hygiene, not just a smattering of bugfix > releases. As a rolling release distro, we regularly find release-day > blockers. That's bad for everyone. v240 was particularly bad as 6 months > had elapsed since v239 (and over 3100 commits). That's the longest > timespan and most commits in any systemd release in its nearly 9 year > history. Well, that sounds as if you want to volunteer as release engineer? ;-) Thing is, we are understaffed. I too have a wishlist of things I'd like to see done, but with only two paid full-time upstream engineers there's only so much we can do. If you (or anyone else in the community) would like to step up and maybe take a position of release engineer, working towards a clearer release cadence I think everybody would love you for that! I know I certainly would. But additional work is not going to be done without anyone doing it... > It's my understanding that there were known problems that prevented > tagging the release of v240 sooner. If that's the case, most other > development should have *stopped* with focus on fixing those problems. > However, that doesn't appear to be the case. Looking at commit > timestamps over time, nearly half the commits were made in the last 2 > months: > > Jun: 86 > Jul: 276 > Aug: 241 > Sep: 317 > Oct: 812 > Nov: 882 > Dec: 560 That it slightly misleading though, as a good chunk of those PRs that good merged late where posted much earlier on, but only entered the master branch late. So, most development work is definitely done at the beginning of the cycle than in the end, but it's hard to see that due to rebases/merges... > Please bring back a regular release process (as dvdhrm attempted to do) > like curl which has a 2 month release cycle. They're actually *beating* > this 2 month period substantially, averaging 40 days between releases > over the last 30 releases (2+ years). They follow a 30 day period of > feature work with a 30 day period of bugfixes. > > Yes, this is probably more work. But maintaining the systemd-stable repo > is work, too. Effort put into making releases cut from master more > stable is ideally offset by the lack of work that will need to go into > maintaining systemd-stable branches. > > Please, let's make all future systemd release better, not just the next > 1 or 2. I certainly see the problem, but quite frankly, I don't see the additional workforce for implementing a tighter cadence appear anywhere... :-( Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
On Mo, 14.01.19 10:59, Jan Synacek (jsyna...@redhat.com) wrote: > Hi, > > since v240 didn't go too well, I would like to suggest that the next one > (preferably two) release(s) are bugfix only. Please, consider it. Well, one thing I'd really like to see happen is a bit more feedback *before* the release from downstreams. Much of the breakage in v240 was totally avoidable, if downstreams would let us know in advance if things break. We do have quite some CI in place now, and it's getting better (some people are doing great work in that area (Frantisek!), in particularly finally on the Fedora/RHEL/CentOS side), but there are plenty areas not covered at all, and that's pretty sad. For example the LVM breakage could have totally been caught beforehand if people would actually test that... Something is a bit wrong if many of the changes v240 made have been in the tree for months, but only the day we finally tag the new release downstreams notice that things don't actually work on their systems. It's easy to request that people do more bugfixes, but this work doesn't come from thin air, it's actual people who need to do the work, and quite frankly there are exactly two people currently paid full-time for upstream systemd development, and that limits what we can from upstream in that area. I'd love to see some more CI hookup with Arch and Debian for example (right now there is zero) or even just a git preview package set or so that interested people can test. Without either it's very likely that things break on those distros, because there's no way we'll catch things beforehand. (That said v241 is going to be a bugfix release mostly, and is currently being prepared.) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
On Mon, Jan 14, 2019 at 10:59:06AM +0100, Jan Synacek wrote: > Hi, > > since v240 didn't go too well, I would like to suggest that the next one > (preferably two) release(s) are bugfix only. Please, consider it. systemd needs better release hygiene, not just a smattering of bugfix releases. As a rolling release distro, we regularly find release-day blockers. That's bad for everyone. v240 was particularly bad as 6 months had elapsed since v239 (and over 3100 commits). That's the longest timespan and most commits in any systemd release in its nearly 9 year history. It's my understanding that there were known problems that prevented tagging the release of v240 sooner. If that's the case, most other development should have *stopped* with focus on fixing those problems. However, that doesn't appear to be the case. Looking at commit timestamps over time, nearly half the commits were made in the last 2 months: Jun: 86 Jul: 276 Aug: 241 Sep: 317 Oct: 812 Nov: 882 Dec: 560 That doesn't seem right to me. Looking at this by week is pretty bad, too: 25: 4 26: 82 27: 31 28: 23 29: 84 30: 104 31: 85 32: 85 33: 8 34: 66 35: 40 36: 35 37: 121 38: 61 39: 91 40: 91 41: 255 42: 240 43: 179 44: 94 45: 181 46: 255 47: 209 48: 271 49: 209 50: 164 51: 105 52: 1 Please bring back a regular release process (as dvdhrm attempted to do) like curl which has a 2 month release cycle. They're actually *beating* this 2 month period substantially, averaging 40 days between releases over the last 30 releases (2+ years). They follow a 30 day period of feature work with a 30 day period of bugfixes. Yes, this is probably more work. But maintaining the systemd-stable repo is work, too. Effort put into making releases cut from master more stable is ideally offset by the lack of work that will need to go into maintaining systemd-stable branches. Please, let's make all future systemd release better, not just the next 1 or 2. dR ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Bugfix release(s)
Hi, since v240 didn't go too well, I would like to suggest that the next one (preferably two) release(s) are bugfix only. Please, consider it. Thank you, -- Jan Synacek Software Engineer, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
