cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: too long to package a release?
Date Thu, 07 Feb 2013 19:59:39 GMT
The doc's not up-to-date, but I think we ended on consensus for the code
version. I've taken a stab at updating the wiki pages:

http://wiki.apache.org/cordova/CordovaAndGit  -- Added the idea of having
both a master and a next branch
http://wiki.apache.org/cordova/CommitterWorkflow  -- Added Jesse's version
of the "which branch - in code"
http://wiki.apache.org/cordova/CuttingReleases  -- Changed tagging
instructions to refer to the "next" branch


On Thu, Feb 7, 2013 at 1:26 PM, Marcel Kinard <cmarcelk@gmail.com> wrote:

> With 2.5 starting, it appears time to poke this thread.
>
> - Is the Google doc refreshed with the latest consensus?
> - If so, should the Google doc be transferred to a wiki page?
> - Have the necessary branches been created?
> - Are we all in the boat, and understand how to row this beast?
>
> -- Marcel Kinard
>
> On Jan 24, 2013, at 5:14 PM, Jesse <purplecabbage@gmail.com> wrote:
>
> > Nice Shaz, but I was hoping it was a github style network visualization
> > that included a few versions worth of merges.
> > Who wants to draw that?
> >
> > On Thu, Jan 24, 2013 at 2:05 PM, Shazron <shazron@gmail.com> wrote:
> >
> >> Inline image got mangled, here it is linked: http://cl.ly/MOrD
> >>
> >>
> >> On Thu, Jan 24, 2013 at 1:39 PM, Shazron <shazron@gmail.com> wrote:
> >>
> >>> Thanks for the pseudocode Andrew, seems simpler to understand ;)
> Jesse's
> >>> re-factor makes it even easier. Here's my contrib for those more
> visually
> >>> inclined:
> >>>
> >>>
> >>> [image: Inline image 2]
> >>>
> >>>
> >>> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <agrieve@chromium.org
> >wrote:
> >>>
> >>>> Nice! even simpler. :)
> >>>>
> >>>>
> >>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <purplecabbage@gmail.com>
> wrote:
> >>>>
> >>>>> Thanks for clarifying Andrew. et al, I guess I was mis-understanding
> >>>> some
> >>>>> of the earlier discussion around naming stuff.
> >>>>>
> >>>>> So everything is going to master all the time, and we only care
about
> >>>>> 'next' if we are inReleaseMode and it is a bug fix?
> >>>>>
> >>>>> if(inReleaseMode && isBugFix) {
> >>>>>    commitToBranch('next');
> >>>>>    mergeBranch('next').into('master');
> >>>>> }
> >>>>> else {
> >>>>>    commitToBranch('master');
> >>>>> }
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <
> agrieve@chromium.org
> >>>>>> wrote:
> >>>>>
> >>>>>> Just to clarify - there should be *no* using of the git
> >>>> cherry-picking
> >>>>>> command, only git merge.
> >>>>>>
> >>>>>> Jesse - not sure what you're referring to with "branch must
be named
> >>>> x".
> >>>>>> The latest revision of the proposal has only two branches: master
> and
> >>>>> next.
> >>>>>> Do you mean you don't like the name "next"?
> >>>>>>
> >>>>>> Maybe the proposal will seem simpler if put in the form of code
:)
> >>>>>>
> >>>>>> if (!inReleaseMode) {
> >>>>>>    commitToBranch('master');
> >>>>>> } else {
> >>>>>>  if (isBugFix) {
> >>>>>>    commitToBranch('next');
> >>>>>>    mergeBranch('next').into('master');
> >>>>>>  } else {
> >>>>>>    commitToBranch('master');
> >>>>>>  }
> >>>>>> }
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <
> >>>> braden@chromium.org
> >>>>>>> wrote:
> >>>>>>
> >>>>>>> Most of the time the flow will be unchanged: push to master.
> >>>> Tagging
> >>>>>> things
> >>>>>>> we already know how to do; that doesn't change.
> >>>>>>>
> >>>>>>> The only new flow for most people is cherrypicking bug fixes
from
> >>>>> master
> >>>>>> to
> >>>>>>> next, which we can give examples of. Plus that could remain
the
> >>>>>>> responsibility of the main platform maintainers, who are
doing the
> >>>>>> tagging.
> >>>>>>>
> >>>>>>> Braden
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, Jan 24, 2013 at 2:56 PM, Jesse <purplecabbage@gmail.com>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson
<
> >>>>>>> braden@chromium.org
> >>>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> The founding goal we're trying to accomplish here
is that we
> >>>> don't
> >>>>>> want
> >>>>>>>>> everyone sitting on changes to be in the next version
while we
> >>>> use
> >>>>>>> master
> >>>>>>>>> to prep a release.
> >>>>>>>>>
> >>>>>>>>> I don't think having one branch for prepping the
release and
> >>>>> another
> >>>>>>> for
> >>>>>>>>> main development is a lot of bureaucracy.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> It is not, the 'branch must be named x' is mainly where
I have
> >>>>>> concerns.
> >>>>>>>> Really I just want things simple.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen
<
> >>>>>>>> purplecabbage@gmail.com
> >>>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> I have been quietly listening on this thread,
but thought I
> >>>>> should
> >>>>>> at
> >>>>>>>>>> least share my opinion.
> >>>>>>>>>>
> >>>>>>>>>> I don't think adding contribution rules helps
anyone. Git is
> >>>>>>>>>> complicated enough as it is, and this just all
seems like
> >>>>>>> bureaucracy.
> >>>>>>>>>>
> >>>>>>>>>> I think master should always contain the latest
stable code,
> >>>> and
> >>>>> be
> >>>>>>>>>> periodically tagged with rc's and versions.
> >>>>>>>>>> All work should be done in personal forks and
feature
> >>>> branches.
> >>>>>>>>>> If the latest tag of master is an rc, then we
should only be
> >>>>>> merging
> >>>>>>>>>> bugfixes, until the release.
> >>>>>>>>>> Immediately after tagging a version we decide
which feature
> >>>>>> branches
> >>>>>>>>>> and pull requests to pull in, and go for it.
> >>>>>>>>>>
> >>>>>>>>>> I don't think this is much different from what
we have, but I
> >>>>> think
> >>>>>>>>>> that is good.
> >>>>>>>>>> The suggestions thus far, while interesting,
don't increase
> >>>> our
> >>>>>>>>>> velocity in my opinion. Also, I can also pretty
much guaranty
> >>>>> I'll
> >>>>>>>>>> screw it up for the next 3-4 versions. ( because
I'm dumb )
> >>>>>>>>>>
> >>>>>>>>>> Cheers,
> >>>>>>>>>>  Jesse
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 2013-01-24, at 5:53 AM, Andrew Grieve <
> >>>> agrieve@chromium.org>
> >>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks
<
> >>>>>>>>> michael@michaelbrooks.ca
> >>>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Before we move forward, I have a few questions
about the
> >>>> "no
> >>>>>>> master"
> >>>>>>>>>>> approach.
> >>>>>>>>>>>
> >>>>>>>>>>> There is *no* master branch, so that community-driven
pull
> >>>>>> requests
> >>>>>>>>> will
> >>>>>>>>>> be
> >>>>>>>>>>>> forced to think about which branch to
request against.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> - Andrew, can you cite other projects that
do not use a
> >>>> master
> >>>>>>>> branch?
> >>>>>>>>>> This project is my first time using git / github,
so I don't
> >>>> have
> >>>>>>> much
> >>>>>>>> to
> >>>>>>>>>> draw from. I was going off of others' suggestions
on this
> >>>> thread
> >>>>>>> when I
> >>>>>>>>>> proposed the names.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> - On Github, you must have a default branch.
If not
> >>>> master, it
> >>>>>> must
> >>>>>>>> be
> >>>>>>>>>>> something else. So, users are not forced
to think about the
> >>>>>> branch
> >>>>>>> to
> >>>>>>>>>> send
> >>>>>>>>>>> a pull request again... they will likely
just use the
> >>>> default.
> >>>>>>>>>>
> >>>>>>>>>> Hmm, good point. The goal is to get people downloading
> >>>> Cordova
> >>>>> for
> >>>>>>> use
> >>>>>>>> to
> >>>>>>>>>> end up with Stable, and for developers to send
pull requests
> >>>>>> against
> >>>>>>>> dev.
> >>>>>>>>>> With a forced default branch, I don't think
we can accomplish
> >>>>> this.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> - Why is the "stable" branch not just "master"?
> >>>>>>>>>>
> >>>>>>>>>> My thinking was that it's not obvious whether
Master ==
> >>>> bleeding
> >>>>>>> edge,
> >>>>>>>> or
> >>>>>>>>>> Master == Stable version. Using the names "dev"
and "stable"
> >>>>> makes
> >>>>>>> it a
> >>>>>>>>> bit
> >>>>>>>>>> clear.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> So... If github forces us to have a default
branch, I'm
> >>>> thinking
> >>>>>> that
> >>>>>>>>>> having users send pull requests against "dev"
is more
> >>>> valuable
> >>>>> than
> >>>>>>>>> having
> >>>>>>>>>> people download the latest "stable" by default.
If people are
> >>>>>> pulling
> >>>>>>>>> code
> >>>>>>>>>> from github rather than from our release .zip
files, then
> >>>> it's
> >>>>>> likely
> >>>>>>>>> they
> >>>>>>>>>> want to hack on it anyways, or that they want
the dev
> >>>> version to
> >>>>>> see
> >>>>>>> if
> >>>>>>>>>> bugs are fixed.
> >>>>>>>>>>
> >>>>>>>>>> Soo.... Here's version #3! If anyone can think
of how to
> >>>> keep the
> >>>>>>> three
> >>>>>>>>>> branches while addressing being forced to have
a default
> >>>> branch,
> >>>>>> feel
> >>>>>>>>> free
> >>>>>>>>>> to speak up! :)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Cordova repositories have two main branches:
> >>>>>>>>>> 1. master
> >>>>>>>>>> 2. next
> >>>>>>>>>>
> >>>>>>>>>> Topic branches exist for collaborating on features,
or for
> >>>>>>> code-review
> >>>>>>>>>> purposes.
> >>>>>>>>>>
> >>>>>>>>>> Cordova uses tags to label releases.
> >>>>>>>>>> - Each release candidate has a tag. e.g. "2.2.0rc1"
> >>>>>>>>>> - Each release has a tag. e.g. "2.2.0"
> >>>>>>>>>> - The "latest" tag points to the last stable
release (this
> >>>>> follows
> >>>>>>> npm
> >>>>>>>>>> conventions)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 1. The "next" branch.
> >>>>>>>>>> - This branch is used only when in the process
of doing a
> >>>>> release.
> >>>>>>>>>> - All tags are created from this branch.
> >>>>>>>>>> - All release-candidate bug-fixes are done on
this branch.
> >>>>>>>>>>
> >>>>>>>>>> 2. The "master" branch.
> >>>>>>>>>> - When not in the release-process, all commits
are made here
> >>>>>>>>>> - When in the release-process, all non-bugfix
commits are
> >>>> made
> >>>>>> here
> >>>>>>>>>> - This is where topic-branches are merged into.
> >>>>>>>>>>
> >>>>>>>>>> Cutting a release:
> >>>>>>>>>> 1. git checkout next && git merge --ff-only
master
> >>>>>>>>>> 2. Test test test!
> >>>>>>>>>> 3. Fix bugs by committing them directly to "next"
and then
> >>>> doing
> >>>>> a
> >>>>>>>> non-ff
> >>>>>>>>>> merge of next into master
> >>>>>>>>>> 4. Tag release candidate
> >>>>>>>>>> 5. Repeat steps 2-4 as necessary
> >>>>>>>>>> 6. Tag the release (both by version and by updating
the
> >>>> "latest"
> >>>>>> tag)
> >>>>>>>>>> 7. Create distribution .zip file
> >>>>>>>>>> 8. Test one last time using the dist files
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>> Michael
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, Jan 23, 2013 at 11:25 AM, Brian
LeRoux <b@brian.io
> >>>>>
> >>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> I'm liking it. Start in 2.5?
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Jan 23, 2013 at 1:19 PM, Filip
Maj <fil@adobe.com
> >>>>>
> >>>>>> wrote:
> >>>>>>>>>>>>> Looks great Andrew!
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If everyone's on board, how are
we going to test run
> >>>> this?
> >>>>>> Flip a
> >>>>>>>>>>> switch
> >>>>>>>>>>>>> at a certain point, give it a shot
with one repo for one
> >>>> RC?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 1/22/13 12:29 PM, "Andrew Grieve"
<
> >>>> agrieve@chromium.org>
> >>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Braden, you're right. I've now
done some local playing
> >>>>> around
> >>>>>> in
> >>>>>>>>> git,
> >>>>>>>>>>> and
> >>>>>>>>>>>>>> have an updated proposal that
uses merges instead of
> >>>>> deleting
> >>>>>>>>>> branches.
> >>>>>>>>>>>>>> PTAL:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Cordova repositories have three
main branches:
> >>>>>>>>>>>>>> 1. stable
> >>>>>>>>>>>>>> 2. next
> >>>>>>>>>>>>>> 3. dev
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Topic branches also exist for
collaborating on
> >>>> features, or
> >>>>>> for
> >>>>>>>>>>>>>> code-review
> >>>>>>>>>>>>>> purposes.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> There is *no* master branch,
so that community-driven
> >>>> pull
> >>>>>>>> requests
> >>>>>>>>>>> will
> >>>>>>>>>>>>>> be
> >>>>>>>>>>>>>> forced to think about which
branch to request against.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 1. The "stable" branch.
> >>>>>>>>>>>>>> - Sits at the latest stable
release of cordova
> >>>>>>>>>>>>>> - This changes only when doing
fast-forward merges from
> >>>>> "next"
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 2. The "next" branch.
> >>>>>>>>>>>>>> - This branch is used only when
in the process of doing
> >>>> a
> >>>>>>> release.
> >>>>>>>>>>>>>> - All tags (both stable and
RC) are done on this branch.
> >>>>>>>>>>>>>> - All release-candidate bug-fixes
are done on this
> >>>> branch.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 3. The "dev" branch.
> >>>>>>>>>>>>>> - This is where non-release-candidate
commits are done
> >>>>>>>>>>>>>> - This is where topic-branches
are merged into.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Cutting a release:
> >>>>>>>>>>>>>> 1. git checkout next &&
git merge --ff-only dev
> >>>>>>>>>>>>>> 2. Test test test!
> >>>>>>>>>>>>>> 3. Fix bugs by committing them
directly to "next" and
> >>>> then
> >>>>>>> doing a
> >>>>>>>>>>> non-ff
> >>>>>>>>>>>>>> merge of next into dev
> >>>>>>>>>>>>>> 4. Tag release candidate
> >>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary
> >>>>>>>>>>>>>> 6. Tag the release
> >>>>>>>>>>>>>> 7. Create distribution .zip
file
> >>>>>>>>>>>>>> 8. Test one last time using
the dist files
> >>>>>>>>>>>>>> 9. git checkout stable &&
git merge --ff-only next
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 1:59
PM, Braden Shepherdson
> >>>>>>>>>>>>>> <braden@chromium.org>wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I think deleting and recreating
branches with the same
> >>>> name
> >>>>>> can
> >>>>>>>>> cause
> >>>>>>>>>>>>>>> badness in git[1] because
of remotes. It's not really
> >>>> the
> >>>>>> same
> >>>>>>>>> branch
> >>>>>>>>>>>> in
> >>>>>>>>>>>>>>> terms of commits, and git
thinks that your old stable
> >>>> and
> >>>>> the
> >>>>>>> new
> >>>>>>>>>>>> stable
> >>>>>>>>>>>>>>> differ by all of each of
their commits. Tags can be
> >>>> moved
> >>>>>>>>>>> arbitrarily,
> >>>>>>>>>>>>>>> so I
> >>>>>>>>>>>>>>> think stable makes sense
as a tag. I'm not sure about
> >>>> how
> >>>>>> best
> >>>>>>> to
> >>>>>>>>>>>> handle
> >>>>>>>>>>>>>>> next.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
> >>>>>>>>>>>>>>> h
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at
11:31 AM, Andrew Grieve <
> >>>>>>>>>>> agrieve@chromium.org
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Michal's attending hackathons
for the week, and I'm
> >>>> not
> >>>>> sure
> >>>>>>> we
> >>>>>>>>>>> need
> >>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>> do
> >>>>>>>>>>>>>>>> a hang-out for this,
as I think we really are quite
> >>>> close
> >>>>> to
> >>>>>>>>>>>> resolving
> >>>>>>>>>>>>>>>> this. I'd really like
to resolve this ASAP so that we
> >>>>> don't
> >>>>>>> need
> >>>>>>>>> to
> >>>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>> code-freeze for this
release.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Here's a proposal:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Cordova repositories
have three main branches:
> >>>>>>>>>>>>>>>> 1. stable
> >>>>>>>>>>>>>>>> 2. next
> >>>>>>>>>>>>>>>> 3. dev
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Topic branches also
exist for collaborating on
> >>>> features,
> >>>>> or
> >>>>>>> for
> >>>>>>>>>>>>>>> code-review
> >>>>>>>>>>>>>>>> purposes.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> There is *no* master
branch, so that community-driven
> >>>> pull
> >>>>>>>>> requests
> >>>>>>>>>>>>>>> will
> >>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>> forced to think about
which branch to request against.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 1. The "stable" branch.
> >>>>>>>>>>>>>>>> - Sits at the latest
stable release of cordova
> >>>>>>>>>>>>>>>> - No one ever commits
to the "stable" branch. It
> >>>> exists
> >>>>> only
> >>>>>>> as
> >>>>>>>> a
> >>>>>>>>>>>>>>>> short-cut for checking
out the latest stable tag.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 2. The "next" branch.
> >>>>>>>>>>>>>>>> - This branch exists
only when in the process of
> >>>> doing a
> >>>>>>>> release.
> >>>>>>>>>>>>>>>> - All tags (both stable
and RC) are done on this
> >>>> branch.
> >>>>>>>>>>>>>>>> - When a stable tag
is done:
> >>>>>>>>>>>>>>>>   - The existing "stable"
branch is deleted
> >>>>>>>>>>>>>>>>   - A new "stable" branch
is created from "next".
> >>>>>>>>>>>>>>>>   - The "next" branch
is deleted.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 3. The "dev" branch.
> >>>>>>>>>>>>>>>> - This is where all
commits are done
> >>>>>>>>>>>>>>>> - This is where topic-branches
are merged into.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Cutting a release:
> >>>>>>>>>>>>>>>> 1. Create "next" from
the HEAD of "dev"
> >>>>>>>>>>>>>>>> 2. Test test test!
> >>>>>>>>>>>>>>>> 3. Fix bugs by committing
them to "dev" and then
> >>>>>>> cherry-picking
> >>>>>>>>>>> them
> >>>>>>>>>>>>>>> into
> >>>>>>>>>>>>>>>> "next"
> >>>>>>>>>>>>>>>> 4. Tag release candidate
> >>>>>>>>>>>>>>>> 5. Repeat steps 2-4
as necessary
> >>>>>>>>>>>>>>>> 6. Tag the release
> >>>>>>>>>>>>>>>> 7. Create distribution
.zip file
> >>>>>>>>>>>>>>>> 8. Test one last time
using the dist files
> >>>>>>>>>>>>>>>> 9. Delete "stable"
> >>>>>>>>>>>>>>>> 10. Create a new "stable"
by branching from the HEAD
> >>>> of
> >>>>>> "next"
> >>>>>>>>>>>>>>>> 11. Delete the "next"
branch
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Wed, Jan 16, 2013
at 10:34 AM, Michal Mocny <
> >>>>>>>>>>> mmocny@chromium.org>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Just going to throw
out one of my personal
> >>>> requirements
> >>>>> for
> >>>>>>>>>>>> whatever
> >>>>>>>>>>>>>>>>> proposal we come
up with, so it doesn't get lost:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> * Feature branches
are great for feature work and/or
> >>>>> large
> >>>>>>>>>>> sweeping
> >>>>>>>>>>>>>>>>> changes, as are
JIRA bugs for tracking them, but
> >>>> cordova
> >>>>>> has
> >>>>>>>> many
> >>>>>>>>>>>>>>> many
> >>>>>>>>>>>>>>>>> trivial issues that
could be fixed with "drive-by"
> >>>>> patches
> >>>>>>> that
> >>>>>>>>>>>>>>> require
> >>>>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>>> little friction
to commit as possible.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Tue, Jan 15,
2013 at 3:05 PM, Marcel Kinard <
> >>>>>>>>>>> cmarcelk@gmail.com
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> How about if
there is a specific straw man proposal
> >>>> at
> >>>>> the
> >>>>>>>>>>>>>>> beginning
> >>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>> the face-time?
Then the folks that are in agreement
> >>>>> won't
> >>>>>>> need
> >>>>>>>>>>> to
> >>>>>>>>>>>>>>> say
> >>>>>>>>>>>>>>>>>> anything ;-)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Seriously, making
adjustments to something tangible
> >>>> is
> >>>>>>> easier
> >>>>>>>>>>>> than
> >>>>>>>>>>>>>>>>>> instantiating
it from scratch. A volunteer for a
> >>>> very
> >>>>>> simple
> >>>>>>>>>>>>>>> writeup
> >>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> wiki?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> -- Marcel Kinard
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 1/14/2013
10:06 PM, Michal Mocny wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Okay gentlemen,
I think there have been countless
> >>>> good
> >>>>>>> points
> >>>>>>>>>>>>>>> made
> >>>>>>>>>>>>>>>> from
> >>>>>>>>>>>>>>>>>>> all
> >>>>>>>>>>>>>>>>>>> parties,
but also some bike-shedding.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Perhaps
it is time to schedule some face-time to
> >>>> better
> >>>>>>>>>>>>>>> articulate
> >>>>>>>>>>>>>>>> some
> >>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>> the finer
points, and to help come to some
> >>>> consensus?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> -Michal
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> @purplecabbage
> >>>>>>>> risingj.com
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> @purplecabbage
> >>>>> risingj.com
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
> > --
> > @purplecabbage
> > risingj.com
>
>

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