On 20 January 2014 21:30, sebb <seb...@gmail.com> wrote: > On 20 January 2014 20:07, jan i <j...@apache.org> wrote: > > On 20 January 2014 16:38, sebb <seb...@gmail.com> wrote: > > > >> On 20 January 2014 15:09, jan i <j...@apache.org> wrote: > >> > On 20 January 2014 15:50, sebb <seb...@gmail.com> wrote: > >> > > >> >> On 20 January 2014 13:32, jan i <j...@apache.org> wrote: > >> >> > Hi. > >> >> > > >> >> > If you read "How it works", Labs makes the following available: > >> >> > > >> >> > - a zone > >> >> > - a virtual host (http://labs.apache.org/) > >> >> > - three mailing lists: > >> >> > - labs@labs.apache.org > >> >> > - comm...@labs.apache.org (this receives the svn commits > diffs) > >> >> > - priv...@labs.apache.org > >> >> > - a lab registry (a collection of machine-readable descriptors) > >> >> > > >> >> > As far as I can see. > >> >> > > >> >> > - there are no zone > >> >> > > >> >> > - there are not virtual host > >> >> > >> >> Huh? > >> >> > >> >> http://labs.apache.org/ does exist. > >> >> > >> > > >> > virtual host is an often used name for a vm, just as it can mean > vhost. > >> > > >> > Fact is we have a home page (have not controlled if its a vhost or > just a > >> > httpd redirect, since it does not matter), sorry for choosing > confusing > >> > words. > >> > > >> > > >> >> > >> >> > - the lab registry is merely a directory in svn > >> >> > > >> >> > >> >> What's wrong with that? > >> >> All the directories should contain doap.rdf files which are machine > >> >> readable. > >> >> > >> > > >> > Nothing, I just want to use it more actively. The "browse labs" page > is > >> not > >> > in sync with the doap.rtf files, and why maintain the same information > >> in 2 > >> > places. > >> > >> Agreed. > >> > >> > However this issue relates more to the proposal about changing > >> > homepage. > >> > > >> >> > >> >> > I hereby propose the following: > >> >> > > >> >> > > >> >> > 1) We remove the mention of zone from the home page > >> >> > > >> >> > 2) We request a labs vm from infra (if the PMC request it with a > >> jira, I > >> >> > can make it) > >> >> > >> >> It looks like options 1 & 2 are alternatives, whereas 3 is > independent > >> >> - or have I got that wrong? > >> >> > >> > > >> > its not alternatives, > >> > > >> > 1) is there to bring the home page in accordance with real life. > >> > > >> > 2) is a request for a vm not a zone. This will of course also lead to > >> > homepage changes. > >> > > >> > > >> >> > 3) We change the homepage to actively use the lab registry (see > >> seperate > >> >> > proposal). > >> >> > > >> >> > > >> >> > --- details --- > >> >> > > >> >> > The vm should be equipped with a generic db and httpd and of course > >> svn > >> >> > allowing labs PI to test their ideas. Labs PI and registred > committers > >> >> > should have access to the vm (NOT sudo). It might be that no labs > >> need it > >> >> > today, but its marketing, we offer more than other sandboxes. > >> >> > >> >> Most TLPs don't have zones. > >> >> > >> > > >> > A lot of projects have vms. Take a look at the machines.a.o then you > see > >> a > >> > >> machines.a.o does not exist. > >> > > sorry I have made myself a local link. > > > >> > >> Did you mean this page? > >> > >> https://www.apache.org/dev/machines.html > >> > > yes. > > > >> > >> > lot (infrastructure/trunk/circonus/vms.py is more complete). > >> > > >> > We have 65 vms, 27 zones and 43 hosts. Of course not all are > allocated to > >> > one project. I think "a lot of" is a fair statement. > >> > > >> > but this is not about "who has", its about what we LABS offer > committers. > >> > Alone for building it would be interesting, and e.g. testing web based > >> labs. > >> > >> For building, there are already several CI servers. > >> > > Labs projects do not have access to the build servers, that would require > > them to be defined as a "real" project. > > Depends on the server; I imagine Jenkins and Continuum would handle Labs > OK. >
I believe we think in 2 different scenarios. To me a labs project (at least for a very long time) does not have the setup needed to build on any of our servers. The idea of labs is to a sandbox, once a project start talking about regularly builds, they should start thinking about moving to incubator. None of our build servers (at far as I know) handle constant build changes very well. That is far better handled on the local SSH, by the labs developer directly. > > > >> And note that allowing Maven builds is likely to need huge amounts of > >> disk space, and lots of maintenance. > >> > > > > I am not sure I can follow what maven builds has to do with labs ? > Looking > > at the current svn, I could not find any real big projects. If a labs > > Project size has no bearing on whether it uses Maven rather than Ant > or Buildr, etc. > > > project get big, it would mean there is a community behind it, and thats > > the point where the project moves to incubator. > > > > > >> As it is, there aren't always enough people to look after the existing > >> CI servers. > >> > > I am not suggesting a new CI server, but simply a vm where labs > committers > > can login, and do whatever their project does in their home dir. > > But if the labs project uses Maven to build, then it will need a Maven > repo. > These are large, as Maven tends to download all dependencies if if > they are not actually needed (yet). > My local repo is 2GB and I mainly work on Commons and HttpComponents, > neither of which have many dependencies. > You would either need to allow at least 2GB per Maven user, or find a > way to share the repo between users. > Or you don't allow Maven to be used (not sure how you police that). > Its easy for a single labs project to share a copy of the repo, but between projects it becomes unpleasant. If we get 20 projects going labs would be a huge success, 20x2Gb = 40Gb disk space, that is really nothing. > > > Maintenance of the vm is a lot less than a CI server, it is also less > than > > most project vms I already maintain. > > I think you may be underestimating what it takes to support arbitrary > manual builds. > I will not support it, that will be the individual labs projects, just like they do today, all we talk about is providing a vm, sparing them from (mis)using other resources. > > > I have volunteered to do the job. > > That's good, but is there any backup cover? > Hopefully there will be, once the PMC group becomes more active. E.g. Humbedooh is getting more involved, and he could easily be backup. rgds jan I. > > > rgds > > > >> > >> But it might be useful to allow deployment of web-based labs. > >> > >> > rgds > >> > jan I > >> > > >> >> > >> >> > I volunteer to maintain the vm (together with all the others I > >> maintain > >> >> as > >> >> > part of infra) and also to help labs in need of installing sw. > >> >> > > >> >> > Rgds > >> >> > > >> >> > jan I. > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org > >> >> For additional commands, e-mail: labs-h...@labs.apache.org > >> >> > >> >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org > >> For additional commands, e-mail: labs-h...@labs.apache.org > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org > For additional commands, e-mail: labs-h...@labs.apache.org > >
