Re: Proposal to deploy GitLab on gnome.org
On Wed, 2017-05-17 at 08:50 -0400, Carlos Soriano via desktop-devel-
list wrote:
[...]
> >
> > > - 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.
This is a point of interest to me.
To clarify:
o Accepting a merge request will automatically close the merge
request and apply the branch with (if enabled) an additional
superficial commit saying MR ${number} was merged.
o If the commit messages say "Closses ${number}" in them, gitlab
will scan this and do automatic things too, iiuc it will close
issues automatically when the merge request is accepted.
In gitlab this automation is quite configurable, so my question is;
will individual project maintainers in GNOME have the power to
configure this how they like for their own modules ?
This is a feature I personally want disabled, closing a bug report is a
manual thing in my mind, a patch itself should not be allowed to
dictate that it closes an issue, although that patch might presume to
do so, someone should stop by and close the issue.
Cheers,
-Tristan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME and Debian usability testing, May 2017
Thought this might be interesting/useful to a wider GNOME audience: Weitergeleitete Nachricht Betreff: GNOME and Debian usability testing, May 2017 Datum: Mon, 15 May 2017 13:10:45 +0200 Von: intrigeri An: Jim Hall , Debian GNOME Maintainers Kopie (CC): more-than-a-...@boum.org Hi Jim & Debian+GNOME people, I guess you'll be interested in this usability testing report: https://people.debian.org/~intrigeri/blog/posts/GNOME_and_Debian_usability_testing_201705/ Let me know if there's anything you'd like me to do with these results so they're as useful as they can be :) Cheers, -- intrigeri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Paperwork / Gnome's dos and don'ts
Howdy! On Wed, May 17, 2017 at 2:57 AM wrote: > > b) Commercialization of Windows portage > > A while ago, I tried to sell the Windows version of Paperwork. It was > based on a 60 days trial > period + activation keys (the code is still visible on GitHub, but it is > disabled). It didn't have > much success at the time, but I still haven't forgotten my dream of being > rich someday ;). I'm > considering re-trying later (I'm thinking of keeping the version N-1 free > and making the version N > commercial). > > Would that be a compatible with being hosted on gnome.org ? > Would that hurt the chances that Paperwork becomes an extra app of Gnome > someday ? > > I would reach out to the board on this particular question. My personal opinion is the GPL does allow you to make money and you would still be compliant with the license. I would do some investigations on a money model around GPL'd software. You might want to talk with Aaron Brockover who wrote Banshee music player. The worry I have is further down the road, and for arguments sake: suppose Paperwork becomes a core application of GNOME there might be some misunderstanding with the community and accusations of bait and switch[1] that we might have to defend at first. So communications around this is very critical here. Because once that misunderstanding occurs, it stays persistent for quite some time. As someone who usually does the defending, I've usually found it a big headache. So this message is partially in my own self interest. :-) Finally, if you're using some of the designs from Allan or other GNOME designers, you would be using their work, time and effort to generate income. Now they might not mind, but you probably want to talk to them up front in regards to compensation (if any). You are also leveraging the GNOME brand here intentionally or not. So these are things that you must work out with the Board of Directors. If you do go down that route, I hope that some portion of the proceeds will be contributed to the GNOME Foundation. I do hope that you succeed. I think it is important for the market for applications if there was a model that succeeded, and that one can make money from copyleft software directly from users. Best, sri [1] - I am not in anyway accusing you of planning a bait-n-switch - just that a semblance of impropriety can start an internet mob going and harm our brand. ___ 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
Hi, On Wed, May 17, 2017 at 5:59 PM, Mathieu Bridon 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 > > 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 […] complaining how […] Please, let's keep it civil. I am not complaining. The whole point of this email thread was to hear members' comments and inputs. So I gave mine. I also explained that I still think it is a good change in many ways, and I listed a few features that I really appreciate in systems like gitlab. But then I also list some of my worries. One of these worries (for me) is about the workflow which is encouraged by gitlab and which I really dislike.
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon wrote: > One-time contributions can be done entirely in the web UI, for example: One-time doesn’t necessarily mean trivial. What you describe is the workflow for a trivial change. One may still want to clone, compile, test locally even for a one-time contribution. > 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! Which is a great thing. That’s not what one-time contribution means though. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Paperwork / Gnome's dos and don'ts
17 mai 2017 18:30 "Debarshi Ray" a écrit: > Hey, > > On Wed, May 17, 2017 at 09:55:15AM +, jfle...@kwain.net wrote: > >> - Libpillowfight (image processing): >> https://github.com/openpaperwork/libpillowfight >> >> In the long term, I will try to replace them by developing alternatives >> based on GObject Introspection. > > For what it is worth, GEGL is a very capable GObject-based image > processing library. > Good point. I wanted specific algorithms (the one in the command-line tool 'unpaper' and SWT for instance), and I couldn't find them in any existing library. I guess now that I have made a first implementation, at some point, I could implement them in GEGL as well (which in turn would bring the benefit of using GPUs). >> But right now, those modules don't use GTK+/Gnome technologies at all >> and therefore don't meet the prerequisites to be hosted on gnome.org[1]. >> >> Even if Paperwork depends on them, I assume I won't be allowed to host >> them on gnome.org, right ? > > The path of least resistance might be to keep them on GitHub for the > time being. Would that be problematic? > Not really actually :-) I was just wondering if keeping everything in one place is an option. But using both hosting is also fine. >> b) Commercialization of Windows portage >> >> A while ago, I tried to sell the Windows version of Paperwork. It was >> based on a 60 days trial period + activation keys (the code is still >> visible on GitHub, but it is disabled). It didn't have much success >> at the time, but I still haven't forgotten my dream of being rich >> someday ;). I'm considering re-trying later (I'm thinking of keeping >> the version N-1 free and making the version N commercial). >> >> Would that be a compatible with being hosted on gnome.org ? > > I would definitely want code using GNOME infrastructure to comply with > the definition of Free Software. ie., it would be fine to charge money > for the Windows build, but once somebody has paid for it she should be > able to (a) run it as they wish (b) study how it works and make > modifications (c) distribute copies, and (d) distribute copies of > their modifications. > > See https://www.gnu.org/philosophy/free-sw.en.html > > The freedom to distribute copies includes both binaries and source > code. > Afaik, what I did (and may do again) do respect the GPLv3. The sources are and were always available (activation mechanism included). I also indicated how to make a Windows build without the evil DRM : https://github.com/openpaperwork/paperwork/blob/unstable/doc/devel.windows.markdown#disabling-the-cruel-and-unusual-drm In that case, the only thing I didn't provide is the private key used to generate the activation keys. I despise Windows, but I love free software. Also Paperwork had many contributions included over time (assuming GPLv3 every time). So it's very important for me to respect the GPLv3 as strictly as possible. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
Le mercredi 17 mai 2017 à 14:55 +, Frederic Crozat a écrit : > Le mer. 17 mai 2017 à 16:02, Ernestas Kulik a > écrit : > > (Attempt no. 2, since Geary hates me) > > > > Hi, > > > > As the current licensing situation in Nautilus is quite > > complicated, I > > and Carlos are planning a move to relicense the entire codebase to > > GPLv3+. > > > > The codebase has files under several licenses: LGPLv2+, GPLv2+ and > > GPLv3+, the latter implicitly making the project be licensed under > > its > > terms, so our options are quite limited here. > > > > The situation wrt extensions is also not entirely clear, as the > > extension library is LGPLv2+ with Nautilus being GPLv2+, which in > > turn > > disallows loading non-free extensions. Given the fact that it is > > not > > meant to be a generic mechanism for loading extensions, I feel like > > relicensing it without much consideration is reasonable. > > I know at least one proprietary extension for Nautilus (integration > with Synology NAS product) and I'm not sure we should prevent > proprietary extensions to be used for Nautilus. You can just mimic Totem exception clause. This is used to allow proprietary GStreamer plugins. https://git.gnome.org/browse/totem/tree/COPYING#n345 regards, Nicolas signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Paperwork / Gnome's dos and don'ts
Hey, On Wed, May 17, 2017 at 09:55:15AM +, jfle...@kwain.net wrote: > - Libpillowfight (image processing): > https://github.com/openpaperwork/libpillowfight > > In the long term, I will try to replace them by developing alternatives > based on GObject Introspection. For what it is worth, GEGL is a very capable GObject-based image processing library. > But right now, those modules don't use GTK+/Gnome technologies at all > and therefore don't meet the prerequisites to be hosted on gnome.org[1]. > > Even if Paperwork depends on them, I assume I won't be allowed to host > them on gnome.org, right ? The path of least resistance might be to keep them on GitHub for the time being. Would that be problematic? > b) Commercialization of Windows portage > > A while ago, I tried to sell the Windows version of Paperwork. It was > based on a 60 days trial period + activation keys (the code is still > visible on GitHub, but it is disabled). It didn't have much success > at the time, but I still haven't forgotten my dream of being rich > someday ;). I'm considering re-trying later (I'm thinking of keeping > the version N-1 free and making the version N commercial). > > Would that be a compatible with being hosted on gnome.org ? I would definitely want code using GNOME infrastructure to comply with the definition of Free Software. ie., it would be fine to charge money for the Windows build, but once somebody has paid for it she should be able to (a) run it as they wish (b) study how it works and make modifications (c) distribute copies, and (d) distribute copies of their modifications. See https://www.gnu.org/philosophy/free-sw.en.html The freedom to distribute copies includes both binaries and source code. Cheers, Rishi ___ 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
On Wed, 2017-05-17 at 17:44 +0200, Jehan Pagès wrote: > On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon > 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? 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. > 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. > 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. 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. -- Mathieu ___ 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
Hi, On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon 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
On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote: > Hi, > […] > The typical workflow as advised by github (and therefore I believe > that's similar in gitlab), if not mistaken, is: Unless you have push privileges, in which case you'd just create a wip- or feature branch and make a merge request. This is what's recommended on the GitLabWorkflows[1] page. > […] 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. For most of us active in this discussion, this won't be an issue since we'll have push privileges (see above). However. What you describe above is how I make drive-by patches on GitHub, and I agree it can be a bit cumbersome. Fortunately there are tools to help you. I use git-spindle[2] which has support for GitHub, GitLab and Bitbucket. The, above manual steps becomes something like this with git-spindle (using graphene as an example repo): $ git hub clone ebassi/graphene && cd graphene $ git checkout -b wip/my-cool-fix [ do some work ] $ git commit -a -m "My awesome fix" $ git hub fork $ git hub pull-request [ Write merge message ] > 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? > With proper tooling, the workflow isn't very complicated at all. And it's definitely not "completely broken" as you suggest. Regards, Mattias 1: https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/GitLabW orkflows 2: https://github.com/seveas/git-spindle ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
On Wed, 2017-05-17 at 11:13 -0400, Carlos Soriano wrote: > There are few by error. > The important cases are lineup-parameters used for uncrustify, and > the threatics part from gnome-builder. > However, we already spent time on implementing our own thing in the > past with git-archive-all (GPLv3+) when meson couldn't handle it, so > I would like to prevent this from happening again and avoid us the > work with asking few upstreams to relicense based on our needs, and > rather switch to GPL3+ where most of the tools are. I don't understand what git-archive-all has to do with this. Is the problem that some of the tools you ship are GPLv3? That doesn't mean the rest of the module has to be... ___ 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
On Wed, May 17, 2017 at 04:36:48PM +0200, Jehan Pagès wrote: > 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. Yeah, I have pushed to master a few times by mistake… Embarrassing *and* permanent ;( There's always git cherry-pick -n. That works as long as the PR has only one commit. Apart from that, I don't think there's a general solution to this problem… You could always play with setting branch.master.pushRemote to your private repo, so that an explicit 'git push origin' is required to actually push. But once you get into the habit of doing that, you're back to square one. So I don't think any automatic solution is possible. > 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. One option is to improve the build system… Gnome is in the process of switching to meson, and meson does much better in this regard. So that might make this issue moot — by the time gitlab is implemented, branching might be cheap again. Zbyszek ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
There are few by error. The important cases are lineup-parameters used for uncrustify, and the threatics part from gnome-builder. However, we already spent time on implementing our own thing in the past with git-archive-all (GPLv3+) when meson couldn't handle it, so I would like to prevent this from happening again and avoid us the work with asking few upstreams to relicense based on our needs, and rather switch to GPL3+ where most of the tools are. Best regards, Carlos Soriano Original Message Subject: Re: Relicensing Nautilus to GPLv3+ Local Time: May 17, 2017 4:59 PM UTC Time: May 17, 2017 2:59 PM From: had...@hadess.net To: Michael Catanzaro Ernestas Kulik , nautilus-l...@gnome.org, desktop-devel-list@gnome.org, release-t...@gnome.org On Wed, 2017-05-17 at 09:45 -0500, Michael Catanzaro wrote: > On Wed, May 17, 2017 at 9:20 AM, Bastien Nocera > wrote: > > If nautilus is GPLv3+, that means we can't link it against GPLv2- > > only > > or LGPLv2-only libraries in the extensions. I'm also not opening > > the > > can of worms that is non-GPL-compatible dependencies of extensions > > (such as proprietary, or patent-encumbered GStreamer plugins), > > because > > that's an existing problem. > > > > What's the end goal for relicensing? What problems do the current > > license cause that require a relicense? > > > > Cheers > > Sounds like the license is already GPLv3+, since it uses GPLv3+ > source > files, and the existing GPLv2+ notices are incorrect or misleading. Were those licenses applied in error, or imported from projects that were GPLv3 themselves? -- nautilus-list mailing list nautilus-l...@gnome.org https://mail.gnome.org/mailman/listinfo/nautilus-list___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
On Wed, 2017-05-17 at 16:20 +0200, Bastien Nocera wrote: > > If nautilus is GPLv3+, that means we can't link it against GPLv2-only > or LGPLv2-only libraries in the extensions. That’s fair. > I'm also not opening the > can of worms that is non-GPL-compatible dependencies of extensions > (such as proprietary, or patent-encumbered GStreamer plugins), because > that's an existing problem. Loading GPL-incompatibly-licensed extensions is already a problem. For all I know, it always was. > What's the end goal for relicensing? What problems do the current > license cause that require a relicense? The end goal here is to announce what has been the case since at least two years ago (sans libnautilus-extension). We’ve got code that is licensed under GPLv3+ and we’ve wanted to use code licensed under GPLv3+, but, ironically, didn’t, because of these issues. Having libnautilus-extension licensed under LGPL makes no sense if the extensions have to be compatible with GPL when loaded. ___ 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
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: 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! And if I send you a patch, you might find it easier to test it locally. But that completely bypasses your pre-merge CI. 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
On Wed, 2017-05-17 at 09:45 -0500, Michael Catanzaro wrote: > On Wed, May 17, 2017 at 9:20 AM, Bastien Nocera > wrote: > > If nautilus is GPLv3+, that means we can't link it against GPLv2- > > only > > or LGPLv2-only libraries in the extensions. I'm also not opening > > the > > can of worms that is non-GPL-compatible dependencies of extensions > > (such as proprietary, or patent-encumbered GStreamer plugins), > > because > > that's an existing problem. > > > > What's the end goal for relicensing? What problems do the current > > license cause that require a relicense? > > > > Cheers > > Sounds like the license is already GPLv3+, since it uses GPLv3+ > source > files, and the existing GPLv2+ notices are incorrect or misleading. Were those licenses applied in error, or imported from projects that were GPLv3 themselves? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
Le mer. 17 mai 2017 à 16:02, Ernestas Kulik a écrit : > (Attempt no. 2, since Geary hates me) > > Hi, > > As the current licensing situation in Nautilus is quite complicated, I > and Carlos are planning a move to relicense the entire codebase to > GPLv3+. > > The codebase has files under several licenses: LGPLv2+, GPLv2+ and > GPLv3+, the latter implicitly making the project be licensed under its > terms, so our options are quite limited here. > > The situation wrt extensions is also not entirely clear, as the > extension library is LGPLv2+ with Nautilus being GPLv2+, which in turn > disallows loading non-free extensions. Given the fact that it is not > meant to be a generic mechanism for loading extensions, I feel like > relicensing it without much consideration is reasonable. > I know at least one proprietary extension for Nautilus (integration with Synology NAS product) and I'm not sure we should prevent proprietary extensions to be used for Nautilus. -- -- Frédéric Crozat ___ 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
On Wed, May 17, 2017 at 4:08 PM Mathieu Bridon wrote: > On Wed, 2017-05-17 at 15:55 +0200, Bastien Nocera wrote: > > > 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. > > The merge request gets automatically closed when you merge it. > > The "Closes #number" is to associate the commit to the corresponding > issue (and have it closed automatically), not the pull request. > Can we please have the full issue URL there, either by convention (as we do now) or enforced by the tooling? In the best case, the raw number is inconvenient when looking up the issue from the commit (outside the web UI): "Select+copy number, switch to browser, go to gitlab.gnome.org, paste number" vs. "click a link". In the worst case it's confusing, because it is unclear what the number refers to - for example the github mirror will likely turn them into links to non-existent issues on github, and if we ever decide to migrate to something else in the future, you need to know which issue tracker was used at the time of the commit. Florian ___ 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
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 bug report and the merge request are >> > separate. >> > >> > > If that's th
Re: Relicensing Nautilus to GPLv3+
On Wed, May 17, 2017 at 9:20 AM, Bastien Nocera wrote: If nautilus is GPLv3+, that means we can't link it against GPLv2-only or LGPLv2-only libraries in the extensions. I'm also not opening the can of worms that is non-GPL-compatible dependencies of extensions (such as proprietary, or patent-encumbered GStreamer plugins), because that's an existing problem. What's the end goal for relicensing? What problems do the current license cause that require a relicense? Cheers Sounds like the license is already GPLv3+, since it uses GPLv3+ source files, and the existing GPLv2+ notices are incorrect or misleading. Michael ___ 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
On Wed, May 17, 2017 at 01:23:43PM +0200, Christoph Reiter wrote:
> On Wed, May 17, 2017 at 12:47 PM, Jehan Pagès
> 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 have the following config (for github):
[alias]
pr-fetch = "!f() { git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1;
}; f"
pr = "!f() { git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1 && git
checkout pr/$1; }; f"
pr-merge = "!f() { git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1
&& git merge pr/$1 --no-ff --edit -m 'Merge pull request #'$1; }; f"
pr-clean = "!git for-each-ref refs/heads/pr/* --format=\"%(refname)\" |
while read ref ; do branch=${ref#refs/heads/} ; git branch -D $branch ; done"
(git pr checks out the PR as a new branch, and git pr-fetch
just creates the new branch but does not check out.)
IIUC, you want to rebase the PR onto your master to do a ff-merge. This should
be
fairly easy to do with 'git cherry-pick ..pr/'.
From another mail:
> 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.
I think there's some confusion as to what git is doing when you switch branches.
All it does is:
1. compare the two trees from the old commit and new commit,
2. write out the files that are different, delete files that are missing from
the new tree.
So it does not touch any files that are identical between two trees.
When git writes out files, it doesn't do anything special, so the os updates
the mtime to "now". This means that the build system will rebuild everything
which has the updated files as deps. How much is rebuilt is depends on the
build system and the changeset... autotools will usually rebuild almost
everything
if configure.ac was touched, but that's an issue with autotools, and git just
dumbly updates the files it is told to. (In particular, whether the commits
you are switching between are from the same remote, or different remotes, or
even from two trees which do not share a common parent — doesn't matter. Only
the SHA1 of the contents is relevant.)
Zbyszek
___
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
On Wed, May 17, 2017 at 2:20 PM Jehan Pagès wrote: > On Wed, May 17, 2017 at 2:10 PM, Bastien Nocera wrote: > > 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. > While I tend to agree, I do see a use case for the separation - multiple pull requests for a single issue, if a fix involves changes to multiple products. We currently often avoid the overhead of cloning the issue, and just attach all patches in the same report (say, a gsettings-desktop-schemas patch and the settings consumer, mutter/gnome-shell). That assumes that whoever applies the patches knows where the different bits go, and linkified commit hashes get messed up for non-matching products. That said, going from a attached-patches-only workflow to a branches+pull-requests-only workflow looks like swapping a toolbox full of hammers for a toolbox full of screwdrivers - the current workflow gets awkward with bigger patch sets, while pull requests add overhead that's fairly pointless when dealing with just a couple of patches (most issues really) ... Florian > ___ 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
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
On Wed, 2017-05-17 at 10:06 -0400, Pat Suwalski wrote: > On 2017-05-16 07:10 PM, Mattias Bengtsson wrote: > > How did you install GitLab? We use the omnibus RPM package for > > CentOS > > and have had no dependency problems while upgrading from some 7.x > > release all the way to 9.1.x over the last few years. A lot come > > bundled in the omnibus package and the rest gets installed from the > > host operating system repositories. > > There's the difference. I don't trust the current omnibus package, so > I install from source. That decision is old, but at the time we > installed, there wasn't an omnibus package. There lies your problem I believe. I'm pretty sure this doesn't apply to GNOME. > A proper package would rely on system libraries only. Shipping software, targeting multiple Linux distributions is hard. > Anyway, this is getting off-topic. Using the only appropriate > install method for this package takes considerable effort. It is. I don't agree that a manual installation from source is "the only appropriate install method". That is a rather extreme position to take and one I'm sure our sysadmins doesn't hold. In short, I don't consider this an issue. Regards, Mattias ___ 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
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' ? 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. ___ 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
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 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
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 01:49:21PM +0200, Sébastien Wilmet wrote: > 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. If the patch is created by git format-patch, it contains the hash of the parent, so git knows the original parent. > 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. 'git am -3' is the same as a rebase. Zbyszek ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
On Wed, 2017-05-17 at 17:01 +0300, Ernestas Kulik wrote: > (Attempt no. 2, since Geary hates me) > > Hi, > > As the current licensing situation in Nautilus is quite complicated, > I > and Carlos are planning a move to relicense the entire codebase to > GPLv3+. > > The codebase has files under several licenses: LGPLv2+, GPLv2+ and > GPLv3+, the latter implicitly making the project be licensed under > its > terms, so our options are quite limited here. > > The situation wrt extensions is also not entirely clear, as the > extension library is LGPLv2+ with Nautilus being GPLv2+, which in > turn > disallows loading non-free extensions. Given the fact that it is not > meant to be a generic mechanism for loading extensions, I feel like > relicensing it without much consideration is reasonable. If nautilus is GPLv3+, that means we can't link it against GPLv2-only or LGPLv2-only libraries in the extensions. I'm also not opening the can of worms that is non-GPL-compatible dependencies of extensions (such as proprietary, or patent-encumbered GStreamer plugins), because that's an existing problem. What's the end goal for relicensing? What problems do the current license cause that require a relicense? Cheers ___ 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
On Wed, 2017-05-17 at 15:55 +0200, Bastien Nocera wrote: > 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? That would be up to you. Choose whichever you prefer? > What about developers that don't have GNOME commit access? Do they > fork, play in their corners and then create a merge request? Yes. > Does that merge request automatically create a branch in the upstream > repo? No. However the merge requests get added as refs in the remote git repo, so you can fetch them locally: https://docs.gitlab.com/ce/user/project/merge_requests/index.html#check out-locally-by-modifying-git-config-for-a-given-repository Alternatively, you can add a remote pointing to the fork, then fetch that to get the branch to merge. > > > > - 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. The merge request gets automatically closed when you merge it. The "Closes #number" is to associate the commit to the corresponding issue (and have it closed automatically), not the pull request. > > > 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. Searching in a repo will give results both in the code, the issues, the merge requests, the wiki, ... -- Mathieu ___ 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
On 2017-05-16 07:10 PM, Mattias Bengtsson wrote: How did you install GitLab? We use the omnibus RPM package for CentOS and have had no dependency problems while upgrading from some 7.x release all the way to 9.1.x over the last few years. A lot come bundled in the omnibus package and the rest gets installed from the host operating system repositories. There's the difference. I don't trust the current omnibus package, so I install from source. That decision is old, but at the time we installed, there wasn't an omnibus package. In general, IMO it's not appropriate to run whatever random libraries they threw into their package. It's very large, and if you don't use the host specifically for gitlab, it gets tricky using it with port 80 and 443 with Apache. A proper package would rely on system libraries only. Could it be that Debian stable is just very old? I think it's proper to expect at least a 3 year lifecycle out of software that runs on a server, no? Can you imagine if Windows Server 2012 was considered too old for a package equivalent to Gitlab? That just wouldn't happen. Anyway, this is getting off-topic. Using the only appropriate install method for this package takes considerable effort. --Pat ___ 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
On Wed, 2017-05-17 at 15:55 +0200, 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? 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? The workflow page is hidden inside the conclusion on the original page that was posted: https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/GitLabWorkflows So it's unbounded growth as the merge request branches are created in the upstream repo. > Do you have a link to the tool and its documentation? There's nothing > in the Wiki linking to it, it just says "a tool exists". The tool is also linked from that page: https://github.com/NARKOZ/gitlab/ FWIW, we should get to a point where I don't need to open my browser to manage a merge request. I do this quite often directly from my bug mail to the terminal, copying the bug URL and appending it to git-bz. I don't think that anything else should be required, and most of it should be automated. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Relicensing Nautilus to GPLv3+
(Attempt no. 2, since Geary hates me) Hi, As the current licensing situation in Nautilus is quite complicated, I and Carlos are planning a move to relicense the entire codebase to GPLv3+. The codebase has files under several licenses: LGPLv2+, GPLv2+ and GPLv3+, the latter implicitly making the project be licensed under its terms, so our options are quite limited here. The situation wrt extensions is also not entirely clear, as the extension library is LGPLv2+ with Nautilus being GPLv2+, which in turn disallows loading non-free extensions. Given the fact that it is not meant to be a generic mechanism for loading extensions, I feel like relicensing it without much consideration is reasonable. If there are no objections, we will make the switch in the following week, most likely. Regards, Ernestas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Relicensing Nautilus as GPLv3+
Hi, Nautilus has been implicitly licensed under GPLv3 for the last couple of years, since some sources ___ 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
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? 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? > > > - 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 bug report and the merge request are > > separate. > > > > > If that's the case, why is the command line tool we mention in > > the > > > wiki not good for you? (you will need some alias for adapting it > > to > > > your needs, or maybe we can modify to make the "create merge > > request" > > > more comprehensible?) > > > > The only mention of a command-line tool says: > > "There is a CLI tool which allows a wide range of actions to be > > done > > from the command line, although it isn't particularly user > > friendly." > > which is a bit low on details to allow me to comment on it. > > It's rather vague, I agree. But you can explore it yourself, the > readme of the project is quite explanation. But I'm afraid is not up > to the expectations you have as it is right now. Would be good to > improve this of course. Do you have a link to the tool and its documentation? There's nothing in the Wiki linking to it, it just says "a tool exists". ___ 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
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? > - 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. 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. "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 bug report and the merge request are separate. > If that's the case, why is the command line tool we mention in the > wiki not good for you? (you will need some alias for adapting it to > your needs, or maybe we can modify to make the "create merge request" > more comprehensible?) The only mention of a command-line tool says: "There is a CLI tool which allows a wide range of actions to be done from the command line, although it isn't particularly user friendly." which is a bit low on details to allow me to comment on it. It's rather vague, I agree. But you can explore it yourself, the readme of the project is quite explanation. But I'm afraid is not up to the expectations you have as it is right now. Would be good to improve this of course.___ 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
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? 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 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
Re: Proposal to deploy GitLab on gnome.org
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
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. > - 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? Do we end up with separate merge requests and bug numbers, segregating users and developers? And yes, clicking a button is a problem when "git-bz file" took care of all the clicky stuff on the command-line. > 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 bug report and the merge request are separate. > If that's the case, why is the command line tool we mention in the > wiki not good for you? (you will need some alias for adapting it to > your needs, or maybe we can modify to make the "create merge request" > more comprehensible?) The only mention of a command-line tool says: "There is a CLI tool which allows a wide range of actions to be done from the command line, although it isn't particularly user friendly." which is a bit low on details to allow me to comment on it. ___ 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
Hi, On Wed, May 17, 2017 at 1:59 PM, Bastien Nocera 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 >> 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
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 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 > >>
Re: Proposal to deploy GitLab on gnome.org
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 > 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. ___ 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
On Wed, 2017-05-17 at 13:49 +0200, 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. That's unsurprising. Presumably, the patch provider can easily rebase, as one probably should in case of conflict anyway. I don't see the gain here. ___ 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
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
Hi
> On 17 May 2017, at 12:33, 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.
>
in github you can setup “hooks" and make it close bugzilla bugs when referenced
in a commit message ("Fixes bug #12345") merged to master, so I guess gitlab
should have something similar.
Not that I like bugzilla :), but it’s true the issues thing in github and, I
guess, gitlab seem to be very basic compared to what you can do in bugzilla.
Rodrigo
___
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
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. 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)? 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 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'v
Re: Proposal to deploy GitLab on gnome.org
Hi, On Wed, May 17, 2017 at 1:23 PM, Christoph Reiter wrote: > On Wed, May 17, 2017 at 12:47 PM, Jehan Pagès > 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
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. -- Sébastien ___ 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
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 > IMO. One gets lost in all these bz options. Simplicity is good > sometimes. :-) > gitlab has cool features t
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 12:47 PM, Jehan Pagès 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 ___ 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
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 for fetching a remote being inconvenient? Is it because it takes considerably more time to fetch a repo than download and applying a patch? 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 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___ 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
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
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 - git-bz attach equals to git push origin HEAD:fix2340issue, then click create merge request. 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? If that's the case, why is the command line tool we mention in the wiki not good for you? (you will need some alias for adapting it to your needs, or maybe we can modify to make the "create merge request" more comprehensible?) Best regards, Carlos Soriano Original Message Subject: Re: Proposal to deploy GitLab on gnome.org Local Time: May 17, 2017 11:45 AM UTC Time: May 17, 2017 9:45 AM From: had...@hadess.net To: Sébastien Wilmet , Jehan Pagès desktop-devel-list@gnome.org 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. ___ 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: Proposal to deploy GitLab on gnome.org
Hi, On Wed, May 17, 2017 at 11:33 AM, Sébastien Wilmet 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
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). -- Sébastien ___ 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
On 17 May 2017 at 13:56, Carlos Soriano wrote: > Hey Arun, > > Glad to hear you are positive about the proposal! > > Let me answer your points: > > Original Message > Subject: Re: Proposal to deploy GitLab on gnome.org > Local Time: May 17, 2017 7:32 AM > UTC Time: May 17, 2017 5:32 AM > From: a...@accosted.net > To: Carlos Soriano > desktop-devel-list@gnome.org > > On 17 May 2017 at 03:57, 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 :) > > Thank you for taking this up. While I share some concerns voiced on > this thread, overall, I think it is a good thing for us to be trying > to move to tools that make our lives easier as well as lower the bar > for new contributors who are used to the Github-esque workflow. > > My first note to folks who are concerned about GitLab being an evil > semi-closed project would be to look at the repository at > https://gitlab.com/gitlab-org/gitlab-ce -- having shared these > concerns in the past, I feel a lot more positive looking at degree to > which external contributions are encouraged. > > > Yes, as mentioned in a different thread, more than 50% is by community. > Of course we had the same concerns in the past But then we explored the tool > and the team more, realized that in the CE repo there ara quite a lot of > non-gitlab contributions, read more about them and their actions in the past > (like moving EE features to CE based on user input), and talked with them. > Now we are pretty confident about it. > > > The things I worry about are the features that are in the EE and not > in CE that I think will be important for us either now, or down the > line: > > * Git hooks -- either admins with file system access need to manage > these for projects because the web interface to do this is EE-only > > > This is not a problem really. We were doing it already with Bugzilla/cgit. > > > * Automatic rebase for fast forward commits -- Carlos mentioned that > this might be something that'll just be part of the CE > > > Yes, no worries about this one. > > > * Single-sign-on with the remaining GNOME account infra -- maybe this > will just be something we'll have to maintain ourselves > > > Care to expand? You mean using the gnome account to login? If so, that's > already possible. I looked at the LDAP support item in the CE vs. EE page, but if it's solved already, that's awesome. > * Issue templates -- again, this seems like a basic feature for this > kind of platform so we can get more meaningful bug reports to start > with > > > This is on CE. > https://docs.gitlab.com/ce/user/project/description_templates.html > You might remembered from the past, before 8.1, when it was EE. > Test our gitlab test instance as outlined in the wiki so you know what's the > current status of the tool, since it changed and added quite a few things in > the last months that otherwise we would have ponder much more if it makes > sense for us. I was looking at the CE vs. EE page -- I guess that needs to be updated. > * Multiple issue boards per project -- I haven't used the issue > boards yet, but this seemed like a rather artificial limitation rather > than an actual feature differentiated in EE > > > Not sure how this is necessary for us, compared to what we have in Bugzilla. > Of course this would be useful, but the frame of the problem is more about > what we have now vs what we could have. > > > Other than the hooks which might be an immediate concern, I guess the > rest of these aren't a step down from where we are, so if we have an > idea of how to deal with these in the future, that's good enough. > > > Template issues and ff merge would have been a step down. Not sure template > issues would have been extremely important, but still. But as mentioned, > template issues in is CE since a few months ago, and fast forward merge > shouldn't worry you :) Well, that's two more thumbs up from me, then. :-) -- Arun ___ 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
On Wed, May 17, 2017 at 3:15 PM, 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. I would love a git-bz equivalent for this so I can use it for the projects I contribute to on GitHub ;) This reminds me, does GitLab allow you to review the commit message of a patch or series of patches or does it hide it away like GitHub does? I often forget to review the syntax and content of the commit message because of this on GitHub, and this is probably quite important for GNOME projects. Cheers, Nirbheek ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Paperwork / Gnome's dos and don'ts
Hello, As discussed in a previous thread, I am interested in hosting Paperwork ( https://github.com/openpaperwork/paperwork ) on gnome.org. I got no objection from the other contributors, so I assume they are all fine with that. However, before making the move, I would need some clarifications on what is allowed and what is not. a) Non-Gnome components While developing Paperwork, I made various Python modules for it: - PyOCR (OCR tools wrapper): https://github.com/openpaperwork/pyocr - PyInsane (scanner access): https://github.com/openpaperwork/pyinsane - Libpillowfight (image processing): https://github.com/openpaperwork/libpillowfight In the long term, I will try to replace them by developing alternatives based on GObject Introspection. But right now, those modules don't use GTK+/Gnome technologies at all and therefore don't meet the prerequisites to be hosted on gnome.org[1]. Even if Paperwork depends on them, I assume I won't be allowed to host them on gnome.org, right ? b) Commercialization of Windows portage A while ago, I tried to sell the Windows version of Paperwork. It was based on a 60 days trial period + activation keys (the code is still visible on GitHub, but it is disabled). It didn't have much success at the time, but I still haven't forgotten my dream of being rich someday ;). I'm considering re-trying later (I'm thinking of keeping the version N-1 free and making the version N commercial). Would that be a compatible with being hosted on gnome.org ? Would that hurt the chances that Paperwork becomes an extra app of Gnome someday ? Best regards, -- [1] https://wiki.gnome.org/Projects/Prerequisites ___ 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
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. ___ 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
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). 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 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. -- Sébastien ___ 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
Hey Arun, Glad to hear you are positive about the proposal! Let me answer your points: Original Message Subject: Re: Proposal to deploy GitLab on gnome.org Local Time: May 17, 2017 7:32 AM UTC Time: May 17, 2017 5:32 AM From: a...@accosted.net To: Carlos Soriano desktop-devel-list@gnome.org On 17 May 2017 at 03:57, 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 :) Thank you for taking this up. While I share some concerns voiced on this thread, overall, I think it is a good thing for us to be trying to move to tools that make our lives easier as well as lower the bar for new contributors who are used to the Github-esque workflow. My first note to folks who are concerned about GitLab being an evil semi-closed project would be to look at the repository at https://gitlab.com/gitlab-org/gitlab-ce -- having shared these concerns in the past, I feel a lot more positive looking at degree to which external contributions are encouraged. Yes, as mentioned in a different thread, more than 50% is by community. Of course we had the same concerns in the past But then we explored the tool and the team more, realized that in the CE repo there ara quite a lot of non-gitlab contributions, read more about them and their actions in the past (like moving EE features to CE based on user input), and talked with them. Now we are pretty confident about it. The things I worry about are the features that are in the EE and not in CE that I think will be important for us either now, or down the line: * Git hooks -- either admins with file system access need to manage these for projects because the web interface to do this is EE-only This is not a problem really. We were doing it already with Bugzilla/cgit. * Automatic rebase for fast forward commits -- Carlos mentioned that this might be something that'll just be part of the CE Yes, no worries about this one. * Single-sign-on with the remaining GNOME account infra -- maybe this will just be something we'll have to maintain ourselves Care to expand? You mean using the gnome account to login? If so, that's already possible. * Issue templates -- again, this seems like a basic feature for this kind of platform so we can get more meaningful bug reports to start with This is on CE. https://docs.gitlab.com/ce/user/project/description_templates.html You might remembered from the past, before 8.1, when it was EE. Test our gitlab test instance as outlined in the wiki so you know what's the current status of the tool, since it changed and added quite a few things in the last months that otherwise we would have ponder much more if it makes sense for us. * Multiple issue boards per project -- I haven't used the issue boards yet, but this seemed like a rather artificial limitation rather than an actual feature differentiated in EE Not sure how this is necessary for us, compared to what we have in Bugzilla. Of course this would be useful, but the frame of the problem is more about what we have now vs what we could have. Other than the hooks which might be an immediate concern, I guess the rest of these aren't a step down from where we are, so if we have an idea of how to deal with these in the future, that's good enough. Template issues and ff merge would have been a step down. Not sure template issues would have been extremely important, but still. But as mentioned, template issues in is CE since a few months ago, and fast forward merge shouldn't worry you :) Thanks again to everyone helping with this, Arun p.s.: I do think Bugzilla allows for more complexity in tracking/management but that might just be because of my familiarity with it. ___ 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: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 12:04 AM, Mattias Bengtsson wrote: > 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. Do you have a public repo online to see what this looks like? -- Alexandre Franke GNOME Hacker & Foundation Director ___ 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
From the migration plan in the wiki: "Our contention is that copying/moving every existing GNOME issue to a new issue tracker is impractical and, in many situations, undesirable." May you expand in which many situations is undesirable? I have tickets in Shotwell that have migrated three times now. From Trac to Redmine to bgo. Most of them are unreadable, are missing attachments or other viable information. Also, all references to older tickets in code are hard or even impossible to find. So in my opinion, either all information has to be transferred properly, INCLUDING a possibility to find the old bgo number, or better nothing. But I would be perfectly happy with a r/o bgo instance for reference. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
