cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Plugins Release today
Date Wed, 04 Dec 2013 20:50:04 GMT
On Wed, Dec 4, 2013 at 2:54 PM, David Kemp <drkemp@google.com> wrote:

> You can definitely do an automated build on demand, but the interesting
> part is specifying exactly what to build.
> Currently a build is made up of a bunch of repos at one tag, and some other
> repos at another tag.
> We would need to have a well defined way to specify which tag for each
> repo.
>
> example:
> I want to build cordova-android from the 'fancy-pants' branch, because I am
> ready to push it to master
>
> I presumably need:
>   cordova-android - fancy-pants branch
>   cli,plugman,coho,mobilespec, js from master branch
>   all plugins from master branch
>
> If we can ALWAYS say that a demand build is the same as a master build, but
> with one repo at a different branch that might be pretty easy...
>
+1 to this.

I suspect we almost always want to test new feature against tip-of-tree (I
guess thats master).  So being able to run that but replace some of the
repos with a different branch would be awesome.  What if we used the
convention of naming feature branches in all the applicable repos the same
thing, that way we can poke CI with a single name and it would check out
that branch on all the repos if it existed?


>
>
>
>
> On Wed, Dec 4, 2013 at 2:44 PM, Ian Clelland <iclelland@google.com> wrote:
>
> > On Tue, Dec 3, 2013 at 3:29 PM, Steven Gill <stevengill97@gmail.com>
> > wrote:
> >
> > > On Tue, Dec 3, 2013 at 12:14 PM, Ian Clelland <iclelland@google.com>
> > > wrote:> Dev becomes a staging branch, essentially; and all actual dev
> > work
> > > happens
> > >  > on branches. That sounds like a more sane way to do it. The only
> > reason
> > > I
> > > > had it on dev in the first place was to be able to test with buildbot
> > --
> > > > I'd love to have a way to run those branches through the CI server
> > before
> > > > merging them into dev/staging/master.
> > >
> > >
> > > Good point. Maybe we standardize a third branch (ducks for cover) that
> > the
> > > CI server also tests and can be used for breaking dev work. This way
> dev
> > is
> > > used for staging and only has code that can be released. I'm afraid
> that
> > > this just adds more complexity to plugins though and I am not a fan of
> > > adding more complexity.
> > >
> >
> > I was thinking that it would be cool to be able to force a buildbot build
> > of a specific branch (though maybe a set of branches would be required)
> --
> > it wouldn't have to happen with every commit, but you could say "I'm
> ready
> > to merge my feature into dev, let's get buildbot to run all of the tests
> on
> > that branch first, to see if the merge will break anything".
> >
> > That would avoid the need for a third special branch, but would let
> anybody
> > with access to buildbot (which we hope is everybody, soon) the ability to
> > test a branch before merging.
> >
> > I don't know if it's possible to get buildbot to do that or not; I'll
> defer
> > to David on that subject :)
> >
> > Ian
> >
> >
> > >
> > > >
> > >  Ian
> > > >
> > > >
> > > >
> > > > > Still confusing at times. It will be
> > > > > nice once we can get away from this dev-master setup we have. I'm
> > sure
> > > > many
> > > > > of us have pushed code to dev that isn't in a sate to be released.
> > > Maybe
> > > > > this point/process should get added to our wiki? Not sure where the
> > > best
> > > > > place for it would be.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland <
> iclelland@google.com>
> > > > > wrote:
> > > > >
> > > > > > Hey Steven,
> > > > > >
> > > > > > File is close to being ready, but I haven't merged in my Android
> > code
> > > > > yet,
> > > > > > and I want to add some more tests, given how critical the plugin
> > is.
> > > > I'm
> > > > > > not comfortable with it going to master yet. If you want, I
can
> > pull
> > > it
> > > > > out
> > > > > > of dev and put it on another branch. (There have been some other
> > > > commits,
> > > > > > so we could also create a new branch without those commits,
and
> > merge
> > > > > > *that* into master instead)
> > > > > >
> > > > > > Let me know how you want to handle it, I'll help out any way
I
> can.
> > > > > >
> > > > > > Ian
> > > > > >
> > > > > >
> > > > > > On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill <
> > stevengill97@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Any plugin issues I should know about before releasing
today?
> > > > > > >
> > > > > > > Last I heard file and file-transfer dev branches aren't
ready
> to
> > be
> > > > > > merged
> > > > > > > into master. Has this changed? Ian?
> > > > > > >
> > > > > > > Plugin issues that are still being reviewed/worked on:
> > > > > > > https://issues.apache.org/jira/browse/CB-5525
> > > > > > > https://issues.apache.org/jira/browse/CB-5531
> > > > > > > https://issues.apache.org/jira/browse/CB-5532
> > > > > > > https://issues.apache.org/jira/browse/CB-5430
> > > > > > > https://issues.apache.org/jira/browse/CB-5504
> > > > > > > https://issues.apache.org/jira/browse/CB-5505
> > > > > > >
> > > > > > > I can wait until later in the day to release if some of
these
> are
> > > > > getting
> > > > > > > resolve today. I know Jesse is looking at the windows ones.
> > > > > > >
> > > > > > > We can also just do another plugin release next week (or
post
> > > > holidays)
> > > > > > > once some of these land.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

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