Re: [perldoc2-developers] General Questions

[Robert 'p. S. <rs...@47...>]

Joergen W. Lang said:

> [This (not Roberts preceding) post should be mostly obsolete since most
> of it should be answered in the Specification. Anyway - for
> completeness' sake... here we go:]

I'll concentrate on the points being separate from the spec then :)

> I was referring to forums that run on the platform or as part of is. Th=
e
> data accumulated by these forums will probably be stored in one or the
> other DB. This DB should be easily maintainable.

I'm not sure if it's a good idea to include a bboard into the codebase, a=
s
this just adds up work distracting from the real thing[tm]. For example,
the german perl community has a self written board which is in
re-development. It surely isn't perfect, but it might be fitting for our
purposes.

> With "resources" I meant things like glossaries that might be available
> to transalators or other people. Maybe people could have their own
> glossary or dictionary.

Now I get it. ++ to that then.

> -T comes to mind. The things you mention above could probably be
> incorporated in some sort of "coding guideline" for the project. For th=
e
> moment I do not think, we need this, since the people involved had
> enough time to learn from their own mistakes already, right? ;o))

Guidelines are certainly good. If we want to keep it maintainable we also
shouldn't start adding dependencies like there's no tomorrow. So we might
want to discuss those things separately.

>> I can't really remember any stability issues with the current popular
>> Perl
>> web frameworks, anyway.
>
> Do they stay up and running even if one or more required modules fail t=
o
> work (maybe due to an update, API change or whatever)? Especially with
> these huge lists of dependencies this could be an issue. But maybe I'm
> just paranoid.

That's rather a deployment and development issue imho. We should certainl=
y
do testruns before deploying/updating the main site. Things like PAR coul=
d
also help us with this, as it captures a whole environment (optionally
even including core modules).

> This might be important if we start developing the platform on SF and
> then have to move it to whatever the final destination might be.

Well, SF can't run it anyway, can it? It should be possible for developer=
s
of the platform to check it out and run it on their own systems. Another
neutral systems before regular deployments to the end site would imho be
another good idea, too.

gr.,
Robert

--=20
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg, Germany
{ EMail =3D> ' rs...@47... ', Web =3D> ' http://474.at ' }