Well said ;) On 21/02/2009, at 1:29 AM, Jonathon Brenner wrote: > > Please step into my wayback machine... > > In the old days (when we had to walk 5 miles uphill in snow without > shows to get to school), meaning before test driven development and > github, a project was typically stored in one central repository. Edge > development was kept in trunk and tags were used to denote stable > releases. Stable releases were packaged as zip archives for delivery. > > Now hop back into this badass time machine (it's got spinners! they > just keep spinning! even when it's stopped!) and let's fast-forward a > bit... > > Rubyists are partial to the whole git/github thing and we have much > love for TDD/BDD. Git decentralized ruby development to some extent, > in that development workflows have changed to accommodate the fork, > update, pull/push pattern. Branching is still done all the time on > local repositories. They're used for stories/features. The reason why > you don't often see them in github repositories is because they are > typically merged back into master before it's pushed to github. > > Tags can be used for stable releases, but TDD muddied the water a > little bit. Now, with TDD, the master branch is essentially production > quality. Good testing ensures that what we wrote won't break shit. > That's why the zip that you see on lovdbyless.com is just an archive > of a revision. If we were a professional development shop or were just > less lazy, we'd use a formal development roadmap. Features and > releases would be planned. Release candidates would be thoroughly > click-tested and releases would be tagged. The zip on our website > would refer to github's "download" link for the tag that refers to the > stable release. > > Ok, now let's go back to the present... Let's apply what we've > learned. Pop quiz time! > > We, the LovdByLess team, are: > A. Too lazy to follow a proper development path. > B. Too arrogant to believe that our tests leave us with anything less > than a production quality master. > C. Indifferent because we have other stuff going on. > D. All of the above. > > The answer is E: Who gives a shit? We're putting development time into > a project that would otherwise not exist. If something better comes > out, awesome. If someone forks the project and it catches on, awesome. > I guess that's essentially "C", but whatever. I'm late for work. > > > > > On Fri, Feb 20, 2009 at 8:34 AM, Jason Keenan > <[email protected]> wrote: >> Hi Nick, >> Don't quote me on this as I'm pretty new to git too, but my >> understanding of >> git is that, especially in the case of open source projects, the >> reason that >> there is not much in the way of branching or tagging is that git >> is a true >> 'distributed model'. Every fork is a legitimate 'release'. Some >> may be the >> same, some may be different. At the end of the day the community >> decides >> which is the best version to follow depending on community need >> and the >> speed of development of the fork. If you did a bit of development >> that Steve >> decided he didn't want to pull, say if it clashed with his personal >> philosophies or directions for lovd, but the community likes your >> direction, >> then your fork would be the one that the community would clone >> from. Because >> there is no true owner of a 'central' repository, in lots of cases it >> doesn't make sense to have tags or branches, especially when a >> project isn't >> isn't completely finished. Linus evangelizes git in a video >> that's I think >> is linked to on the main git site. I think it's a talk at google. >> While it's >> not a tutorial it sort of explains what the philosophy is. That's >> my take >> anyway. >> Jason :) >> On 20/02/2009, at 11:38 AM, Nicholas Van Weerdenburg wrote: >> >> Hi Steven, >> >> I'm sure of my own preferences, but was curious about specific >> community >> practices. >> >> For Git, things like branching, release, and maintenance >> strategies. If I >> were to deploy the zip file for a customer, what would there >> upgrade path >> be? If from Git, are there plans for release and maintenance >> branches, etc. >> >> I'm about to start a rails project, and want to define my >> configuration >> management strategy. I'm new to Git having been a svn user, and am >> finding a >> lot of Git projects to run without much branching/tagging, >> especially when >> it comes to maintenance. I'm still unsure why. >> >> Most importantly, I want to leave my clients with a clear >> understanding of >> their platform so that they can move forward on future >> maintenance/upgrades/changes without me being involved if I've >> happened to >> be unavailable. >> >> Overall, I'm fairly sophisticated when it comes to configuration >> management, >> and one things I'm fond of is to align with in-place practices where >> appropriate. >> >> Am I making any sense? >> >> Further along these lines, and I apologize if I may have asked >> similar >> questions a couple of months ago (I've had a break since I started my >> project), what is the envisioned community model regarding >> LovdByLess. I >> don't see many entreaties for contribution,and the sense I get is >> that it's >> viewed somewhat as an almost finished product (which would seem to be >> keeping with the less philosophy). >> >> Thanks, >> Nick >> >> On Thu, Feb 19, 2009 at 12:43 AM, Steven Bristol >> <[email protected]> >> wrote: >>> >>> On Wed, Feb 18, 2009 at 11:02 PM, Nicholas Van Weerdenburg >>> <[email protected]> wrote: >>>> The website doesn't really make much reference to using GitHub >>>> versus >>>> downloading the zip. >>>> >>>> What are most people using? And even if a non-developer, doesn't >>>> it make >>>> sense to use GitHub to allow patching, etc with future versions? >>>> >>>> And reference for using GitHub with LovdByLess? >>>> >>>> Thanks, >>>> Nick >>>> >>> >>> >>> I would say that if you are not sure, then it doesn't really matter. >>> >>> cheers, >>> steven bristol >>> >>> >> >> >> >> -- >> Nicholas Van Weerdenburg >> >> >> >> >> >>> >> > > >
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lovd by Less" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/lovdbyless?hl=en Who loves ya baby? -~----------~----~----~----~------~----~------~--~---
