From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-webteam/2011-January/000140.html | 153 ++++++++++++++++++++++++ 1 file changed, 153 insertions(+) create mode 100644 zarb-ml/mageia-webteam/2011-January/000140.html (limited to 'zarb-ml/mageia-webteam/2011-January/000140.html') diff --git a/zarb-ml/mageia-webteam/2011-January/000140.html b/zarb-ml/mageia-webteam/2011-January/000140.html new file mode 100644 index 000000000..3e4f75c82 --- /dev/null +++ b/zarb-ml/mageia-webteam/2011-January/000140.html @@ -0,0 +1,153 @@ + + + + [Mageia-webteam] Initial hosting requirements for maintainers db + + + + + + + + + +

[Mageia-webteam] Initial hosting requirements for maintainers db

+ Michael Scherer + misc at zarb.org +
+ Wed Jan 12 13:29:53 CET 2011 +

+
+ +
Le mercredi 12 janvier 2011 à 12:29 +0100, Romain d'Alverny a écrit :
+> On Wed, Jan 12, 2011 at 11:52, Michael Scherer <misc at zarb.org> wrote:
+>
+> > Non integrated because that use a totally different system ( ie gem/rvm
+> > vs rpm/urpmi ) with totally different versions ( ie, defined by coders
+> > instead of the one agreed when we decided to use the distribution ),
+> > totally different update mechanism, and with different requirements.
+> 
+> Perfectly aware of that. Or we could as well host it somewhere else,
+> just to host the application on a matching stack. I'm not saying it's
+> the best solution, but it may be a temporary option to keep open.
+
+Then, as decided in the past for the case of the forum hosting done by
+MLO, that would mean no access to ldap if the sysadmin team do not
+manage the server. 
+
+However, having a separate account database could be done indeed.
+But I think we will quickly agree that it is not a good idea.
+
+
+
+> > Another option that I consider would be to use another stack. Nanar
+> > already told me that he would be able to do it quite fast in catalyst,
+> > and I consider myself being able to do it in django without much problem
+> > if I dedicate enough time ( I am quite rusty but for a simple CRUD
+> > application, it would be quite ok ).
+> 
+> Obviously we still have to learn to let it go at some times, delegate,
+> welcome newcomers and new ideas, new stacks, if we want ever to grow
+> the whole thing. It has a cost (flexibility and work), sure, but it
+> has a payback too.
+
+I am just mentioning it for completeness, telling another alternative
+that should be also be kept open.
+
+I am not against rails hosting. I would have told exactly the same to
+someone asking to use python-virtualenv and django, or similar
+technology on any other language.
+
+I just ask that using it do not totally disrupt our hosting and
+procedures. And I would not ask if I was not sure that it could be
+done. 
+
+The current rails stack in Mandriva do not seems to be unusable to the
+point to compile our own, as gitorious worked with it among others. And
+while I understand that it can be a pain to use older versions of the
+stack for a coders, it does seems a so strong requirement. That's still
+ruby, that's still rails. 
+
+> It's not by sticking to a single stack mostly only handled by
+> sysadmins (Catalyst in this case) that we will achieve that delegation
+> and growth. I'm not saying it's crap, I'm saying it does not fit the
+> pool of volunteers we have for contributions in web development.
+
+I didn't ask to stick to one stack so sorry if I gave that impression. 
+
+And given the current state of the server, we are already supporting 2
+stack ( django is the other one for transifex ), and also applications
+without any kind of web stack ( like bugzilla and sympa ), and planning
+to support a 3rd one ( symphony for stormi web application ). 
+
+I would even be ok if people used custom fastcgi from my point of view
+( but you prefer to have people use a popular web stack, I perfectly
+understand that you set some requirement on that part and concur in that
+sense ).
+
+I am not even against supporting a 4th stack ( namely rails ), despites
+the fact that is is more than most commercial shop, since we engineered
+the server for that ( ie fast-cgi ). We anticipated the fact that we
+would have to cope with everybody using his preferred stack, be it here
+or upstream ( ie transifex vs epoll vs gitorious vs custom php
+application ).
+
+So my request is "make and test the application to work with :
+- fastcgi, should not be a problem, rails support it
+- postgresql ( again, i do not see any complex request that would cause
+trouble )
+- our version of rails and ruby ( ie 1.8 or 1.9.1 ), and rails 2.3.
+"
+
+I do not have the impression to ask for the moon, I do not ask for a rpm
+package to be done, nor to have a rigorous code review regarding
+security, or specific development method, requirement on the
+documentation, memory usage, time of response, etc.
+
+There is nothing exotic to my eye :
+- standard version of ruby 
+- a well know database, respecting SQL 2003 standard 
+- a specific version of rails, which is unfortunately not the latest
+
+Nothing that can't be installed ( server just run Mandriva 2010.1 so a
+vm or rvm could perfectly mimic the setup ruby wise ), nothing that
+would requires esoteric knowledge.
+
+-- 
+Michael Scherer
+
+
+ + + +
+

+ +
+More information about the Mageia-webteam +mailing list
+ -- cgit v1.2.1