celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <pepijnnol...@gmail.com>
Subject Re: Travis Continuous Integration
Date Tue, 07 Jul 2015 07:36:11 GMT
Hi All,


On Sun, Jul 5, 2015 at 10:20 PM Bjoern Petri <bjoern.petri@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 <bjoern.petri@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
> >>
> >>
> >>
> >
>

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