I might be jumping the gun here, I’m just excited by the progress here :)
I trust you all will sort this out by whatever means you deem useful. Cheers Jan On Nov 1, 2012, at 13:37 , Jan Lehnardt <j...@apache.org> wrote: > > On Nov 1, 2012, at 13:31 , Octavian Damiean <mainer...@gmail.com> wrote: > >> I'd propose a Futon.Next IRC meeting with all the people that care about >> the topic. There we could gather a list of requirements, ideas and actually >> discuss how we want to proceed. >> >> Discussing, tracking ideas, requirements and suggestions of such a topic >> solely on the ML get a little tedious in my opinion. > > Aren’t these tracked at https://github.com/Futon/Futon.Next/issues?state=open > for now? I’d suggest that IRC is as bad as a mailing list to manage these > things :) > > >> What are the opinions on a Futon.Next IRC meeting? > > I think we have a good foundation to move on with. I’m not sure how a > meeting would help here. I’d rather not distract the people who work > on this :) > > Cheers > Jan > -- > > > >> >> On Mon, Oct 29, 2012 at 7:30 AM, Randall Leeds >> <randall.le...@gmail.com>wrote: >> >>> On Thu, Oct 25, 2012 at 10:35 AM, Ryan Ramage <ryan.ram...@gmail.com> >>> wrote: >>>>>> I'd assume that in a release we'd compile things down into the >>> share/www >>>>>> directory and serve out of there (as we do with the current futon, and >>> will >>>>>> do with the docs), so what we need IMHO is a build tool not a couchapp >>> push >>>>>> tool. >>>>>> >>>>> >>>>> If Futon.Next should become a proper CouchApp as discussed then we >>>>> certainly need a CouchApp push tool. >>>> >>>> One requirement out of Cloudant is the ability to turn things on and >>>> off. This will require persistance. Have a db to persistant settings >>>> would be a feature of using a couchapp. >>> >>> That's not how I read this requirement. My understanding was that >>> Cloudant wanted the ability to turn off features at build >>> configuration time. It would affect which js files get pushed. That >>> means it would either effect which files grunt.js processes, or it >>> would affect what files get listed in some couchapp manifest. >>> >>> If runtime configuration is necessary, that should be articulated more >>> clearly as a requirement, but I worry that this starts to balloon into >>> more of a CMS agree with Alexander that it starts to look like we've >>> gone too far. >>> >
