cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: Cordova vs Company workflow
Date Thu, 06 Jun 2013 01:45:48 GMT
Since I'm starting as a contributor and not a committer I was talking from
that perpective, to follow the process that is in place for contributors to
submit pull requests to be review and  committed by committers.



--Carlos


On Wed, Jun 5, 2013 at 8:28 PM, Jesse <purplecabbage@gmail.com> wrote:

> Personally, if I had a change that I wanted to add to Android, or iOS, I
> would send a pull request to Joe, or Shazron respectively.  I effectively
> consider them to be the gatekeepers for their respective platforms as they
> work on them every day and I consider them to have a much deeper knowledge
> of implications that I might not have thought of.  This inevitably leads to
> a brief discussion, ... Why did you make this change? How confident are you
> that this doesn't break shit?  Did you test it?  All of which are
> important, but perhaps more important is the resultant communication.
>
> Myself, I do ALL my work in my github fork and maintain multiple branches
> there, and I LOVE it when I get a pull request for WP7, WP8, or Windows8,
> which are the platforms I look after day to day.
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Jun 5, 2013 at 4:36 PM, Joe Bowser <bowserj@gmail.com> wrote:
>
> > The thing is that people don't start out as committers. It has to be
> earned
> > over time.  Committership is with an individual, not a company.
> > On Jun 5, 2013 4:32 PM, "Filip Maj" <fil@adobe.com> wrote:
> >
> > > Agree with Lorin, if you are a committer, go ahead and push your
> changes
> > > but please for the love of god test every change you make. If you
> cannot
> > > test due to lack of devices, then please for the love of god ask
> someone
> > > on the list to do the testing for you.
> > >
> > > On 6/5/13 4:30 PM, "Lorin Beer" <lorin.beer.dev@gmail.com> wrote:
> > >
> > > >-1 for allowing time for discussion/code-review between
> diff/commit/pull
> > > >request to the issue and committing to master, if I understand the
> > > >suggestion.
> > > >
> > > >For non-committer contributors, yes, this is a natural workflow and
> > > >a necessary step for getting your code into the project in the first
> > > >place.
> > > >
> > > >But the status of committership denotes those that are trusted to push
> > > >commits to master without the contribution being vetted by someone
> else.
> > > >If
> > > >the commit adds additional functionality or drastically changes
> existing
> > > >functionality, the workflow is to discuss it on the list and open up a
> > > >lazy
> > > >consensus vote *prior* to beginning work on it in the first place.
> > > >
> > > >
> > > >
> > > >On Wed, Jun 5, 2013 at 11:44 AM, Carlos Santana
> > > ><csantana23@gmail.com>wrote:
> > > >
> > > >> +1 on moving to Status:"In Progress" to denote someone is working
on
> > it
> > > >> +1 on allowing time for discussion/code-review between request and
> > > >>commit
> > > >>
> > > >> Sorry trying to learn the Cordova lingo :-)
> > > >>
> > > >> --Carlos
> > > >>
> > > >>
> > > >> On Wed, Jun 5, 2013 at 2:32 PM, Jeffrey Heifetz <
> > > jheifetz@blackberry.com
> > > >> >wrote:
> > > >>
> > > >> > I also think there's value in having some time between posting
a
> > > >> > diff/commit/pull request to the issue and committing to master
to
> > > >>allow
> > > >> > some discussion.
> > > >> >
> > > >> > On 13-06-05 2:25 PM, "Lorin Beer" <lorin.beer.dev@gmail.com>
> wrote:
> > > >> >
> > > >> > >Yes, putting a comment on the issue itself should be sufficient.
> If
> > > >> > >you're familiar with the person, im/irc message is appreciated,
> but
> > > >> > >not necessary.
> > > >> > >
> > > >> > >Generally, Fil is correct. I generally do not mark issues
I'm
> > working
> > > >> > >on as "in progress", but that's something I will immediately
> > adress.
> > > >> > >
> > > >> > >On Wed, Jun 5, 2013 at 9:41 AM, Filip Maj <fil@adobe.com>
wrote:
> > > >> > >> Pretty much.
> > > >> > >>
> > > >> > >> My assumption is when looking through JIRA that if an
issue
> isn't
> > > >>"In
> > > >> > >> Progress" then I can freely assign to myself and mark
it as "In
> > > >> > >>Progress"
> > > >> > >> to denote that I am working on it.
> > > >> > >>
> > > >> > >> On 6/5/13 9:28 AM, "Carlos Santana" <csantana23@gmail.com>
> > wrote:
> > > >> > >>
> > > >> > >>>Lorin,
> > > >> > >>>  When you say "ping the person it is assigned to"
you mean
> put a
> > > >> > >>>comment
> > > >> > >>>on the JIRA ticket?
> > > >> > >>>This way everyone is aware that someone is interested
on taking
> > > >>over
> > > >> the
> > > >> > >>>ticket or have some input?
> > > >> > >>>
> > > >> > >>>Sorry if it was a dumb, question I'm trying to understand
the
> > > >>workflow
> > > >> > >>>of
> > > >> > >>>contributing
> > > >> > >>>
> > > >> > >>>(open ticket, add comment to JIRA ticket showing
interest on
> > > >>working
> > > >> the
> > > >> > >>>ticket, get agreement from assignee, start solving
problem,
> > submit
> > > >> pull
> > > >> > >>>request, post to dev mailing list for code review)
> > > >> > >>>
> > > >> > >>>
> > > >> > >>>--Carlos
> > > >> > >>>
> > > >> > >>>
> > > >> > >>>On Tue, Jun 4, 2013 at 5:17 PM, Lorin Beer
> > > >><lorin.beer.dev@gmail.com>
> > > >> > >>>wrote:
> > > >> > >>>
> > > >> > >>>> I've CC'd the relevant parties, but as a reminder
of best
> > > >>practice:
> > > >> > >>>>
> > > >> > >>>> regardless of internal company workflow for
Cordova
> > contribution,
> > > >> when
> > > >> > >>>> tackling an issue filed on jira:
> > > >> > >>>>
> > > >> > >>>> 1. if it is not assigned to you, ping the person
it is
> assigned
> > > >>to
> > > >> > >>>> 2. discuss assigning to yourself
> > > >> > >>>> 3. begin solving the issue
> > > >> > >>>>
> > > >> > >>>> Keeping work in non-apache repos, and chiming
in with a fix
> > once
> > > >>the
> > > >> > >>>> issue has already been resolved leads to frustration
and
> > > >>duplication
> > > >> > >>>> of work.
> > > >> > >>>>
> > > >> > >>>> Clear communication is key to cooperating on
a project like
> > this,
> > > >> and
> > > >> > >>>> that involves letting everyone know what you
are working on.
> > The
> > > >> > >>>> system we employ for that purpose is JIRA.
> > > >> > >>>>
> > > >> > >>>> - Lorin
> > > >> > >>>>
> > > >> > >>>
> > > >> > >>>
> > > >> > >>>
> > > >> > >>>--
> > > >> > >>>Carlos Santana
> > > >> > >>><csantana23@gmail.com>
> > > >> > >>
> > > >> >
> > > >> >
> > > >> >
> > ---------------------------------------------------------------------
> > > >> > This transmission (including any attachments) may contain
> > confidential
> > > >> > information, privileged material (including material protected
by
> > the
> > > >> > solicitor-client or other applicable privileges), or constitute
> > > >> non-public
> > > >> > information. Any use of this information by anyone other than
the
> > > >> intended
> > > >> > recipient is prohibited. If you have received this transmission
in
> > > >>error,
> > > >> > please immediately reply to the sender and delete this information
> > > >>from
> > > >> > your system. Use, dissemination, distribution, or reproduction
of
> > this
> > > >> > transmission by unintended recipients is not authorized and may
be
> > > >> unlawful.
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Carlos Santana
> > > >> <csantana23@gmail.com>
> > > >>
> > >
> > >
> >
>



-- 
Carlos Santana
<csantana23@gmail.com>

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