On Fri, Apr 30, 2010 at 7:04 PM, Sean Corfield <seancorfi...@gmail.com> wrote:
> After much consideration I have decided to move FW/1 from the RIAForge
> svn repository to github.com.

> After much consideration I have decided to move FW/1 from the RIAForge
> svn repository to github.com. I've been usinggitheavily on a client
> project for about nine months and I'd been using it before then when
> collaborating with Ron Hopper on cfSpec. A lot of the (mostly
> non-CFML) projects I work with these days are using github.com now and
> as FW/1 continues to gain in popularity, I want to make it easier for
> others to provide input and ideas which github allows easily.

> I've imported the current svn repository - with all history - to
> github.com here:

> http://github.com/seancorfield/fw1

> (Ryan, I imported you as Ryan Cogswell <ryancogsw...@gmail.com> - I
> don't know if you have a github.com account?)

> I'll be updating the RIAForge site over the next few days to point all
> the links over to github and I'll be migrating the wiki as well.
> Essentially FW/1 1.1 will launch from github.com and all future
> development will be from there.

> FWIW, Andy Jarrett and AJ Mercer have a security models projects on
> github.com for FW/1:

> http://github.com/andyj/FW-1-Security-Models/
> --
> Sean A Corfield -- (904) 302-SEAN
> Railo Technologies, Inc. --http://getrailo.com/
> An Architect's View --http://corfield.org/

> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood

> --
> You received this message because you are subscribed to the Google Groups "framework-one" group.
> To post to this group, send email to framework-one@googlegroups.com.
> To unsubscribe from this group, send email to framework-one+unsubscribe@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/framework-one?hl=en.

On Fri, May 7, 2010 at 11:26 AM, Jamie Krug <jamiek...@gmail.com> wrote:
> I'll definitely add my "+1" for git/github! I've been getting very
> excited about git, in general, and just spent merely 15 minutes to
> learn the basics of github. I created my account, forked FW/1,
> committed a change, pushed it to my (forked) project and sent you a
> pull request!

> For all others, I thought I'd point out the issue of keeping
> consistent line endings in any project. In short, Windows uses CRLF
> (carriage return/line feed, or \r\n) for line endings, while the rest
> of the universe uses LF (just line feed, or \n).

> On Fri, May 7, 2010 at 11:26 AM, Jamie Krug <jamiek...@gmail.com> wrote:
> > I'll definitely add my "+1" for git/github! I've been getting very
> > excited about git, in general, and just spent merely 15 minutes to
> > learn the basics of github. I created my account, forked FW/1,
> > committed a change, pushed it to my (forked) project and sent you a
> > pull request!

> Pulled and merged.

> > For all others, I thought I'd point out the issue of keeping
> > consistent line endings in any project. In short, Windows uses CRLF
> > (carriage return/line feed, or \r\n) for line endings, while the rest
> > of the universe uses LF (just line feed, or \n).

> Another thing to bear in mind: DO NOT MAKE SPURIOUS WHITESPACE OR
> LAYOUT CHANGES!

> If you are adding functionality and change the whitespace, indentation
> or { } layout of surrounding lines, it makes it nearly impossible for
> me to figure out what you've really changed and it makes it impossible
> to pull & merge changes from your repo.

> I was trying to pull in Brett's changes but I've had to give up (after
> spending half an hour on it) because Brett had added lots of
> whitespace, both between lines and within lines - and had changed
> lowercase operators (eq, not) to UPPERCASE (EQ, NOT). In the end it
> was absolutely impossible to figure out what was really changed and
> what was just noise in terms of Brett's whitespace preferences.

> When you're modifying someone else's code, you must be consistent with
> what they've done in terms of style - changing existing code just to
> suit your layout preferences is counter-productive.

> Sorry if it sounds like I'm picking on Brett here but he'd added a
> hook for implementing routes and I wanted to try it out but I could
> not make the merge work because of all the other changes.

> Another tip: make your commits as small as possible. If a commit
> contains a small change, I can easily review it and apply it. If a
> commit contains several changes, it's very hard to review and is more
> likely to conflict.

> That said, I'm glad to see enough interest that we're already seeing
> forks on github. With the guidelines above, it'll help me coalesce
> changes back into the core.

> I've added both Jamie's and Brett's repos as remotes so I can pull all
> their changes and keep track of the network locally (via GitX - highly
> recommended if you're on a Mac).
> --
> Sean A Corfield -- (904) 302-SEAN
> Railo Technologies, Inc. --http://getrailo.com/
> An Architect's View --http://corfield.org/

> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood

> --
> You received this message because you are subscribed to the Google Groups "framework-one" group.
> To post to this group, send email to framework-one@googlegroups.com.
> To unsubscribe from this group, send email to framework-one+unsubscribe@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/framework-one?hl=en.

On Fri, May 7, 2010 at 1:16 PM, Brett <webfl...@gmail.com> wrote:
> Is there anyway I can clean up my
> mess in a way you can get a handle on it?

> As more people get involved we might want to think about putting up a
> coding conventions page on the wiki.

> I'm loving the framework, but I think the code can be cleaned up quite
> a bit and that would also help with these issues moving forward.

> I was also curious if there are any unit tests writing for FW/1?

> I'd be very interested in folks contributing unit tests. Due to the
> nature of FW/1 - a single component that must be extended and whose
> behaviors are mostly side-effects on the request lifecycle - it isn't
> as easy to write tests for as you might think. I did at one point try
> to write some cfSpec tests but didn't get very far.

> Just follow the coding conventions already in the code.

> On Fri, May 7, 2010 at 1:16 PM, Brett <webfl...@gmail.com> wrote:
> > Is there anyway I can clean up my
> > mess in a way you can get a handle on it?

> I don't know. But starting with a fresh copy of FW/1 and only making
> the route changes would at least let me look at the implications of
> what you're trying to do :)

> Also, working with git is very different to SVN. git commits can (and
> should) be very small, isolated changes (preferably working changes
> but not necessarily :). Pushes should be of collections of commits
> that together make up a single working new feature. I pulled your
> Google Groups link in README because it was a clean, simple commit.
> But your route commit changed a lot of code that wasn't relevant. You
> also introduced methods out of alphabetical order (although method
> insertion is an easy thing to merge - I'd just commit that and then,
> in a separate commit, move the method to where it should be).

> > As more people get involved we might want to think about putting up a
> > coding conventions page on the wiki.

> Just follow the coding conventions already in the code.

> That's a standard "best practice" in open source: you follow what's
> already there and you do not change surrounding code.

> > I'm loving the framework, but I think the code can be cleaned up quite
> > a bit and that would also help with these issues moving forward.

> Ryan has done a great job of "cleaning up" whilst keeping the style
> consistent so I'd like others to follow his lead.

> When you work on open source projects, part of the benefit is learning
> to subdue your own preferences and follow those expressed by the
> existing code and project leads. What looks like "cleaning up" to you
> might be horrible style to them. That applies to whitespace, braces,
> capitalization, naming conventions and so on. That's a good skill for
> team development in general, whenever you join a project that is
> already in progress.

> Trying to change an existing project's "style" is usually an exercise
> in frustration (for everyone involved).

> > I was also curious if there are any unit tests writing for FW/1?

> I'd be very interested in folks contributing unit tests. Due to the
> nature of FW/1 - a single component that must be extended and whose
> behaviors are mostly side-effects on the request lifecycle - it isn't
> as easy to write tests for as you might think. I did at one point try
> to write some cfSpec tests but didn't get very far.

> FWIW, John Paul Ashenfelter ran into the same problem trying to write
> unit tests for Fusebox.

> That's not to say frameworks are inherently hard to test, but some of
> FW/1's principles run counter to best practices for testability - and
> a framework's internal principles are not (generally) reflective of
> best practices for application code, since frameworks have to jump
> thru some weird hoops in order to make it easier for developers to use
> the framework.
> --
> Sean A Corfield -- (904) 302-SEAN
> Railo Technologies, Inc. --http://getrailo.com/
> An Architect's View --http://corfield.org/

> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood

> --
> You received this message because you are subscribed to the Google Groups "framework-one" group.
> To post to this group, send email to framework-one@googlegroups.com.
> To unsubscribe from this group, send email to framework-one+unsubscribe@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/framework-one?hl=en.

> Why are some functions
> written entirely in cfscript and some with cfml.

> Just follow the coding conventions already in the code.
>> Problem is I don't know what those are.

> Well said! Agreed. Thanks, Ryan.

> On Fri, May 7, 2010 at 9:03 PM, Ryan Cogswell <ryancogsw...@gmail.com>wrote:

> > > Why are some functions
> > > written entirely in cfscript and some with cfml.

> > The preference is for cfscript, but we are also maintaining backwards
> > compatibility with older cf versions (I believe a couple people are
> > using FW/1 with CF 7).  This means there are a lot of things that we
> > cannot do using cfscript.

> > > Just follow the coding conventions already in the code.
> > >> Problem is I don't know what those are.

> > If some aspect is completely inconsistent, then chances are it's an
> > aspect of code style that we don't feel very strongly about.  For
> > those things that are largely consistent in the current code, try to
> > maintain the consistency.  If there's something that seems consistent,
> > but to which you have strong objections (for reasons beyond
> > aesthetics) -- ask about it.  So long as you keep your changes as
> > isolated as possible and as consistent as possible with the existing
> > code, it will be easy for Sean to merge and clean up as he sees fit.
> > The easiest way to refine your knowledge of the code style aspects we
> > care about are to pay attention to what Sean bothers to change.

> > In general, I find documenting coding conventions to not be very
> > useful.  The easiest things to document clearly are also the most
> > obvious aspects to glean from looking at the code.  The more subtle
> > aspects are very difficult to document clearly and also tend to
> > gradually evolve as the code matures and as the styles of the
> > contributors evolve.  I think that kind of gradual evolution is a good
> > thing and trying to document every last detail of the coding style
> > stunts this evolution and also results in documents that are so long
> > and pedantic that no one wants to read or maintain them.

> > Ryan

> > --
> > You received this message because you are subscribed to the Google Groups
> > "framework-one" group.
> > To post to this group, send email to framework-one@googlegroups.com.
> > To unsubscribe from this group, send email to
> > framework-one+unsubscribe@googlegroups.com<framework-one%2Bunsubscribe@goog legroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/framework-one?hl=en.

> --
> You received this message because you are subscribed to the Google Groups "framework-one" group.
> To post to this group, send email to framework-one@googlegroups.com.
> To unsubscribe from this group, send email to framework-one+unsubscribe@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/framework-one?hl=en.

On Fri, May 7, 2010 at 2:37 PM, Brett <webfl...@gmail.com> wrote:
> Problem is I don't know what those are.  Why are some functions
> written entirely in cfscript and some with cfml.

> noticed is that sometimes arguments are scoped inside functions some
> times they are not.

> Putting functions in alphabetic order, GTK.

On Thu, May 13, 2010 at 8:21 AM, Mike Henke <henkem...@gmail.com> wrote:
> John Allen asked: github that much better than riaforge?

> I am excited to see a major CF project make the jump to Github.

> @Sean Maybe a blog post eventually on how the process to move over
> code and tickets along with updates on how it is going.

On Thu, May 13, 2010 at 8:21 AM, Mike Henke <henkem...@gmail.com> wrote:
> but Github is built specifically for open source source project
> COLLABORATION.  It is kinda like a product versus a feature.

> incorporated in Sean's repository yet some people may want those so they
> will go to the other fork with the changes.

On Thu, May 13, 2010 at 1:09 PM, Mike Henke <henkem...@gmail.com> wrote:
> Or lets say Sean takes a 3 month vacation and doesn't work on FW1.

> There could even be changes that are deemed outside the FW1 scope so
> not incorporated in Sean's repository yet some people may want those
> so they will go to the other fork with the changes.

On Thu, May 13, 2010 at 1:48 PM, Baz <b...@thinkloop.com> wrote:
> GitHub makes collaboration easier and more fun (I'm all for it), but it is
> not required to fork an OS project. If Sean disappears, the project would be
> dormant regardless of what versioning was used, because he's the only one
> with the keys - it's the fork that would be open, and that could be in any
> VCS.

> Same with adding features, it's just a fork, the VCS doesn't matter.

> On Thu, May 13, 2010 at 1:09 PM, Mike Henke <henkem...@gmail.com> wrote:
>> Or lets say Sean takes a 3 month vacation and doesn't work on FW1.

> That would be nice (but a sadly unlikely prospect :)

>> There could even be changes that are deemed outside the FW1 scope so
>> not incorporated in Sean's repository yet some people may want those
>> so they will go to the other fork with the changes.

> Once thing Brett and I have talked about is having satellite FW/1
> extension projects that add features not deemed core. Those projects
> could simply extend framework.cfc and then users' Application.cfc
> could extend that wrapper. That may be a good way to incubate new
> features as well - and forking the FW/1 repo to create various
> satellite projects makes a lot of sense for that as well so the
> wrapper and the core can continue in parallel, picking up changes from
> each other as appropriate.

> --
> Sean A Corfield -- (904) 302-SEAN
> Railo Technologies, Inc. -- http://getrailo.com/
> An Architect's View -- http://corfield.org/

> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood

> --
> You received this message because you are subscribed to the Google Groups "framework-one" group.
> To post to this group, send email to framework-one@googlegroups.com.
> To unsubscribe from this group, send email to framework-one+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/framework-one?hl=en.

On Thu, May 13, 2010 at 2:04 PM, Javier Julio <jjfut...@gmail.com> wrote:
> Be great to see "utilities" or "plugins" show up. My concern though with the suggested approach is that it would require inheritance. So if I like one extension' feature and the other, I'd have to pick one and/or move the functionality from the other. I know it wouldn't be easy but would appreciate it if you would somehow consider how you could support this extensibility but through composition instead. If not no worries from me, happy with FW1 as is! :) Thanks.