diff options
| author | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
|---|---|---|
| committer | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
| commit | 1be510f9529cb082f802408b472a77d074b394c0 (patch) | |
| tree | b175f9d5fcb107576dabc768e7bd04d4a3e491a0 /zarb-ml/mageia-webteam/2011-January/000140.html | |
| parent | fa5098cf210b23ab4f419913e28af7b1b07dafb2 (diff) | |
| download | archives-1be510f9529cb082f802408b472a77d074b394c0.tar archives-1be510f9529cb082f802408b472a77d074b394c0.tar.gz archives-1be510f9529cb082f802408b472a77d074b394c0.tar.bz2 archives-1be510f9529cb082f802408b472a77d074b394c0.tar.xz archives-1be510f9529cb082f802408b472a77d074b394c0.zip | |
Diffstat (limited to 'zarb-ml/mageia-webteam/2011-January/000140.html')
| -rw-r--r-- | zarb-ml/mageia-webteam/2011-January/000140.html | 153 |
1 files changed, 153 insertions, 0 deletions
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 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-webteam] Initial hosting requirements for maintainers db + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-webteam%40mageia.org?Subject=Re%3A%20%5BMageia-webteam%5D%20Initial%20hosting%20requirements%20for%20maintainers%20db&In-Reply-To=%3C1294835393.32187.350.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="000139.html"> + <LINK REL="Next" HREF="000141.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-webteam] Initial hosting requirements for maintainers db</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-webteam%40mageia.org?Subject=Re%3A%20%5BMageia-webteam%5D%20Initial%20hosting%20requirements%20for%20maintainers%20db&In-Reply-To=%3C1294835393.32187.350.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-webteam] Initial hosting requirements for maintainers db">misc at zarb.org + </A><BR> + <I>Wed Jan 12 13:29:53 CET 2011</I> + <P><UL> + <LI>Previous message: <A HREF="000139.html">[Mageia-webteam] Initial hosting requirements for maintainers db +</A></li> + <LI>Next message: <A HREF="000141.html">[Mageia-webteam] Initial hosting requirements for maintainers db +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#140">[ date ]</a> + <a href="thread.html#140">[ thread ]</a> + <a href="subject.html#140">[ subject ]</a> + <a href="author.html#140">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le mercredi 12 janvier 2011 à 12:29 +0100, Romain d'Alverny a écrit : +><i> On Wed, Jan 12, 2011 at 11:52, Michael Scherer <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-webteam">misc at zarb.org</A>> wrote: +</I>><i> +</I>><i> > Non integrated because that use a totally different system ( ie gem/rvm +</I>><i> > vs rpm/urpmi ) with totally different versions ( ie, defined by coders +</I>><i> > instead of the one agreed when we decided to use the distribution ), +</I>><i> > totally different update mechanism, and with different requirements. +</I>><i> +</I>><i> Perfectly aware of that. Or we could as well host it somewhere else, +</I>><i> just to host the application on a matching stack. I'm not saying it's +</I>><i> the best solution, but it may be a temporary option to keep open. +</I> +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. + + + +><i> > Another option that I consider would be to use another stack. Nanar +</I>><i> > already told me that he would be able to do it quite fast in catalyst, +</I>><i> > and I consider myself being able to do it in django without much problem +</I>><i> > if I dedicate enough time ( I am quite rusty but for a simple CRUD +</I>><i> > application, it would be quite ok ). +</I>><i> +</I>><i> Obviously we still have to learn to let it go at some times, delegate, +</I>><i> welcome newcomers and new ideas, new stacks, if we want ever to grow +</I>><i> the whole thing. It has a cost (flexibility and work), sure, but it +</I>><i> has a payback too. +</I> +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. + +><i> It's not by sticking to a single stack mostly only handled by +</I>><i> sysadmins (Catalyst in this case) that we will achieve that delegation +</I>><i> and growth. I'm not saying it's crap, I'm saying it does not fit the +</I>><i> pool of volunteers we have for contributions in web development. +</I> +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 + +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="000139.html">[Mageia-webteam] Initial hosting requirements for maintainers db +</A></li> + <LI>Next message: <A HREF="000141.html">[Mageia-webteam] Initial hosting requirements for maintainers db +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#140">[ date ]</a> + <a href="thread.html#140">[ thread ]</a> + <a href="subject.html#140">[ subject ]</a> + <a href="author.html#140">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-webteam">More information about the Mageia-webteam +mailing list</a><br> +</body></html> |