Re: Relicensing Nautilus to GPLv3+
On Wed, May 17, 2017 at 7:01 AM, 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 there are no objections, we will make the switch in the following > week, most likely. My primary objection is not ideological, but practical - relicensing Nautilus GPLv3+ means that it becomes more difficult to promote code from Nautilus to Gtk+, which has happened a significant number of times in the past and I expect it will continue some into the future. Stacked with the other reasons (plugins, etc), it just doesn't seem like a very good idea. -Andrew Walton. > Regards, > Ernestas > ___ > 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: Relicensing Nautilus to GPLv3+
Ah yes, my bad. For some reason my mind didn't accept the "GPL2-only is compatible with GPL2+". All clear now. Original Message Subject: Re: Relicensing Nautilus to GPLv3+ Local Time: May 19, 2017 12:05 AM UTC Time: May 18, 2017 10:05 PM From: had...@hadess.net To: Carlos Soriano release-t...@gnome.org , nautilus-l...@gnome.org , Emilio Pozuelo Monfort , Frederic Crozat , desktop-devel-list@gnome.org On Thu, 2017-05-18 at 15:47 -0400, Carlos Soriano wrote: > Maybe I didn't explain well. Emilio points out there could one one of > those extensions that say GPL2+ to link to a GPL2-only library. But > that would make the extension itself GPL2 anyway, and it's License > file would have to reflect that initially. Again, it wouldn't. The combined work would be GPLv2-only, but each one of the items keeps its own license. The licenses are compatible. You don't have to have an piece of code depending on the exact same version of the license if those licenses are compatible. GPLv2-only is compatible with GPLv2+, as the license mentions for that dependency says: "either version 2 of the License, or (at your option) any later version." The selection is "made" automatically when you run those 2 items in the same memory address space (eg. when you "link" them). > It's just a hipotetical case, I checked the extensions dependencies > in a quick look and look fine (>= GPL+2). -- 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 Thu, 2017-05-18 at 15:47 -0400, Carlos Soriano wrote: > Maybe I didn't explain well. Emilio points out there could one one of > those extensions that say GPL2+ to link to a GPL2-only library. But > that would make the extension itself GPL2 anyway, and it's License > file would have to reflect that initially. Again, it wouldn't. The combined work would be GPLv2-only, but each one of the items keeps its own license. The licenses are compatible. You don't have to have an piece of code depending on the exact same version of the license if those licenses are compatible. GPLv2-only is compatible with GPLv2+, as the license mentions for that dependency says: "either version 2 of the License, or (at your option) any later version." The selection is "made" automatically when you run those 2 items in the same memory address space (eg. when you "link" them). > It's just a hipotetical case, I checked the extensions dependencies > in a quick look and look fine (>= GPL+2). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
Maybe I didn't explain well. Emilio points out there could one one of those extensions that say GPL2+ to link to a GPL2-only library. But that would make the extension itself GPL2 anyway, and it's License file would have to reflect that initially. It's just a hipotetical case, I checked the extensions dependencies in a quick look and look fine (>= GPL+2). Original Message Subject: Re: Relicensing Nautilus to GPLv3+ Local Time: May 18, 2017 9:29 PM UTC Time: May 18, 2017 7:29 PM From: had...@hadess.net To: Carlos Soriano , Emilio Pozuelo Monfort release-t...@gnome.org , nautilus-l...@gnome.org , desktop-devel-list@gnome.org , Frederic Crozat On Thu, 2017-05-18 at 13:50 -0400, Carlos Soriano via desktop-devel- list wrote: > Wouldn't that make the actual extension GPL2-but-not-GPL3 comaptible > since the start, and therefore cannot be GPL2+ project and therefore > its License file would need to reflect that? No. nautilus' license says "GPLv2 or later". The extension's license says "GPLv2 only". When you combine both licenses into the final product/memory address space (the "linking" mentioned in the GPL license) you end up with a "combined work" license of GPLv2. So it was compatible, but wouldn't be any more. As mentioned on IRC, I think that the original intent of using the LGPL for the libnautilus-extensions library was to allow non-GPL-compatible extensions to link into nautilus, at will. It's not like you could link to the extensions library without also eventually linking to nautilus itself... If that were the case, and that might require some digging to talk to the original authors, then you might be able to mention this in the extensions document that was recently (and erroneously) removed. HTH ___ 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: Relicensing Nautilus to GPLv3+
On Thu, 2017-05-18 at 13:50 -0400, Carlos Soriano via desktop-devel- list wrote: > Wouldn't that make the actual extension GPL2-but-not-GPL3 comaptible > since the start, and therefore cannot be GPL2+ project and therefore > its License file would need to reflect that? No. nautilus' license says "GPLv2 or later". The extension's license says "GPLv2 only". When you combine both licenses into the final product/memory address space (the "linking" mentioned in the GPL license) you end up with a "combined work" license of GPLv2. So it was compatible, but wouldn't be any more. As mentioned on IRC, I think that the original intent of using the LGPL for the libnautilus-extensions library was to allow non-GPL-compatible extensions to link into nautilus, at will. It's not like you could link to the extensions library without also eventually linking to nautilus itself... If that were the case, and that might require some digging to talk to the original authors, then you might be able to mention this in the extensions document that was recently (and erroneously) removed. HTH ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
Wouldn't that make the actual extension GPL2-but-not-GPL3 comaptible since the start, and therefore cannot be GPL2+ project and therefore its License file would need to reflect that? Original Message Subject: Re: Relicensing Nautilus to GPLv3+ Local Time: May 18, 2017 7:02 PM UTC Time: May 18, 2017 5:02 PM From: poch...@gmail.com To: Carlos Soriano , Nicolas Dufresne release-t...@gnome.org , nautilus-l...@gnome.org , desktop-devel-list@gnome.org , Frederic Crozat On 18/05/17 18:22, Carlos Soriano via desktop-devel-list wrote: > Hello, > > After asking some authors of the current code that we have as GPL3+ inside > nautilus, and pondering for a while, I realized the practicity of moving away > from that code or convince those authors to relicense as GPL2+ is more a > burden > than the real benefit. > > The only problem that arises if Nautilus becomes GPL3+ as per yesteday > discussion in IRC at #gnome-hackers is that extensions that are GPL2-only > cannot > be used anymore. > Keep in mind GPL2+ are fine. > > Said this, I took a look at extensions which are not retired from distros and > that have seen a release in at least the last 3 years. So far they are: > nautilus-dropbox - GPL3+ > nautilus-image-converter - GPL2+ > nautilus-pastebin - GPL2+ > nautilus-python - GPL2+ > nautilus-search-tool - GPL2+ > nautilus-sendto - GPL2+ > nautilus-terminal - GPL2+ > > Which is completely fine. As someone already mentioned, if any of those extensions links to a non-GPL3-compatible library, then they won't be compatible with a GPL3+ nautilus. In other words, extensions are now forbidden from linking to GPL2-but-not-GPL3-compatible libraries. I don't know whether there are any examples of extensions that do this. Just thought I'd point this out so the final decision is an informed one. Cheers, Emilio___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-settings-daemon/gnome-control-center under new ownership
On Thu, May 18, 2017 at 10:49 AM, Bastien Nocera wrote: > Hey, > > At GUADEC 2010, Matthias asked Richard Hughes and I to help with gnome- > control-center's port to GTK+ 3.x and update all the panels to the new > control-center shell that Jon McCann had been polishing. > > Skip forward 7 years later, and I'm mostly doing patch reviews for > features and redesigns done by others, along with being the person that > rejects adding new options. > You've been doing it for along time. Thanks for your service! ___ 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 18/05/17 18:22, Carlos Soriano via desktop-devel-list wrote: > Hello, > > After asking some authors of the current code that we have as GPL3+ inside > nautilus, and pondering for a while, I realized the practicity of moving away > from that code or convince those authors to relicense as GPL2+ is more a > burden > than the real benefit. > > The only problem that arises if Nautilus becomes GPL3+ as per yesteday > discussion in IRC at #gnome-hackers is that extensions that are GPL2-only > cannot > be used anymore. > Keep in mind GPL2+ are fine. > > Said this, I took a look at extensions which are not retired from distros and > that have seen a release in at least the last 3 years. So far they are: > nautilus-dropbox - GPL3+ > nautilus-image-converter - GPL2+ > nautilus-pastebin - GPL2+ > nautilus-python - GPL2+ > nautilus-search-tool - GPL2+ > nautilus-sendto - GPL2+ > nautilus-terminal - GPL2+ > > Which is completely fine. As someone already mentioned, if any of those extensions links to a non-GPL3-compatible library, then they won't be compatible with a GPL3+ nautilus. In other words, extensions are now forbidden from linking to GPL2-but-not-GPL3-compatible libraries. I don't know whether there are any examples of extensions that do this. Just thought I'd point this out so the final decision is an informed one. Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
Ah good catch, thanks! The copyright is holded by only one person, so he can freely change it the plugin is still maintained. Best regards, Carlos Soriano Original Message Subject: Re: Relicensing Nautilus to GPLv3+ Local Time: May 18, 2017 6:54 PM UTC Time: May 18, 2017 4:54 PM From: mbi...@gmail.com To: Carlos Soriano release-t...@gnome.org , nautilus-l...@gnome.org , Frederic Crozat , desktop-devel-list@gnome.org 017-05-18 18:22 GMT+02:00 Carlos Soriano via desktop-devel-list : > The only problem that arises if Nautilus becomes GPL3+ as per yesteday > discussion in IRC at #gnome-hackers is that extensions that are GPL2-only > cannot be used anymore. > Keep in mind GPL2+ are fine. > > Said this, I took a look at extensions which are not retired from distros > and that have seen a release in at least the last 3 years. So far they are: > nautilus-dropbox - GPL3+ > nautilus-image-converter - GPL2+ > nautilus-pastebin - GPL2+ > nautilus-python - GPL2+ > nautilus-search-tool - GPL2+ > nautilus-sendto - GPL2+ > nautilus-terminal - GPL2+ I found the tortoise-hg plugin in the Debian archive, which seems to be GPL2 only https://sources.debian.net/src/tortoisehg/4.0-1/contrib/nautilus-thg.py/ -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ 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: Relicensing Nautilus to GPLv3+
017-05-18 18:22 GMT+02:00 Carlos Soriano via desktop-devel-list : > The only problem that arises if Nautilus becomes GPL3+ as per yesteday > discussion in IRC at #gnome-hackers is that extensions that are GPL2-only > cannot be used anymore. > Keep in mind GPL2+ are fine. > > Said this, I took a look at extensions which are not retired from distros > and that have seen a release in at least the last 3 years. So far they are: > nautilus-dropbox - GPL3+ > nautilus-image-converter - GPL2+ > nautilus-pastebin - GPL2+ > nautilus-python - GPL2+ > nautilus-search-tool - GPL2+ > nautilus-sendto - GPL2+ > nautilus-terminal - GPL2+ I found the tortoise-hg plugin in the Debian archive, which seems to be GPL2 only https://sources.debian.net/src/tortoisehg/4.0-1/contrib/nautilus-thg.py/ -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ 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 Thu, 2017-05-18 at 12:17 +0200, Milan Crha wrote: > please, do not forget of Bugzilla integration with backtraces. It can > colorize them, it can show possible duplicates with score when the > backtrace is opened in its own window, and it can even notify the > reporter that the backtrace matches some other bugs and it offers the > reporter to eventually join an existing bug, instead of filling a new > bug report. Of course, an average user cannot decipher backtrace of > random projects, thus it's fine he/she files a new bug report, but my > main point for Bugzilla is that it knows what to do with inline > backtraces. Does gitlab issue tracker know it too? The Traceparser is another (basically) unmaintained custom extension we have in our Bugzilla, with some confusing bugs (e.g. bug 744491). GNOME Bugzilla does not receive gazillions of crasher bug reports anymore (like after the 2.16 release, which was the reason to write this extension if I remember correctly) and most distributions nowadays ship their own tools (and own backends) for automatic crasher analysis. The Traceparser is convenient but I would not strongly miss it if there was nothing similar in GitLab. I'd say a regression we could live with? > I've seen a screenshot of the gitlab issue tracker in an early stage of > the wiki page [1], which I cannot find right now. It was full of > colored tags, which effectively hid the main purpose, the information > which had been meant to be shared. The page looked like a rainbow, not > like a clean interface to share information between the reporter and > the developer. I do not know GitLab much but I'd expect functionality to set a color when creating a label. So color rules could be established if wanted / needed [4]. I'd call GitLab a way cleaner interface than Bugzilla. :) andre [4] notorious Wikimedia example for project/tag/label coloring rules: https://www.mediawiki.org/wiki/Phabricator/Project_management#Types_of_Projects -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
Hello, After asking some authors of the current code that we have as GPL3+ inside nautilus, and pondering for a while, I realized the practicity of moving away from that code or convince those authors to relicense as GPL2+ is more a burden than the real benefit. The only problem that arises if Nautilus becomes GPL3+ as per yesteday discussion in IRC at #gnome-hackers is that extensions that are GPL2-only cannot be used anymore. Keep in mind GPL2+ are fine. Said this, I took a look at extensions which are not retired from distros and that have seen a release in at least the last 3 years. So far they are: nautilus-dropbox - GPL3+ nautilus-image-converter - GPL2+ nautilus-pastebin - GPL2+ nautilus-python - GPL2+ nautilus-search-tool - GPL2+ nautilus-sendto - GPL2+ nautilus-terminal - GPL2+ Which is completely fine. Now, there is an issue with Totem plugin for Nautilus which adds a custom page to the properties page, since Totem is GPL2+ with a special clause for propietary gstreamer plugins. However, that was already an unnoticed issue. I don't want to get much deeper into all of this, given that being unnoticed for so long time probably means in practicity it doesn't matter much. We will work on a workaround for this though, making this feature available through DBUS where this doesn't apply. Given this, we will continue to our plan to relicense Nautilus project to GPL3+ next week if nothing serious gets noticed. Best regards, Carlos Soriano Original Message Subject: Re: Relicensing Nautilus to GPLv3+ Local Time: May 17, 2017 6:49 PM UTC Time: May 17, 2017 4:49 PM From: nico...@ndufresne.ca To: Frederic Crozat , nautilus-l...@gnome.org release-t...@gnome.org, desktop-devel-list@gnome.org 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___ 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 Tue, 2017-05-16 at 10:51 -0400, Shaun McCance wrote: > That said, here's a potential pain point: in Bugzilla, you can have > different components auto-assign to different accounts, and we made > these @gnome.bugs fake accounts for teams. The docs team uses this to > make it easy to follow docs bugs across products. I don't think GitLab > has any sense of components, preferring the more casual labels for > categorization. When all that overcategorization in a ticket (Bugzilla: 1 "product" per ticket, 1 "component" per ticket, 0-∞ "keywords" per ticket, random freetext in a "whiteboard" entry, upstream's "tags" fields that GNOME hides via custom CSS) is turned into a single "Labels" field, with 0-∞ labels associated to a ticket, and everybody tries to remember adding that #user-docs label, and if a GitLab user can receive notifications for certain labels (so docs team members could follow activity), I don't see a real problem? :) Our "@gnome.bugs virtual assignee" setup in Bugzilla is a horrible hack, due to unavailability of an "allow me to receive notifications for these products / components" functionality for ages [1]. andre [1] To be fair, a downstream bgo extension got upstreamed at https://github.com/bugzilla/extensions-ComponentWatching but that's not shipped /by default/ which makes following anything that is neither a ticket nor a user to stalk rather complicated/cumbersome. -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ 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, 2017-05-16 at 17:54 +0100, Allan Day wrote: > On Tue, May 16, 2017 at 5:36 PM, wrote: > ... > > We need a much better migration plan than that. If we don't have a > > script to migrate Bugzilla issues, comments, and attachments to our > > new GitLab instance, then we should not be considering using > > GitLab's issue tracker at all. > > We're committed to creating the necessary migration tooling; I think > that Alberto already has something in the works. The "Release often, release early" mantra makes me reply by "Please show me the code." andre -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ 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, 2017-05-16 at 10:28 -0400, Carlos Soriano wrote: > 2- what are the migration plans for bugzilla: bugzilla URL, bug numbers and > the actual content [...] > Also, different projects might have different needs for migration. While that is true, it is more confusing if I can find all the Bugzilla tickets I created about project X now in GitLab while I cannot find all Bugzilla tickets I created about project Y now in GitLab but you expect me to find out myself what to find where (some BZ, some GitLab?). > For example, for Nautilus we could migrate just specific important > bugs or just file new bugs in GitLab while preserving the old ones in > Bugzilla, where I can still follow/fix/comment them. [...] > As I'm the one maintaining it, I prefer a slow and smooth transition > rather than a hard one and take the opportunity to focus on the > priority ones. If I interpret "slow" and "hard" correctly and if "old ones" means "older unresolved tickets", you propose running two task tracking systems in parallel with some tickets or some projects here and some there and I (simple user) may have no idea where to do or find what. When Wikimedia killed their Bugzilla instance they made a hard cut (first migration step was turning Bugzilla entirely read-only [1]). https://xkcd.com/927/ also applies. andre [1] https://phabricator.wikimedia.org/T1234 -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-settings-daemon/gnome-control-center under new ownership
Hey, At GUADEC 2010, Matthias asked Richard Hughes and I to help with gnome- control-center's port to GTK+ 3.x and update all the panels to the new control-center shell that Jon McCann had been polishing. Skip forward 7 years later, and I'm mostly doing patch reviews for features and redesigns done by others, along with being the person that rejects adding new options. I'm writing this mail because I want to be able to focus on writing code again, implementing new features desktop-wide such as integrating OOM handling into the desktop, porting our session handling to systemd, dealing with kernel bugs and, finally, spending some time on my old friend Videos. Rui will be taking over handling of day-to-day operations for gnome- control-center and gnome-settings-daemon. I'll still be around to handle bugs in my own area of expertise (such as the Bluetooth panel or the fingerprint integration). If you have long-standing bugs still opened because the maintainer got jaded, or because your patches didn't get reviewed, please connect with Rui to get a fresh look. 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
Hey, On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote: > [Written on behalf of Alberto Ruiz, Carlos Soriano, Andrea Veri, > Emmanuele Bassi and myself.] > > Please bear in mind that this is just a recommendation! We are not > claiming to have complete knowledge and we would like to hear > questions and comments. At the same time, we do ask that members of > the community approach this proposal with an open mind: please read > the wiki pages and try to resist making assumptions about GitLab > without familiarising yourself with it. I've now read through the documentation, and annotated my early thoughts on the migration. - Keep bugzilla URLs working, along with history This is very important for code history purposes, and has been mentioned as an explicit goal at: https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/#Migration_Possibilities - Keep cgit URLs working Again, important for code history purposes. We often link to those in bug reports and commit messages. This could probably be achieved through redirections rather than keeping the cgit instance alive - Keep git URLs working While not a problem for developers (you'd change your gitconfig and update jhbuild, and done, mostly), it has the potential to break a lot of flatpaks, possibly also upstream packaging. I know something similar was done in the Fedora package repos when they migrated, so maybe it's possible? - Component bug assignment: g-c-c/g-s-d or gnome-documents/gnome-books This is probably the most important one for bug handling. Otherwise managing bugs for g-c-c and g-s-d, the different components of which require a lot of domain-specific knowledge, would be terribly unwieldy. - Equivalent to NEEDINFO? This status was pretty important in terms of bug triaging, as the reporter was allowed to remove that flag when they were done providing the information, removing the burden from the bug triager to monitor the bug. Is there an equivalent? - Cross-module issue searching? Again, quite useful in terms of bug triaging, allowing to find a "root cause" bug, possibly assigned to a different component than the top level application. For example, a crash in Videos could be in about 7 different modules, being able to search the whole instance would be useful. - Mail for own replies (a-la bugzilla) - This is also a useful tool for bug triaging, as all the comments end up in my Bugzilla folder, and I can search through them. I'm guessing/hoping it's possible. - Handling of private bugs? Bugzilla has the ability to create private bugs, for security and community feedback management purposes. Does GitLab allow that? - Bugzilla yearly reports Is there some statistics tool builtin to GitLab? - Bugzilla points Will they be migrated? :) Overall, the migration is a good idea, especially the ability to report bugs and contribute without a GNOME specific account. I hope the information about how different teams and bugzilla triagers use Bugzilla, in particular, was of interest. Cheers ___ 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 21:58 "Sriram Ramkrishna" a écrit: > 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. > Ok, I will do that. > 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. :-) > I understand perfectly your worry, and the last thing I want is to make a mess. I'll ask the board what they think. If they tell me they prefer I don't commercialize a Windows portage, I won't. > 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). > I understand. When I did my first try, I did discuss it with Paperwork's main contributors beforehand. While the GPL allows it, I consider it basic politeness. This is also why I'm asking now, before hosting Paperwork on gnome.org. > 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. > Agreed. > If you do go down that route, I hope that some portion of the proceeds will > be contributed to the > GNOME Foundation. > Yes, it would be fair. > 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. Thank you for this very detailed answer :) > 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
Heya, Good discussion, nice input from everyone involved! I summarized what we have so far in a new page with community input in https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/CommunityInput Keep in mind I tried to extract the most important points, to have an effective list of actions to take. Feel free to put more comments in the comments section https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/Comments and/or continue with the emails. Cheers, Carlos Soriano Original Message Subject: Re: Proposal to deploy GitLab on gnome.org Local Time: May 17, 2017 9:02 PM UTC Time: May 17, 2017 7:02 PM From: jehan.marmott...@gmail.com To: Mathieu Bridon Carlos Soriano , desktop-devel-list@gnome.org , Bastien Nocera 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 th
Re: Proposal to deploy GitLab on gnome.org
On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote: > The outcome of this evaluation process is that we are recommending > that GNOME sets up its own GitLab instance, as a replacement for > Bugzilla and cgit. Hi, with respect of the cgit, it lets me download sources (snapshot) as a .zip and a .tar.xz. The gitlab offers .zip, .tar.gz, .tar.bz2 and .tar. I think there had been some good reasoning for projects to do releases as .tar.xz (maybe it was even a GNOME Goal, I do not recall, neither cannot find it), it's quite efficient with compression, thus it would make sense to teach gitlab to use it beside .zip, instead of those three not-that-useful-these-days .tar variants. Would they do it upstream, or you'll need to patch it downstream, or it's just some option somewhere? Bye, Milan ___ 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, 2017-05-16 at 10:51 -0400, Shaun McCance wrote: > That said, here's a potential pain point Hi, please, do not forget of Bugzilla integration with backtraces. It can colorize them, it can show possible duplicates with score when the backtrace is opened in its own window, and it can even notify the reporter that the backtrace matches some other bugs and it offers the reporter to eventually join an existing bug, instead of filling a new bug report. Of course, an average user cannot decipher backtrace of random projects, thus it's fine he/she files a new bug report, but my main point for Bugzilla is that it knows what to do with inline backtraces. Does gitlab issue tracker know it too? Also, with respect of searching in Bugzilla, what some folks in this thread call complicated, I call powerful. Bugzilla is powerful in searching. The search UI can be complicated, that's why there is a Simple and Advanced search page, but it allows you do many good things. I've seen a screenshot of the gitlab issue tracker in an early stage of the wiki page [1], which I cannot find right now. It was full of colored tags, which effectively hid the main purpose, the information which had been meant to be shared. The page looked like a rainbow, not like a clean interface to share information between the reporter and the developer. One of the test issues [2] also looks somehow odd, but maybe if I would get use to it, then it might not be that bad as it looks like now. How many comments does it show? Four? One? Something in between? It looks like there are four of them, all grey thin font (hard to read), and wasting like 1/3 of my browser window height. Height is problem, not width, with wide screens. I didn't try how it looks like on a cell phone. The issue [3] also says: > Carlos Soriano @csoriano mentioned in issue #30668 (closed) 2 weeks ago Should that "mentioned" be "is marked as duplicate" instead? I can mention bugs between itself and I do it all the time (like "this is partly related to bug #1234", or even "can be duplicate of bug #1234", which used to do bug squad folks in the past too), but it doesn't mean they are duplicates, neither that I want to add some possibly misleading automated comment into the other bug report. I would mark them as a duplicate, or add them to Depends/Blocks, if I'd be sure. >From my point of view, it doesn't make much sense to have both Bugzilla and gitlab issue tracker running at the same time and let the product maintainers decide what is better for them. There should be some consistency. You cannot tell the reporter that the issue he/she filled belongs to other project, but that project issues are hosted elsewhere (even still under gnome.org domain). I understand this whole initiative to also make life easier for sysadmins, where maintaining two issue trackers doesn't sound like less work for them. Bye, Milan [1] https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/ [2] https://gitlab.gnome.org/GNOME/nautilus/issues/30668 [3] https://gitlab.gnome.org/GNOME/nautilus/issues/20958 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
