Re: [ Revised Proposal ] Continuous Builds in GNOME

On Fri, 2016-06-17 at 17:11 +0900, Tristan Van Berkom wrote:
I dont believe you have any such functionality in jhbuild.

At best, you can specify the sha1 of the commit you want to build of
a given module, this would not let you single out one commit,
omitting it from history in integration and at least attempt to apply
subsequent commits without that one included, re-including that
commit in the correct place in history only when CI infrastructure
would find integration unbroken.

I never thought of a single commit removal from a set of commits. To be
honest, that sounds even more crazy (not 'crazy' like 'insane'). :)
We are talking about master, the development version of the software.
If you'd like to tell me that you are at commit X and feature which I
added at commit X-3 does not work for you, then trying to figure out
why exactly you do not see that feature is a real nightmare and waste
of time for both the reporter and the developer, especially when you
want to remove only single commit from a history. Not talking that
following commit can "build on top of the previous commit", which is
quite usual.

The thing is, either way; your work flow will not be interrupted at
all with this approach, ...

See above.

I realize my answer is quickly written and I would like to keep my
mind open and receptive, but I would also like to hear a more
detailed counter proposal on your end too, weighing the benefits of
managing this in a jhbuild moduleset vs a unified project wide git

I didn't think of my workflow changes in any deep way, also because I
do not use jhbuild (that's not a tool for me). I just want to keep
things simple as much as possible. Not only for me, but for the others
too. Adding a new branch adds some non-trivial complexity.

Consider the early adopters, whom will fill bugs against the developer
version of some module. The developer will not only ask "what steps to
do to reproduce the issue", but also "which branch was used and with
what commits". And it happens often that the developers do not react on
bugs "quickly", thus the commit numbers in the integration branch can
be easily lost (branch rebuilt), thus making the bug report more or
less useless.

I said earlier in the thread that the current situation works for me
the best. There is clearly stated what the continuous builds from, at
which exact commit it "stopped updating" certain module, because of
some breakage, and everything references the real master branch. That
the continuous uses jhbuild might be just a coincidence, even it sounds
like the moduleset is targeted for the Continuous builds, when it can
influence an environment for any developer using the jhbuild (I do not
use it, this is how I understood how it works in the jhbuild world).

I do not care about the new branch, if you (plural 'you') will decide
to use it, then I've nothing significant against. I only think it'll
add too much confusion for the developers, that it'll strike back in
some way in the future. I only do not like the idea of random reverts,
the master branch is the pure bleeding edge, thus if the automatically
managed branch is a way to go for you (plural 'you'), to avoid those
reverts, then feel free to do it.

Maybe, only, it would be ideal if the new branch won't influence daily
`git pull` on the projects, due to bandwidth limitation, connection
speed and similar constraints. That would, maybe, better fit to create
a new project for the automatic builds, with the "interesting" git
sub-modules there at certain commits. There might not be much
difference between the new project with submodules and 10K branches in
each module, right? Your new tool would still work on the git commits.
That's still too complex, too limiting for a daily work on the master
(not for me, but for jhbuild users to whom some modules will
automatically stop updating at certain commit which can break other
modules, like with the API changes, but the developer of the affected
module might not ever notice, because he/she will stay at the commit
which precedes the API change).

There had been said in this thread already that having a continuous
integration (automatic builds) is not easy, especially for such a large
project like GNOME. Whenever a "Continuous" was said in this thread a
shortly after followed "jhbuild". It's understood. The jhbuild is the
current tool for the automatic builds. Supporting random automatic
build systems, which is what you said could be done with the
'integration' branches, is not needed from my point of view, due to the
GNOME project complexity. Thus target jhbuild only. Using modulesets
(it's called like that, right?) for jhbuild and writing an
export/import utility to transform the jhbuild's moduleset into another
automated build integration could be also doable, hypothetically
speaking. If any such thing would be needed in the future. That is,
let's target jhbuild first. The jhbuild already has a functionality to
deal with build breaks, thus make them automatic, as much as possible,
instead of developing some super-duper new generic tool to deal with
build breaks, which will be finally used by the jhbuild only anyway.

Oops, I'm sorry, this is long and I feel like repeating myself, just
not finding the right words and arguments why I think you try to do
this unnecessary complex. Consider this just as some random Friday


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]