On Sun, Sep 8, 2013 at 5:40 PM, Andrea Pescetti <pesce...@apache.org> wrote: > On 04/09/2013 Rob Weir wrote: >> >> On Wed, Sep 4, 2013 at 12:36 PM, janI wrote: >> >> I assume we want well-maintained servers that help us get our >> project-related tasks done, and also help serve our users. > > > Yes we do. And Jan's proposal seems very reasonable and dictated from > experience (both personal experience and the experience of actually > maintaining these servers). > > >>> some thoughts on how admins could work, but in general I >>> believe we should convince infra to take over the vm responsibility and >>> keep our well functioning forum/wiki admins. > > > Last time we approached Infra on this, their answer was: find resources > (people) within the OpenOffice project to take care of the non-standard > tools (MediaWiki, phpBB) and Infra can be there as a backup. I believe they > helped a bit respecting these lines so far. > > Handing over to Infra would indeed be "peace of mind" for us, but I still > think that your proposal makes sense in light of the above: Infra prefers > that project-specific tools are maintained by the project itself as a > first/primary contact, and escalate to Infra if needed. > > By the way, if you believe that Infra could now be available to support us > more closely, feel free to investigate. > > >> maybe >> 3b) Try to evolve systems so users can implement their own wishes, in >> a way compatible with 1) and 2). For example, if routine logos and >> footers are synched to resources in the project's SVN tree, then any >> committer can update things. > > > This is not feasible in the current state. Even ignoring the fact that this > issue derailed the discussion, I see no benefit in implementing this: if we > have a real (reasonable active) team maintaining the servers, and the team > is not a bottleneck for the community, we will be fine with it. I won't feel > "excluded" if I have to ask someone to change some configuration: this > routinely happens for Infra-maintained services, or for our Bugzilla, and it > works. >
That does not match my experience at all. From trying to get the terms and conditions statement on the Forum to integrating Google Analytic across the websites to rolling out the new logo, my experience has been that getting simple content changes make to the VMs has been very frustrating. Some of these changes took months. (Note: I'm not talking about "configuration". I'm talking about website content, things like logos, contact information, terms and conditions, copyright statements, etc.) You say that if we had active admin teams maintaining the servers, this would be easier. But we don't have such a team So these changes have been painful. Considering the admins are scarce and their time is precious, I'd like to find ways that we can allow some degree of "self- service" for committers, so we don't waste admin time on trivial content changes. Have the admins focus on things that only they can do. So this is not an either/or question. We should both have an active admin team as well as move toward allowing committers to maintain the content of our websites. Regards, -Rob > >>> A good setup would be, 3 types of admin: >>> Each server will have an appointed "owner" (anchor-admin) >>> A number of persons have full sudo on a server (admin) >>> A number of persons can reboot/restart/work on po files (help-admin) > > > Something that we might discuss (but I guess this is implicit in your > proposal) is to avoid that the same person is the "anchor-admin" (or > "contact-admin", i.e., the first point of contact) for all the three > machines. This might help in sharing the knowledge and mitigate the > "loneliness" you have experienced so far in maintaining our infrastructure. > > It would actually make a lot of sense that you continue to be the > "main/anchor-admin" for at least one of the machines, so that the other > machines can be smoothly transitioned and that the whole knowledge, not only > what's written in the documentation, can be shared. > > Regards, > Andrea. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
