Re: Futon.Next

[Octavian Damiean <ma...@gmail.com>]

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.

What are the opinions on a Futon.Next IRC meeting?

On Mon, Oct 29, 2012 at 7:30 AM, Randall Leeds <ra...@gmail.com>wrote:

> On Thu, Oct 25, 2012 at 10:35 AM, Ryan Ramage <ry...@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.
>

Re: Futon.Next

[Alexander Shorin <kx...@gmail.com>]

On Thu, Nov 1, 2012 at 4:31 PM, Octavian Damiean <ma...@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.
>

+1 for special meeting about Futon.Next.

Some of requirements was defined at github issues:

https://github.com/Futon/Futon.Next/issues

But they needs in well discussion and explanation to make sure that
everyone understand them in same way.

--
,,,^..^,,,


On Thu, Nov 1, 2012 at 4:31 PM, Octavian Damiean <ma...@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.
>
> What are the opinions on a Futon.Next IRC meeting?
>
> On Mon, Oct 29, 2012 at 7:30 AM, Randall Leeds <ra...@gmail.com>wrote:
>
>> On Thu, Oct 25, 2012 at 10:35 AM, Ryan Ramage <ry...@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.
>>

Re: Futon.Next

[Jan Lehnardt <ja...@apache.org>]

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 <ja...@apache.org> wrote:

> 
> On Nov 1, 2012, at 13:31 , Octavian Damiean <ma...@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 <ra...@gmail.com>wrote:
>> 
>>> On Thu, Oct 25, 2012 at 10:35 AM, Ryan Ramage <ry...@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.
>>> 
> 

Re: Futon.Next

[Jan Lehnardt <ja...@apache.org>]

On Nov 1, 2012, at 13:31 , Octavian Damiean <ma...@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 <ra...@gmail.com>wrote:
> 
>> On Thu, Oct 25, 2012 at 10:35 AM, Ryan Ramage <ry...@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.
>>