couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: Futon.Next
Date Sat, 03 Nov 2012 16:58:27 GMT
I think it's fine, and desirable even, to hash out a technical plan. But
there is a fine line between that and stymying progress through objection.
Ultimately, whoever implements it makes the final call, and I would hate
for them to feel like they have to please everyone. As a project, we have
experienced problems in the past, with features being blocked because
someone disliked X or Y decision. Let's try to avoid that.

It sounds to me like there's one or more Cloudant folks wanting to take the
lead, and a few community members who want to assist. I'd say it probably
makes sense for you guys to form a team and knock this one out of the park
together. Have you had a kick-off meeting yet?


On 28 October 2012 19:28, Octavian Damiean <mainerror@gmail.com> wrote:

> While I agree that we should make use of this momentum to get something
> done I don't quite agree on the "let's jump right into it and use whatever
> one thinks" approach.
>
> If we plan to use technology X to build it, then technology Y might be a
> dependency. Less for example is a dependency of Bootstrap (unless we want
> the default Bootstrap design).
>
> Same goes for the underlying framework, replacing Sammy.js with Backbone.js
> is not just like replacing the JavaScript files it comes close to a
> complete rewrite.
>
> Also, having multiple people work on the same project requires them to
> reach a consensus on what they use to they can actually plug it together in
> the end, it's not like everyone can develop their part in isolation and
> everything will just work eventually.
>
> On Sun, Oct 28, 2012 at 5:51 PM, Jan Lehnardt <jan@apache.org> wrote:
>
> > Summing up:
> >
> > We have some momentum going here, let’s use it and roll!
> >
> > I suggest whoever ends up writing the CSS gets to choose
> > whether they like plain CSS or a preprocessor. Same for
> > all other build-utilities. If one of them ends up being
> > an issue, we can rip them out later. I prefer to have a
> > Futon.Next that we need to rip something out of for the
> > long term than not having a Futon.Next for the long term.
> >
> > I’m so looking forward to see some results here soon! :)
> >
> > If whoever ends up working on this needs anything, please
> > let me/us know. Very happy to help with any roadblocks.
> >
> > Cheers
> > Jan
> > --
> >
> >
> >
> >
> > On Oct 25, 2012, at 22:03 , Ryan Ramage <ryan.ramage@gmail.com> wrote:
> >
> > >> You misunderstood that requirement. If we're not using a feature (e.g.
> > config) it won't get deployed anywhere, it'll be removed at build time.
> > It's not a user facing optional thing, the code just won't be on our CDN.
> > >>
> > >
> > > Ok, interesting. Good to know.
> > >
> > >
> > >> Right, and there are ~10 that exist and approximately interoperate
> > today.
> > >
> > > Haha. With the new ability of attachment first design of erica your
> > > normal web style folders are couchapps. One can push futon in its
> > > current form, with no modifications*. We could be done with the new
> > > futon as well.
> > >
> > > * ok, one modification. Couch does not like attachments with _
> > > starting, which current futon has. We can make a conscious decision to
> > > not do that.
> >
> >
>



-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message