On Jul 28, 2013, at 8:43 AM, janI 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.
If this is a new page then it should be called "Infrastructure" and be linked to from the left nav in the Community section of the project site. Once the page is created and we are happy with it we can update the PMC facts by replacing the duplicate content with a link. Regards, Dave > > >>> >>> >>> >>>> 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. > > 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 ? > > >> >> 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
