streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanton Sievers <ssiev...@apache.org>
Subject Re: Build failures
Date Tue, 25 Feb 2014 17:22:57 GMT
I agree it's a good discussion to get started.

Any branch management is likely to be easier to discuss in the context of
Git, which seems like the way things are heading per the other discussion
thread. And if there are other projects on builds.a.o that are managing
their builds in a similar way, we should look at what they are doing as a
template.

Thanks,
-Stanton


On Tue, Feb 25, 2014 at 12:11 PM, Steve Blackmon <sblackmon@apache.org>wrote:

> A lead integrator knowing and asserting state of the code is
> essential, but having easily accessible objective stats at the ready
> can help with effective communication and decision making.  Scanning
> builds.apache.org it's apparent that many projects have multiple
> stable, unstable, and release candidate branches under CI
> concurrently.
>
> I was thinking some other developers might pitch in on refactoring the
> 17 remaining modules in streams-contrib to work with
> StreamsLocalBuilder, and that comparing the jenkins build reports of
> trunk and branch could indicate when it was ready to merge.  The code
> base is reasonably simple and small today, but growing rapidly, and
> will become more complex as additional runtimes such as storm and
> hadoop with external version and dependency issues are supported.
> Since we are setting up CI, we might as well discuss and pilot some of
> these scenarios.
>
> Thanks,
> Steve
>
> On Tue, Feb 25, 2014 at 6:33 AM, Stanton Sievers <ssievers@apache.org>
> wrote:
> > IMHO, knowing which modules and tests are active/passing should be the
> > responsibility of the individual developer.  You can build the whole
> > project in a reasonable amount of time.
> >
> > I would agree that such a process would be good to introduce into the CI
> > system but only if there were functional or integration-level tests that
> > required resources unavailable to an individual developer.
> >
> >
> > On Mon, Feb 24, 2014 at 12:37 PM, Steve Blackmon <sblackmon@apache.org
> >wrote:
> >
> >> It would be nice to have a way to place feature branches we are
> >> planning to merge under automated build as well, not to publish any
> >> artifacts necessarily, just to identify any breaking changes and track
> >> how many and which modules and tests are active/passing.
> >>
> >> STREAMS-26 is a good example we could use to test this process out.
> >>
> >> Steve
> >>
> >> On Mon, Feb 24, 2014 at 11:03 AM, Stanton Sievers <ssievers@apache.org>
> >> wrote:
> >> > Can you help set that up?  I've never setup snapshots in the
> builds.a.o
> >> > environment before.  Certainly willing to learn. :)
> >> >
> >> >
> >> > On Mon, Feb 24, 2014 at 11:49 AM, Matt Franklin <
> >> m.ben.franklin@gmail.com>wrote:
> >> >
> >> >> On Mon, Feb 24, 2014 at 10:46 AM, Stanton Sievers <
> ssievers@apache.org
> >> >> >wrote:
> >> >>
> >> >> > A new job [1] has been created on builds.a.o for Streams trunk.
 It
> >> will
> >> >> > build using JDK 1.7 and the latest maven (currently 3.0.5).  Once
> I've
> >> >> > verified it builds successfully, I'll set the job to e-mail this
> list
> >> >> when
> >> >> > builds fail.
> >> >> >
> >> >> > We can setup snapshot deploys and other CI functionality as we
see
> >> fit.
> >> >> >
> >> >>
> >> >> Let's setup snapshots now.
> >> >>
> >> >>
> >> >> >
> >> >> > [1] https://builds.apache.org/job/Streams%20Trunk/
> >> >> >
> >> >> >
> >> >> > On Mon, Feb 24, 2014 at 11:39 AM, Matt Franklin <
> >> >> m.ben.franklin@gmail.com
> >> >> > >wrote:
> >> >> >
> >> >> > > >
> >> >> > > > If we can revert trunk to revision 1569602, it should
build
> again
> >> >> with
> >> >> > > >> all modules in the build plan.
> >> >> > > >>
> >> >> > > >
> >> >> > > > I will revert the code.
> >> >> > > >
> >> >> > >
> >> >> > > This is done.
> >> >> > >
> >> >> >
> >> >>
> >>
>

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