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 to test the patches and push the changes all at once in a coordinated way. I mean, that's what release engineering and engineers have been doing as part of a job function. We could ask the release team to provide that coordination.
These are just suggestions, trying to create simple processes using what we have today.
> 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.
Thank you for providing your perspective, it was very useful and helps move this discussion forward.
sri
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
