Hi, On Wed, May 17, 2017 at 1:05 PM, Carlos Soriano <csori...@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.marmott...@gmail.com > To: Tristan Van Berkom <tristan.vanber...@codethink.co.uk>, > desktop-devel-list <desktop-devel-list@gnome.org> > > Hi, > > On Wed, May 17, 2017 at 12:33 PM, Sébastien Wilmet <swil...@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
