Re: Pull request template for github mirror

[Jehan Pagès]

Hi,

On Sat, Feb 27, 2016 at 12:10 AM, Lasse Schuirmann
 wrote:
> Is there any advantage of having those mirrors after all? Nobody really
> seems to care and I'm against adding a folder to trick a proprietary tool
> into not hurting us. It's read only anyway...
>
> (I have not followed all previous discussions regarding this though.)

About this point, is there any link to discussions which led to this
decision? What was the actual point of having read-only mirrors there?

Jehan

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

Re: Pull request template for github mirror

[Jehan Pagès]

Hello,

Speaking as one of the GIMP developers (which does not mean I speak on
behalf of the GIMP project here, but in my name). I certainly don't
want us to start using github, and actually would not care if we
stopped using it to mirror our repository. As you say yourself, this
is very confusing and probably a lot of people would think that all
these GNOME projects are actually hosted there as upstream, since
nothing tells otherwise by looking at the github page!

BUT if we really have to continue mirror the repos there, I would
personally say that we may as well do it well and add such a file, if
that is all it takes to stop people from creating pull requests.
Isn't there more simply a way to just forbid pull requests? I see we
already don't use the bug tracker nor the wiki. Isn't it possible to
do the same for the pull request UI?

Also another thing I was wondering is: who has the rights to close the
pull requests? On the GIMP project for instance, we have 4 pull
requests: https://github.com/GNOME/gimp/pulls
I have (exceptionnally) pushed one of the commits separately, some
time ago, another is not valid anymore, and the last 2 have also been
made on the bugtracker by this contributor since then. Could someone
with rights on the Github GNOME account close these 4 pull requests?
Thanks.

Jehan


On Fri, Feb 26, 2016 at 11:16 PM, Thomas H.P. Andersen  wrote:
> Hi maintainers,
>
> We have mirrors of git set up at github.com/gnome. Apparently developers are
> mistaking these mirrors as upstream and send pull requests there. Unless the
> maintainers actively keeps an eye on it these pull requests will go
> unnoticed.
>
> One way to deal with this is to add a pull request template to github
> telling the user that this is not the correct place for submitting patches
> and a link to the relevant bugzilla page.
>
> The way to add a pull request template is by creating a file
> .github/PULL_REQUEST_TEMPLATE in the repository. As the repos on github are
> just mirrors such a file would have to go into upstream git.
>
> I volunteer to create template files for all our mirrored repositories if
> there is interest. I understand that adding these files upstream may be
> controversial, but I think that being visible on github is helpful to new
> developers, and this could be a way to avoid those lost patches.
>
> Tell me what you think.
>
> - Thomas
>
> ___
> 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: Pull request template for github mirror

[Jehan Pagès]

Hi,

On Sat, Feb 27, 2016 at 12:30 AM, Alberto Ruiz  wrote:
> Perhaps I should jump in as I created the mirror alongside Andrea Veri.
>
> The mirror in general is quite useful, a lot of people fork projects and
> check them out automatically instead of checking them out from git.gnome.org
> and then pushing them in github. These contributions (there's about 200 pull
> requests, see link below) would likely not have happened if we didn't have a
> presence in Github. Shutting down the mirror would simply stop that energy.
>
> https://github.com/search?utf8=%E2%9C%93=type%3Apull+user%3Agnome+state%3Aopen

Ok.

> I do know it is not ideal to have unattended contributions, mind though,
> GitHub won't allow an option for disabling Pull Requests even though we
> asked for it. And I committed to not allow usage of PRs since we don't want
> to rely on a closed service for our operations.
>
> As per Thomas suggestion I think it's an overkill to modify every single
> repo. The real solution is to finish this script/hook that would find the
> right bugzilla product URL in the .doap file and create a bug in bugzilla
> automatically for the user. If we were able to then allow logins from
> github's OAuth into our bugzilla instance that'd be great as it would reduce
> friction.

If that means just creating a bugzilla ticket with the patch attached,
and closing the pull request, the problem is that we lose discussion
with the contributor. Even though we would add a message on the pull
request basically saying "we opened a bug report at this address,
please continue the discussion there", I noticed that many people who
would use github rather than the project's prefered method of
contribution (GNOME's bugzilla in our case) are simply reluctant on
creating a new account for some reason (as though they did not have to
do so for github, but somehow they consider this one a given). So we
could not ask them to modify the patch, etc. Basically I would be a
little scared we end up with tickets where the contributor never
answer to our patch modification requests, and we never close the
report nonetheless because the original proposition still made sense
(just quality, code logics, or whatnot are not acceptable just yet to
be merged in our tree). Basically more ghost bug reports. We already
have a lot of these on the GIMP project.

If that means "syncing" the github pull request and the bugzilla
ticket, as Lasse suggests, that's a little more useful, since we can
still have a dialog with the contributor without having him to create
an account. But in such a case, we should still make sure that
contributors understand this is not the prefered way of contributing,
by at least adding a message atop. Indeed the problem of the sync
solution is that we give legitimity to github pull requests. From
contributor's point of view, they become equivalent to making a ticket
on GNOME's bugzilla. So why would they ever make an account upstream?
Moreover how will it be possible to move tickets to another project
now (as far as I know, you cannot "move" a pull request)? Should we
start blocking bugzilla tickets when synced to a github pull request,
and thus limit ourselves to what github decides?
As such, as you say above, we would start "relying on a close service
for our operations".

These look like very difficult implementation decisions if we want to
keep usability (be able to discuss with contributors) while still stay
independent of github repos.

Jehan

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

Fixes for librsvg

[Jehan Pagès]

Hello,

According to librsvg webpage, development discussions about this
library are to be held here.
I am one of the GIMP developer, and we have used librsvg already for
some time. But lately we are working on vectorial icons and I wanted
to use librsvg for icon extraction from a single source file. But I
have had a bunch of issues with it. One of these is that librsvg
returns int dimensions and positions (dimensions actually also have
double values, but these are made out of the int values, which make
them useless. Positions are only int).

I have just uploaded patches for this issue in order to get useful
double values: https://bugzilla.gnome.org/show_bug.cgi?id=762039
Could these be reviewed upon? This would really help me (and GIMP!).
If you tell me these are good, I can push the commits you validate.
Thanks.

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

Re: Proposal to deploy GitLab on gnome.org

[Jehan Pagès]

Hi,

On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon <boche...@daitauha.fr> wrote:
> On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote:
>> IMO this is a completely broken and over-complicated workflow. For
>> long term contributors, having their own remote can be
>> understandable.
>> But for one-time contribs?
>
> One-time contributions can be done entirely in the web UI, for example:

Ok. Sorry but no.
I code in my text editor, not in my browser. And I am not going to
change that. The web GUI has some great stuff that we can't do at this
time on a text editor. Like I cannot review and comment line by line a
patch. So I do it in the browser, out of luck. But that doesn't mean
that I am going to push my workflow and start coding in a browser.
It's nice that it's possible for others, but it should only be used in
very rare cases.

> 1. find the file in the source code you want to modify
> 2. click the "edit" button
> 3. "You don't have permission to edit this file. Try forking this
> project to edit the file." -> click the "fork" button
> 4. you get presented with a web-based editor for the file you wanted to
> edit, in your fork, do your changes, write a commit message, click
> "commit changes"
> 5. this **automatically** opens a form to create a merge request, you
> can just submit it
>
> For one-time contributions, this is a **much** simpler workflow than
> cloning the repository, making the changes, committing the change,
> making a patch, then sending the patch by email/bugzilla. It even
> enables non-technical people to contribute!

Well much simpler for developers who like to push buttons. We are many
who don't like this. Let's not generalize!

Also such patches are acceptable for very simple stuff. For instance
typo fixes, or string fixes, or similar. But other than this, even
one-liners of actual code, I don't want to encourage people who do
things without actually testing (and expecting us to test for them).

When I do a fix to a code, even if it's my code, even if it's a very
simple code and I'm like 100% sure that it's good, I compile (when on
compiled code) and run the code to test if that does what I expected
and did not bring undesirable side effects that I failed to foresee.
This is also the minimum I expect from contributors to a code I
maintain.

So in the end, this feature of editing and pushing everything on the
web GUI should be used very rarely.

> And if I send you a patch, you might find it easier to test it locally.
> But that completely bypasses your pre-merge CI.

CI test basic stuff like "it builds", and "the tests don't fail". But
there is much more in a patch than this. There is code logics. Yes I
test contributed patches locally after the first visual check of the
diff. I assume/hope others do the same.

Of course, you could say that the tests should include every case. But
the fact is that if there is a bug that was not seen before, that
probably means there is no tests for it (otherwise we'd have seen
it!). Even if we add a test, then we have to check first that the test
is fine by building locally. Back to square 1. Also in reality,
everyone knows that tests cannot possibly test each and every piece of
a code, especially in a project as big as GIMP.

So it's not that I find it "easier", it's that I find it totally
complementary and non-optional.

Jehan

> With a pull-request, your CI can run **before** merging any change,
> which means you can try and keep master always building and with
> passing tests.
>
>
> --
> Mathieu



-- 
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

Re: Proposal to deploy GitLab on gnome.org

[Jehan Pagès]

Hi,

On Wed, May 17, 2017 at 5:59 PM, Mathieu Bridon <boche...@daitauha.fr> wrote:
> On Wed, 2017-05-17 at 17:44 +0200, Jehan Pagès wrote:
>> On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon <boche...@daitauha.fr
>> > wrote:
>> > On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote:
>> > > IMO this is a completely broken and over-complicated workflow.
>> > > For
>> > > long term contributors, having their own remote can be
>> > > understandable.
>> > > But for one-time contribs?
>> >
>> > One-time contributions can be done entirely in the web UI, for
>> > example:
>>
>> Ok. Sorry but no.
>> I code in my text editor, not in my browser.
>
> That's fine, me too.
>
> But you're not a one-time contributor to GNOME, are you?

GNOME is a lot of projects. I have been a one-time contributor to
several GNOME projects and will likely continue to do so for the same
or other projects. Even though I have a GNOME git account, I
(obviously) don't push to random projects which never heard of me. I
am still going through the normal bugzilla procedure and will continue
to go through the normal gitlab procedure if the migration is done.

> Remember that I'm responding to your thread about how the fork+merge-
> request workflow is too complex for trivial one-time contributions.
>
>> > For one-time contributions, this is a **much** simpler workflow
>> > than cloning the repository, making the changes, committing the
>> > change, making a patch, then sending the patch by email/bugzilla.
>> > It even enables non-technical people to contribute!
>>
>> Well much simpler for developers who like to push buttons. We are
>> many who don't like this. Let's not generalize!
>>
>> Also such patches are acceptable for very simple stuff. For instance
>> typo fixes, or string fixes, or similar.
>
> Well yes, that's exactly what this thread was about: simple one-time
> contribution that are so trivial that they make the fork+merge-request
> workflow prohibitive.

Since I kind of started the discussion on this topic, it's good to
assume I know what it is about. I never discussed about trivial
contributions, and I don't think to remember anyone else discussing on
this topic as an answer to my emails.

So no, the discussion was on the contribution workflow (for people who
don't push directly, but will make bug reports/merge
requests/patches/etc. Most of them being one-time contributors).

>> But other than this, even
>> one-liners of actual code, I don't want to encourage people who do
>> things without actually testing (and expecting us to test for them).
>
> That's why you have a CI that runs before merging.
>
>> > And if I send you a patch, you might find it easier to test it
>> > locally. But that completely bypasses your pre-merge CI.
>>
>> CI test basic stuff like "it builds", and "the tests don't fail". But
>> there is much more in a patch than this.
>
> A CI can do pretty much anything you want it to, it's not limited to
> "basic stuff" at all.

Yes you can do tests for a lot of things. Anything is scriptable. It
doesn't mean that everything is scripted in tests. Otherwise software
who succeed all the tests would have no bugs by definition.
So we still need to test many things manually.

>> Of course, you could say that the tests should include every case.
>> But the fact is that if there is a bug that was not seen before, that
>> probably means there is no tests for it (otherwise we'd have seen
>> it!). Even if we add a test, then we have to check first that the
>> test is fine by building locally. Back to square 1.
>
> And the person doing that is not the one-time contributor, but you, the
> maintainer.

Yes, which is why I say that I still test the patches locally before
pushing and don't rely only on CI.

> Seriously, you started complaining that the fork+clone is too complex
> for trivial one-time contributions, and now you've completely changed
> the goal-posts, complaining how the wokflow that was specifically
> designed for trivial one-time contributions doesn't allow bigger
> changes.

Once again, I was not speaking about trivial changes. Quite the
opposite since we were discussing about the issue of rebuilding a
tree, what happens on timestamps when you checkout a branch based on
older code, etc.

Also yes, sometimes the discussions evolve anyway. That's how
discussions work. Someone says something, that makes someone else say
something related but different, and so on. Fortunately. That would be
very boring if we were to discuss on the exact same point of detail
for 10 emails.

> Seriously, you started complaining […] complai

Re: Proposal to deploy GitLab on gnome.org

[Jehan Pagès]

Hi,

On Wed, May 17, 2017 at 1:23 PM, Christoph Reiter
<reiter.christ...@gmail.com> wrote:
> On Wed, May 17, 2017 at 12:47 PM, Jehan Pagès
> <jehan.marmott...@gmail.com> wrote:
>> 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.
>
> In case you didn't know, just like with github you can fetch the PRs
> from the main remote if you adjust the git config accordingly:
> https://docs.gitlab.com/ce/user/project/merge_requests/#checkout-merge-requests-locally
>
> $ git fetch
> $ git branch -a # look for PR branch
> $ git checkout origin/merge-requests/42
> $ git checkout master

I didn't know about this. That is indeed not too bad. I would still
cherry-pick the merge-requests commits into my current branch so that
the next make does not try to rebuild too much and for me not to waste
20 minutes. But that's still a good feature.

Jehan

-- 
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

Re: Proposal to deploy GitLab on gnome.org

[Jehan Pagès]

Hi,

On Wed, May 17, 2017 at 11:33 AM, Sébastien Wilmet <swil...@gnome.org> wrote:
> On Wed, May 17, 2017 at 01:42:15AM +0200, Jehan Pagès wrote:
>> Github/gitlab wants to force you to fork the project into a public
>> repository on your private account so that you can make a pull
>> request. This is seriously stupid IMO and very poor workflow. That's
>> the reason why github/gitlab is absolutely littered with useless
>> repositories containing absolutely no difference with the upstream
>> repository (except they are outdated since the person didn't touch it
>> for months). I'm sure trash "fork" repositories are the majority of
>> github/gitlab contents.
>
> Once your commit is merged upstream, you can delete your fork repo (but
> yes, maybe the majority of people don't do it).

And I perfectly understand why they don't. They think that maybe they
will finish their patch some day and be able to make a pull request
(since they would usually fork first before actually make their first
commit). They think that they may do another patch some day; so when
this day come, why bother forking again? I would do the same. After
all, it's not my own disk space!

Well if GNOME is fine with hosting thousands of clones of all their
repositories for every one-time committer which comes, I guess it's
ok.

> On GitHub at least it's easy to see if a repo is a fork, with a link to
> the upstream repo.
>
> Most developers are more familiar with the GitHub workflow, I think it's

Most developers who are on github because they discovered public
project contribution there, maybe. So they got used to the only thing
they know. I am absolutely not sure that they are actually more than
all the developers who used saner workflows for years! But I don't
have statistics, so who knows! I may be wrong. ;-)

Now don't take me wrong. I am not fully against the migration. I think
a lot of things would be nice on gitlab. But the workflow part is
horrible IMO. This whole public forking business. I am not asking for
the gitlab dev to change it (or for GNOME to patch gitlab) as a
default. I know that won't happen. I am only asking if we can have
"alternative" support for patches so that the ones who don't want to
fork can go the alternative route. Basically a bug report with a patch
should be considered same as a "merge request".

Also obviously having a git-bz equivalent, as others pointed, would be
very nice.

> an easier workflow than attaching a patch to a bugtracker ticket. Once
> the contributor has pushed a branch on the fork repo, all the rest can
> be done from the web interface by clicking on some buttons.

Assuming you consider than pushing on buttons on a web GUI is "easier"
workflow, you may be right.
As a developer, I spent most of my time in my terminal. The less I get
out of the terminal, the better I feel. I don't want some actions
which didn't need web browser interaction to suddenly need it.

Jehan

> --
> Sébastien



-- 
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

Re: Proposal to deploy GitLab on gnome.org

[Jehan Pagès]

Hi,

On Wed, May 17, 2017 at 12:33 PM, Sébastien Wilmet  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

Re: Proposal to deploy GitLab on gnome.org

[Jehan Pagès]

Hi,

On Wed, May 17, 2017 at 1:49 PM, Sébastien Wilmet  wrote:
> On Wed, May 17, 2017 at 11:45:26AM +0200, Bastien Nocera wrote:
>> On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote:
>> >
>> 
>> > Most developers are more familiar with the GitHub workflow, I think
>> > it's
>> > an easier workflow than attaching a patch to a bugtracker ticket.
>> > Once
>> > the contributor has pushed a branch on the fork repo, all the rest
>> > can
>> > be done from the web interface by clicking on some buttons.
>>
>> I absolutely hate this workflow, fwiw. I prefer being able to run "git-
>> bz" to both create and apply patches, rather than keeping a clone with
>> a bunch of patches in my own org, or remembering the commands to push a
>> repo to my own repo from the upstream clone.
>>
>> I hope there will be a git-bz equivalent available.
>
> By attaching a patch to a bugtracker ticket, we loose the information of
> the parent commit: where the commit has been initially created in the
> git history.
>
> I've already had the problem that git-bz apply fails (there was a
> conflict), while git was able to resolve automatically the conflict when
> rebasing the branch.

Right. Patches are not a perfect workflow either. It's just nice and simple.

Another problem of patches is that the email in it is not validated
(it's just a text file). I don't think this has ever been a problem
for us, but still theoretically: will gitlab validate contributor's
email and make sure the email in the commit are the same as the one
they validated in their profile? I assume it will do this, just
checking. Because it would be good for minimal author check.

Jehan

> --
> Sébastien



-- 
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

Re: Proposal to deploy GitLab on gnome.org

[Jehan Pagès]

Hi,

On Wed, May 17, 2017 at 1:59 PM, Bastien Nocera <had...@hadess.net> wrote:
> On Wed, 2017-05-17 at 13:54 +0200, Jehan Pagès wrote:
>> Hi,
>>
>> On Wed, May 17, 2017 at 1:49 PM, Sébastien Wilmet <swil...@gnome.org>
>> wrote:
>> > On Wed, May 17, 2017 at 11:45:26AM +0200, Bastien Nocera wrote:
>> > > On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote:
>> > > >
>> > >
>> > > 
>> > > > Most developers are more familiar with the GitHub workflow, I
>> > > > think
>> > > > it's
>> > > > an easier workflow than attaching a patch to a bugtracker
>> > > > ticket.
>> > > > Once
>> > > > the contributor has pushed a branch on the fork repo, all the
>> > > > rest
>> > > > can
>> > > > be done from the web interface by clicking on some buttons.
>> > >
>> > > I absolutely hate this workflow, fwiw. I prefer being able to run
>> > > "git-
>> > > bz" to both create and apply patches, rather than keeping a clone
>> > > with
>> > > a bunch of patches in my own org, or remembering the commands to
>> > > push a
>> > > repo to my own repo from the upstream clone.
>> > >
>> > > I hope there will be a git-bz equivalent available.
>> >
>> > By attaching a patch to a bugtracker ticket, we loose the
>> > information of
>> > the parent commit: where the commit has been initially created in
>> > the
>> > git history.
>> >
>> > I've already had the problem that git-bz apply fails (there was a
>> > conflict), while git was able to resolve automatically the conflict
>> > when
>> > rebasing the branch.
>>
>> Right. Patches are not a perfect workflow either. It's just nice and
>> simple.
>>
>> Another problem of patches is that the email in it is not validated
>> (it's just a text file). I don't think this has ever been a problem
>> for us, but still theoretically: will gitlab validate contributor's
>> email and make sure the email in the commit are the same as the one
>> they validated in their profile? I assume it will do this, just
>> checking. Because it would be good for minimal author check.
>
> That'd be broken. I wouldn't want to use the same email for the
> bug/issue tracker and the code I commit. It also wouldn't work for
> folks who want to use personal/work mail depending on the area of
> contribution, or file pull requests with non-GNOME contributors.

Often these kind of web software allow you to register several emails.
Can't gitlab do this?

Anyway that's just a detail. Previous workflows were already broken on
this topic anyway. I just know that this is one of the problem
(reliability of authorship and contact) of patch files on bug trackers
and I was wondering if gitlab would fix it. Apparently not.

Jehan

-- 
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

Re: Proposal to deploy GitLab on gnome.org

[Jehan Pagès]

Hi,

On Wed, May 17, 2017 at 1:05 PM, Carlos Soriano  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 ,
> desktop-devel-list 
>
> Hi,
>
> On Wed, May 17, 2017 at 12:33 PM, Sébastien Wilmet 
> 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

Re: Proposal to deploy GitLab on gnome.org

[Jehan Pagès]

Hi,

On Wed, May 17, 2017 at 2:10 PM, Bastien Nocera  wrote:
> On Wed, 2017-05-17 at 06:36 -0400, Carlos Soriano via desktop-devel-
> list wrote:
>> Do you mean you don't like the extra step that is clicking once per
>> issue the "create merge request" button?
>
> I don't like the fact that the bug report and the merge request are
> separate.

I don't like this either. This just makes no sense.

Very often a bug report could become a merge request (someone — either
the original bug reporter or someone else — could bring a patch later)
or a merge request could become a bug report (if the original patch is
not right; yet the bug actually exists, we acknowledge it and don't
want to just get rid of the report because we would forget about the
bug). In other words, they are the same things. A "merge request" is
simply a bug report where a patch has been proposed. I don't
understand why they had to make 2 concepts.

I didn't mention it earlier because I imagined that would never change
anyway and I would just have to live with this strange separation.
Gitlab just obviously tries to do the same as github here. But since
you mention it. Yeah I also think this is a completely broken
workflow.

Jehan


-- 
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

Re: Proposal to deploy GitLab on gnome.org

[Jehan Pagès]

Hi,

On Wed, May 17, 2017 at 2:44 PM, Carlos Soriano  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.marmott...@gmail.com
> To: Carlos Soriano 
> desktop-devel-list 
>
> Hi,
>
> On Wed, May 17, 2017 at 1:50 PM, Carlos Soriano 
> 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.marmott...@gmail.com
>> To: Carlos Soriano 
>> desktop-devel-list 
>>
>> Hi,
>>
>> On Wed, May 17, 2017 at 1:05 PM, Carlos Soriano 
>> 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 

Re: Proposal to deploy GitLab on gnome.org

[Jehan Pagès]

Hi,

On Wed, May 17, 2017 at 4:30 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Wed, May 17, 2017 at 04:25:09PM +0200, Jehan Pagčs wrote:
>> Hi,
>>
>> On Wed, May 17, 2017 at 2:44 PM, Carlos Soriano  
>> 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).
>
> 'git cherry-pick ..branch' ?

That's what I said I would likely do indeed a few emails ago. :P
But I was answering about the problems of rebasing for timestamp as an
alternative.

cherry-pick still has a problem though. Unless the patch is trivial
and looks like it's totally good from reading the diff (I would still
do a quick build just to be sure), I don't really like to work on
master with commits. You never know, some day, just a reflex, you git
push… Hopefully it has never happened, but still. That's like working
on a production server.

That's why I like to work on master (so that I don't checkout outdated
branches and have long builds), but with git apply as a first step.

Jehan

> Zbyszek
>
>> 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.



-- 
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

Re: Proposal to deploy GitLab on gnome.org

[Jehan Pagès]

Hi,

On Wed, May 17, 2017 at 3:55 PM, Bastien Nocera  wrote:
> On Wed, 2017-05-17 at 08:50 -0400, Carlos Soriano wrote:
>> >  Original Message 
>> > Subject: Re: Proposal to deploy GitLab on gnome.org
>> > Local Time: May 17, 2017 2:10 PM
>> > UTC Time: May 17, 2017 12:10 PM
>> > From: had...@hadess.net
>> > To: Carlos Soriano 
>> > desktop-devel-list@gnome.org 
>> >
>> > On Wed, 2017-05-17 at 06:36 -0400, Carlos Soriano via desktop-
>> > devel-
>> > list wrote:
>> > > Hey Bastien,
>> > >
>> > > Not sure if you read the wiki and the workflow we outlined in
>> > there,
>> > > since we mention how this works. You will realize that's not
>> > > necessary for you, neither a git-bz alternative since you will
>> > use
>> > > just git:
>> > > - git-bz apply equals to git checkout remoteBranch
>> >
>> > No, it doesn't. git-bz apply on a master or version branch will
>> > allow
>> > me to amend commits. It does everything but push. The above doesn't
>> > allow me to apply the same set of patches to a development and a
>> > stable
>> > branch for example.
>>
>> Doesn't git rebase do precisely this?
>
> I don't quite understand the workflow for users to create merge
> requests with patches added, compared to my experiences with GitHub for
> example, so bear with me.
>
> If I'm a registered developer for the GNOME org, or that particular
> module, I'd create my merge requests as wip branches in the main
> repo?Or as branches in a separate repo that I have the control of?
>
> What about developers that don't have GNOME commit access? Do they
> fork, play in their corners and then create a merge request?

The typical workflow as advised by github (and therefore I believe
that's similar in gitlab), if not mistaken, is:

1/ clone the repo you want to fix into a new public remote by clicking
a "fork" button in the web GUI.
  So for instance if your nickname is 'bastien' in git.gnome.org,
let's assume that 'gnome-shell' repo is under
git.gnome.org/git/gnome/gnome-shell, then clicking the button will
create a new remote git.gnome.org/git/bastien/gnome-shell.
  Notice that the origin URL is slightly different from current
(adding gnome/), that's because github/gitlab need are all prefixed
with some kind of project or user namespace (so I guess git.gnome.org
will have to update project URLs with this concept, no?).

2/ Clone your personal repo into a working branch on your computer.

3/ Make your commits and push.

4/ Go back to the web GUI and click the merge request button.

Personally I don't think I ever did this, because I want to checkout a
code before even being sure I would do a patch. Creating a public repo
just to read code is dumb. So I just clone the upstream, and only if I
end up doing a patch, I would only then "fork" on github, then update
my local repository to point to my "fork", so that I can push then
click the "pull request" button. That's still very cumbersome.

IMO this is a completely broken and over-complicated workflow. For
long term contributors, having their own remote can be understandable.
But for one-time contribs?

> Does that
> merge request automatically create a branch in the upstream repo? How
> do we stop merge request spam, or the unbounded growth of the repo with
> all the wip branches, if that's the case?

No. AFAIK, merge requests don't create an upstream branch. Fortunately
this would be a very bad security issue!

Jehan

>> > > - git-bz attach equals to git push origin HEAD:fix2340issue, then
>> > > click create merge request.
>> >
>> > Does this rewrite the commit message to include the PR or bug
>> > number?
>>
>> No, as written in the wiki you write "Closes: $number" and it will
>> handle things automatically.
>> Of course some addition could be done to do the rewrite.
>
> Right, so that's not automated, and you can't know what to put in the
> commit messages until you've create the merge request. Kind of a
> chicken and egg problem.
>
>> > Do we end up with separate merge requests and bug numbers,
>> > segregating
>> > users and developers? And yes, clicking a button is a problem when
>>
>> Yes. They are different concepts in this tool, which I though it was
>> an improvement. The bug is more about the discussion of what is
>> wanted/motivation/reasoning/design/etc., the merge request is about
>> pure code.
>> Not sure I would frame it as segregating users and developers though.
>
> As Jehan mentions, it is. Users filing bugs look at open issues, most
> of the time, but don't look at merge requests at all.
>
>> > "git-bz file" took care of all the clicky stuff on the command-
>> > line.
>>
>> Right, that can be improved.
>>
>> > > And since you will have access to all projects...not need for
>> > your
>> > > own repo.
>> > >
>> > > Do you mean you don't like the extra step that is clicking once
>> > per
>> > > issue the "create merge request" button?
>> >
>> > I don't like the fact that the 

Re: Proposal to deploy GitLab on gnome.org

[Jehan Pagès]

Hi!

On Wed, May 17, 2017 at 12:27 AM, Carlos Soriano via
desktop-devel-list  wrote:
> Hello Mattias,
>
> Thanks for sharing your thoughs!
>
> Your concern is about using fast forward merge. Yes, we raised this concern
> as the top most important for us, and as we mention in the wiki we have good
> news, GitLab team is willing to strongly consider making fast forward merge
> to CE if GNOME decides to switch to GitLab.
>
> Don't worry much about this one :)

Good to read! This would also be a big problem for GIMP. We are trying
to keep up master commit log as linear as possible, without any merge
commits (it failed sometimes, errors were made!).

One of my other main issues with github/lab is the way it forces you
to fork a project on your personal account so that you can contribute.
Many of my contributions to various projects are one-liners or small
commits (as is the case for many developers). When I do this, I want
to just upload a git formatted patch file (which will also be easy for
the reviewer to test with a `git apply|am`).

Unfortunately gitlab does not allow simple .patch files.If I recall,
you can still upload one but there is no support of it. That's just
considered as a text file. So you don't get the UI for review, etc. It
is not handled the same as there "merge requests".
Well last time I tried. Correct me if I am wrong.

Github/gitlab wants to force you to fork the project into a public
repository on your private account so that you can make a pull
request. This is seriously stupid IMO and very poor workflow. That's
the reason why github/gitlab is absolutely littered with useless
repositories containing absolutely no difference with the upstream
repository (except they are outdated since the person didn't touch it
for months). I'm sure trash "fork" repositories are the majority of
github/gitlab contents.

Could GNOME's gitlab instance make sure that patch files are properly
handled so that contributors are still allowed to upload patches?
Will GNOME's gitlab instance have the same politics on "everything
should be forked one thousand times"?

Jehan

P.S.: apart from this, I am happy that things go forward and I think
gitlab has some great tools for code reviewing, and simpler UI for bug
reporters. But there are some things which really make things
complicated each time I have to contribute to a github or gitlab
project (since gitlab is apparently trying to mimic github on many
core features). This made me not contribute sometimes on some projects
when I thought that the annoyance was worse than the usefulness of my
patch (whereas if I could have just git-formatted a patch, I would
have done it).


> Best regards,
> Carlos Soriano
>
>  Original Message 
> Subject: Re: Proposal to deploy GitLab on gnome.org
> Local Time: May 17, 2017 12:04 AM
> UTC Time: May 16, 2017 10:04 PM
> From: mattias.jc.bengts...@gmail.com
> To: desktop-devel-list@gnome.org
>
> Hi all!
>
> On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote:
>> The outcome of this evaluation process is that we are recommending
>> that GNOME sets up its own GitLab instance, as a replacement for
>> Bugzilla and cgit.
>
> This is very exciting! I've been following the plans on the wiki and
> the discussions in #sysadmin and have been waiting impatiently for you
> to reveal the plans to the public.
>
> As part of my responsibilities at my current work I help maintaining
> our internal GitLab CE instance and from my limited experience,
> updating and maintaining it has been rather easy.
>
> One exciting thing about GitLab is its fast pace of development. New
> releases with new features are coming often.
>
> One question though regarding the GitLab CE merge button:
>
> The merge button in GitLab CE produces (non-ff) merge-commits
> which might be undesirable (the history gets really hard to read
> IMHO). GitLab EE allows you to rebase and/or perform --ff merges
> instead.
>
> At my work we keep a semi-linear git history:
>  - we only allow merges based on the tip of master
>  - we always merge with --no-ff (which is what GitLab's merge
>button does)
>
> This gives us grouping of commits into features, while still
> making sure our history is reasonably easy to follow.
>
> To enforce this with GitLab CE we use a pre-merge CI test that
> tries to perform a fast forward merge, and fails if it can't. We
> then set the merge setting for the repo in question to not allow
> merging MR's with failing CI pipelines.
>
> In GNOME, the most common workflow has been to use a straight
> history without merge-commits + release-branches. This implies making
> a fast-forward merge or a rebase, which means that the above mentioned
> trick won't work with our model.
>
> From my understanding (after reading the workflow description),
> the plan is to just not use the merge-button if you want to keep
> the current merging model.
>
> This is /definitely/ fine by me, the net gain from moving to
> GitLab is still 

Re: Looking for gexiv2 maintainer

[Jehan Pagès via desktop-devel-list]

Hi Jens!

Didn't see this email until today.

On Sun, Aug 29, 2021 at 2:30 AM Jens Georg  wrote:

> Hello,
>
> I am going to give up gexiv2 maintainership, for multiple reasons.
>

Ouch!


> One of them is that I have too many projects, the other one is I don't
> want to work with Exiv2 upstream anymore.
>
> I will do a final 0.14 release for GNOME 41 and than I'll stop caring.
> Sorry about that, but I have to let that go, for my onw personal
> sanity.
>

It's hard, but I understand. You should never give up sanity (or anything
which makes your life nice to live) for a program.

I hope we'll find a nice new maintainer for GExiv2 and I wish you a good
continuation. Thanks for all the past work! And obviously you'd be welcome
if you want to be back (as far as I can say on GIMP behalf at least).

As for Shlomi Fish, one is indeed a nice and useful person going around in
the community for quite a long time. So it's a good start! 

Jehan


> ___
> 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
Liberapay: https://liberapay.com/ZeMarmot/
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