On 20 January 2014 22:10, sebb <seb...@gmail.com> wrote: > On 20 January 2014 20:50, jan i <j...@apache.org> wrote: > > 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. > > One of the first things a lab needs to do if they are to get > co-operation from another user is to set up a working build script or > build tool. >
you come to labs with an idea, not a finalized project, so the first part is a lot more to get the idea transformed into code, that part will hopefully attract one type of committers. Once the skeleton code is there, then you are right, that is the time for build scripts etc. that will hopefully then attract more developer oriented committers. > > 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. > > Jenkins and Continuum are quite easy to use for SVN-based projects. > Jenkins can use arbitrary shell scripts (not tried with Continuum). > > And it's quite easy to change the way the build is invoked. > However, normally the changes need to be made in the build script or > its config files, rather than in the build environment. > So once the CI system is set up, it should not need much attention. > I have to check up, until now I thought only a defined (TLP or incubator) could use the build servers. With labs it would be very different projects inside one TLP, so handling build logs might be a challenge. It clearly something that can and should be looked into, but I would not offer access to build servers at this point in time. > > > >> > > >> >> 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. > > There will inevitably be jobs that only someone with super-user karma can > do. > Hopefully these will reduce as the VM stabilises. > Correct, e.g. keeping the OS updated, just like we have it on all other vms. > > And there will be lots of questions as to how to use the system. > > I'm not saying that the idea of a VM is a bad one, but I think the > support will be a lot more time consuming than you expect. > > With a large project that has its own VM, it's likely that several > people will be familiar with how to use the VM, so they can help > themselves. > This is not the case with Labs. > I would say AOO is a fairly large project, they dont have several people so familiar with the vms that they can help themself. A number of the other projects I know off, does even have a sudo user, they depend on infra to keep the vm updated. I expect labs to be time consuming, not only because of the vm, but because there are so many other issues. I dont expect labs to be something I finalize with just writing a mail. I do think however, that I have shown several times, that I can handle that. But all of this depends on a well functioning PMC, and if that works there are more hands to help. > > > >> > >> > 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. > > Has he agreed to help? > Have not asked him directly, I am neither PMC nor member so its not my place to ask, but I know he is doing a lot of good for labs right now (e.g. trying to get responses from the PMC members that did not care/want to respond to me). rgds jan I. > > > 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 > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org > For additional commands, e-mail: labs-h...@labs.apache.org > >
