Travis Continuous Integration

[Bjoern Petri <bj...@sundevil.de>]

Hi everyone,

A while ago I stumbled over Travis CI. Travis is a continuous
integration service which automatically detects when a commit
has been pushed to a GitHub repository. It can be configured to
trigger a build or do some tests runs, when this happens.

After asking Apache Infra to enable the necessary hook for Celix,
I configured Travis CI to just perform a simple cmake-build using gcc
and clang, but we could improve this later , so that unit- or even
integration tests can be performed once a commit has been pushed.

Currently, only the develop branch is handled by Travis CI. If you
want to enable Travis CI in your feature branch, you just need to
add a .travis.yml file, so Travis knows how to handle the build.

See also the current travis.yml:
https://github.com/apache/celix/blob/develop/.travis.yml

and our (yet still short) build history:
https://travis-ci.org/apache/celix/


Regards,
Bjoern

Re: Travis Continuous Integration

[Pepijn Noltes <pe...@gmail.com>]

Hi All,


On Sun, Jul 5, 2015 at 10:20 PM Bjoern Petri <bj...@sundevil.de>
wrote:

>
>
>
> Hi Gerrit,
>
> Indeed, Celix releases doesn't occur that often and I agree that we
> could benefit from changing that.
>
> Especially having alpha releases would offer a nice way for users to get
> early access to features as long as a release isn't planned yet (like
> the etcd discovery for the INAETICS project). Feedback could be provided
> more early and therefore bugs could already be fixed within the next
> alpha release.
>
> The only thing am not sure about is whether working in sprints will
> work for us.At the moment, I would consider planning in time boxed
> iterations and especially fulfilling this to be quite difficult. But
> maybe that is even not the important part.
>

I agree. Although I would like to have a sprint like approach I do not
think we can ensure a fixed development speed / resource commitment to the
project.


>
> I think that having a prioritized roadmap/planning combined with a
> monthly review what has been achieved would be more realistic


+1 .I think that having a roadmap (especially public) could really help
Celix. I we make the list of (prioritized) features small enough we could
also work to making more "releases" (e.g. alpha tags)


> .
>
> If some new feature or just some bugfixes have been implemented, tested
> and documented the issues could be added to an alpha release.
>
> To sum it up, I would like to set up a release schedule as proposed by
> you, but skip the sprints and instead:
>
> 1 Create a public available roadmap/planning what is currently under
> development, what is planned and what could be from interest in long term.
>
> 2 based on a monthly review test and document new features. If
> successful, integrate into monthly alpha release.
>
> 3 (same as gerrits proposal) If "enough" features are integrated and
> have run for some time an alpha release (for sure not the latest) can be
> promoted to an "official".
>
>
> Alexander, Pepijn - what is your opinion?
>


+1

On a practical note: I am not able to edit version/roadmaps in the Celix
JIRA environment.
@Marcel Offermans: Seeing that you are the project lead in JIRA could give
me & Bjorn (I think Alexander already has) rights to do this?





>
>
> Regards,
> Bjoern
>
>
>
> On 03.07.2015 22:28, Gerrit Binnenmars wrote:
> > Hello,
> >
> > Nice work Bjoern. For sure Travis will help to improve the quality and
> more
> > people become aware of Celix.
> > Some time ago I asked about a planning for Celix release 2.0.
> Unfortunately
> > it still is not clear.
> > The main reason for asking this was that I want to be able to refer to a
> > specific version of the Celix main branch.
> >
> > At the moment, I work with CoreOS. and they work with a kind of
> continuous
> > release in an alpha channel. I like that.
> > I am not sure if the voting mechanism of the Apache process prevents
> this,
> > but I would like to propose the following idea
> >
> > 1 Start working with short sprints (at most 4 weeks) in which some
> > pre-agreed Jira issues and or features are solved
> >   Not sure yet about the best way to discuss this. (Planningsboard?)
> > 2.Finish this sprint with an update of the tests and documentation
> > 3.Use Travis to test this version. If no errors are detected this will be
> > the next alpha release.
> > 4. If "enough" features are integrated and have run for some time an
> alpha
> > release (for sure not the latest) can be promoted to an "official"
> release.
> >
> > I know that a lot is going on in Celix, and it would be nice if this
> became
> > more visible.
> >
> > Curious for reactions,
> >
> > Greetings Gerrit
> >
> >
> > On Thu, Jul 2, 2015 at 10:08 PM, Bjoern Petri <bj...@sundevil.de>
> > wrote:
> >
> >>
> >> Hi everyone,
> >>
> >> A while ago I stumbled over Travis CI. Travis is a continuous
> >> integration service which automatically detects when a commit
> >> has been pushed to a GitHub repository. It can be configured to
> >> trigger a build or do some tests runs, when this happens.
> >>
> >> After asking Apache Infra to enable the necessary hook for Celix,
> >> I configured Travis CI to just perform a simple cmake-build using gcc
> >> and clang, but we could improve this later , so that unit- or even
> >> integration tests can be performed once a commit has been pushed.
> >>
> >> Currently, only the develop branch is handled by Travis CI. If you
> >> want to enable Travis CI in your feature branch, you just need to
> >> add a .travis.yml file, so Travis knows how to handle the build.
> >>
> >> See also the current travis.yml:
> >> https://github.com/apache/celix/blob/develop/.travis.yml
> >>
> >> and our (yet still short) build history:
> >> https://travis-ci.org/apache/celix/
> >>
> >>
> >> Regards,
> >> Bjoern
> >>
> >>
> >>
> >
>

Re: Travis Continuous Integration

[Bjoern Petri <bj...@sundevil.de>]

Hi Gerrit,

Indeed, Celix releases doesn't occur that often and I agree that we
could benefit from changing that.

Especially having alpha releases would offer a nice way for users to get
early access to features as long as a release isn't planned yet (like
the etcd discovery for the INAETICS project). Feedback could be provided
more early and therefore bugs could already be fixed within the next
alpha release.

The only thing am not sure about is whether working in sprints will
work for us.At the moment, I would consider planning in time boxed
iterations and especially fulfilling this to be quite difficult. But
maybe that is even not the important part.

I think that having a prioritized roadmap/planning combined with a
monthly review what has been achieved would be more realistic.

If some new feature or just some bugfixes have been implemented, tested
and documented the issues could be added to an alpha release.

To sum it up, I would like to set up a release schedule as proposed by
you, but skip the sprints and instead:

1 Create a public available roadmap/planning what is currently under
development, what is planned and what could be from interest in long term.

2 based on a monthly review test and document new features. If
successful, integrate into monthly alpha release.

3 (same as gerrits proposal) If "enough" features are integrated and
have run for some time an alpha release (for sure not the latest) can be
promoted to an "official".


Alexander, Pepijn - what is your opinion?


Regards,
Bjoern



On 03.07.2015 22:28, Gerrit Binnenmars wrote:
> Hello,
> 
> Nice work Bjoern. For sure Travis will help to improve the quality and more
> people become aware of Celix.
> Some time ago I asked about a planning for Celix release 2.0. Unfortunately
> it still is not clear.
> The main reason for asking this was that I want to be able to refer to a
> specific version of the Celix main branch.
> 
> At the moment, I work with CoreOS. and they work with a kind of continuous
> release in an alpha channel. I like that.
> I am not sure if the voting mechanism of the Apache process prevents this,
> but I would like to propose the following idea
> 
> 1 Start working with short sprints (at most 4 weeks) in which some
> pre-agreed Jira issues and or features are solved
>   Not sure yet about the best way to discuss this. (Planningsboard?)
> 2.Finish this sprint with an update of the tests and documentation
> 3.Use Travis to test this version. If no errors are detected this will be
> the next alpha release.
> 4. If "enough" features are integrated and have run for some time an alpha
> release (for sure not the latest) can be promoted to an "official" release.
> 
> I know that a lot is going on in Celix, and it would be nice if this became
> more visible.
> 
> Curious for reactions,
> 
> Greetings Gerrit
> 
> 
> On Thu, Jul 2, 2015 at 10:08 PM, Bjoern Petri <bj...@sundevil.de>
> wrote:
> 
>>
>> Hi everyone,
>>
>> A while ago I stumbled over Travis CI. Travis is a continuous
>> integration service which automatically detects when a commit
>> has been pushed to a GitHub repository. It can be configured to
>> trigger a build or do some tests runs, when this happens.
>>
>> After asking Apache Infra to enable the necessary hook for Celix,
>> I configured Travis CI to just perform a simple cmake-build using gcc
>> and clang, but we could improve this later , so that unit- or even
>> integration tests can be performed once a commit has been pushed.
>>
>> Currently, only the develop branch is handled by Travis CI. If you
>> want to enable Travis CI in your feature branch, you just need to
>> add a .travis.yml file, so Travis knows how to handle the build.
>>
>> See also the current travis.yml:
>> https://github.com/apache/celix/blob/develop/.travis.yml
>>
>> and our (yet still short) build history:
>> https://travis-ci.org/apache/celix/
>>
>>
>> Regards,
>> Bjoern
>>
>>
>>
> 

Re: Travis Continuous Integration

[Gerrit Binnenmars <ge...@gmail.com>]

Hello,

Nice work Bjoern. For sure Travis will help to improve the quality and more
people become aware of Celix.
Some time ago I asked about a planning for Celix release 2.0. Unfortunately
it still is not clear.
The main reason for asking this was that I want to be able to refer to a
specific version of the Celix main branch.

At the moment, I work with CoreOS. and they work with a kind of continuous
release in an alpha channel. I like that.
I am not sure if the voting mechanism of the Apache process prevents this,
but I would like to propose the following idea

1 Start working with short sprints (at most 4 weeks) in which some
pre-agreed Jira issues and or features are solved
  Not sure yet about the best way to discuss this. (Planningsboard?)
2.Finish this sprint with an update of the tests and documentation
3.Use Travis to test this version. If no errors are detected this will be
the next alpha release.
4. If "enough" features are integrated and have run for some time an alpha
release (for sure not the latest) can be promoted to an "official" release.

I know that a lot is going on in Celix, and it would be nice if this became
more visible.

Curious for reactions,

Greetings Gerrit


On Thu, Jul 2, 2015 at 10:08 PM, Bjoern Petri <bj...@sundevil.de>
wrote:

>
> Hi everyone,
>
> A while ago I stumbled over Travis CI. Travis is a continuous
> integration service which automatically detects when a commit
> has been pushed to a GitHub repository. It can be configured to
> trigger a build or do some tests runs, when this happens.
>
> After asking Apache Infra to enable the necessary hook for Celix,
> I configured Travis CI to just perform a simple cmake-build using gcc
> and clang, but we could improve this later , so that unit- or even
> integration tests can be performed once a commit has been pushed.
>
> Currently, only the develop branch is handled by Travis CI. If you
> want to enable Travis CI in your feature branch, you just need to
> add a .travis.yml file, so Travis knows how to handle the build.
>
> See also the current travis.yml:
> https://github.com/apache/celix/blob/develop/.travis.yml
>
> and our (yet still short) build history:
> https://travis-ci.org/apache/celix/
>
>
> Regards,
> Bjoern
>
>
>