On Wed, Jun 17, 2015 at 10:30:28AM +0200, anonym wrote:
> On 06/16/2015 02:41 PM, bertagaz wrote:
> > On Fri, May 29, 2015 at 01:59:06PM +0200, intrigeri wrote:
> >> anonym wrote (30 Mar 2015 07:48:28 GMT) :
> >>> On 29/03/15 15:04, bertagaz wrote:
>
> >>> Wild (possibly unrelated) idea: instead o
On 06/16/2015 02:41 PM, bertagaz wrote:
> On Fri, May 29, 2015 at 01:59:06PM +0200, intrigeri wrote:
>> anonym wrote (30 Mar 2015 07:48:28 GMT) :
>>> On 29/03/15 15:04, bertagaz wrote:
>>> Wild (possibly unrelated) idea: instead of only notifying the author of
>>> the last commit of a topic branch
Hi,
Just realized while searching for leftovers in this thread that this last
bit of the discussion was still not over.
On Fri, May 29, 2015 at 01:59:06PM +0200, intrigeri wrote:
>
> [This is about builds triggered by uploads to our APT repository.]
>
> anonym wrote (30 Mar 2015 07:48:28 GMT) :
Hi,
[This is about builds triggered by uploads to our APT repository.]
anonym wrote (30 Mar 2015 07:48:28 GMT) :
> On 29/03/15 15:04, bertagaz wrote:
>> However, one point it raises (added to the blueprint) is determining who
>> would be notified of this kind of build on failure.
Given the way w
Hi,
On Mon, Apr 06, 2015 at 06:53:35PM +0200, intrigeri wrote:
> bertagaz wrote (06 Apr 2015 16:44:30 GMT) :
>
> > Was there any other topics to discuss on this subject? I kinda remember
> > this was the last review round, and we managed to answer to all the raised
> > questions.
>
> No idea. I
bertagaz wrote (06 Apr 2015 16:44:30 GMT) :
> How did you know I was confused? Long running threads are a bit hard to
> follow, and I tend to have more and more troubles getting the full
> picture. :)
> Removed it.
:)
> Was there any other topics to discuss on this subject? I kinda remember
> th
Hi,
On Mon, Mar 30, 2015 at 09:28:08PM +0200, intrigeri wrote:
>
> Scenario 15 looks good.
>
> I don't understand what scenario 14 is about, especially right after
> the discussion we've had on this thread. How could base branches be
> possibly affected by changes in topic branches?
>
> Did I m
Hi,
bertagaz wrote (29 Mar 2015 13:04:11 GMT) :
> On Wed, Mar 25, 2015 at 04:44:32PM +0100, intrigeri wrote:
>> => bertagaz and Jurre, may you please capture this problem, and the
>> long-term solution ideas we had, in the "Future ideas" section of
>> the blueprint?
> Done in scenarios 14 and 15,
Hi,
anonym wrote (25 Mar 2015 16:30:26 GMT) :
> On 25/03/15 16:44, intrigeri wrote:
>> anonym wrote (24 Mar 2015 16:50:06 GMT) :
>>> However, I think the reason I asked for this feature was to trigger
>>> rebuilds when the feature branch's APT suite has been updated. From
>>> reading the blueprint
On 29/03/15 15:04, bertagaz wrote:
> Hi,
>
> Sorry, lagging a bit one my emails.
>
> On Wed, Mar 25, 2015 at 04:44:32PM +0100, intrigeri wrote:
>> Hi,
>>
>> anonym wrote (24 Mar 2015 16:50:06 GMT) :
>>> However, I think the reason I asked for this feature was to trigger
>>> rebuilds when the feat
Hi,
Sorry, lagging a bit one my emails.
On Wed, Mar 25, 2015 at 04:44:32PM +0100, intrigeri wrote:
> Hi,
>
> anonym wrote (24 Mar 2015 16:50:06 GMT) :
> > However, I think the reason I asked for this feature was to trigger
> > rebuilds when the feature branch's APT suite has been updated. From
>
On 25/03/15 16:44, intrigeri wrote:
> Hi,
>
> anonym wrote (24 Mar 2015 16:50:06 GMT) :
>> However, I think the reason I asked for this feature was to trigger
>> rebuilds when the feature branch's APT suite has been updated. From
>> reading the blueprint it only mentions "Git", so I assume the "wa
Hi,
anonym wrote (24 Mar 2015 16:50:06 GMT) :
> However, I think the reason I asked for this feature was to trigger
> rebuilds when the feature branch's APT suite has been updated. From
> reading the blueprint it only mentions "Git", so I assume the "watchdog"
> won't look at the feature branch's
On 01/03/15 12:49, intrigeri wrote:
> hi,
>
> bertagaz wrote (27 Feb 2015 10:07:03 GMT) :
>> On Thu, Feb 26, 2015 at 08:46:17PM +0100, bertagaz wrote:
>>> On Thu, Feb 26, 2015 at 05:21:23PM +0100, anonym wrote:
On 11/01/15 20:07, Jurre van Bergen wrote:
> Developers should be able to trig
Hi,
On Sun, Mar 01, 2015 at 12:49:35PM +0100, intrigeri wrote:
> bertagaz wrote (27 Feb 2015 10:07:03 GMT) :
> > Does that sound better to you?
>
> At least it does sound better to me: the problem at hand is detecting
> the transition of a branch between inactive and active state.
>
> When comin
hi,
bertagaz wrote (27 Feb 2015 10:07:03 GMT) :
> On Thu, Feb 26, 2015 at 08:46:17PM +0100, bertagaz wrote:
>> On Thu, Feb 26, 2015 at 05:21:23PM +0100, anonym wrote:
>> > On 11/01/15 20:07, Jurre van Bergen wrote:
>> > > Developers should be able to trigger automatic builds for a branch
>> > > wh
Hi,
On Thu, Feb 26, 2015 at 08:46:17PM +0100, bertagaz wrote:
> On Thu, Feb 26, 2015 at 05:21:23PM +0100, anonym wrote:
> > On 11/01/15 20:07, Jurre van Bergen wrote:
> > > Developers should be able to trigger automatic builds for a branch
> > > whose build was dropped (eg. last commit too old) by
On Thu, Feb 26, 2015 at 05:21:23PM +0100, anonym wrote:
> On 11/01/15 20:07, Jurre van Bergen wrote:
> > https://tails.boum.org/blueprint/automated_builds_and_tests/autobuild_specs/
>
> Sorry for joining in so late. All looks good, and I only have minor
> concerns.
>
> > Developers should be able
On 11/01/15 20:07, Jurre van Bergen wrote:
> https://tails.boum.org/blueprint/automated_builds_and_tests/autobuild_specs/
Sorry for joining in so late. All looks good, and I only have minor
concerns.
> Developers should be able to trigger automatic builds for a branch
> whose build was dropped (e
bertagaz wrote (24 Feb 2015 16:04:14 GMT) :
> Yesterday, 40 ISOs were build on Jenkins...
I bet that the majority of those were triggered mistakenly, due to
https://labs.riseup.net/code/issues/8692. I recommend working on this
during the 1.3.1 cycle if possible, so that we have more useful data
to
bertagaz wrote (24 Feb 2015 14:19:02 GMT) :
> On Sat, Feb 21, 2015 at 05:26:09PM +0100, intrigeri wrote:
>> bertagaz: I think it can now be clarified accordingly on the blueprint :)
> Done.
Thanks. I've clarified on the blueprint the fact that we're talking
about a *local* merge, since that's pre
Hi,
bertagaz wrote (24 Feb 2015 14:12:14 GMT) :
> On Fri, Feb 20, 2015 at 11:56:02AM +0100, intrigeri wrote:
>> It currently reads:
>>
>> For base branches:
>>
>> * When failing after a git push, notify the last commit author.
>> * When failing after the daily trigger, notify the RM.
>>
>
On Wed, Feb 18, 2015 at 09:51:48AM +, sajolida wrote:
> > The Global build stats Jenkins plugin [1] seems interesting to display the
> > stats once more logs are kept. Shall I install it?
>
> I would love to have stats about the number of branches and ISO built
> and tested each day to put in
On Sat, Feb 21, 2015 at 05:26:09PM +0100, intrigeri wrote:
> bertagaz: I think it can now be clarified accordingly on the blueprint :)
Done.
bert.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe f
Hi,
On Fri, Feb 20, 2015 at 11:56:02AM +0100, intrigeri wrote:
> bertagaz wrote (19 Feb 2015 18:15:35 GMT) :
> > On Tue, Feb 17, 2015 at 10:32:59PM +0100, intrigeri wrote:
>
> > I like this idea, simple and effective. :)
>
> > So for the base branches, the RM would be the contact point for daily
Alan wrote (21 Feb 2015 13:36:41 GMT) :
>> Most of us (including me) do the same as Alan, but IMO that's almost
>> irrelevant to the topic at hand. This same scenario reads:
>>
>>And I need to know if my branch build is broken by something else
>> possibly weeks after my last commit (by
Hi,
intrigeri wrote:
> bertagaz wrote (16 Feb 2015 14:32:57 GMT) :
> > On Wed, Feb 11, 2015 at 11:49:02PM +0100, intrigeri wrote:
> >> I have a few concerns, though:
> >>
> >> * "Scenario 2 : developer" doesn't make it clear if branch T is
> >> build *after being locally merged into branch
bertagaz wrote (19 Feb 2015 22:52:20 GMT) :
>> If you prefer, in the future I can dump such research results into the
>> blueprint instead of here. Just tell me where it should go.
> The blueprint/automated_builds_and_tests/jenkins page seems perfect for
> that.
Right => done.
___
Hi,
bertagaz wrote (19 Feb 2015 18:15:35 GMT) :
> On Tue, Feb 17, 2015 at 10:32:59PM +0100, intrigeri wrote:
>> Now, I wonder if we could solve this quite simply by having the RM be
>> notified for *base* branch build failure only. The RM doesn't care
>> about topic branches that haven't been subm
Hi,
bertagaz wrote (19 Feb 2015 21:39:25 GMT) :
> On Mon, Feb 16, 2015 at 04:39:22PM +0100, intrigeri wrote:
>> bertagaz wrote (16 Feb 2015 12:03:12 GMT) :
>> > Ack, sounds reasonable. However from what I've seen, it sometimes means a
>> > lot of branches so I wonder if we scaled our infra enough
On Tue, Feb 17, 2015 at 09:47:51PM +0100, intrigeri wrote:
> bertagaz wrote (16 Feb 2015 14:37:56 GMT) :
> > On Thu, Feb 12, 2015 at 12:22:45AM +0100, intrigeri wrote:
> >> Here's one more: the proposed notification mechanism makes sense to me
> >> for topic branches. But for "base" branches, it's
Hi,
On Mon, Feb 16, 2015 at 04:39:22PM +0100, intrigeri wrote:
> bertagaz wrote (16 Feb 2015 12:03:12 GMT) :
> > Ack, sounds reasonable. However from what I've seen, it sometimes means a
> > lot of branches so I wonder if we scaled our infra enough for that, as we
> > didn't include this branches
Hi,
On Tue, Feb 17, 2015 at 10:32:59PM +0100, intrigeri wrote:
> bertagaz wrote (16 Feb 2015 14:32:57 GMT) :
> > On Wed, Feb 11, 2015 at 11:49:02PM +0100, intrigeri wrote:
>
> > That's a logical awesome idea I'm ashamed not to have had sooner.
> > Still, it seems that it comes too late, after som
bertagaz:
>> * I see no statistics about how many ISOs we are *currently*
>> building each day. So it's not clear to me if our current setup
>> can support building N more branches, once a day each. It would be
>> useful to have this number (e.g. raw number per day during the 1.3
>>
Hi,
bertagaz wrote (16 Feb 2015 14:32:57 GMT) :
> On Wed, Feb 11, 2015 at 11:49:02PM +0100, intrigeri wrote:
>> I have a few concerns, though:
>>
>> * "Scenario 2 : developer" doesn't make it clear if branch T is
>> build *after being locally merged into branch B*, or not.
>> Given that
Hi,
bertagaz wrote (16 Feb 2015 14:37:56 GMT) :
> On Thu, Feb 12, 2015 at 12:22:45AM +0100, intrigeri wrote:
>> Here's one more: the proposed notification mechanism makes sense to me
>> for topic branches. But for "base" branches, it's more complicated:
>>
>> * when building after a Git push, [..
bertagaz wrote (16 Feb 2015 12:03:12 GMT) :
> Ack, sounds reasonable. However from what I've seen, it sometimes means a
> lot of branches so I wonder if we scaled our infra enough for that, as we
> didn't include this branches in our maths since the beginning of the
> discussion.
This seems like a
On Wed, Feb 11, 2015 at 11:29:45PM +0100, intrigeri wrote:
> Hi,
>
> bertagaz wrote (18 Jan 2015 16:39:28 GMT) :
> > 0. Do we think we might also need or want a mechanism to blacklist a branch,
> > or we should just assume that our algos will only select the right ones
> > and not hit any corner c
On Thu, Feb 12, 2015 at 12:22:45AM +0100, intrigeri wrote:
> Here's one more: the proposed notification mechanism makes sense to me
> for topic branches. But for "base" branches, it's more complicated:
>
> * when building after a Git push, it does make sense to notify the
> committer on failure
Hi,
Thx for the extensive review!
On Wed, Feb 11, 2015 at 11:49:02PM +0100, intrigeri wrote:
> > We're already drafted some scenario's on:
> > https://tails.boum.org/blueprint/automated_builds_and_tests/autobuild_specs/
>
> I have a few concerns, though:
>
> * "Scenario 2 : developer" doesn't
intrigeri wrote (11 Feb 2015 22:49:02 GMT) :
> I have a few concerns, though:
Here's one more: the proposed notification mechanism makes sense to me
for topic branches. But for "base" branches, it's more complicated:
* when building after a Git push, it does make sense to notify the
committer o
Hi,
> We're already drafted some scenario's on:
> https://tails.boum.org/blueprint/automated_builds_and_tests/autobuild_specs/
I've finally looked at it. I've pushed minor typo/formatting fixes and
rephrasing, nothing important.
I'm very happy with basically everything in the "2. Scenarios"
sect
Hi,
bertagaz wrote (18 Jan 2015 16:39:28 GMT) :
> 0. Do we think we might also need or want a mechanism to blacklist a branch,
> or we should just assume that our algos will only select the right ones
> and not hit any corner cases?
I think this is a good question, that deserves more thought.
Un
Hi,
On Mon, Jan 26, 2015 at 01:33:25PM +0100, bertagaz wrote:
>
> The blueprint has been updated with some proposalsi for each question. If
> you want to consider them, or propose another one, please have a look.
I've updated the blueprint again.
Revelant changes:
+Given a branch take around 4
Hi,
On Mon, Jan 19, 2015 at 08:14:55PM +0100, bertagaz wrote:
>
> On Sun, Jan 18, 2015 at 08:07:46PM +, sajolida wrote:
> > bertagaz:
> > > 0. We might also want a mechanism for devs to pro-actively state they
> > > want to
> > > keep their branches being build even if the last commit was ol
Hi,
On Sun, Jan 18, 2015 at 08:07:46PM +, sajolida wrote:
> bertagaz:
> > 0. We might also want a mechanism for devs to pro-actively state they want
> > to
> > keep their branches being build even if the last commit was older than the
> > last release. IIRC
>
> If I understand correctly, add
bertagaz:
> 0. We might also want a mechanism for devs to pro-actively state they want to
> keep their branches being build even if the last commit was older than the
> last release. IIRC
If I understand correctly, adding a dummy commit would bring back my
branch in the set of branches that are au
Hi,
Some thoughts and questions, raised in parts from past IRL discussions.
Consider it like a ping for this thread. :)
On Sun, Jan 11, 2015 at 08:07:13PM +0100, Jurre van Bergen wrote:
> Hi,
>
> For the first iteration, which is automatically build of interesting
> branches, we need to specify:
Hi,
As some of you might know, we'll spend quite some time this year seting
up automated builds and test using our Jenkins platform and make it
easier to extract information and data from it.
For the first iteration, which is automatically build of interesting
branches, we need to specify:
* W
49 matches
Mail list logo
