cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: too long to package a release?
Date Thu, 03 Jan 2013 15:28:56 GMT
On Thu, Jan 3, 2013 at 9:43 AM, Andrew Grieve <agrieve@chromium.org> wrote:

> On Wed, Jan 2, 2013 at 11:05 PM, Michal Mocny <mmocny@chromium.org> wrote:
>
> > On Wed, Jan 2, 2013 at 7:27 PM, Andrew Grieve <agrieve@chromium.org>
> > wrote:
> >
> > > From my understanding of git, there's nothing special about the master
> > > branch, except that it's what gets checked out when someone doesn't
> > > explicitly say which branch they want.
> > >
> > > Joe pointed out that sometimes random people check out the code and
> > expect
> > > it to be stable.
> > > Gord pointed out that people tend to submit pull requests assuming that
> > > master == dev branch.
> > >
> > > I think choosing between these two data points, I'd lean towards having
> > > people submit more useful pull requests.
> > >
> > Well put, agreed.
> >
> >
> > >
> > > I don't think either option affects how you'd go about doing a point
> > > release. You would:
> > > 1. Check out the relevant release tag (e.g. 2.3.0)
> > > 2. Give the branch a name (e.g. branch_2.3.1)
> > >
> > I'm not sure why you would name the branch after checkout?  Wouldn't you
> > name it by tagging after doing the merges in step 3?
> >
>
> When I check out one of our current tags, my branch is "(no branch)". I
> suggest giving it a name right away so that you are able to switch to it
> again.
> $ git checkout 2.2.0
> Note: checking out '2.2.0'.
>
I think that you could just do a "git checkout 2.2" in this case which is
already a branch.  "2.2.0" would be a tag of the HEAD of 2.2 branch if that
was the most recent point release.
Otherwise, we would have multiple branches for each point release, on which
no dev should be done except on the most recent one.  Also, if bugfixes are
done in feature branches of a release branch, every merge back could be
considered a point release?


>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by performing another checkout.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -b with the checkout command again. Example:
>
>   git checkout -b new_branch_name
>
> HEAD is now at 02b91c5... Version 2.2.0
>
>
> >
> >
> > > 3. Merge in all of the changes that you want to put in the point
> release
> > > (ideally, these would already be committed in the dev branch, be it
> > "next"
> > > or "master").
> > > 4. Tag the release.
> > >
> > >
> > > On Wed, Jan 2, 2013 at 5:11 PM, Gord Tanner <gtanner@gmail.com> wrote:
> > >
> > > > Also a problem we have encountered with using a 'next' branch for
> > active
> > > > development is from third party commits.
> > > >
> > > > Every single 3rd party pull request is going to come into master.
> > > >
> > > > You can ether:
> > > > 1. tell them to redo it on next
> > > > 2. rebase it into next for them and let them know for next time.
> > > >
> > > > The cost of option 2 gets more the longer it takes to release.  A 3rd
> > > party
> > > > pull request coming in could be based on code that is 2+ months old.
> > > >
> > > > This isn't a vote against a development branch, but a small annoyance
> > we
> > > > have run into.
> > > >
> > > >
> > > > On Wed, Jan 2, 2013 at 5:08 PM, Gord Tanner <gtanner@gmail.com>
> wrote:
> > > >
> > > > > A hot fix is usually branched off of master, tested, merged and
> > > released.
> > > > >
> > > > > We then rebase / merge the hotfix up into next.
> > > > >
> > > > >
> > > > > On Wed, Jan 2, 2013 at 4:51 PM, Michal Mocny <mmocny@chromium.org>
> > > > wrote:
> > > > >
> > > > >> Also: while I personally prefer master to be the dev channel,
I
> will
> > > say
> > > > >> that I do like Gord's suggestion of how its done in ripple in
that
> > the
> > > > >> name
> > > > >> of the dev branch is 'next' and not '2.3.0' so that your dev
setup
> > > > doesn't
> > > > >> need to change every month.
> > > > >>
> > > > >> Gord: how do you deal with bugfixes/point releases?  Do you fix
in
> > > > feature
> > > > >> branch, merge into next, and then cherry-pick/merge just that
fix
> > into
> > > > >> master before doing a major release?  Or, do you just offer
> bugfixes
> > > via
> > > > >> 'next'?
> > > > >>
> > > > >>
> > > > >> On Wed, Jan 2, 2013 at 4:45 PM, Michal Mocny <mmocny@chromium.org
> >
> > > > wrote:
> > > > >>
> > > > >> > I don't have much weight here, but personally I feel that
this
> > seems
> > > > >> > backwards.
> > > > >> >
> > > > >> > With this proposal (if I understand it), when you do a fresh
> > > checkout
> > > > of
> > > > >> > the codebase, instead of sitting on the bleeding edge, you
would
> > be
> > > > >> sitting
> > > > >> > at a "stable" release which is conceptually read-only for
most
> > > > >> contributors
> > > > >> > (writes happen in the form of batch "releases" which itself
> would
> > > just
> > > > >> be
> > > > >> > some git-fu to rebase master).
> > > > >> >
> > > > >> > I am happy enough to have features be worked on in branches
> etc, I
> > > > just
> > > > >> > think that it should be flipped and the stable release be
the
> > branch
> > > > and
> > > > >> > dev to be on master.
> > > > >> >
> > > > >> >
> > > > >> > As a separate issue, I would suggest not using branches
to
> "name"
> > > > point
> > > > >> > releases, but just tag them.  If you have a 2.3.0 release,
and
> you
> > > > need
> > > > >> to
> > > > >> > fix a bug in 2.3.1, those should not become two logically
> separate
> > > > code
> > > > >> > branches with independent dev, but rather they are a logically
> > > single
> > > > >> > timeline with many names for each historically significant
> commit,
> > > > >> right?
> > > > >> >  Thats what tags are for (
> > > > http://git-scm.com/book/en/Git-Basics-Tagging
> > > > >> ).
> > > > >> >
> > > > >> > -Michal
> > > > >> >
> > > > >> >
> > > > >> > On Wed, Jan 2, 2013 at 3:05 PM, Gord Tanner <gtanner@gmail.com>
> > > > wrote:
> > > > >> >
> > > > >> >> This is what we have done in ripple (and webworks)
> > > > >> >>
> > > > >> >> master - always stable current shipping code
> > > > >> >> next - always 'stable' next release. Expectation that
code has
> > been
> > > > >> tested
> > > > >> >> / run before merged into this branch.
> > > > >> >> feature branches - branched off of next and merged into
next
> when
> > > > >> stable /
> > > > >> >> done. Not expected to be stable or runnable until merge
time.
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> On Wed, Jan 2, 2013 at 2:32 PM, Filip Maj <fil@adobe.com>
> wrote:
> > > > >> >>
> > > > >> >> > Am I correct when I say that, with this approach,
master
> > becomes
> > > a
> > > > >> >> series
> > > > >> >> > of merge commits coming from dev, then ?
> > > > >> >> >
> > > > >> >> > A couple questions to follow up:
> > > > >> >> >
> > > > >> >> > - "features get forked from stable" - forked from
master,
> yes?
> > > > >> >> > - "features, when ready, tested against dev branch"
- what
> does
> > > > this
> > > > >> >> mean?
> > > > >> >> > Does this mean, you would merge feature branch
into dev
> branch
> > > > >> (locally)
> > > > >> >> > then run tests to make sure things work?
> > > > >> >> >
> > > > >> >> > On 1/2/13 11:19 AM, "Joe Bowser" <bowserj@gmail.com>
wrote:
> > > > >> >> >
> > > > >> >> > >OK, Let's rethink this:
> > > > >> >> > >
> > > > >> >> > >After talking with Brian on the 21st, I think
we agree on
> > this:
> > > > >> >> > >
> > > > >> >> > > * Master remains stable and sits at the most
recent
> released
> > > code
> > > > >> >> > >(i.e. 2.3.0 once we get 2.3.0 done) (Stable
Channel)
> > > > >> >> > > * Dev happens on branches for the releases
(i.e. 2.4.0)
> (Dev
> > > > >> Channel)
> > > > >> >> > > * In the case of a point release, dev happens
in the branch
> > of
> > > > the
> > > > >> >> > >major release (i.e. 2.3.1 would happen in the
2.3.0 branch,
> > not
> > > > >> >> > >master) (Testing Channel)
> > > > >> >> > > * Features get forked on stable then once
the feature is
> > ready,
> > > > >> >> > >tested against the dev branch.  If they work
with stable,
> they
> > > > >> SHOULD
> > > > >> >> > >work with 2.4.0.  If they don't, the tickets
get added to
> > 2.4.0
> > > to
> > > > >> >> > >make it work with that release.  That way things
are more
> > > > >> predictable
> > > > >> >> > >as far as new features are concerned. (You
will burn your
> face
> > > > >> >> > >channel).
> > > > >> >> > >
> > > > >> >> > >Does that make sense? Working on master for
things causes us
> > > pain
> > > > >> and
> > > > >> >> > >we should use git conventions to make it simpler
for people
> > who
> > > > >> expect
> > > > >> >> > >our master to work all the time.  I don't think
this will
> > speed
> > > up
> > > > >> the
> > > > >> >> > >release as much as automating tagging of RCs
so that when
> the
> > JS
> > > > is
> > > > >> >> > >tagged, everything else is tagged.  The week
it takes to tag
> > an
> > > RC
> > > > >> is
> > > > >> >> > >way too long.
> > > > >> >> > >
> > > > >> >> > >
> > > > >> >> > >On Wed, Jan 2, 2013 at 11:08 AM, Filip Maj
<fil@adobe.com>
> > > wrote:
> > > > >> >> > >> Bumping this thread. I'd like Joe to clarify
as well.
> > > > >> >> > >>
> > > > >> >> > >> On 12/20/12 12:26 PM, "Brian LeRoux" <b@brian.io>
wrote:
> > > > >> >> > >>
> > > > >> >> > >>>Ok, I want to understand this, let
me take a stab.
> > > > >> >> > >>>
> > > > >> >> > >>>You describe three long-lived branches
like this:
> > > > >> >> > >>>
> > > > >> >> > >>>- Master: This is stable and frozen
on the last tagged
> > > release.
> > > > >> >> > >>>- Dev: the next release to be tagged.
Feature branches
> > merged
> > > > from
> > > > >> >> > >>>master when confident.
> > > > >> >> > >>>- Unstable: the current working branch
for a particular
> tag.
> > > > >> Feature
> > > > >> >> > >>>branches merged as needed for collaboration.
> > > > >> >> > >>>
> > > > >> >> > >>>Everyone works from local feature branch
rebasing and
> > > committing
> > > > >> to
> > > > >> >> > >>>master. When that feature branch is
considered good
> enough,
> > it
> > > > is
> > > > >> >> > >>>merged into dev, and work continues.
Whatever date we
> happen
> > > to
> > > > >> pick
> > > > >> >> > >>>for a release that is what dev becomes,
we tag, and move
> > that
> > > > sha
> > > > >> to
> > > > >> >> > >>>stable if its not an RC.
> > > > >> >> > >>>
> > > > >> >> > >>>?
> > > > >> >> > >>>
> > > > >> >> > >>>
> > > > >> >> > >>>
> > > > >> >> > >>>
> > > > >> >> > >>>On Thu, Dec 20, 2012 at 10:52 AM, Joe
Bowser <
> > > bowserj@gmail.com
> > > > >
> > > > >> >> wrote:
> > > > >> >> > >>>> I'm OK with this, but I think
your example is off:
> > > > >> >> > >>>>
> > > > >> >> > >>>> Where n is the current released
piece of the software:
> > > > >> >> > >>>>
> > > > >> >> > >>>> n.x.x = Stable
> > > > >> >> > >>>> n+1.x.x = Dev
> > > > >> >> > >>>> master = Unstable, can have things
merged in from
> feature
> > > > >> branches
> > > > >> >> > >>>>
> > > > >> >> > >>>> This fully uncouples features
from release planning,
> which
> > > is
> > > > >> good
> > > > >> >> > >>>> because it means the release will
land in the version
> when
> > > > it's
> > > > >> >> ready,
> > > > >> >> > >>>> and not for any other reason.
 I also propose that we
> keep
> > > > using
> > > > >> >> the
> > > > >> >> > >>>> same RC tags and that for a final
release we tag it
> > > > x.x.xFinal.
> > > > >>  We
> > > > >> >> > >>>> still need to tag an RC and re-tag
it.
> > > > >> >> > >>>>
> > > > >> >> > >>>> Release Process:
> > > > >> >> > >>>> 1. Tag the dev tree
> > > > >> >> > >>>> 2. merge the dev tree back into
master
> > > > >> >> > >>>> 3. Create 2.5.0 branch
> > > > >> >> > >>>> 4. File issues from 2.5.0 in JIRA
> > > > >> >> > >>>>
> > > > >> >> > >>>> I also propose that we automate
the tagging.  If an RC
> is
> > > > >> broken,
> > > > >> >> we
> > > > >> >> > >>>> just cut another RC.  A lot of
our retagging is done to
> > get
> > > > >> around
> > > > >> >> the
> > > > >> >> > >>>> pain of having to do another RC.
 The biggest part of
> the
> > > > delay
> > > > >> is
> > > > >> >> > >>>> waiting for every single platform
maintainer to tag
> their
> > > > >> platform
> > > > >> >> > >>>> after the JS was tagged.  For
example, I tagged rc2 for
> > the
> > > JS
> > > > >> and
> > > > >> >> for
> > > > >> >> > >>>> Android on Monday last week from
my hotel room, and the
> > > > release
> > > > >> >> wasn't
> > > > >> >> > >>>> fully tagged until this week.
 I'm fine with RCs going
> up
> > to
> > > > 10
> > > > >> as
> > > > >> >> > >>>> long as we can release early,
release often and release
> > when
> > > > we
> > > > >> >> want
> > > > >> >> > >>>> to and not run out of time and
have to delay.
> > > > >> >> > >>>>
> > > > >> >> > >>>> On Thu, Dec 20, 2012 at 10:33
AM, Brian LeRoux <
> > b@brian.io>
> > > > >> wrote:
> > > > >> >> > >>>>> Truth. Though lets not get
hung up on the past and just
> > > focus
> > > > >> on
> > > > >> >> the
> > > > >> >> > >>>>> present. We've done a really
good job getting where we
> > are.
> > > > >> >> > >>>>>
> > > > >> >> > >>>>> So, Joe, are you saying you
like the idea of three long
> > > lived
> > > > >> >> > >>>>>branches
> > > > >> >> > >>>>> and merges happen from local
feature branches?
> > > > >> >> > >>>>>
> > > > >> >> > >>>>>
> > > > >> >> > >>>>> On Thu, Dec 20, 2012 at 10:22
AM, Joe Bowser <
> > > > >> bowserj@gmail.com>
> > > > >> >> > >>>>>wrote:
> > > > >> >> > >>>>>> We are totally doing something
wrong with the way that
> > we
> > > do
> > > > >> >> > >>>>>>releases.
> > > > >> >> > >>>>>>  I personally think that
we're not using git right,
> and
> > > > here's
> > > > >> >> why:
> > > > >> >> > >>>>>>
> > > > >> >> > >>>>>> Currently, when we do
a release, we tag the RC, and we
> > > test
> > > > >> the
> > > > >> >> RC.
> > > > >> >> > >>>>>> There's nothing preventing
us from putting things
> after
> > > that
> > > > >> tag
> > > > >> >> and
> > > > >> >> > >>>>>> if we don't want to those
things in the release
> > branching
> > > > off
> > > > >> >> that
> > > > >> >> > >>>>>> tag.  We've done it before
and other than the problem
> > with
> > > > >> CoHo,
> > > > >> >> it
> > > > >> >> > >>>>>> worked really well.  I
propose that instead of tagging
> > the
> > > > >> >> release,
> > > > >> >> > >>>>>>we
> > > > >> >> > >>>>>> branch when we want to
do a release, and we do all the
> > bug
> > > > >> fixes
> > > > >> >> on
> > > > >> >> > >>>>>> that branch.  Once that
branch is ready to roll, we
> > merge
> > > it
> > > > >> back
> > > > >> >> > >>>>>>into
> > > > >> >> > >>>>>> master.  In fact, nobody
should be working on master
> > > except
> > > > >> to do
> > > > >> >> > >>>>>> merges.  The way we're
doing this now feels dirty and
> > > wrong.
> > > > >> >> > >>>>>>
> > > > >> >> > >>>>>> I honestly feel that this
is a much faster way of
> > working,
> > > > and
> > > > >> >> that
> > > > >> >> > >>>>>> we're missing the point
if we have to tell everyone to
> > > jump
> > > > >> out
> > > > >> >> of
> > > > >> >> > >>>>>>the
> > > > >> >> > >>>>>> pool every time we do
an RC.  I know that we could be
> > > > working
> > > > >> on
> > > > >> >> our
> > > > >> >> > >>>>>> branches, but that work
is almost entirely invisible
> to
> > > the
> > > > >> rest
> > > > >> >> of
> > > > >> >> > >>>>>> the project until it's
time to merge it back in, which
> > > takes
> > > > >> >> > >>>>>>forever.
> > > > >> >> > >>>>>>
> > > > >> >> > >>>>>>
> > > > >> >> > >>>>>> On Thu, Dec 20, 2012 at
10:07 AM, Michal Mocny <
> > > > >> >> mmocny@chromium.org
> > > > >> >> > >
> > > > >> >> > >>>>>>wrote:
> > > > >> >> > >>>>>>> So there is something
to be said about having devs
> > shift
> > > > >> focus
> > > > >> >> from
> > > > >> >> > >>>>>>>dev to
> > > > >> >> > >>>>>>> testing during an
RC.  However, as the team grows,
> not
> > > all
> > > > >> of us
> > > > >> >> > >>>>>>>are
> > > > >> >> > >>>>>>>really
> > > > >> >> > >>>>>>> being responsible
for cutting releases.  Maybe that
> > means
> > > > we
> > > > >> >> need
> > > > >> >> > >>>>>>>to
> > > > >> >> > >>>>>>>train
> > > > >> >> > >>>>>>> the entire team to
change current behavior, but that
> > > > doesn't
> > > > >> >> feel
> > > > >> >> > >>>>>>> necessary/scalable.
> > > > >> >> > >>>>>>>
> > > > >> >> > >>>>>>> With growing external
contributions, I would have to
> > say
> > > > >> that a
> > > > >> >> > >>>>>>>code
> > > > >> >> > >>>>>>>freeze
> > > > >> >> > >>>>>>> on trunk doesn't seem
to make as much sense.
> > > > >> >> > >>>>>>>
> > > > >> >> > >>>>>>> -Michal
> > > > >> >> > >>>>>>>
> > > > >> >> > >>>>>>>
> > > > >> >> > >>>>>>> On Thu, Dec 20, 2012
at 9:47 AM, Andrew Grieve
> > > > >> >> > >>>>>>><agrieve@chromium.org>
wrote:
> > > > >> >> > >>>>>>>
> > > > >> >> > >>>>>>>> I definitely think
we'd get more done if we didn't
> > have
> > > > >> such a
> > > > >> >> > >>>>>>>>long
> > > > >> >> > >>>>>>>> code-freeze. I'm
not sure this is the same as what
> you
> > > > were
> > > > >> >> > >>>>>>>>suggesting, but
> > > > >> >> > >>>>>>>> have a script/tool
to branch all of the platforms
> into
> > > an
> > > > rc
> > > > >> >> > >>>>>>>>branch. Then,
> > > > >> >> > >>>>>>>> each platform
can fix themselves up a bit and tag
> > their
> > > > RC.
> > > > >> >> > >>>>>>>>Meanwhile, dev
> > > > >> >> > >>>>>>>> can continue to
happen on edge.
> > > > >> >> > >>>>>>>>
> > > > >> >> > >>>>>>>> My main concern
with our current approach is just
> that
> > > the
> > > > >> >> > >>>>>>>>code-freeze time
> > > > >> >> > >>>>>>>> is super long.
> > > > >> >> > >>>>>>>>
> > > > >> >> > >>>>>>>>
> > > > >> >> > >>>>>>>> On Wed, Dec 19,
2012 at 3:36 PM, Marcel Kinard
> > > > >> >> > >>>>>>>><cmarcelk@gmail.com>
> > > > >> >> > >>>>>>>>wrote:
> > > > >> >> > >>>>>>>>
> > > > >> >> > >>>>>>>> > One of the
things that strikes me here is the
> > > difference
> > > > >> >> between
> > > > >> >> > >>>>>>>>calendar
> > > > >> >> > >>>>>>>> > time and
effort time. (This assumes folks already
> > > > >> concurred
> > > > >> >> that
> > > > >> >> > >>>>>>>>the rc
> > > > >> >> > >>>>>>>> is
> > > > >> >> > >>>>>>>> > ready to
release.) Based on my reading of
> > > > >> >> > >>>>>>>>http://wiki.apache.org/**
> > > > >> >> > >>>>>>>> > cordova/CuttingReleases
> > > > >> >> > >>>>>>>><http://wiki.apache.org/cordova/CuttingReleases
> >there
> > > > >> >> > >>>>>>>> isn't a lot of
effort time involved to cut a
> release.
> > It
> > > > >> seems
> > > > >> >> > >>>>>>>>like
> > > > >> >> > >>>>>>>>a
> > > > >> >> > >>>>>>>> > good chunk
of the calendar time is getting folks
> to
> > > tag
> > > > >> their
> > > > >> >> > >>>>>>>>platform.
> > > > >> >> > >>>>>>>> > Ideally the
promotion from rc to final should take
> > > very
> > > > >> >> little
> > > > >> >> > >>>>>>>>effort
> > > > >> >> > >>>>>>>> time.
> > > > >> >> > >>>>>>>> >
> > > > >> >> > >>>>>>>> > What I like
about the rc is that it provides a
> > > settling
> > > > >> >> > >>>>>>>>mechanism
> > > > >> >> > >>>>>>>>for the
> > > > >> >> > >>>>>>>> > churn to
calm down, run tests across more
> > integration,
> > > > and
> > > > >> >> see
> > > > >> >> > >>>>>>>>the bigger
> > > > >> >> > >>>>>>>> > picture to
assess release readiness. I would
> expect
> > > that
> > > > >> the
> > > > >> >> > >>>>>>>>promotion
> > > > >> >> > >>>>>>>> from
> > > > >> >> > >>>>>>>> > edge to rc
should take a decent amount of effort
> > time,
> > > > but
> > > > >> >> not
> > > > >> >> > >>>>>>>>because of
> > > > >> >> > >>>>>>>> > the "cut"
activities.
> > > > >> >> > >>>>>>>> >
> > > > >> >> > >>>>>>>> > So when we
are at rc and don't find any surprises,
> > why
> > > > >> does
> > > > >> >> it
> > > > >> >> > >>>>>>>>take a
> > > > >> >> > >>>>>>>> week
> > > > >> >> > >>>>>>>> > to promote
to final? If we spend a week in rc1,
> > > another
> > > > >> week
> > > > >> >> in
> > > > >> >> > >>>>>>>>rc2, and
> > > > >> >> > >>>>>>>> > another week
to cut final, that leaves only 1 week
> > in
> > > a
> > > > >> >> 4-week
> > > > >> >> > >>>>>>>>cycle for
> > > > >> >> > >>>>>>>> > active dev
work?
> > > > >> >> > >>>>>>>> >
> > > > >> >> > >>>>>>>> > I like the
ideal of a
> channel/stream/branch/whatever
> > > > where
> > > > >> >> there
> > > > >> >> > >>>>>>>>is a
> > > > >> >> > >>>>>>>> > place for
the rc to settle without necessarily
> > > blocking
> > > > >> >> commits
> > > > >> >> > >>>>>>>>to edge.
> > > > >> >> > >>>>>>>> > Where I'm
going with this is that if there is an
> > area
> > > > >> where
> > > > >> >> > >>>>>>>>commits to
> > > > >> >> > >>>>>>>> the
> > > > >> >> > >>>>>>>> > rc are carefully
controlled, then perhaps one
> person
> > > > (i.e,
> > > > >> >> Steve
> > > > >> >> > >>>>>>>>G) could
> > > > >> >> > >>>>>>>> > cut the release
for ALL platforms using scripts.
> > This
> > > > may
> > > > >> >> > >>>>>>>>involve
> > > > >> >> > >>>>>>>>that
> > > > >> >> > >>>>>>>> one
> > > > >> >> > >>>>>>>> > person tagging/branching/whatever
across multiple
> > > > >> platforms.
> > > > >> >> > >>>>>>>> >
> > > > >> >> > >>>>>>>> > I also like
putting the "how to cut" magic in each
> > > > >> platform.
> > > > >> >> > >>>>>>>>Then
> > > > >> >> > >>>>>>>>perhaps
> > > > >> >> > >>>>>>>> > a good chunk
of coho is tests to make sure that
> the
> > > > >> platform
> > > > >> >> > >>>>>>>>magic
> > > > >> >> > >>>>>>>> > delivered
the correct format to it.
> > > > >> >> > >>>>>>>> >
> > > > >> >> > >>>>>>>> > -- Marcel
Kinard
> > > > >> >> > >>>>>>>> >
> > > > >> >> > >>>>>>>>
> > > > >> >> > >>
> > > > >> >> >
> > > > >> >> >
> > > > >> >>
> > > > >> >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

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