Re: Thank you! (was: Re: Reducing the load on Sysadmin)
Amen to that! Sysadmin have always supported us (Student Programs, Community Working Group) in when we've asked and even before we ask. :-) Thank you. Valorie On Sun, Nov 10, 2019 at 3:28 AM Martin Steigerwald wrote: > Dear Ben, dear admins for KDE infrastructure, > > Ben Cooksley - 09.11.19, 00:49:49 CET: > > One of the things that was prepared as a result of the Sysadmin BoF at > > Akademy was a list of systems and services which we look after and > > provide to the community. > > > > Whilst individually all of the services seem fairly reasonable and > > maintainable, the cumulative number of them has created a situation > > where they limit our ability to reasonably maintain our services as a > > collective whole. > > I followed the discussion followed by this and your other mails about > that topic. And I am completely missing a very important thing in there: > > *Thank you*! > > *Thank you big time* to you and the other admins for all the work you do > to keep KDE infrastructure running smoothly. > > Your work often is a lot less visible than the next shiny feature inside > of Plasma or an application. It often happens in the background and may > not be always thanked for at all, just cause no one notices to what > extent it is your work that keeps all the services we take for granted > running so smoothly as I do. I know how it can feel as I did quite some > of similar work myself for some time. > > On top of that you and other admins responded to some requests of mine > often quite quickly and even when it was just about re-open and fill a > mailing list archive for kdepim / kdepim-users on own KDE's own > infrastructure or some spam here and there. You did that on top of all > the other work you have. > > So again, so that it really sinks in: > > *Thank you* > > > In addition to that I ask everyone who responds to the more detailed > mails to consider whether your answer will mostly mean even more work > for the admins or whether it would actually help to reduce some of the > workload. Please think a moment or two how you can make is easier for > the admins to ease reduce their workload instead of adding even more > work on top of it. > > I considered to offer some of my time to KDE admin work some times ago, > but so far did not do that step out of the fear that I would easily be > swamped by work then while leading an already very busy life and > struggling to achieve some of my most important goals. And knowing how > challenging it can be for me to say "no"… I rather did not offer help, > even tough I would consider myself qualified enough for this kind of > work, beyond a little collecting of some mails into an archive so far or > so. > > I see your mail as a call for help, a call to have your workload eased a > bit, Ben. I thought you would only be writing this in case you struggle > with the current workload. And I can easily imagine that you do. > > All I ask everyone for is some respect for that, some respect for the > often unseen work you admins do. > > So again: > > *Thank you!* > > I appreciate your work. Big time. > > Best, > -- > Martin > > > -- http://about.me/valoriez - pronouns: she/her
Re: Reducing the load on Sysadmin
El dimecres, 13 de novembre de 2019, a les 23:48:02 CET, Albert Astals Cid va escriure: > El dilluns, 11 de novembre de 2019, a les 10:30:09 CET, Ben Cooksley va > escriure: > > When assessing paste.kde.org, it was noted that we already had a > > direct replacement for this, in the form of Snippets in Gitlab. As we > > get this for free as part of running Gitlab, it means that the benefit > > of running a separate Pastebin service now drops to effectively zero. > > The only use i had for paste.kde.org which was sharing encrypted tests with N > people is now gone, but fair enough I guess i was one of the few people using > that specific part of the service. s/tests/text Sorry LinuxAppSummit organizing is draining my brain Cheers, Albert > > Cheers, > Albert > > >
Re: Reducing the load on Sysadmin
El dilluns, 11 de novembre de 2019, a les 10:30:09 CET, Ben Cooksley va escriure: > When assessing paste.kde.org, it was noted that we already had a > direct replacement for this, in the form of Snippets in Gitlab. As we > get this for free as part of running Gitlab, it means that the benefit > of running a separate Pastebin service now drops to effectively zero. The only use i had for paste.kde.org which was sharing encrypted tests with N people is now gone, but fair enough I guess i was one of the few people using that specific part of the service. Cheers, Albert
Re: Reducing the load on Sysadmin
On Mon, Nov 11, 2019 at 4:02 AM Luigi Toscano wrote: > > KDE ha scritto: > > Hi, > > > > It seems there is always seem to be someone within KDE that wants something > > new and shiny, I name gitlab, Discourse, a new identity system, etc. > > > > On the flip side, there is always someone that does not want to part with > > the > > old stuff. > > > > Hence there is always more stuff to do, while we must also maintain all the > > old stuff. > > > > Sometime you need a step back to create room to go two forward. We are just > > asking to think with us if some services are really needed. > > This way of representing the reality is a bit of a stretch, to say the least. > > Most of the proposals haven't raised any concerns. > No one is going to shed a tear on the demise of cgit. > Moving to static-generator all the websites which does not need to be dynamic > has been on the work for a lot of time, and it will continue. > And so on. > > What's left? Some services which you may think have no users, but they really > solve problems. > API and EBN are probably not working in their current form, but something that > covers they use case is needed anyway. There is some discussion, it's likely Looks like we're missing part of the sentence here? In any event, my email on that topic was mostly a state of fact that the current way of operating it is unmaintainable and cannot continue. It was a call of action as it were to the broader community to do something about the problem in question. Please note that nowhere in my mail did I mention shutting it down - so i've no idea where this impression came from - because that is certainly not what was proposed at all. > > Of course, when you propose many changes it is expected to see that not all of > them may work as planned. That's why the discussion here is needed. > > About dealing with old services: it does not automatically mean "let's cancel > them" but more "let's see if this is useful, and if it but we have workload > issues, let's find a way to make it work". > As a rule, the approach i've taken does not take the age of the service into account. We've been users of some software for many, many years now (Drupal, Bugzilla, Mediawiki, etc) and have no plans to discontinue them simply due to their age. What I instead do is compare the benefit it provides to the community as a collective whole versus the cost to provide it, and whether something else we have within our systems can provide a similar service. To provide examples of how this logic works: When assessing paste.kde.org, it was noted that we already had a direct replacement for this, in the form of Snippets in Gitlab. As we get this for free as part of running Gitlab, it means that the benefit of running a separate Pastebin service now drops to effectively zero. As the cost of maintaining paste.kde.org was now higher than the benefit of providing it, it now makes sense to no longer provide this service. With regards to notes.kde.org, we were pointed in the direction of a Nextcloud plugin which provided very similar functionality (with a couple of minor regressions, but also improvements in some areas including information security). As it was rather costly to provide the notes.kde.org service maintenance wise, and this had the effect of providing a very similar service with a much reduced maintenance cost, it made sense to discontinue the notes.kde.org service in favour of the Nextcloud plugin. > Talking about websvn, I'm pretty sure that there are various solutions and > some of them have been proposed. To summarize the need: we do reference websvn > from pointing out specific changes in emails or other channels. It can be done > for git changes, it should still be possible for other changes. > > I has been said many times that recruiting new people for sysadmins is > difficult for trust reasons, but I'm pretty sure that there are some people in > the community who can be trusted by sysadmin right now. In fact there are > already people managing some of the services, not all of them, so I don't see > why it can't be done for other services. > Or is the set of people who are potentially trusted by sysadmins really empty? > This is a two sided problem. The first being that people aren't asking about looking after their favourite service, the second being whether we can trust them. To date we've not received much interest in regards to people joining. Please note though that even if people do join, services must still pass the benefit vs. cost test noted above (ie. even if available human and technical resources were extended to infinity, the number of things we would host would still remain limited) > > To be honest, the replies I've seen so far (which I'm nevertheless grateful > for) looks more like point to point replies dismissing the proposals. What I'd > like to see are more "yes, this can't be done this way BUT we may consider > this.". Please try to help each other to find the solutions,
Re: Reducing the load on Sysadmin
This mail does not specifically reply to the following email from "KDE". By the way Tom, your name comes out as the kind of vague "KDE", period. I consider that reviewing whether a service should keep being offered is a healthy exercise. At the same time, I agree with Albert in the sense that the sysadmin manpower is not a constant, so phrasing the exercise as one of "load reduction" can sound like a wasted recruitment opportunity. Verifying that resources are sufficient seems like a less confrontational, more positive and constructive angle. I think the process should look like: 1. Listing the future costs (for example, we will need to reinstall the server since Slackware Linux is no longer supported) and the recurrent costs (for example, 1 hour of computation time each day), next to the benefits provided. 2. Identify which contributors are willing to commit to support the service, and to what level. 3. Listing the possible changes which can be done such shutting down the service, adding a warning indicating that the service is scheduled for shutdown in 1 year unless volunteers step up, hiring employees, adding advertisements, giving more place to credits for administrators, optimizing the work, etc. 4. If someone favors a change, validate its acceptability with the community. Building a wiki page which is widely editable seems like an efficient and more perennial way to achieve steps 1 to 3 (and perhaps a preliminary part of #4). Wiki pages would have the added benefit of leaving some documentation and crediting the volunteers in charge. On 09/11/2019 14:51, KDE wrote: Hi, It seems there is always seem to be someone within KDE that wants something new and shiny, I name gitlab, Discourse, a new identity system, etc. On the flip side, there is always someone that does not want to part with the old stuff. Hence there is always more stuff to do, while we must also maintain all the old stuff. Sometime you need a step back to create room to go two forward. We are just asking to think with us if some services are really needed. Best, Tom Albers KDE Sysadmin On 9 Nov 2019, 20:43 +0100, Albert Astals Cid , wrote: El dissabte, 9 de novembre de 2019, a les 0:49:49 CET, Ben Cooksley va escriure: Hi all, One of the things that was prepared as a result of the Sysadmin BoF at Akademy was a list of systems and services which we look after and provide to the community. Whilst individually all of the services seem fairly reasonable and maintainable, the cumulative number of them has created a situation where they limit our ability to reasonably maintain our services as a collective whole. I've therefore conducted an analysis of all the various services we operate, with the objective of shutting down those services and sites that either provide marginal benefit to the community, are historical in nature or which could be provided better by others. Please note that while individually each item may seem small (and therefore "not an issue" to continue running), it is the collective number of them that create the problem. I'll shortly be sending out a series of emails regarding the services in question which have been identified for shutdown. Honestly i think you took the wrong approach here, removing things we seem to be using because there's not enough sysadmins instead of trying to increase the sysadmins. Cheers, Albert P.S: Maybe there has been an attempt to increase the sysadmins, if so I apologize Cheers, Ben -- Philippe Cloutier http://www.philippecloutier.com
Re: Reducing the load on Sysadmin
KDE ha scritto: > Hi, > > It seems there is always seem to be someone within KDE that wants something > new and shiny, I name gitlab, Discourse, a new identity system, etc. > > On the flip side, there is always someone that does not want to part with the > old stuff. > > Hence there is always more stuff to do, while we must also maintain all the > old stuff. > > Sometime you need a step back to create room to go two forward. We are just > asking to think with us if some services are really needed. This way of representing the reality is a bit of a stretch, to say the least. Most of the proposals haven't raised any concerns. No one is going to shed a tear on the demise of cgit. Moving to static-generator all the websites which does not need to be dynamic has been on the work for a lot of time, and it will continue. And so on. What's left? Some services which you may think have no users, but they really solve problems. API and EBN are probably not working in their current form, but something that covers they use case is needed anyway. There is some discussion, it's likely Of course, when you propose many changes it is expected to see that not all of them may work as planned. That's why the discussion here is needed. About dealing with old services: it does not automatically mean "let's cancel them" but more "let's see if this is useful, and if it but we have workload issues, let's find a way to make it work". Talking about websvn, I'm pretty sure that there are various solutions and some of them have been proposed. To summarize the need: we do reference websvn from pointing out specific changes in emails or other channels. It can be done for git changes, it should still be possible for other changes. I has been said many times that recruiting new people for sysadmins is difficult for trust reasons, but I'm pretty sure that there are some people in the community who can be trusted by sysadmin right now. In fact there are already people managing some of the services, not all of them, so I don't see why it can't be done for other services. Or is the set of people who are potentially trusted by sysadmins really empty? To be honest, the replies I've seen so far (which I'm nevertheless grateful for) looks more like point to point replies dismissing the proposals. What I'd like to see are more "yes, this can't be done this way BUT we may consider this.". Please try to help each other to find the solutions, keeping in mind that may not always fit your original plan. -- Luigi
Re: Thank you! (was: Re: Reducing the load on Sysadmin)
Martin Steigerwald - 10.11.19, 12:27:47 CET: > Your work often is a lot less visible than the next shiny feature > inside of Plasma or an application. It often happens in the > background and may not be always thanked for at all, just cause no > one notices to what extent it is your work that keeps all the > services we take for granted running so smoothly as I do. I know how they do > it can feel as I did quite some of similar work myself for some time. -- Martin
Thank you! (was: Re: Reducing the load on Sysadmin)
Dear Ben, dear admins for KDE infrastructure, Ben Cooksley - 09.11.19, 00:49:49 CET: > One of the things that was prepared as a result of the Sysadmin BoF at > Akademy was a list of systems and services which we look after and > provide to the community. > > Whilst individually all of the services seem fairly reasonable and > maintainable, the cumulative number of them has created a situation > where they limit our ability to reasonably maintain our services as a > collective whole. I followed the discussion followed by this and your other mails about that topic. And I am completely missing a very important thing in there: *Thank you*! *Thank you big time* to you and the other admins for all the work you do to keep KDE infrastructure running smoothly. Your work often is a lot less visible than the next shiny feature inside of Plasma or an application. It often happens in the background and may not be always thanked for at all, just cause no one notices to what extent it is your work that keeps all the services we take for granted running so smoothly as I do. I know how it can feel as I did quite some of similar work myself for some time. On top of that you and other admins responded to some requests of mine often quite quickly and even when it was just about re-open and fill a mailing list archive for kdepim / kdepim-users on own KDE's own infrastructure or some spam here and there. You did that on top of all the other work you have. So again, so that it really sinks in: *Thank you* In addition to that I ask everyone who responds to the more detailed mails to consider whether your answer will mostly mean even more work for the admins or whether it would actually help to reduce some of the workload. Please think a moment or two how you can make is easier for the admins to ease reduce their workload instead of adding even more work on top of it. I considered to offer some of my time to KDE admin work some times ago, but so far did not do that step out of the fear that I would easily be swamped by work then while leading an already very busy life and struggling to achieve some of my most important goals. And knowing how challenging it can be for me to say "no"… I rather did not offer help, even tough I would consider myself qualified enough for this kind of work, beyond a little collecting of some mails into an archive so far or so. I see your mail as a call for help, a call to have your workload eased a bit, Ben. I thought you would only be writing this in case you struggle with the current workload. And I can easily imagine that you do. All I ask everyone for is some respect for that, some respect for the often unseen work you admins do. So again: *Thank you!* I appreciate your work. Big time. Best, -- Martin
Re: Reducing the load on Sysadmin
Hi, It seems there is always seem to be someone within KDE that wants something new and shiny, I name gitlab, Discourse, a new identity system, etc. On the flip side, there is always someone that does not want to part with the old stuff. Hence there is always more stuff to do, while we must also maintain all the old stuff. Sometime you need a step back to create room to go two forward. We are just asking to think with us if some services are really needed. Best, Tom Albers KDE Sysadmin On 9 Nov 2019, 20:43 +0100, Albert Astals Cid , wrote: > El dissabte, 9 de novembre de 2019, a les 0:49:49 CET, Ben Cooksley va > escriure: > > Hi all, > > > > One of the things that was prepared as a result of the Sysadmin BoF at > > Akademy was a list of systems and services which we look after and > > provide to the community. > > > > Whilst individually all of the services seem fairly reasonable and > > maintainable, the cumulative number of them has created a situation > > where they limit our ability to reasonably maintain our services as a > > collective whole. > > > > I've therefore conducted an analysis of all the various services we > > operate, with the objective of shutting down those services and sites > > that either provide marginal benefit to the community, are historical > > in nature or which could be provided better by others. > > > > Please note that while individually each item may seem small (and > > therefore "not an issue" to continue running), it is the collective > > number of them that create the problem. > > > > I'll shortly be sending out a series of emails regarding the services > > in question which have been identified for shutdown. > > Honestly i think you took the wrong approach here, removing things we seem to > be using because there's not enough sysadmins instead of trying to increase > the sysadmins. > > Cheers, > Albert > > P.S: Maybe there has been an attempt to increase the sysadmins, if so I > apologize > > > > > Cheers, > > Ben > > > > > >
Re: Reducing the load on Sysadmin
El dissabte, 9 de novembre de 2019, a les 0:49:49 CET, Ben Cooksley va escriure: > Hi all, > > One of the things that was prepared as a result of the Sysadmin BoF at > Akademy was a list of systems and services which we look after and > provide to the community. > > Whilst individually all of the services seem fairly reasonable and > maintainable, the cumulative number of them has created a situation > where they limit our ability to reasonably maintain our services as a > collective whole. > > I've therefore conducted an analysis of all the various services we > operate, with the objective of shutting down those services and sites > that either provide marginal benefit to the community, are historical > in nature or which could be provided better by others. > > Please note that while individually each item may seem small (and > therefore "not an issue" to continue running), it is the collective > number of them that create the problem. > > I'll shortly be sending out a series of emails regarding the services > in question which have been identified for shutdown. Honestly i think you took the wrong approach here, removing things we seem to be using because there's not enough sysadmins instead of trying to increase the sysadmins. Cheers, Albert P.S: Maybe there has been an attempt to increase the sysadmins, if so I apologize > > Cheers, > Ben >
Reducing the load on Sysadmin
Hi all, One of the things that was prepared as a result of the Sysadmin BoF at Akademy was a list of systems and services which we look after and provide to the community. Whilst individually all of the services seem fairly reasonable and maintainable, the cumulative number of them has created a situation where they limit our ability to reasonably maintain our services as a collective whole. I've therefore conducted an analysis of all the various services we operate, with the objective of shutting down those services and sites that either provide marginal benefit to the community, are historical in nature or which could be provided better by others. Please note that while individually each item may seem small (and therefore "not an issue" to continue running), it is the collective number of them that create the problem. I'll shortly be sending out a series of emails regarding the services in question which have been identified for shutdown. Cheers, Ben
