This is Interesting
-
http://www.3d-architectural-rendering.com
--
View this message in context:
http://nabble.documentfoundation.org/Broken-master-and-newcomers-tp4180386p4182075.html
Sent from the Dev mailing list archive at Nabble.com.
___
Libr
On Thu, Apr 21, 2016 at 6:14 AM, jan iversen
wrote:
> Sorry for double mail, to this theme, but speaking with a good friend of mine
> (who runs a very big ci system), I got an idea, which might solve the problem
> for good.
>
> Whenever jenkins builds a gerrit job, jenkins master knows when all
Sorry for double mail, to this theme, but speaking with a good friend of mine
(who runs a very big ci system), I got an idea, which might solve the problem
for good.
Whenever jenkins builds a gerrit job, jenkins master knows when all platforms
for that patch is compiled, so it should be possibl
Just had an interesting IRC chat on the infra channel.
It seems it would be easy to have our ci system maintain a tag pr. platform.
The idea would be:
when master compiles on platform Foo, set/move tag "buildable_on_".
Doing that would have a very minimal effect on the build job, but give (
On 07/04/16 00:17, Norbert Thiebaud wrote:
> On Wed, Apr 6, 2016 at 6:14 PM, Anthonys Lists
> wrote:
>> On 07/04/2016 00:08, Norbert Thiebaud wrote:
Imho, IF we do something like this, we should use the git facilities to
> create a shallow clone backup, that people can then use ftp
On Wed, Apr 6, 2016 at 6:14 PM, Anthonys Lists wrote:
> On 07/04/2016 00:08, Norbert Thiebaud wrote:
>>>
>>> Imho, IF we do something like this, we should use the git facilities to
>>> >create a shallow clone backup, that people can then use ftp or rsync or
>>> > some
>>> >other interruptible prot
On 07/04/2016 00:08, Norbert Thiebaud wrote:
Imho, IF we do something like this, we should use the git facilities to
>create a shallow clone backup, that people can then use ftp or rsync or some
>other interruptible protocol to download.
We have been doing that for years:
http://dev-www.libreof
On Wed, Apr 6, 2016 at 5:58 PM, Anthonys Lists wrote:
> On 06/04/2016 08:21, Bjoern Michaelsen wrote:
>>>
>>> An alternative (which I have seen used in another project), would be to
>>> let
>>> >jenkins generate a source tar ball, incl. the .git directory, of the
>>> > latest
>>> >sane build.
>>
>
On 06/04/2016 08:21, Bjoern Michaelsen wrote:
An alternative (which I have seen used in another project), would be to let
>jenkins generate a source tar ball, incl. the .git directory, of the latest
>sane build.
No, thats horrible -- it make onboarding to git even harder.
What quite do you mean
On Wed, Apr 6, 2016 at 1:04 AM, jan iversen wrote:
> Hi.
>
> I experience quite frequently that new contributors follow the instructions,
> but end up with a master that will not compile,
these day that is unlucky:
here are the stats for the last 14 days:
from:Wed Mar 23 21:30:24 2016
Hi,
On Wed, Apr 06, 2016 at 07:08:06PM +0200, jan iversen wrote:
> > http://people.canonical.com/~bjoern/presentations/tb3.odp
> > http://people.canonical.com/~bjoern/presentations/tb3-2014.odp
> > https://gerrit.libreoffice.org/gitweb?p=tb3-django.git;a=summary
> > https://gerrit.libreoffice.org/
>
> That idea is old -- and yes, having it directly in as a note, tag or brach git
> would be awesome. Personally, I would love to see a "master-ci-verfied"
> _branch_
> that is following the master branch up to the point that is known good by CI.
> A
> branch has the advantage that it would all
Hi,
On Wed, Apr 06, 2016 at 08:04:39AM +0200, jan iversen wrote:
> I have been thinking for a while, if we could get jenkins to keep a marker of
> the last buildable version, store it somwhere easy to grap (preferable in the
> repo itself), and then extend our build instructions to do "git checkou
13 matches
Mail list logo
