On 28 July 2013 19:38, Rob Weir <robw...@apache.org> wrote: > On Sun, Jul 28, 2013 at 11:43 AM, janI <j...@apache.org> wrote: > > On 28 July 2013 14:31, Rob Weir <robw...@apache.org> wrote: > > > >> On Sun, Jul 28, 2013 at 5:26 AM, janI <j...@apache.org> wrote: > >> > On 28 July 2013 09:01, Andrea Pescetti <pesce...@apache.org> wrote: > >> > > >> >> Rob Weir wrote: > >> >> > >> >>> Note that we do have this page already: > >> >>> http://openoffice.apache.org/**pmc-faqs.html#moderator< > >> http://openoffice.apache.org/pmc-faqs.html#moderator> > >> >>> Maybe that can be updated? Or if you have something more ambitious > in > >> >>> mind, the existing page can be retired. > >> >>> > >> >> > >> >> It will be just fine to update that page. > >> >> > >> > > >> > that page is very outdated, and it is a mixture of all kinds of > >> > information. I think it would be better to have a special page, > >> > > >> > I think pmc-faq, should have exact that content. > >> > > >> > objections ? > >> > > >> > >> An outdated page versus a page that doesn't exist yet? I guess I > >> don't care, so long as in the end there is a single place to go for > >> this info. > >> > > > > Well I could say the same, a page only a few knows that contains quite a > > lot of diifferent information, and where the maintenance part is outdated > > (doesnt even contain the services we offer), or a new page with the sole > > purpose of information who is doing the job. > > > > > >> > > >> > > >> > > >> >> Additional contact information, if desired, can be stored in the > private > >> >> (PMC members only) SVN repository for this PMC: > >> >> svn checkout https://svn.apache.org/repos/**private/pmc/openoffice< > >> https://svn.apache.org/repos/private/pmc/openoffice> > >> >> > >> > > >> > That is a possibility, do you think of telephone numbers etc, for > >> emergency > >> > situations ? > >> > > >> > I will make a proposal on ~jani and ask for lazy consensus. > >> > > >> > Does any maintainer (sysadm, sysop, root etc) have a problem that the > >> page > >> > contain our apache emails ? > >> > If so please object now, before I show my proposal. > >> > > >> > >> We should be using existing tools like the mailing list and BZ and IRC > >> for admin requests and reporting outages. I don't think we want to > >> encourage direct emails. > >> > > > > hmm, if thats the case then there are no purpose of telling who is doing > > the job...then we all just scream help on whatever list and hope the > right > > person reads its. On the other hand, if we want to identify the people > > doing the job I have only found the mailId as a common dominator, if you > > have another id then please tell me. > > > > I don't recall ever seeing the mailing list down. So that seems to be > a solid solution. It has the advantage that we can check email from > any device from any location. >
I have only seen it down a couple of times, but not long enough to really disturb anybody. > Using BZ for outages, would be at least interesting, on a good day it > would > > take 2-3 weeks before I became aware of the problem. I think for outages > BZ > > is not really the suited. IRC might be suited, but I seldom see people > who > > can do something in there. Maybe I am just negative, but at least I have > > nearly a full year experience with AOO (and 25+ with other systems) and > all > > ourages an until today I have not received a single outage request from > BZ > > or IRC. > > > > > >> The real goal, IMHO, should be making sure that the responsible party > >> can easily find out what issues/requests are related to their area. > >> This could be done by using the dev list for all such requests. It > >> could also be done by having BZ areas for such requests, something we > >> do have today in most cases. > >> > > > > I honestly think that the responsible party know what their area are, I > > think it is more important the informing part knows where to inform. > > > > I take your word for using BZ and dev@, since it saves me the work of > > making a list. But bear in mind that I (as an example) from time to time > > only read dev mail with 72 hours interval, do you really want to wait > that > > long to get a server restarted ? > > > > > >> > >> So I would recommend just listing names or Apache ID's (robweir, etc.) > >> without mailto: hyperlinks, for reference. > >> > > > > now you confuse me, you have just argued to use BZ and dev list, so no > need > > for specific names ? > > > > > Sorry for the confusion. I'm suggesting listing names, but not email > address. The idea is to not make it trivial for someone to click and > send an email. Remember, we're still dealing with the masses who are > looking for the easy way to technical support. As BZ admin I receive > quite a few product support questions sent to the admin address. > Ditto to the list help address. So make it sufficient for project > members to know who owns the area, but not so simple that any random > person will use it. > I see your point, but that also means to me, that there are no reason to list the people (listing the people reveals their email addresses). > > Remember, in many areas we have more than one authorized person who > can fix things. But we also all take vacations. Sending an outage > message to personal email has two problems: > > 1) It does not let others on the dev list know about the outage or > that it has already been reported. This leads to a cascade of more > notifications sent, to the general annoyance of everyone. > you are right about that, but that has more or less been the practical aproach while I have been monitoring our vms and with remarkable few "wrong" mails. > > 2) If the person notified is not available, due to vacation or > whatever, the fix is delayed even further. > > So I recommend sending all such issues to BZ if it is not urgent or to > the dev list if it is urgent. Sometimes I'll even put the dev list > and the person both into the address list if it is urgent, hoping to > escape some level of auto-filing in the mail clients. > > Another approach would be to create an ad...@openoffice.apache.org > mailing list for such things. If all admins subscribed to that list > it would be equally efficient. > Creating an admin@ would solve a lot of issues, but would equally open for the support questions which you fear. You have convinced me, I just wanted to provide a way to make sure our services have an even higher attention and thereby higher availability. Look at the forum issue, we had a whole mail thread, where the solution was a one-liner in mysql.ini, but it seems that either nobody felt responsible or the responsible persons did not read the mail list. But you are right, I would not like to have my mailbox flooded with user questions, so lets just leave things as they are. rgds jan I. > > Regards, > > -Rob > > > > > >> > >> Of course, every rule has exceptions. > >> > >> Maybe a variation on this approach would work for us as well? > >> > >> http://www.apache.org/dev/infra-contact#how > >> > > > > that was my basic idea, but the difference is that #asfinfra and infra@are > > solely for maintenance and not for general development (infra-dev@ is > for > > that purpose), dev@ is of course mainly related to non-maintenance > issues, > > and as such an outage mail can easily be overlooked. > > > > > > > >> > >> Regards, > >> > >> -Rob > >> > > > > thanks for your views, we do have a big gap between your views and what I > > feel is needed. > > > > Maybe I am just too focused on providing 24/7 service, and not something > > with 72hours gaps. I will let the discussion mature before I start doing > > wasted work. > > > > rgds > > jan I. > > > > > >> > >> > have a nice sunday. > >> > rgds > >> > jan I. > >> > > >> >> > >> >> Regards, > >> >> Andrea. > >> >> > >> >> > >> >> > >> > ------------------------------**------------------------------**--------- > >> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org< > >> 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 > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
