!
---
Sahil Sareen
Foundation Member and Game Dev, GNOME
Software Dev Engineer, Amazon
From: desktop-devel-list on behalf of
Michael Catanzaro
Sent: Tuesday, January 26, 2016 4:30 AM
To: desktop-devel-list@gnome.org
Subject: Re: Build sheriffs for GNOME
On Thu
On Thu, 2016-01-21 at 12:19 -0600, Michael Catanzaro wrote:
> The next step is to convert either jhbuild or gnome-continuous to use
> the others' modulesets.
In retrospect, this was an ignorant suggestion. The Continuous manifest
does not specify dependencies, so it's unsuitable for use by JHBuild
Not being a gnome developer, what follows is just a report of what I
experienced in a continuous integration/delivery environments at
$BIGCORPs where HEADs always build together, test stay green and
developers are (hopefully) able to evolve the design and
implementation without much hindrance.
Som
On Sun, 2016-01-24 at 19:02 +0900, Tristan Van Berkom wrote:
> What jhbuild is not, is a delivery system to users who want to try
> the
> latest bleeding edge version of every project in GNOME together. Even
> though it is possible that 80% of the time or even more, every
> project's master branch
On Sun, 2016-01-24 at 05:18 +0100, Vamp898 wrote:
> Hi,
>
Hi Shirakawa,
I see you replied off list, I am returning this to the list because it
is a good question to answer and it's rather wasteful to compose a full
reply to this and not have the benefit of it being recorded in the
archives for
> On 22 Jan 2016, at 17:32, Michael Catanzaro wrote:
>
>> On Sat, 2016-01-23 at 03:14 +0900, Tristan Van Berkom wrote:
>> I do not support the vague notion that a "sheriff" can come along and
>> revert an entire branch I've just landed which changes the API
>> contract
>> early enough in the re
On Fri, 2016-01-22 at 13:32 -0600, Michael Catanzaro wrote:
> Ah, yeah, we should not be reverting entire large sequences of
> commits... I agree that would be excessive. In cases like this, we
> can
> tag your module in Continuous and branch it in jhbuild, until other
> modules have caught up with
On Sat, 2016-01-23 at 03:14 +0900, Tristan Van Berkom wrote:
> I do not support the vague notion that a "sheriff" can come along and
> revert an entire branch I've just landed which changes the API
> contract
> early enough in the release cycle for depending modules to catch on
> and
> adapt to.
A
On Fri, 2016-01-22 at 11:40 -0600, Michael Catanzaro wrote:
> On Fri, 2016-01-22 at 09:25 -0800, Jasper St. Pierre wrote:
> > It's more frequent than you might think.
> >
> > In the past week, alone, we've had to tag glib, gnome-calculator,
> > e-d-s, gstreamer, and more, all because of broken bui
On Fri, 2016-01-22 at 12:12 -0500, Shaun McCance wrote:
> On Fri, 2016-01-22 at 16:03 +0900, Tristan Van Berkom wrote:
> > On Thu, 2016-01-21 at 14:54 +, Emmanuele Bassi wrote:
> > [...]
> > > This is not enough, and it does not raise the bar in keeping
> > > GNOME
> > > in
> > > a buildable st
On Fri, 2016-01-22 at 09:25 -0800, Jasper St. Pierre wrote:
> It's more frequent than you might think.
>
> In the past week, alone, we've had to tag glib, gnome-calculator,
> e-d-s, gstreamer, and more, all because of broken builds. Take a look
> at how busy gnome-continuous is as a project:
> htt
On Sat, 2016-01-23 at 01:55 +0900, Tristan Van Berkom wrote:
> This kind of breakage is just a fact of life, you cannot sweep it
> under
> the rug and pretend it does not exist.
>
> Sure, it's a barrier of entry for newcomers and an annoyance for
> experienced developers who realize the facts of li
It's more frequent than you might think.
In the past week, alone, we've had to tag glib, gnome-calculator,
e-d-s, gstreamer, and more, all because of broken builds. Take a look
at how busy gnome-continuous is as a project:
https://git.gnome.org/browse/gnome-continuous/log/
We currently have a tea
On Fri, 2016-01-22 at 16:03 +0900, Tristan Van Berkom wrote:
> On Thu, 2016-01-21 at 14:54 +, Emmanuele Bassi wrote:
> [...]
> > This is not enough, and it does not raise the bar in keeping GNOME
> > in
> > a buildable state. It actually lowers it a fair , to the effective
> > point that *nobod
2016-01-22 16:55 GMT+00:00 Tristan Van Berkom :
> Of course, when you commit something and your *own* code does not
> compile, this is a very, very rare thing, rare enough to not be worth
> discussion I think, it that's happening, it's a problem.
>
> But it's common enough with many moving parts t
On Fri, 2016-01-22 at 10:55 +0100, Milan Crha wrote:
> Hi,
> I agree with Tristan. I was just about to write something along his
> lines. Seeing semi-automated reverts in the projects would be quite
> depressing, especially when the semi-automat has no idea about the
> project and what the ch
On Fri, 2016-01-22 at 13:38 +, Emmanuele Bassi wrote:
> Continuous generates VM images that you can easily install inside
> Boxes, and keep them updated (they are based on OSTree and allow
> atomic updates).
>
> The latest successfully built image is always at:
> http://build.gnome.org/continu
On Fri, 2016-01-22 at 13:31 +, Emmanuele Bassi wrote:
> Hi;
>
> > Continuous is a great first step (the response time is *stunningly*
> > good) and we're better off now that we have it, but it's not good
> > enough as it's not testing the build tool we use for development,
> > it's
> > not te
On Fri, 2016-01-22 at 10:37 -0600, Michael Catanzaro wrote:
[...]
> I really don't think it's a big deal to have a few reverts in the git
> history. And anyway, reverts should be relatively rare, because build
> breakage should be relatively rare.
>
> The master branch may be unstable, but that do
On Fri, 2016-01-22 at 16:03 +0900, Tristan Van Berkom wrote:
> o We are a volunteer driven project with contributors distributed
> across timezones, who have dayjobs, it is ridiculous to expect
> that
> maintainers can be reachable within a 3 hour turnaround period.
>
> This leads me
To be clear on what I'd like to see:
The most important requirement for our CI system is to run 'jhbuild
build' for each module with a clean install prefix, to find missing
dependencies in our moduleset. Not having to maintain jhbuild
modulesets separate from the Continuous manifest would be good
Hi;
On 22 January 2016 at 13:03, Simon McVittie
wrote:
> On 21/01/16 14:54, Emmanuele Bassi wrote:
>> In short, I want to ensure that GNOME maintainers become
>> a bit more proactive in giving a crap about their modules breaking on
>> something that is not their own computers.
>
> Is there a way
Hi Alberto;
you're asking for a try server, which is a fairly complex piece of machinery.
Mozilla has one, based on buildbot; it may be possible to have a
machine dedicated to try builds, but that's not what Continuous does,
and it would not be what Continuous aims to be.
Ciao,
Emmanuele.
On
Hi;
On 21 January 2016 at 18:19, Michael Catanzaro wrote:
> The next step is to convert either jhbuild or gnome-continuous to use
> the others' modulesets. Currently the jhbuild modulesets are the
> official "what we release,"
"What we release" and "what we actually run" are two fairly differen
One ideal end result IMO would be that some service similar to GNOME
continuous that validates any commit or patch ahead of time. If a
commit wasn't validated and somebody tried to push it to master, the
server should reject it. (GitLab does this implicitly with protected
branches and merge request
Another thing that would be really useful in this line is to be able to
submit specific branches for testing. Say I'm working on wip/foobar to
avoid breaking master, and before pulling that stuff from master I want to
make sure I won't break the builds.
Is anything like this possible at all?
2016
On 21/01/16 14:54, Emmanuele Bassi wrote:
> In short, I want to ensure that GNOME maintainers become
> a bit more proactive in giving a crap about their modules breaking on
> something that is not their own computers.
Is there a way in which contributors/maintainers can reproduce something
equival
On Fri, 2016-01-22 at 16:03 +0900, Tristan Van Berkom wrote:
> In summary, I am not opposed to applying your proposal as is to the
> stable builds, there is no justification *ever* for breakage in stable
> branches.
>
> For master, I only think this needs to be detailed properly, perhaps it
> woul
On Thu, 2016-01-21 at 14:54 +, Emmanuele Bassi wrote:
[...]
> This is not enough, and it does not raise the bar in keeping GNOME in
> a buildable state. It actually lowers it a fair , to the effective
> point that *nobody* cares about Continuous builds.
>
> I want this to change. I want to be
On Thu, 2016-01-21 at 12:19 -0600, Michael Catanzaro wrote:
> Thank you Emmanuele, this will really help with keeping GNOME
> building.
> I strongly support this change.
Also, to clarify, this surely means that maintainers are responsible
for updating the Continuous manifest in addition to JHBuild
Thank you Emmanuele, this will really help with keeping GNOME building.
I strongly support this change.
On Thu, 2016-01-21 at 14:54 +, Emmanuele Bassi wrote:
> This effort led to various benefits, including JHBuild not constantly
> being in a broken state, and most projects hosted on git.gnome
hursday, January 21, 2016 8:24 PM
> To: Desktop Development List
> Subject: Build sheriffs for GNOME
>
> Hi all;
>
> Many of you know about GNOME Continuous, and build.gnome.org — and for
> those who don't, here's two handy links:
>
> - https://build.gnome.org
>
Re: Build sheriffs for GNOME
SAHIL SAREEN
Reply|
To:
Emmanuele Bassi ; Thu 1/21/2016 8:47 PM
Hey ebassi
I feel we should spend time building a simple "build sheriff" (maybe an
extension of https://build.gnome.org) that auto-files a "cri" bug for the
module whose build fail
Hi all;
Many of you know about GNOME Continuous, and build.gnome.org — and for
those who don't, here's two handy links:
- https://build.gnome.org
- https://wiki.gnome.org/Projects/GnomeContinuous
In short: we're currently building the core GNOME and some
applications every time something get
34 matches
Mail list logo
