bigtop-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olaf Flebbe <o.fle...@science-computing.de>
Subject AW: [DISCUSS] Working on the BOM.next (0.9.0 or 1.0?)
Date Mon, 20 Oct 2014 13:36:23 GMT
Hi,

Problem is I do not have a running puppet and docker infrastructure right now. 

Olaf




-----Urspr√ľngliche Nachricht-----
Von: Konstantin Boudnik [mailto:cos@apache.org] 
Gesendet: Sonntag, 19. Oktober 2014 20:51
An: user@bigtop.apache.org
Cc: dev@bigtop.apache.org
Betreff: Re: [DISCUSS] Working on the BOM.next (0.9.0 or 1.0?)

Olaf,

Debian can be added, if desired, considering how easy the Docker based build now is. Will
you be willing to champion it including maintenance of Docker image, etc.?

thanks for raising the points below. See my comments inline:

On Fri, Oct 17, 2014 at 10:04AM, Olaf Flebbe wrote:
> Hi,
> 
> Sorry, had other priorities last two weeks.
> 
> I vote for including Debian 8 jessie (the next stable aka LTS version) 
> which I have to use for my project.  But since there seems  no other 
> user for this, I am comfortably with compiling it myself, since Ubuntu 
> and Debian is very similar to each other from the packaging/compiling perspective.
> 
> From my perspective it is most important targets for Bigtop should be  
> to have fresh and interoperable set of components and second a 
> reproducible build environment for packaging.

Yes, this is the big part of User eXperience, IMO. And it should be flawless where we can
help it.

> Since nobody else mentioned it here:
> 
> I am not very comfortable with a build which modifies the maven cache, 
> overwriting downloaded artifacts. This is an open door for hard to 
> find dependency problems.

Could you be more specific about this? 'cause the build needs to modify the cache as it installs
freshly built artifacts. If you feel like there's an issue - let's open a JIRA and continue
it there.

> Furthermore, I observed that gradle (and make) build system does not 
> handle needed recompiles correctly. I observed that patches to a 
> bigtop component did not force a recompile of the effected component 
> (and all other down the road). IMHO many compile problems introduced 
> by patches did go unnoticed in jenkins.

That's pretty hard part. Besides, the philosophy we had in mind is not to patch the upstream.
As the result, make build has some rudimentary functionality for this and gradle doesn't at
all. I hear more and more request for patching support, so perhaps we need to revisit the
original concept and invest some time into making this experience better? Let's again handle
this on a JIRA?

> I vote to have the release goal to be able to do a full recompile with 
> a clean maven cache.

+1 (as much as we can help it). We might have to be prepared do more of 
+ugly
hacks like BIGTOP-1445.

Thanks,
  Cos

> Olaf
> 
> --
> Vorstandsvorsitzender/Chairman of the board of management:
> Gerd-Lothar Leonhart
> Vorstand/Board of Management:
> Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz Vorsitzender 
> des Aufsichtsrats/ Chairman of the Supervisory Board:
> Philippe Miltin
> Sitz/Registered Office: Tuebingen
> Registergericht/Registration Court: Stuttgart 
> Registernummer/Commercial Register No.: HRB 382196

-- 
Vorstandsvorsitzender/Chairman of the board of management:
Gerd-Lothar Leonhart
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Philippe Miltin
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
Mime
View raw message