On 28 July 2013 18:33, Dave Fisher <dave2w...@comcast.net> wrote: > > 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. >
Agreed, I actually get quite confused by the difference between www.openoffice.org and openoffice.apache.org, I wonder if the users share the confusion. I agree with both name of link. > > 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. > if/when the page is made it will be available on people.a.o/~jani and aquire lazy consensus, before moving it anywhere. Rob raised some very valid doubts, if a detailed listing is wanted, and I would like to see what other people think. rgds jan I. > > 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 > >
