GNOME.org
 

Re: Proposal to deploy GitLab on gnome.org

Hi,

On Wed, May 17, 2017 at 2:44 PM, Carlos Soriano <csoriano protonmail com> wrote:

Ah, I see what you mean now. But then you can rebase yourself in master
right? And the build time would be exactly the same no?


Not sure what you mean. You don't want to rebase master under any
circumstances (unless you rebase over origin/master to be able to push
new commits of course). Anyway you usually won't be able to, since
force push should be forbidden in master. And in any cases, this does
not solve the issue I was talking about.

What I want is rebasing a patch branch over master. And no, you cannot
do it *from* master. You have to first checkout the branch so that you
can rebase. Once you checked out, it's too late. Timestamps of various
files are changed even though they didn't change between master and
the rebased branch (but they changed in the in-between step).

This is a very common git issue, you can look it up. :-)
There are workarounds. The best one is to create a second working tree
attached to the same local repository (git help worktree), to do the
rebase there without touching the main working tree (the one you
build). Then when you are done, you can checkout the rebased branch.
This is possible and not too bad if you have to do it often, actually.
Though it's still going through a lot of hoops.

Jehan



Best regards,
Carlos Soriano

-------- Original Message --------
Subject: Re: Proposal to deploy GitLab on gnome.org
Local Time: May 17, 2017 2:03 PM
UTC Time: May 17, 2017 12:03 PM
From: jehan marmottard gmail com
To: Carlos Soriano <csoriano protonmail com>
desktop-devel-list <desktop-devel-list gnome org>

Hi,

On Wed, May 17, 2017 at 1:50 PM, Carlos Soriano <csoriano protonmail com>
wrote:

So the main problem is autotools rebuilds everything when switching
branches, even if the files didn't change?
That's sounds very strange, autotools builds based on mtime of the files,
and I checked this personally.


Yes that's how autotools works.


Are you sure of the reason of this situation? Could it be because the
branch
is not rebased properly on top of the master branch (and the UI in GitLab
will say so, so the contributor will need to do it because otherwise there
is no fast forward merge anyway)?


As I said in the email you answer, that's the most obvious reason, yes. :-)
Quoting myself:


actually for good reasons sometimes; for instance often the branch would
be based on older commits than master HEAD


The contributor will usually work on master and when one pushes, it
would be usually properly rebased (though while one worked, there
would usually be commits). Then patches are rarely immediately
reviewed the next few minutes! It may be days until we make time to do
so. You cannot ask a contributor to rebase the branch constantly and
immediately at the second when you want to review (they also have
their own schedules and not at our orders!). Even more if you review
it in several steps accross several days (which could happen for
complicated patch).
So no, we are usually the ones to rebase the contributor's branch.
That means, when we do rebase, it's too late. We already checked out
the branch, file timestamps changed and are not going to be reverted.
So the next `make` will be long, even if we rebased.

GIMP has commits nearly every day, and very often many commits a day.
You cannot expect the contributor branches to be always up to date
with master. They will always be at least a few commits late. And even
more since we don't review straight away.

Jehan


Best regards,
Carlos Soriano

-------- Original Message --------
Subject: Re: Proposal to deploy GitLab on gnome.org
Local Time: May 17, 2017 1:41 PM
UTC Time: May 17, 2017 11:41 AM
From: jehan marmottard gmail com
To: Carlos Soriano <csoriano protonmail com>
desktop-devel-list <desktop-devel-list gnome org>

Hi,

On Wed, May 17, 2017 at 1:05 PM, Carlos Soriano <csoriano protonmail com>
wrote:

Hey Jehan,

Knowing that core contributors like you and GIMP maintainers will have
access to the repo, are the sporadic contributions still many enough
enough


Yes we still have regular one-time contributions. If anything, we are
the ones who don't review them fast enough, though we have been
getting better now and try to review external patches in a more timely
fashion.


for fetching a remote being inconvenient? Is it because it takes
considerably more time to fetch a repo than download and applying a
patch?


It does take more time indeed. But the most annoying part is having to
switch branches. When you checkout another branch, autotools gets
confused and will re-build much more than what it should have if I
just applied the patch (actually for good reasons sometimes; for
instance often the branch would be based on older commits than master
HEAD). So you transform a 10-second builds into a 10-minute build
(this is *not* exageration; if the patch is on a plugin or even on
most of the core for instance, the rebuild will be very quick; but if
it starts rebuilding libgimp*, then we are doomed!).
When it's a separate remote, I even wonder if git will still make the
link between the 2 remotes? Will it try to rebuild everything from
scratch? This would be absolutely terrible.

What I would do to test a patch is:
- wget
- git apply (this won't make a commit so I won't push it by mistake)
- test it. If it looks good…
- git checkout -- .
- git am
- Optionally fix minor stuff and amend, edit the commit message if needed.
- git push

If the patch looks really simple and obviously good from the basic
visual review, I would just ignore the `git apply` steps. Just git am,
test, push. This can all be done in 15 minutes. In these 15 minutes,
the procedure and rebuild could take just 2 or 3 minutes; the 10+
additional minutes are because I do thorough tests even for small
patches.

If I am forced to checkout another branch, the procedure + build would
be suddenly extremely long and boring.

Now I don't say that there is no alternative. I guess what I would do
is: fetch the remote (don't checkout it), then cherry-pick only the
commit. This way, I avoid a stupid rebuild of useless stuff. It's
still not as good as previously since it will still take longer, and I
lose the `git apply` step, which is the step which allows me to work
and test patches on master without fearing making a stupid push
mistake. Now here too there are workarounds, like I could git reset
immediately to get rid of the commit (still keeping the code), but
that makes a lot of workarounds now! ;P

So yeah, that's not as bright and simple as it could be.

Jehan


Cheers,
Carlos Soriano

-------- Original Message --------
Subject: Re: Proposal to deploy GitLab on gnome.org
Local Time: May 17, 2017 12:47 PM
UTC Time: May 17, 2017 10:47 AM
From: jehan marmottard gmail com
To: Tristan Van Berkom <tristan vanberkom codethink co uk>,
desktop-devel-list <desktop-devel-list gnome org>

Hi,

On Wed, May 17, 2017 at 12:33 PM, Sébastien Wilmet <swilmet gnome org>
wrote:

On Tue, May 16, 2017 at 11:15:51PM +0900, Tristan Van Berkom wrote:

I don't share your optimism about gitlab bug tracking, nor do I share
in the mentioned frustration with bugzilla.


Me too, I like bugzilla (but not for doing code reviews).

What would be the pain points if GitLab is used only for git and code
reviews, and we keep bugzilla for the bug tracker? Have you considered
that option?

We would loose automatic links between bug tracker tickets and pull
requests. When a pull request is merged, we would need to close manually
the bugzilla ticket if everything is done. And when someone requests a
pull, the person would need to add a comment manually on bugzilla so
that other people know that the bug is being worked on.

Mmh I think that's not practical if the links must be done manually.

Maintaining the bugzilla instance would also require sysadmin time, and
development efforts to rebase the patches to new bugzilla versions.

I don't know, I'm excited about the idea to use a similar contribution
workflow as in GitHub, but less excited about having a bug tracker
similar to the GitHub one. (I've never used GitLab, but I'm familiar
with GitHub, and after seeing some screenshots it seems that the GitLab
bug tracker is similar to GitHub's).


I like bugzilla too and guess it probably does more than github/lab
bug trackers. But I also know there are annoying parts. Like someone
noted that searching projects in the long list of GNOME projects is
terrible experience (I even have a browser keyword so that I don't
have to do this anymore, because it was so annoying; but obviously new
contributors would not have such shortcuts).

Also the fact that the reports actually have less options is not bad
IMO. One gets lost in all these bz options. Simplicity is good
sometimes. :-)
gitlab has cool features too, like it's much easier to mention someone
to have them take a look at a report, for instance.
And finally, as you say, code review is much better. I like that you
can annotate line per line (easier for the reviewee in particular to
understand our review).

Bottom line: I definitely don't think we should keep both bz and
gitlab in the end.

The only thing I am annoyed at is this forking workflow. Both as a
contributor, and as a code committer/reviewer. Having to fetch a new
remote for every single-commit contribution out there is terrible.

Jehan


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




--
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list






--
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list






--
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list






-- 
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]