Re: [perldoc2-developers] General Questions

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

Joergen W. Lang said:

> Sorry for being so unclear. I did not think of including anything like
> BBoard or Forum capabilities directly into the codebase (that's why I
> put them under "additional features" in the specification, maybe
> should've called them "add-ons" or something...).

How about "infrastructure"? :)

> Although I feel that things like a BBoard, forum or whatever means of
> communication are very neccessary features they should not clutter up
> the codebase.

Sure. The question is more which way to take. Personally, I prefer mailin=
g
lists.

>> 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.
>
> Sorry, not clear. What do you mean by "dependencies" is in this context=
?

CPAN :) The web frameworks manage their own dependencies pretty well. I
mean we should discuss _which_ XML module we use, _which_ database access=
,
and so on. To keep the dependencies as simple and as communicated as
possible. This should ease deployment too.

>> [stability issues]
>>
>> That's rather a deployment and development issue imho. We should
>> certainly do testruns before deploying/updating the main site. Things
>> like PAR could also help us with this, as it captures a whole environm=
ent
>> (optionally even including core modules).
>
> Or one step further - and you have something like apachefriends.org's
> XAMPP project.

Also a possibility. Although I see the "other projects" and "whole
different languages" target groups more fit to this way of distribution.

>>> 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
>> developers 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.
>
> Well - there's webspace, there's perl, there's shell access - what else
> do we need? Apart from that I do agree to the point of checking out and
> testing locally.

Question is which perl, what kind of webspace, how much influence on the
perl environment, etc.

> BTW - There's plenty of space on my server... :o)

Which might be a much better fit. Sidenote: Of course I mean the
translation platform itself, not the hosting of the finally translated
files. For that I'd think a sort of export (e.g. into the projects SVN, s=
o
everyone, including the $lang.perldoc.perl.org space can easily stay up t=
o
date) would be a much better fit for that.

gr.,
Robert

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