Re: Continuous Builds in GNOME

[Milan Crha]

On Mon, 2016-06-06 at 20:32 +, Sriram Ramkrishna wrote:
> I think that is the point of the try server, right?  You push it to
> the try server and make sure that it builds correctly for everyone...

Hi,
if you mean that "jhbuild" is a synonym for "everyone", then you surely
didn't open [1], to which I gave a link to earlier. There jhbuild
succeeded, my local build succeeded, Fedora build succeeded, still
there was an environment where it failed. And it failed properly, I'd
say.

Your idea of the "try server" makes me think of the way WebKit has it
done. You attach a patch to their bugzilla, set some flags and a bot
runs some testing and builds in various environments with that patch
applied. All automated. Anything like that can work for smaller
patches, but once you think of the bigger changes, like the
aforementioned Camel API change [2], you get into a very different
world.

> A lack of diligence on your part for instance costs time and
> headache somewhere else.

Right, I agree, there will be always someone unhappy. The question of
this thread, and the whole idea of the reverts, is who that will be.

> Nope and Emmanuele does stipulate that we need someone to monitor the
> build and act accordingly.  However, the rest of you have an
> obligation when that person nags you about it to respond in a timely
> manner.

I hope it was understood from my mail that I am not part of that "the
rest of you" group. What you said makes me feel that you think that
everyone else is "a bad guy". That's really not true.
 
The "timely manner" is the keyword too. Sometimes it takes time before
the maintainer notices that the Continuous broke. Consider different
timezones, weekends, public holidays in different countries and so on.
Everything matters when it comes to "timely manner".

I know, this thread is also about addressing just this in some not so
cruel way to anyone.

> I think we all agree that there should be change, we just need to
> agree what is the minimal set of things we can accomplish today and
> then iterate there.  We just need to establish a place where we can
> at least start on a path and break current status quo.

I'm sorry, but the current state works for me. Of course, I do not work
on the Continuous, I have no idea how much time and headache it costs
to keep it working with so many involved projects. Thus my point of
view is not objective, it's rather subjective.

> In general, I really don't like the idea that we're all a set of
> fiefdoms with no influence on each other.

Some projects are core parts, where others can use them. Some are on
"leafs", final applications, which cannot be reused (in a library
sense) by others. Those are very different types of projects. As had
been said in this thread, Continuous doesn't build each hosted project
in the GNOME infrastructure.
Bye,
Milan

> > [1] https://bugzilla.gnome.org/show_bug.cgi?id=766540
> > [2] https://bugzilla.gnome.org/show_bug.cgi?id=764065

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Continuous Builds in GNOME

[Milan Crha]

On Mon, 2016-06-06 at 22:21 +0200, Sébastien Wilmet wrote:
> On Mon, Jun 06, 2016 at 10:10:58PM +0200, Sébastien Wilmet wrote:
> > 
> > There is a solution: bump the major version of Camel or EDS each time an
> > API or ABI break is unavoidable, making the new major version
> > parallel-installable with the previous ones. And that, every 6 months if
> > needed (or one year if the development cycle is longer for the
> > Evolution-related projects).

Hi,
there is no need to give me pointers to things and practices which are
already used in the project. It can be useful for some other projects,
for some maintainers following this thread, thought.

I mean, that's exactly what we do (unless accidentally overlooked). If
the API/ABI changes, a soname version is bumped for that respective
part, at least once between releases (I just did a soname version bump
of Camel for 3.21.3 in one commit, then I did another change in the
Camel API in another commit, but I didn't bump the soname version,
because that all will be available for the early adopters in one single
release, 3.21.3).

> Mmh maybe it's not possible for EDS, since it's a daemon (or contains
> a daemon) and thus only one instance can run on a system. I don't
> know much about how EDS, Camel etc are designed.

The Camel is a library, which happens to be part of the evolution-data-
server. The evolution-data-server consist also of some D-Bus services,
which allow clients to connect to them and have address books and
calendars, tasks, memos. The Camel library is used for Mail and it
doesn't provide any such D-Bus service as of today. The D-Bus services
are also versioned, thus, if needed, the version can be bumped.

Nonetheless, the evolution-data-server doesn't support parallel builds
into the same prefix, neither the evolution.

We diverged from the initial thread topic a bit here, I'm afraid.
Bye,
Milan

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Continuous Builds in GNOME

[Christian Hergert]

On 06/06/2016 01:35 PM, Sriram Ramkrishna wrote:
> I would think the docs team would be also interested.  I wonder if we
> could create coverage maps using this..

Generally the docs team doesn't write API documentation, but I certainly
wouldn't turn anyone away that wants to write API docs for me.

-- Christian

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Continuous Builds in GNOME

[Sriram Ramkrishna]

On Mon, Jun 6, 2016 at 1:03 PM Christian Hergert 
wrote:

> On 06/06/2016 12:48 PM, Michael Catanzaro wrote:
> > I agree with you that when landing a big API change, if you don't want
> > to use side branches, then a revert is less preferable to tagging in
> > Continuous and branching in jhbuild. (In such cases, it'd be great if
> > you could handle that before pushing the API change, though. :)
>
> A couple weeks ago I wrote a quick hack to parse Continuous build logs
> and extract CFLAGS for the built files. It can use this to then go
> perform static analysis on the module with clang and extract/resolve all
> function calls.
>

This is pretty cool!


>
> The goal was to be able to tell us which API are used the most (and
> therefore requires our attention to documentation), but we could also
> use it to tell developers everywhere in g.g.o that their API is being used.
>
>
I would think the docs team would be also interested.  I wonder if we could
create coverage maps using this..


> I expect to build this out as I work more on documentation stuff for
> Builder.
>

Excellent!

sri


>
> -- Christian
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Continuous Builds in GNOME

[Sriram Ramkrishna]

Hi Milan!

On Mon, Jun 6, 2016 at 10:05 AM Milan Crha  wrote:

> On Mon, 2016-06-06 at 09:49 -0500, Michael Catanzaro wrote:
> > A revert is not supposed to be "punishment" in any way... rather,
> > consider it as assistance to make sure GNOME stays buildable. :)
>
> Hi,
> maybe it's not supposed to be, but it is in my eyes. I try my best to
> not break builds, I'm grateful when other folks let me know when the
> builds are broken for them. Neither jhbuild catches everything [1],
> which you seem to suggest. I broke build in general, not only in the
> jhbuild, in the not so distant past, which was a shame and it was all
> my fault. I'm sorry for that, though in that particular case the change
> on the evolution-data-server side was correct, only the evolution build
> broke, because it wasn't updated appropriately. The revert on the eds
> side would not make any sense. It was correct, as I said. (API changed
> in some way and I didn't realize that the evolution uses the API in a
> way which breaks it. Just my fault.)
>

I think that is the point of the try server, right?  You push it to the try
server and make sure that it builds correctly for everyone and then you'll
know whether something is broken or not before it get committed to master.

Perhaps, reverting might seem like over kill, but I think we need to have a
social contract to at least use the try server and make sure that it builds
there before pushing it to master.  After all, we all committed to a six
month release cycle and this doesn't add too much additional overhead, and
helps enables development across the stack without anybody getting stuck.
A lack of diligence on your part for instance costs time and headache
somewhere else.  Just another perspective on the issue.


> I do not fully understand why reverting in some random project (and
> making sort of hostile environment) is easier than the current state,
> when the same person "tags" what commit is supposed to be used in
> Continuous in the jhbuild. You still need the person, the person cannot
> be a monkey, it will think before doing anything (I mean, it's not a
> mechanical job where one rule fits each case).
>

Nope and Emmanuele does stipulate that we need someone to monitor the build
and act accordingly.  However, the rest of you have an obligation when that
person nags you about it to respond in a timely manner.


>
> I appreciate how Emmanuele and others (are there any others?) handle
> the situation right now. I do not want to add them more work, really
> not.
>

I think we all agree that there should be change, we just need to agree
what is the minimal set of things we can accomplish today and then iterate
there.  We just need to establish a place where we can at least start on a
path and break current status quo.


>
> Right, it's unrealistic in some cases to land all of that at one time.
> Side branches is a nice idea, but it won't work, because you do not
> have any influence on the other project maintainers usually, thus even
> a bugzilla requests can lurk there for a long time. Having a side
> branch only means that the maintainers whom do not follow particular
> mailing list will notice only later, rather than sooner.
>

Well that's when we ask the release team for help.  They are in my opinion
currently under utilized for this kind of thing.

In general, I really don't like the idea that we're all a set of fiefdoms
with no influence on each other.  We all here to move this platform
forward.  We should all be making sure that we support each other, because
that support helps GNOME and moves our purpose forward.  This shouldn't be
about my little piece of soil with the myopic view that this is all I care
about unless you are a contributor to the module.  If I come to you with a
build breakage issue then I expect a return courtesy because my request
comes with the intent that we want to improve things.


>
> There is a bug to make more structures in Camel GObject based [2], to
> be able to introspect it in a much easier way and so on. That change
> will not be only a simple API change, it'll break core Camel things,
> everything what uses it. If you open the [2], then I listed affected
> projects at the end of the comment #5. It counts 18 projects. Maybe
> there are more. I do not think I'd be able to coordinate the change in
> a side branch for all of them, I (we) will surely provide patches in
> the bugzilla around the time of the change landing, then it'll be up to
> the respective maintainers to pick or reject them. What will the
> Continuous do during this "broken period" is something I do not know. I
> only know that the change will be for good. Introspection support for
> the Mail part is good, I believe. Trying to revert such change in the
> eds would hurt very much, no doubt.
>

I would say that is a matter of negotiation.  If we are tolerating a full
break in the builds, then be it.  You schedule that time, and then give
people a chance 

Re: Continuous Builds in GNOME

[Sébastien Wilmet]

On Mon, Jun 06, 2016 at 10:10:58PM +0200, Sébastien Wilmet wrote:
> There is a solution: bump the major version of Camel or EDS each time an
> API or ABI break is unavoidable, making the new major version
> parallel-installable with the previous ones. And that, every 6 months if
> needed (or one year if the development cycle is longer for the
> Evolution-related projects).

Mmh maybe it's not possible for EDS, since it's a daemon (or contains a
daemon) and thus only one instance can run on a system. I don't know
much about how EDS, Camel etc are designed.

--
Sébastien
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Continuous Builds in GNOME

[Christian Hergert]

On 06/06/2016 01:02 PM, Christian Hergert wrote:
> A couple weeks ago I wrote a quick hack to parse Continuous build logs
> and extract CFLAGS for the built files. It can use this to then go
> perform static analysis on the module with clang and extract/resolve all
> function calls.

And the missing link: https://github.com/chergert/sightline



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Continuous Builds in GNOME

[Christian Hergert]

On 06/06/2016 12:48 PM, Michael Catanzaro wrote:
> I agree with you that when landing a big API change, if you don't want
> to use side branches, then a revert is less preferable to tagging in
> Continuous and branching in jhbuild. (In such cases, it'd be great if
> you could handle that before pushing the API change, though. :)

A couple weeks ago I wrote a quick hack to parse Continuous build logs
and extract CFLAGS for the built files. It can use this to then go
perform static analysis on the module with clang and extract/resolve all
function calls.

The goal was to be able to tell us which API are used the most (and
therefore requires our attention to documentation), but we could also
use it to tell developers everywhere in g.g.o that their API is being used.

I expect to build this out as I work more on documentation stuff for
Builder.

-- Christian

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Continuous Builds in GNOME

[Michael Catanzaro]

On Mon, 2016-06-06 at 19:05 +0200, Milan Crha wrote:
> Right, it's unrealistic in some cases to land all of that at one
> time.
> Side branches is a nice idea, but it won't work, because you do not
> have any influence on the other project maintainers usually, thus
> even
> a bugzilla requests can lurk there for a long time. Having a side
> branch only means that the maintainers whom do not follow particular
> mailing list will notice only later, rather than sooner.

Hi,

If you have a patch that e.g. adapts another module to your API change,
but the relevant maintainers are not responsive on Bugzilla, you should
feel free to just push ahead with your changes. If you're not
comfortable pushing to other modules, you can contact the release team
and we'll push your work for you. We understand this happens sometimes;
everyone's busy, but nobody wants your work to get blocked in such
cases. (I remember recently we had this issue with e-d-s and
california, although california is neither in jhbuild nor continuous,
so we're not going to nag you if it breaks.)

I agree with you that when landing a big API change, if you don't want
to use side branches, then a revert is less preferable to tagging in
Continuous and branching in jhbuild. (In such cases, it'd be great if
you could handle that before pushing the API change, though. :)

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Continuous Builds in GNOME

[Milan Crha]

On Mon, 2016-06-06 at 09:49 -0500, Michael Catanzaro wrote:
> A revert is not supposed to be "punishment" in any way... rather,
> consider it as assistance to make sure GNOME stays buildable. :)

Hi,
maybe it's not supposed to be, but it is in my eyes. I try my best to
not break builds, I'm grateful when other folks let me know when the
builds are broken for them. Neither jhbuild catches everything [1],
which you seem to suggest. I broke build in general, not only in the
jhbuild, in the not so distant past, which was a shame and it was all
my fault. I'm sorry for that, though in that particular case the change
on the evolution-data-server side was correct, only the evolution build
broke, because it wasn't updated appropriately. The revert on the eds
side would not make any sense. It was correct, as I said. (API changed
in some way and I didn't realize that the evolution uses the API in a
way which breaks it. Just my fault.)

I do not fully understand why reverting in some random project (and
making sort of hostile environment) is easier than the current state,
when the same person "tags" what commit is supposed to be used in
Continuous in the jhbuild. You still need the person, the person cannot
be a monkey, it will think before doing anything (I mean, it's not a
mechanical job where one rule fits each case).

I appreciate how Emmanuele and others (are there any others?) handle
the situation right now. I do not want to add them more work, really
not. 

> we can create a list of maintainers who don't want this

Nah, that's one more place to look at and to forget about. That adds
work to those nice folk(s) whom take care of the Continuous.

> In this case, when the API change breaks something in core or gnome-
> apps, then the module and its dependencies really need to be updated
> in jhbuild at (approximately) the same time, so there's at most a
> small window of time where jhbuild is broken.
> ...

Right, it's unrealistic in some cases to land all of that at one time.
Side branches is a nice idea, but it won't work, because you do not
have any influence on the other project maintainers usually, thus even
a bugzilla requests can lurk there for a long time. Having a side
branch only means that the maintainers whom do not follow particular
mailing list will notice only later, rather than sooner.

There is a bug to make more structures in Camel GObject based [2], to
be able to introspect it in a much easier way and so on. That change
will not be only a simple API change, it'll break core Camel things,
everything what uses it. If you open the [2], then I listed affected
projects at the end of the comment #5. It counts 18 projects. Maybe
there are more. I do not think I'd be able to coordinate the change in
a side branch for all of them, I (we) will surely provide patches in
the bugzilla around the time of the change landing, then it'll be up to
the respective maintainers to pick or reject them. What will the
Continuous do during this "broken period" is something I do not know. I
only know that the change will be for good. Introspection support for
the Mail part is good, I believe. Trying to revert such change in the
eds would hurt very much, no doubt.

> Yeah, of course runtime bugs are problems, but not the problem we are
> trying to solve here. :)

Heh, true, though the runtime bugs are more important. I believe.
I know, that's one reason why you want to have the jhbuild working, to
make it easier for the contributors to test and develop. Which is a
good thing for everyone.
Bye,
Milan

[1] https://bugzilla.gnome.org/show_bug.cgi?id=766540
[2] https://bugzilla.gnome.org/show_bug.cgi?id=764065
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Continuous Builds in GNOME

[Michael Catanzaro]

Hi,

A revert is not supposed to be "punishment" in any way... rather,
consider it as assistance to make sure GNOME stays buildable. :) But if
you really don't like it and don't want other folks reverting your
commits when you're not around, we can create a list of maintainers who
don't want this; that way, on the rare occasions when something breaks,
we can branch your module in jhbuild and tag it in Continuous instead
of reverting your change. I think it's generally better to avoid
branching/tagging, so I'd encourage maintainers to just accept the
occasional revert now and then, but it's understandable if we won't all
agree on this.

On Mon, 2016-06-06 at 11:01 +0200, Milan Crha wrote:
> - a soname version bump can break dependant projects. Such change
>   should not be reverted, the dependencies should be rebuilt.

Right; incremental builds with jhbuild are not completely reliable, and
a soname bump is generally not a valid reason to revert a commit. But
if a clean build doesn't work, then we have a problem to be fixed.

> - a soname version bump with an API change can break dependant
>   projects. Such change should not be reverted, the dependencies
>   should be rebuilt and adapted to the change.

In this case, when the API change breaks something in core or gnome-
apps, then the module and its dependencies really need to be updated in
jhbuild at (approximately) the same time, so there's at most a small
window of time where jhbuild is broken. Of course it can take time to
port dependencies; in such cases, we can either (a) make the API change
on a side branch, port dependencies on side branches, and merge the
changes to master when all GNOME modules are ready; or (b) make the API
change on master, but branch the module in the jhbuild moduleset so
that other modules continue to build against the older version of the
module with the API change. Really, you can do whatever you want, so
long as you avoid breaking jhbuild or Continuous, please!

> - a change which can build, but causes regressions in runtime. Such
>   change should be reverted, right? But wait, you care only about
>   the build, not about runtime. Having a software buildable and
>   having the same software usable are two very different things.

Yeah, of course runtime bugs are problems, but not the problem we are
trying to solve here. :)

Hope that clarifies where I'm coming from.

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Continuous Builds in GNOME

[Alberto Mardegan]

On 03/06/2016 17:26, Sriram Ramkrishna wrote:
> Yes, but it highlights the value something like GitHub provides.  What
> about GitLab?  (BTW I'm not advocating we move, just looking to see
> alternatives)  GitLab while open source, does not seem to open source
> its CI work that I can tell.  Still, maybe a deal can be made.. 

It's all open-source:
https://about.gitlab.com/gitlab-ci/

Ciao,
  Alberto
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Continuous Builds in GNOME

[Carlos Soriano Sanchez]

Hey Milan,

| The proposal about random reverts makes me feel that you want to flip
| the positions. While I agree that the maintainers point of view is
| broken, the position flip just means (for me): "the GNOME
| infrastructure/jhbuild environment is the only good build environment
| and if the maintainer breaks it, then the GNOME infrastructure team can
| punish the maintainer if it needs to". Do you see how absurd it sounds?

I see what you meant, but I think you are looking at it with "bad eyes". It is 
not punishment, is just that should be a requirement that the master branch is 
buildable on continuous and jhbuild, and the only way to do so it's reverting 
the breaking change.
In the meantime the maintainer can do whatever he wants in a branch and wait 
until the he/she figures out the build problem before merging to master again.

| The breakage should be dealt with in a cooperation manner, rather than
| in a force manner. Of course, if the maintainer is not willing to
| cooperate..., but I hope that's only a minority of the GNOME-hosted

Indeed, and I think Emmanuelle acts in the right way, trying to reach the 
maintainer, and if he/she is not available, just reverting with a commit 
message explaining the reason or fixing it temporarily so everyone can still 
build the module.

I think this is more about that bad feeling of someone else not involved in the 
module touching "our" project without even asking to us the maintainers, and I 
also have that feeling, however I think it's more important that everyone can 
build our modules. Otherwise we are going to make worse the already difficult 
experience of building GNOME.

Cheers,
Carlos Soriano
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Enabling builddir != srcdir by default in jhbuild

[Emmanuele Bassi]

Hi;

On 6 June 2016 at 12:23, Bastien Nocera  wrote:

> The "srcdir != builddir" implemented in jhbuild isn't the same one as
> the one implemented in Continuous[1].

I know, that's why I wrote:

"""
The main change is that jhbuild runs the autogen script from within
the build directory, instead of running it into the source directory
and then running the configure script from the build directory.
"""

Continuous does:

  $(srcdir): NOCONFIGURE=1 ./autogen.sh
  $(builddir): $(srcdir)/configure $(arguments)
  $(builddir): make

whereas jhbuild (and most of our build instructions) let the
autogen.sh script call the configure script directly.

> Which is a bit of a shame when the jhbuild implementation was done to
> avoid continuous breaking. And that might also have explained a number
> of the breakages you've found.

In general, autogen.sh needs to cope with non-srcdir invocation
because the usual way to build with jhbuild is not. A large number of
GNOME modules, including the ones still using gnome-autogen.sh,
support this out of the box. The breakages I've seen mostly come from
copy-pasting autogen.sh from other (older) sources, or incomplete
attempts to support non-srcdir builds.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Enabling builddir != srcdir by default in jhbuild

[Bastien Nocera]

On Fri, 2016-06-03 at 13:11 +0200, Bastien Nocera wrote:
> On Thu, 2016-06-02 at 23:50 +0100, Emmanuele Bassi wrote:
> > [ Picking this up again ]
> > 
> > I've been spending the last couple of days fixing modules on
> > git.gnome.org (you may have noticed a commit or two from me on your
> > modules fixing builddir != srcdir issues); submitting bugs/patches
> > to
> > modules that are hosted elsewhere; and disabling non-srcdir builds
> > directly in the jhbuild modulesets. I'm fairly confident that all
> > remaining issues are now limited to modules that are in gnome-apps
> > or
> > gnome-world, but I haven't tested things like all the C++ language
> > bindings modules.
> > 
> > If you maintain a module listed in jhbuild, *please* update your
> > jhbuild local repository and try build your module with the new
> > buildroot setting enabled. If your module fails to build, fixing it
> > would also be appreciated — as it would spare you and everybody
> > else
> > time and effort; alternatively, you can poke me on IRC, and I'll
> > either fix it for you, or help you out in fixing it.
> > 
> > As a last resource, we can mark modules that do not support non-
> > srcdir
> > builds in the various modulesets, but I'd rather avoid it as it
> > defeats the purpose.
> 
> Looks like this is uncovering more bugs.
> $ jhbuild buildone -afn gnome-documents
> *** Configuring gnome-documents *** [1/1]
> /home/hadess/Projects/jhbuild/gnome-documents/autogen.sh --prefix
> /home/hadess/Projects/gnome-install --disable-Werror  --enable-
> getting-
> started 
> /usr/bin/gnome-autogen.sh
> fatal: Not a git repository (or any parent up to mount point /home)
> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not
> set).
> 
> 
> The autogen.sh tries to run:
> git submodule update --init --recursive
> 
> Which might, or might not be a good idea. In any case, that won't
> work
> if cwd isn't the git repo.
> 
> What's the proper fix for this then?

The "srcdir != builddir" implemented in jhbuild isn't the same one as
the one implemented in Continuous[1].

Which is a bit of a shame when the jhbuild implementation was done to
avoid continuous breaking. And that might also have explained a number
of the breakages you've found.

[1]: Continuous runs autogen.sh from srcdir, jhbuild from builddir.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Continuous Builds in GNOME

[Milan Crha]

On Fri, 2016-06-03 at 08:28 -0500, Michael Catanzaro wrote:
> I expect module maintainers to be understanding when reverts happen.
> It's not the end of the world; you can land your change again as soon
> as you figure out why it was broken. We can all live with a few
> revert commits in our git history. Your module can still be your
> fiefdom... just so long as it's still building with the rest of
> GNOME.

Hi,
I'm not a fan of the random reverts from some 3rd party person whom
doesn't know the "bigger picture" of the project changes which can lead
to a win-win state, even the changes are that large that it's better
(for whatever reason) to split them into several commits, which not
necessarily follow in a short time. Such reverts would mean more work
for the maintainers, which is always a pita.

I hear here an argument that the maintainers claim that "it builds on
their machine" and they do not care of the other build environments.
Personally, I do not understand this statement, one (the maintainer)
should be willing to support his project home, appreciate that the
project can use the infrastructure and be tested in more places, which
is always a good thing.

The proposal about random reverts makes me feel that you want to flip
the positions. While I agree that the maintainers point of view is
broken, the position flip just means (for me): "the GNOME
infrastructure/jhbuild environment is the only good build environment
and if the maintainer breaks it, then the GNOME infrastructure team can
punish the maintainer if it needs to". Do you see how absurd it sounds?
The breakage should be dealt with in a cooperation manner, rather than
in a force manner. Of course, if the maintainer is not willing to
cooperate..., but I hope that's only a minority of the GNOME-hosted
projects (I do not know any numbers here) and definitely the core
project maintainers are all good, I believe, thus there might not be
any issue. The "bad" projects, if not from the core part, can be
skipped in the Continuous builds due to the lack of the interest from
the maintainers side.

There had been discussed also what can be reverted and what not.
If you recall:
- a soname version bump can break dependant projects. Such change
  should not be reverted, the dependencies should be rebuilt.
- a soname version bump with an API change can break dependant
  projects. Such change should not be reverted, the dependencies
  should be rebuilt and adapted to the change.
- a change which can build, but causes regressions in runtime. Such
  change should be reverted, right? But wait, you care only about
  the build, not about runtime. Having a software buildable and
  having the same software usable are two very different things.

I suppose the GNOME build system runs some unit tests, if the module
provides such, but such tests are testing the new code, not the
regressions the change in the module can cause in another module which
had been/will be built against it.

Just my opinion on the matter.
Bye,
Milan

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list