Re: Invent/gitlab, issues and bugzilla
mmunity like FreeDesktop and Gnome moved to GitLab and their issues is undeniable, those are facts. They had those same discussions we are having and they chose GitLab (with issues). Looking for hard proof from within KDE is obviously deeply flawed because if a desktop Qt project is on GitHub and not on KDE, it is because either they don't know about KDE or they didn't think it would be better for them for X reasons and we don't known unless we ask each of them. Looking from the other side (from within KDE), you only have the projects that think moving to KDE infrastructure benefits them (like automatic releases for KDE applications, a CI that works well for Qt (kdenlive, ktechlab) or for longstanding KDE related apps whose maintainer moved on and someone else wants to share some of the maintenance burden with us to spread the costs (kdiff3)). So, no, from within, there is no such proofs, but there is a lot of them in the larger ecosystem. On Thu, 4 Jul 2019 at 17:11, Christoph Cullmann wrote: > > Hi, > > On 2019-07-04 22:49, Boudewijn Rempt wrote: > > On donderdag 4 juli 2019 22:18:32 CEST Elv1313 . wrote: > >> Ok, lots of email in the last few hours, lets recap a bit. > >> > >> 1. "Top" projects don't like GitLab issues because they are too > >> simple. Can we try to make a comprehensive list of issues on a pad > >> somewhere? So far, I see: > > > > I did make a comparison between bugzilla as it is current and gitlab; > > I don't think anyone could conclude from that there is any chance of > > gitlab's issues feature being capable of being improved to the point > > where it can replace bugzilla. It is, simply enough, _not designed to > > do that_. It is not designed to be a bug database, it's a developer > > task tracker. Not a good one, but it is NOT a bug tracker. Everyone > > should stop thinking it is. We've had enough mails today to prove that > > beyond all doubt. > > > > Nobody should advocate anymore for replacing bugzilla with gitlab's > > issues. That ship has sunk. > > > >> 2. For point 1.3, maybe this is where the solution is. @Boud, you > >> mention that Krita "ask" failed. Can you provide more insight here on > >> why? > > > > It failed, as I have said, because the software was modeled on > > stackoverflow. That is, on users helping each other. Users cannot help > > other users with support questions; they do not have the knowledge for > > that. > > > >> Is there anything to learn so we can try better? > > > > A good user support system is smart and offers a shortlist of most > > common answers to any question. It does not require logging in for the > > user. Zoho helpdesk might be a good user support system; none of the > > open source user support systems is usable. Me and the rest of the > > Krita team looked at all of them. > > > >> How about > >> redirecting users directly to a ticket system for top-10 projects? > >> Ticket systems are overkill (and problematic) for 95% of the KDE > >> projects, but seem a step forward for larger projects. Or maybe send > >> people to "a forum" first? For my largest non-KDE project (AwesomeWM), > >> when we switched to GitHub (from FlySpray), we updated the contact > >> page of the website to point to StackOverflow.com, SuperUser.com and > >> Reddit above the GitHub Issue link. This worked fine for a relatively > >> medium-large user base (of geeks). > > > > AwesomeWM's userbase is exceptionally technically capable. Our users > > are just about capable of shouting out on Reddit things like "Help! I > > have an issue! Help me! I have an assignment due tomorrow!" Without > > giving more detail. > > > >> 3. The login (identity.kde.org) issue. Maybe I am not on enough > >> mailing lists, but what is the situation regarding generic OAuth2 > >> login for a subset of non-developer services? Is it only an > >> integration issue or a political one? Being able to login with > >> Google/Facebook/GitHub/Yahoo/Microsoft/GitLab/Gnome(?!) accounts with > >> a path to upgrade to "proper" account seems to currently be the > >> popular and future proof way to handle this. This is better from a > >> security standpoint because all of them support 2 factor > >> authentication in a way *normal people* can understand (aka, a > >> notification on Android phones). Of course it doesn't help with GPG > >> and SSH public key wallets and other dev related concerns. That's not > >> relevant for most u
Re: Invent/gitlab, issues and bugzilla
Ok, lots of email in the last few hours, lets recap a bit. 1. "Top" projects don't like GitLab issues because they are too simple. Can we try to make a comprehensive list of issues on a pad somewhere? Sa far, I see: 1.1 It doesn't allow custom combo boxes like BZ/RedMine which then forces manual abuse of labels. This probably runs a bit deep and affect the search. 1.2 It doesn't allow fine grained issues tree where dependencies and relationship can be tracked "well enough". 1.3 It doesn't allow a "walled garden" to separate technical discussions from support. 1.4 Someone should chat with GitLab about this to see what they think about adding some EE features into CE. 1.5 There is BZ 6, 7 and 8 in various level of development or planning which seem good 2. For point 1.3, maybe this is where the solution is. @Boud, you mention that Krita "ask" failed. Can you provide more insight here on why? Is there anything to learn so we can try better? How about redirecting users directly to a ticket system for top-10 projects? Ticket systems are overkill (and problematic) for 95% of the KDE projects, but seem a step forward for larger projects. Or maybe send people to "a forum" first? For my largest non-KDE project (AwesomeWM), when we switched to GitHub (from FlySpray), we updated the contact page of the website to point to StackOverflow.com, SuperUser.com and Reddit above the GitHub Issue link. This worked fine for a relatively medium-large user base (of geeks). 3. The login (identity.kde.org) issue. Maybe I am not on enough mailing lists, but what is the situation regarding generic OAuth2 login for a subset of non-developer services? Is it only an integration issue or a political one? Being able to login with Google/Facebook/GitHub/Yahoo/Microsoft/GitLab/Gnome(?!) accounts with a path to upgrade to "proper" account seems to currently be the popular and future proof way to handle this. This is better from a security standpoint because all of them support 2 factor authentication in a way *normal people* can understand (aka, a notification on Android phones). Of course it doesn't help with GPG and SSH public key wallets and other dev related concerns. That's not relevant for most users. 4. For point 1.5, this isn't really solving anything. Sure, a better BZ with all the powerful features would be nice. It would not solve the PR<->Issues integration problems at all, which still leaves half of the people here unsatisfied. It would not be welcoming to projects looking to move into the incubator because they are used to a more integrated pipeline. It would also leave the whole problem of slowly making the services more bot friendly, which is the future. 4.1 This would leave the sequestration of BKO and IKO into 2 ecosystems. This makes bots more complex and makes porting good open source bots such as mergify.io even harder since it would be more painful than just a GitHub<->GitLab API compat (or if they ever support GitLab). Bots are a solution to many of the problem outlined here, such as when is a pull request acceptable to merge or some magic rebase/squash/fixup bots. On Thu, 4 Jul 2019 at 15:39, Boudewijn Rempt wrote: > > On donderdag 4 juli 2019 21:32:59 CEST Ben Cooksley wrote: > > > With regards to Identity, I'm well aware it has its issues - it was > > originally designed as a system for developers and other contributors (so > > not users) and is now many years old. > > > > It's trying to do a job it was never designed to do, in a world that is > > quite different from the one it was originally created for. We do have > > plans to replace it, but getting time to seriously look into those is quite > > difficult. > > It's mostly outside KDE's own infrastructure that we get those complaints -- > people on IRC, Twiter, Reddit and so on complaining they just cannot figure > out how the heck they can make it possible for themselves to login on the > forum. > > -- > https://www.valdyas.org | https://www.krita.org > >
Re: Invent/gitlab, issues and bugzilla
> So, proposed alternative solution: We make sure that all projects that > want a public-facing bug tracker have a product on bugzilla, and that > they communicate that as the only bug tracker to users for the time being. > Would that work? Probably not. 1. As Nate points out, the bugzilla UX isn't very friendly to *users*, but is superior for *maintainers*. The concept of "bug" isn't a thing to most people. It is a thing only to older software developers and older users. People have "problems", "issues", "ideas" or "opinions". *They*, as humans, (hopefully), don't have bugs. 2. As Bhushan points out, it is important for incubation of new projects. I disagree with Albert on this. "New" developers consider a well integrated VCS + CI + Issue + Patch (or and pull requests) system to be the bare minimum of a "good practice" software development process. Bugzilla+Jenkins+Phab+Git/SVN+Mailing_lists are loosely integrated. From an Unix point of view, they are different things that do one thing and do it well. However, from a continuous delivery pipeline point of view, this is a problem. Tracking a change from its request (bug report / issue) to its presence on users systems (store.kde.org / Plasma discover / Neon) and then the feedbacks (telemetry, drkonqi) should be unified and "bot/tools friendly". With enough effort, we could find a way to better integrate them. However "find a way" is currently "complain Ben and wait". I think he has enough on his shoulder already, so I assume if we never found the resource to better integrate our components over the year, it wont magically become a reality tomorrow, or ever. Phab had some integration, but not much compared to mature (with dev processes) projects on GitHub or GitLab. 3. This should also not require external tools. As Boudewijn points out in the "Tipping the apple cart?" thread, new users don't install Arcanist and it isn't even part of many distributions (or they are scarred of installing PHP, or they don't know about it). This goes against the onboarding goals since it makes development experience for new users inferior to power users by a large margin. Plus, people who learn software development *now* learn the Agile and GitHub workflow as the "good practice" and in the same way the older generation learnt OOP+MVC+SVN or SOA as they "modern way". The worst case is currently Ubuntu, where, at least recently, it wasn't possible to report a bug without using Ubuntu (the OS) because the buttons were removed from Launchpad. So an Ubuntu server or some user "technical friend" could literally not report problems. This is user and new-developer hostile. Bugzilla doesn't require external tools per se, but requires to interact with different systems. 4. Again as Boudewijn points out, a bug tracker is often the wrong tool. Many users genuinely don't see a difference between interrogations about how to use a software, a problem with the software and a review. As the product becomes more popular with the "general crowd" rather than "geeks", the problem is amplified to the point Bugzilla becomes a liability. Given those 4 points, I think it is clear that Bugzilla as an endpoint for all problems, bugs and project management is clearly an horrible idea going forward. * It isn't good for non technical users because well, it isn't for them. * It isn't good for projects who wish to become part of KDE because they see this as an outdated workflow lacking tight pipeline integration. * It doesn't scale to more popular projects because what they need is a ticket system in front of the "real" issues to avoid large volume or non-bug "spam" shadowing the real bugs. * It doesn't work (well) for potential new contributors who have a patch for their bug because they need to go though 2 different systems and they wont. * It is not bad with bots, but it is definitely harder to integrate bots with 5 different project rather than 1 with a real API "just for that". * DrKonqi not being able to talk to GitLab is a technological issue on our side that favors bugzilla for legacy reasons. Something like a Cannonical Apport middleware would help. GitLab isn't perfect and is too large to be under control. It may die, sold or go into directions we cannot accept. In 5 years it may be a problem and blah, blah blah. This was discussed before and a decision was made. However the idea of rejecting half of what makes GitLab good in order to unify everything under the Bugzilla umbrella is in my opinion short signed and classical resistance to changes. Sorry if this feels a bit harsh. I agree that we need to discuss this here and now rather than as a separate discussion "in the future". On Wed, 3 Jul 2019 at 16:46, Thomas Pfeiffer wrote: > > On 7/3/19 9:05 PM, Luigi Toscano wrote: > > Boudewijn Rempt ha scritto: > >> On woensdag 3 juli 2019 20:23:41 CEST Nate Graham wrote: > >>> On 7/3/19 11:53 AM, Albert Astals Cid wrote: > If the new is much better than the old, let's just remove the old.
Re: Call for contributors for Fixture [ Qt5 based raster graphics editor ]
[boud] > Sorry, that's just something you'll have to dig in for yourself. It's not > worth my time at least to get you started on something like that: it will not > help me achieve my goals. I guess it depends on the scope and ability of parallel works to give back to Krita. KOffice/Calligra was apparently not in the end closely related enough to bring more value from the shared portions than the cost of maintaining those portions for the different use cases. However this historical event may not be a definitive proof that it is not worth sharing Krita code with derivative products. As said many time, Krita focuses on drawing workflows and its restricted scope allows it to excel at it and gain market share and donations, in return funding further development. Photo editing and graphics design are larger markets but are even more entrenched as they are mostly done by paid people instead of having an active community of artists around it. But then again, as Krita gain more drawing related features that happen to also benefit the other workflows, it gets potentially significantly more attractive to those markets *if* there was some work on missing core features and an UX optimized for them. Bloating Krita into a jack of all trace raster and vector graphics design apps would most likely overwhelm the (already crowded) GUI and make it less attractive. >From that point of view, maybe having more generally reusable libraries within Krita would improve the situation. In no means should you even consider freezing their API or officially supporting them when used by 3rd parties. That adds development and maintenance cost that indeed prevent you from achieving your goals. But lowering the cost of new GUI experiments and alternate workflow can maybe help second or third parties implement toy GUIs and maybe contribute back some features that may eventually lower the cost of getting an official Krita derivative (Karbon14 new generation?) out of the door to tap into a new donation market. It seems a generally "low cost" avenue to take a bet toward getting closer to achieve your goals. I would love a better alternative to GIMP to exist as a companion (or even better, directly integrated) app for Digikam. I do some hobby photography and often have to use GIMP or, back then, my old PhotoShop 7 license to remove electric wires and similar changes. GIMP user interface is ridiculously illogical and unintuitive. Krita one is much better but lacks some photo manipulation features I like and I acknowledge it is not designed for the same kind of work. I guess I am not alone on being on the "edge" of being able to enjoy all the work invested in Krita but who have workflows it isn't optimized for (or lack features). [Kuntal] > So a couple us are trying to build a raster graphics editor which looks and > behaves similar to Photoshop with the help of Qt5. As everybody here said, it's a lot of work for a market that has been proven not to exist. I wont repeat what was said above, but just add 2 examples: The first one is the original GimpShop. Back in Photoshop 7 days, GIMP was mostly on par when it came to features beside non-RGB color systems. So someone just forked it to clone the Photoshop menu and tools layout. It was a novelty for a time, but didn't take Photoshop crown when it was technically close to be on par with it. Then someone usurped the project brand recognition to distribute malwares and the current "GimpShop" has nothing to do with the original fork. The second was called Pixel. This person made a shareware that really, really cloned Photoshop. It was ported to every operating systems under the sun[1], even the most obscure ones. You could pay a very small fee to get the version that didn't add random watermarks from time to time when you saved. The GUI was a 1:1 clone and all the features actually worked surprisingly well. Still, that was a dozen year ago and where is it now? Apparently people who want Photoshop will use Photoshop and no amount of time and love will fix it. Plus, the time it takes to maintain such large software is apparently requiring some sort of full time developers as demonstrated successfully by Krita (please everybody, consider donating to their ongoing fund raising). My advice would also be to contribute to Krita or a derivative to better tap into the other workflows (pick one and master it). Boudewijn and the other Krita contributors proved that you can compete with Photoshop if you have a laser focus on the needs of the group of users you target and love your work and your users. But as far as just cloning it and hope for the best, I think that avenue is totally hopeless. Cheers, Emmanuel Lepage [1] http://www.kanzelsberger.com/pixel/?page_id=5 On Sat, 22 Sep 2018 at 09:43, Boudewijn Rempt wrote: > > On zaterdag 22 september 2018 15:38:03 CEST Luigi Toscano wrote: > > Andy B ha scritto: > > > Can you guys maybe now move this discussion to telegram or phabricator? It > > > seems t
