Re: Gitlab, Git History and Merge Options
Hi Tomaz, On Tue, May 19, 2020 at 10:10:41AM +0200, Tomaz Canabrava wrote: > By default Gitlab will create merge commits, and this can create a really > nasty history if a branch is based on a branch and not in master. To > overcome this, please - if you own a repository - go to the repository > settings, Merge Requests, Fast Forward Merge. > > I see that a few repositories are already having the `github style` ladder > of merge commits. That really makes a hard time for git bisect. We have globally enabled this option for all repositories already right after migration, so if you're still seeing new instances of the such merge commits, please let us know. Thanks -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Namespaces for a few repositories on invent (was Re: Migration to Gitlab -- Update)
On Sun, May 10, 2020 at 02:54:35PM +0200, Luigi Toscano wrote: > I went through the list of the new structure, and I can only imagine the work > needed to reshuffle > Am I still on time to propose some fine tuning? Sure, feel free to make suggestions on final place of items on structure > == Proposed moves: > kio-upnp-ms: applications -> network > mark: applications -> education > kdecoration-viewer: applications -> sdk > kolorfill: applications -> games > klook: applications -> graphics > peruse: applications -> graphics done! > == A bit more open questions about: > libkdegameai: libraries -> games (like libkdegames) done! > macports-kde: sdk -> packaging (not 100% sure) this kinda looks unmaintained to me, last commit is in 2014/15, and otherwise seems untouched, should unmaintained be better place for this? > kup: system -> utilities (like kbackup!) Good that we have backup for backup applications , anyway would it make sense to move this otherway around? (kbackup -> system?) I kind of consider backup "system"/"core" stuff... > mangonel seems a bit of place too in system (which has mostly lower-level > configuration stuff), maybe utilities? done! > > == There are a few second-level namespaces, are we going to keep them? I can > see: Thanks for noticing the second-level namespaces, I completely overlooked it seems > * graphics/digikam/ > - it only contains digikam-doc, which should maybe just go under graphics/ > * graphics/libs > - a few libraries which be moved under graphics/ directly (or libraries, but > they are graphics-related) > * network/telepathy > - only telepathy-logger-qt, it could go under network/ directly I've flattened these ones. > * others/kde-edu-courses/ > - why not directly under education ? I guess it can go into education, but looking at content I am more inclined to think that this belongs into unmaintained, aren't those applications instead using the GHNS? I am not even sure where this content is hosted if at all (seems to have .php files in there) > Also unmaintained/ contains two of them (necessitas, strigi), but it doesn't > matter much I guess. I've flattened necessitas and strigi. > Ciao! > -- > Luigi -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Migration to Gitlab -- Update
Hello, On Sun, May 10, 2020 at 01:20:23PM +0200, Johan Ouwerkerk wrote: > On Sun, May 10, 2020 at 9:49 AM Ben Cooksley wrote: > > > > Following lengthy discussion in the original thread, it was agreed > > that the original sysadmin proposal of various categories would be > > implemented, with repositories organised according to that structure. > > > > You can find this documented at > > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent > > > > -- Conclusion -- > > > > Should anyone have any questions regarding the above, please let us know! > > > > Just to confirm, by documented you mean that the layout of the various > `metadata.yaml` files indicates what the layout of the repositories > will become? Becuase looking at Keysmith for example, it seems that > the metadata repopath has not been updated yet: > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent/utilities/keysmith/metadata.yaml?h=bshah/invent Yes, that is correct, currently directory structure is what will be final structure, repopath and other bits will migrated all at once when actual move happens -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Information regarding upcoming Gitlab Migration: clarifications
Good afternoon, [Please keep sysad...@kde.org list or bs...@kde.org in the CC for replies] I want to clarify some bits for which we have gotten a questions about, - Non unique naming: There's some teams which prefer if we dropped the namespace- part from their name which we have added. While currently this does not result in the naming conflict right away, we realize this will cause it at one point, for example, maui-dialer -> maui/dialer plasma-dialer -> plasma-mobile/dialer To minimize the impact of the Gitlab move we won't be doing such renames which introduce non-unique names right away. But we would prefer if the existing tooling or infrastructure is ready for this kind of cases at later point. Only way to enforce non-unique naming is one big KDE/ subgroup which we want to avoid. Current naming in the repo-metadata branch[1] I've pointed does not reflect those renames, as we are not planning to do those renames right away during gitlab move, but at a later stage. - Existing configurations: we want to reduce impact on existing release schedule, and existing developer workflow, therefore we will continue to privide the existing anongit.kde.org and git.kde.org (although this will be read-only) with current flat structuring for 3 weeks after actual migration, which will keep the existing scripts/clones working enough to give developers time to change to the new structure. We will also try to provide a script which allows you to migrate your existing clones to new repo paths and as mentioned by Ben in other message, potentially a git-kde script which would allow you to clone individual repository without knowing it's namespace (provided that there is no conflict of it's name). like "git kde karchive" - Translations: we will co-ordinate with the translations team to let them adapt their tooling to updated structure as this requires changes on their side how translations are stored in svn repository Thanks! [1] https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
Hello Johan, On Tue, Apr 28, 2020 at 06:18:14PM +0200, Johan Ouwerkerk wrote: > I would like to propose that the sysadmin team pick the layout that is > easiest to *implement*, which I suspect is also the most like what we > have now, and that we live with that. Unless there is a pressing need, > like real hard data that we're losing contributors because they can't > find our repos or a sysadmin burden that would be excessively higher > than otherwise... let's keep things as simple and straightforward for > syadmin and tooling maintainers to implement during the Gitlab > migration. > > Let's worry about the perfect project layout once we've identified the > need. That way it's a lot easier to garner consensus for a practical > solution that isn't just a wishlist of all the features we would like > but which Gitlab may or may not have and which tooling is probably > completely unprepared for. Going with flat namespace right now and then making whole thing non-flat means double amount of work for sysadmins, once to migrate everything on invent, and then later to their final home. It is equal amount of work for contributors, once to migrate to invent URL and then migrate to new grouping. If setups needs changing, I'd rather change it now at once then later. > By all means disregard this stuff if the pressing need has already > been identified and I've either neglected to read e-mails properly or > wasn't aware for some other, possibly historical, reason. We have gotten a request for namespacing from projects on multiple occassion, in cgit our workaround has always been that we prefix the repo name with namespace- (i.e wikitolearn-courses-backend). While this works out with our current workflow, it is not really optimal. I've also mentioned various new contributor focused requirements which lead us to this proposal for structuring in previous emails. -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
Hi Adriaan, On Tue, Apr 28, 2020 at 01:08:33PM +0200, Adriaan de Groot wrote: > A tool-like actor that I don't think has been mentioned so far is "existing > checkouts". I have a src/kde with all the bits I've looked at "recently". > There may even be some SVN checkouts there -- I'm willing to forget about > those. Surprising and annoying me every time I update those sometime in the > future is not good, but it's only going to annoy me once (per repo, so at > most > 143 times for my clones). We have a plan to provide a script which can change remotes in existing clones. (It would take a top-level directory path for all your clones). > Perhaps it's the "old school", but kdesrc-build doesn't do anything for me. > I'm intermittently interested in the source of some random part of KDE -- > generally because it's mentioned on IRC -- and then I need that source where > I > can look at it. Whether it's 'git clone' or 'kdesrc-build --just-the-source- > please' doesn't matter much. > > If there's any compiling to be done, the less magic there is between me and > the compile, the better. > > So, yeah: `git clone kde:x` all the way, but I'm also not really invested in > the structure of the label x, or the precise configuration of kde:. > > > > Now, if a simple(ish) script can be created to make > > something akin to the kde: rewriting work, even if what it really does is to > > search gitlab and create a clone with the appropriate command, i could deal > > with that, but having the ability to simply ask for the project name is > > more than a little useful. > > I think we shouldn't underestimate how names are a social construct, though: > the current flat structure comes after a structured SVN naming epoch. But I'd > totes +1 a search-and-redirector, especially if it means I can write `git > clone kde:peruse` and the resulting .git/config has followed the redirects > and > whatnot and ended up with `url: kdeforreal:audio/peruse` One thing to remember is, you can't really have a dynamic insteadOf URL setup. Besides, even if we had a everything under KDE namespace I'd find a setup for this weird enough. Let's assume that everything is under invent.kde.org/kde (and invent.kde.org/sysadmin and invent.kde.org/websites as it is right now). Now you add a following snippet in gitconfig, [url "https://invent.kde.org/KDE/";] insteadOf = kde: [url "g...@invent.kde.org:KDE/"] pushInsteadOf = kde: Which is slightly modified version of the existing kde: URL helper shown here, https://community.kde.org/Sysadmin/GitKdeOrgManual#Let_Git_rewrite_URL_prefixes Now this is perfectly fine for the something which is kde/ so you can do git clone kde:krita and it would happily replace 'kde:' part with 'https://invent.kde.org/KDE/' and would clone 'https://invent.kde.org/KDE/krita' But, now things get interesting when you want to clone the docs-krita-org which is in the websites/ namespace. We will have to keep this things in separate namespace for policy reasons (and same goes for sysadmin stuff). How would you clone docs-krita-org? git clone kde:../websites/krita-org ? add a separate prefix for websites and sysadmin? Let's assume that you added snippet for sysadmin and websites, it's just 8 more lines after all, [url "https://invent.kde.org/websites/";] insteadOf = websites: [url "g...@invent.kde.org:websites/"] pushInsteadOf = websites: [url "https://invent.kde.org/sysadmin/";] insteadOf = sysadmin: [url "g...@invent.kde.org:sysadmin/"] pushInsteadOf = sysadmin: Does this solve all use-cases? I believe no, it still does not support the personal repositories of users. So you also need to add 4 more lines for your own user, and 4 for each user whose repository you want to clone. What our workflow with the kde: prefix so far had been really useful I agree, and I will miss it, but with departure of gitolite which allowed repositories at top-level, we can't easily support this, and we have to accept it. Perhaps solution suggested by Ben in his email could be useful instead and in addition generic invent: snippet which does not include any namespace. [url "https://invent.kde.org/";] insteadOf = invent: [url "g...@invent.kde.org:"] pushInsteadOf = invent: > (That said, bigflatlistofrepositories.kde.org .. or maybe call it > cgit.kde.org > .. could be a particular view onto gitlab which does flattening and search, > but only if there's people around to create it and maintain it) Just to clarify, sysadmins have no plan to support or maintain the cgit instance once we migrate to Gitlab. Thanks -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
Hi Olivier, On Mon, Apr 27, 2020 at 10:49:46PM +0200, Olivier Churlaud wrote: > >Because in order to search for something, you need to know it exists. > > > >If you are just casually browsing, then the search can't help you. > > I don't think people casually browse our repos. What use case is more likely > to happen and do we want to support? We don't really want to discard use-cases just because it does not suit our workflow. That is not how we are going to gain new contributors, we should value each contribution, be it drive-by contribution, or focused contribution towards one single project. > Use case 1 : Jerry learns about KDE and go in their forge in the Multimedia > section. After carefully reading the code of two applications and three libs > he starts contributing to Elisa. > > Use case 2 : While using her Ubuntu installation of Elisa / while reading on > reddit about Elisa, Jerry decides to try to contribute to this project/fix > this bug that itches her and searches for it in KDE's forge. Let me add a some more usecases, some of which I've been dealing with in project I maintain. Use case 3 : Tom comes in Plasma Mobile channel and asks for Plasma Mobile applications source code Use case 4 : Tom is a student in Germany and is interested in contributing to wikitolearn, and he asks where can I find code of the wikitolearn? Suggestion offered by sysadmin team does not cater to one single use-case, but offers a way to provide a solution to all 4 usecases. For Plasma Mobile team or Wikitolearn team it would be much easier to refer contributors to the https://invent.kde.org/plasma-mobile or https://invent.kde.org/wikitolearn then tell them to go to https://invent.kde.org/KDE and search for the tag wikitolearn or Plasma Mobile. > On the other hand, I think the discussion about spotting open merge requests > (in a derived thread from this one) should be answered, being by relevant > tags, subgroups or whatever. (super personal note) Ironically, Usecase 1 is how I started contributing to KDE 7 years back. While I was inspired by battery monitor re-design in 4.11 release, I wanted to work on "something" so I did literally browse through various repositories to find something where my technical capabilities were enough to work on [1]. Back then it was projects.kde.org (chiliproject installation). [1] https://blog.bshah.in/2013/09/01/hello-planet/ -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
Hi Ingo, On Mon, Apr 27, 2020 at 03:46:13PM +0200, Ingo Klöcker wrote: > > > I'm sorry, but I don't think that this is solved by your proposal for the > > > KDE PIM projects because not everything related to KDE PIM (e.g. relevant > > > frameworks like kcontacts, kholidays, kpeople and soon kdav) will be in > > > the same group. The same is true for any project which uses some > > > frameworks, e.g. graphics and the imageformats framework or whatever > > > group kate and kwrite are going to end up in and the ktexteditor > > > framework. > > > > This is something which can be easily solved by Gitlab, Gitlab offers a > > solution where project can be shared with another group. > > > > So e.g. sharing kcontacts with kdepim should be possible, then all merge > > requests/issues from kcontacts would show up under pim as well. > > Great. So we could put all repos into an "all" group (e.g. rename kde to all) > and then have every subcommunity decide for themselves which repos they want > to see in their group. No, sadly this does not work, I just tested this, I have two different groups here - https://invent.kde.org/sysadmin/test/test1 - https://invent.kde.org/sysadmin/test/test2 test1 have a repo called foo under it, which is shared with the test2 group. When someone visits test2, they are not offered the list of the shared repositories but they are instead offered the empty page. One have to click on Shared repositories tab to actually see the list. https://invent.kde.org/groups/sysadmin/test/test2/-/shared This defeats the purpose of the creating subgroups (offering easy reachability). -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
Hi Nate, On Mon, Apr 27, 2020 at 07:45:23AM -0600, Nate Graham wrote: > Trying to categorize everything into a single group cannot succeed because > many projects could logically belong to multiple groups (e.g > plasma-framework is a framework that's a part of Plasma; Discover is an app > that's a part of Plasma; kdenetwork-filesharing and kio-extras are libraries > that are distributed via the apps release service). I foresee endless > pointless arguments about the best group for something to live in. I've agreed in previous threads that sometime our grouping is not perfect, but this is something we can improve instead of throwing idea of grouping out altogether. > Let's step back: do we have to put every repo inside a group in the first > place? Is it solely so you can look at a nice list of all open merge > requests for PIM/Frameworks/etc? If so, perhaps this workflow could be > approximated with tags instead or group assignments instead No goal is not just that you get nice list of all open merge requests or issues. Main goal is we want to offer user or potential contributors a list of closely related projects instead of list of all 1100+ projects we have. That would mean, If user wants to see all frameworks, or graphics applications, or multimedia applications, they can. The workflow, with labels you mention is trying to achieve a totally different goal then what we are trying to solve here. Labels/Tags are for sorting issues, and/or merge requests. They can't be reliable solution for the sorting of the multiple repositories. On technical side, Gitlab does not offer labels for projects, but setting called topic. You can see that in screenshot[1] linked. Besides, from home page there's no way to filter something for e.g "Graphics". nore project listing shows the tags alongside of the project names, also making use of this tags means that if user clicks this tags, what they are offered is *all* the repositories including forks of the repositories, which means when you search for graphics [2], you get many duplicative results and this is really not something discoverable. > We create many very granular groups for the purposes of organizing teams and > and performing code review (e.g. Plasma, KWin, Frameworks, PIM, Krita, > Dolphin, Okular, VDG, etc.) and then every new merge request could receive a > tag or assignee corresponding to its relevant code review groups (e.g. merge > requests for kio and kio-extras could get get tagged with both "Frameworks", > and "Dolphin"; plasma-frameworks MRs could get tagged with both "Plasma" and > "Frameworks", and so on). As explained above, while grouping repositories is trying to solve the merge requests/issue organization, it is not sole purpose of the suggested grouping, discoverability and reachability is the main issue we are trying to solve here. [1] https://i.imgur.com/h1L1A5H.png [2] https://i.imgur.com/ajOszEL.png -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
In part I am mostly re-iterating what Ben already mentioned in different messages. On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote: > Does this mean that to clone it we'll have to go "git clone > kde:games/knetwalk" or something along the lines? Yes [Rest of message is with sysadmin hat off and as a developer] > If that's the case I'd much prefer if we didn't do this, at the moment > it's already uncomfortable for me to remember the URL for some of the > repos (e.g. is it sysadmin/ or not?), this will only increase the > problem and I personally don't see the advantage. I do agree that it maybe small inconvience, but let's be honest, most of us have been using kdesrc-build or some kind of automated tooling for building everything, apart from very rare case we never have to manually clone any of KDE repository, at least it is true for me personally. I am not sure about others. [Very non-scientific test, I did "history | grep 'git clone kde:'" on my machine and only instances were 4, websites/conf-kde-in, kde-build-metadata, sysadmin/irc-notifications, sysadmin/binary-factory-tooling, rest was automatically downloaded by the kdesrc-build] Anyway, getting back on topic, while this option gives some initial setbacks in our own personal workflow, let's look at bigger picture. Let's say I am the new developer who wants to contribute to frameworks. One of reason we are switching to gitlab is better onboarding, current state is that we have cgit.kde.org as a repository browser. By default I open it, I get the sorting by name, first repository is abakus. Commits as old as 14 years(!), after that some more mix of unmaintained repositories and scrolling almost 1.5 page, I get greeted with baloo, first framework in whole list. Let's just assume that name based sorting is bad idea, and we sort by activity instead. Here I get much better results, first framework is solid. But at same time if I was looking for SDK, kdevelop would appear at 3rd scroll-page. Here cgit is able to show many items in single scroll page, you can be assured that on gitlab it would not show kdevelop in first 6-7 pages. You might wonder why search does not help here? So problem with search is you need to know what you are looking for[*], but drive-by contributors, or users who are simply browsing our repositories won't know what they are looking for, they are simply trying to find a thing that interests them. Giving them categories/groups allows them to focus on topic they like and they can contribute to. > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is > krita graphics or its own thing? I agree that categories are something which we can improve upon, but this is something which we can improve upon, rejecting idea of categories just because 7-10 repos are at wrong place is ultimately not going to do anything good. > I really prefer when I don't have to guess this kind of things when > fetching a repository. [*] Ironically, in your case search would be helpful as you know you are looking for knetwalk so you can just add it and search it -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Information regarding upcoming Gitlab Migration
[Please keep sysad...@kde.org list or bs...@kde.org in the CC for replies] Hello Community members, In view of upcoming Gitlab migration, we sysadmin team wants to share the recommended structuring for the repositories on Gitlab. We had multiple options, - Flat structure: In this option we would have everything under one single namespace/group: https://invent.kde.org/kde/knetwalk - Subgroups under top-level group: In this option we would have a groups under KDE namespace: https://invent.kde.org/kde/games/knetwalk - Groups at top level: In this option we would establish a series of groups at the top level, e.g. https://invent.kde.org/games/knetwalk We have discussed this with small but representative group of contributors or maintainers, and based on their suggestions, we recommend that we go with option 3. Having sub-groups at top level will allow us to, - Provides good visibility on all reviews, tasks and other items within the groups/modules we define - Provides improvements to discoverability of projects - Makes it possible for groups of projects to establish a group level task board should it fit their needs (for tracking a release for instance) - Makes the most semantic sense, as the ‘KDE’ top level group suggested in option 2 is duplicative considering the Gitlab instance is under kde.org. - The discoverability of projects is maximised, as there is no need to open the top level ‘KDE’ group before going into the subgroup. I've worked on draft "move" of the current set of the repositories in their respective subgroups at the repo-metadata project's branch [1]. You can browse the directory structure to get idea of how final structure on Gitlab would look like. If we don't have any objections we would like to implement this next week and move projects to https://invent.kde.org. Thanks! Bhushan for sysadmin team [1] https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Taking over maintainership of the kaccounts-* repos
Hello! At akademy we talked about the KAccounts and realized that kaccounts is unmaintained and/or Martin is not active. So I propose to take over maintainership of the following repositories. - kaccounts-integration - kaccounts-providers - kaccounts-mobile If you have any concerns/objections with this, let me know. Thanks -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Downtime announcement: www.kde.org
[sending again from right address since my gmail address is not subscribed to somee lists] Hello, On Mon, Nov 05, 2018 at 11:02:43PM +1300, Ben Cooksley wrote: > > In order to allow for hardware maintenance, one of our physical > > hardware hosts will need to be shutdown for a few hours on Monday. > > This downtime will commence around 9:30am UTC and may take several > > hours. The maintenance is now completed, and as far as we are aware, all services are now back up. If you have trouble accessing any of services, please let us know over email or sysadmin ticket. Thanks! > > > > During this time a number of sites will be inaccessible, including: > > - www.kde.org > > - autoconfig.kde.org > > - docs.kde.org > > - ev.kde.org > > - freebsd.kde.org > > - hig.kde.org > > - kdesrc-build.kde.org > > - neon.kde.org > > - releases.neon.kde.org > > - networkcheck.kde.org > > - planet.kde.org > > > > Other websites within KDE.org that are dependent on resources hosted > > on those sites may also experience delayed loading times in browsers > > during this window. > > > > As some of these sites are relied upon by applications to function > > properly, those applications may experience degraded functionality > > during this time. > > > > Affected applications include: > > - Discover > > - Kaffeine > > - Kopete > > - Plasma Network Manager (when behind a captive portal) > > - Any application using GHNS > > > > In addition, any other site which is hosted by the server known as > > "olios.kde.org" will also be unavailable during this time. > > > > Apologies for any inconvenience caused. > > The maintenance window has now commenced. > The above sites will be inaccessible until the maintenance is completed. > > > > > Regards, > > Ben Cooksley > > KDE Sysadmin > > Regards, > Ben -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Downtime announcement: www.kde.org
Hello everyone, On Mon, Nov 05, 2018 at 11:02:43PM +1300, Ben Cooksley wrote: > > In order to allow for hardware maintenance, one of our physical > > hardware hosts will need to be shutdown for a few hours on Monday. > > This downtime will commence around 9:30am UTC and may take several > > hours. The maintenance is now completed, and as far as we are aware, all services are now back up. If you have trouble accessing any of services, please let us know over email or sysadmin ticket. Thanks! > > > > During this time a number of sites will be inaccessible, including: > > - www.kde.org > > - autoconfig.kde.org > > - docs.kde.org > > - ev.kde.org > > - freebsd.kde.org > > - hig.kde.org > > - kdesrc-build.kde.org > > - neon.kde.org > > - releases.neon.kde.org > > - networkcheck.kde.org > > - planet.kde.org > > > > Other websites within KDE.org that are dependent on resources hosted > > on those sites may also experience delayed loading times in browsers > > during this window. > > > > As some of these sites are relied upon by applications to function > > properly, those applications may experience degraded functionality > > during this time. > > > > Affected applications include: > > - Discover > > - Kaffeine > > - Kopete > > - Plasma Network Manager (when behind a captive portal) > > - Any application using GHNS > > > > In addition, any other site which is hosted by the server known as > > "olios.kde.org" will also be unavailable during this time. > > > > Apologies for any inconvenience caused. > > The maintenance window has now commenced. > The above sites will be inaccessible until the maintenance is completed. > > > > > Regards, > > Ben Cooksley > > KDE Sysadmin > > Regards, > Ben -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
PSA: Phabricator staging repositories
Hello developers, So in last few days I and Ben has been working on setting up the staging repositories for phabricator. More information on this feature is documented as part of Harbormaster documentation [1] change handoff section. To explain further, this will allow the people to push commits for review to a dedicated staging area, which opens up the new possibilities like, - Landing the changes directly from Web UI - Handing over the changes to CI systems like build.kde.org or build.neon.kde.org or binary-factory.kde.org which in turn can run the build against proposed changes and send status back to review saying "Hey! That review doesn't build" or "All Green!" Currently required changes for those two usecases is not implemented yet. But, enabling staging repository is the first step in that direction. Currently we have all pieces to enable the staging area in the repositories ready, but it is not enabled. As we think we should notify community about upcoming changes. We will be enabling this feature in upcoming week. # So how does staging repository works? When you create a diff using arcanist, what it does is, push the commit for which changes were created to tag like phabricator/diff/12345, where 12345 represents the diff ID to different git mirror of mainline git repositories on git.kde.org. The URL where this tags will be pushed is, "stag...@git.kde.org:reponame.git" One imporant thing to note is, stag...@git.kde.org won't accept the normal pushes, and for most of the developers this URL is implementation detail. You should not push direct changes to this repositories. Also, to allow non-developers to push to the staging area, we have enabled the option to upload ssh keys for the normal users. The keys added there will be synced to stag...@git.kde.org automatically allowing the non-developers to push to staging area. So in general here is what you should do, # For users who want to submit the changes to phabricator Please make sure you have your keys uploaded to identity.kde.org, you can do it by clicking on "Manage SSH Keys" option in right sidebar after logging in. # For both users and developers Make sure your ~/.ssh/config have entry for stag...@git.kde.org. Below is example from my ssh config. Host git.kde.org HostName git.kde.org User staging IdentityFile ~/.ssh/id_rsa_kde # For maintainers of projects For some reason you don't want your project to use the staging repositories on phabricator, or have any questions, please get in touch with us. PS: We are interested in getting some beta testing for this feature before we enable this changes to all repositories, if you maintain a project and if you are interested in testing this out, please mention us. PPS: I have just sent this e-mail to few lists I am subscribed to (kde-devel, kde-core-devel, kde-frameworks-devel, plasma-devel and sysadmin list) but if you think I have missed sending this to some list, feel free to forward it and please make sure to include sysad...@kde.org or me in reply. Thanks [1] https://secure.phabricator.com/book/phabricator/article/harbormaster/ -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Participation of KDE in GCI 2018
Hey Vijay, On Mon, Oct 23, 2017 at 01:42:31AM +0530, vijay krishnavanshi wrote: > My opinion is that we should participate. Thoughts? My personal opinion about GCI this year is we should take a rest this year, this is due to two reasons, 1) Changed timelines of GSoC, we need to prepare and submit GSoC application much more early (even if after GCI ends, we don't have much of time in between0 2) Currently we need ~25 tasks for org applications but for the competition itself we need to have more like 50 unique and ~100 of total tasks IIRC at everytime, this is stressful task for both mentors and org-admins.. (I know people have promised to put tasks, and I trust them, but based on previous year's experience, often this effort is not enough to meet numbers, not blaming anyone). So yeah, my idea is, take a break this year, and use this time to document the junior jobs for next upcoming GCI and also others who want to work on KDE stuff out of this programs. (Also, just to be clear, I am not blocking anyone from participating.. I will be happy to help and mentor ( pun intended :P) willing org-admin.. Thanks! -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Google Code-in begins soon: Nov. 28, 2016
Hi Priyanshu, On Thu, Nov 10, 2016 at 10:08 AM, priyanshu jain wrote: > > I am Priyanshu Jain want to be mentor for GCi. I will be happy to help kids > accomplishing the tasks for GCi this year and will be available on Nov 28 > for them. Thanks for stepping up, but however since you are participating in Season of KDE as student, we can't allow you to be mentor for Google code-in. Thanks -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
Re: Baloo maintainer required
Hey Vishesh, On Mon, Sep 19, 2016 at 3:06 PM, Vishesh Handa wrote: > I've been steadily loosing motivation to work on Baloo. > > I've removed myself from all the bugs, as it doesn't seem like I'm > going to look at them. I no longer use Baloo or have a KDE development > environment. Therefore, it's not even scratching my own itch. > > If someone else wants to maintain it, I can help with the transition. Few days ago Boudhayan volunteered for maintaining it.. See https://mail.kde.org/pipermail/kde-frameworks-devel/2016-September/037674.html Thanks -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode
Re: Various CI build failures
Hello Ben, On Tue, Aug 30, 2016 at 3:22 PM, Ben Cooksley wrote: > - Plasma Mediacenter Qt 4 branches I am fine with this. -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode
Re: QtSharp as part of KDE in GSoC 2016
Hello Dimitar, On Fri, Apr 15, 2016 at 8:41 PM, Dimitar Dobrev wrote: > Joao has notified me that QtSharp was not given a slot for Google Summer of > Code this year as part of KDE. While I understand your position and would > accept any final decision you make, I do believe it's going to be beneficial > to the KDE community if you could reconsider. I am sorry but your mentor did not realize they were out of order, and notified you about slot allocation process before actual date. Your mentor is notified about this. As a consequence we won't be able to select this proposal anymore under KDE for Google Summer of Code 2016. Apologies. -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode
Re: [kde-community] GSoC Application Deadline is Feb. 19! Get your ideas in ASAP
On Mon, Feb 15, 2016 at 12:30 PM, Gilles Caulier wrote: > Q : why to write a google document if a wiki page exists (or vis versa) ? > Why duplicate work ? Due to spam attack KDE wikis are locked down for edits, See [1] Thanks! [1] https://mail.kde.org/pipermail/kde-community/2016q1/002237.html -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode
GCI tasks needed
Hello, As you guys may already know we are participating in Google code in 2015 like previous years. This years contest is starting on 7th December. And we are running very low on tasks this year.. We need total 75 tasks before Monday when contest starts.. If you have small tasks in your project, please head over to https://codein.withgoogle.com and add your tasks. There are total 5 categories in which you can add your tasks: - Code - User interface - Documentation/Training - Quality Assurance - Outreach/Research If you are not yet signed up as mentor of the KDE organization, please ping either me, valorie or Nightrose in the #kde-soc channel with your Gmail or Google sign-in enabled email address and we will invite you then you will be able to add the tasks in the Google code-in website. Thanks! -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Please fill in SoK ideas
Hello people, Like previous years, we are having Season of KDE this year too https://dot.kde.org/2015/10/08/season-kde-2015-now-open It is meant for people who could not get into Google Summer of Code for various reasons, or people who simply prefer a differently structured, somewhat less constrained program. Season of KDE is managed by the same team of admins and mentors that takes care of Google Summer of Code and Google Code-in matters for KDE, with the same level of quality and care. Other difference between Season of KDE and GSoC is, We are willing to consider non-coding projects as well including artwork and promotion. In past various non-coding projects were accepted in Season of KDE. So if you have any ideas or projects head over to Season of KDE ideas page now : https://community.kde.org/SoK/Ideas/2015 Note the deadlines for the submitting applications are below Student application deadline: Oct 22 2015 Mentor application deadline: Oct 31 2015 Thanks! -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: KScreenGenie stable release
On Sun, Aug 9, 2015 at 3:34 PM, Boudhayan Gupta wrote: > This is a heads-up that I'll be doing a stable release of KScreenGenie > (v2.0.0) sometime late 15th August (after 10 PM) / early 16th August > 2015, Indian Standard Time. Since you are having stable release, do you want bugs.kde.org product created? (I know that this is going to be ksnapshot-next, but for this release it is kscreengenie -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 124439: Add missing 'continue' for balooctl
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124439/#review82884 --- +1, add vHanda to get Ship it! - Bhushan Shah On July 24, 2015, 4:30 p.m., Dāvis Mosāns wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124439/ > --- > > (Updated July 24, 2015, 4:30 p.m.) > > > Review request for Baloo. > > > Repository: baloo > > > Description > --- > > Currently it would say it's skiping file because it's already indexed, but > actually it wouldn't skip and raise assert > > $ balooctl index file.txt > Skipping: file.txt Reason: Already indexed > Indexing file.txt > ASSERT: "!url.isEmpty()" in file > /mnt/KDE/kde/workspace/baloo/src/engine/documentdatadb.cpp, line 60 > > > Diffs > - > > src/tools/balooctl/main.cpp e8f29b21e0100508f39ba5a6a45536979803f144 > > Diff: https://git.reviewboard.kde.org/r/124439/diff/ > > > Testing > --- > > Verified that now it skips file and don't cause assert. > > > Thanks, > > Dāvis Mosāns > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Guidance Required
Hello! On Wed, Jun 3, 2015 at 1:37 AM, Karan Thakkar wrote: > > I am interested and excited to contribute to KDE, basically for Plasma > Media Centre. I have gone around through development guide of KDE for the > same. > Thanks for your interest in the Plasma Media Center. > I have basic C++ knowledge and have been indulged in competitive coding > for a while. I would appreciate if you guide me about the things I need to > learn and study before contributing for KDE Plasma Media Center and how to > get involved with KDE for the same. > First thing you should do is build plasma-mediacenter from the source code. For that required information is available in README file http://quickgit.kde.org/?p=plasma-mediacenter.git&a=blob&h=55a0315922025d12f22d720f5c06776116d3b8f5&hb=7e972198cf2b55f9b14befdd8a9c0c84a32f4b39&f=README One of the dependency of plasma-mediacenter is KDE Frameworks 5. You can either build it from source or use pre-built binary packages for it. Once you build plasma-mediacenter from source and get it running here are some of the open bugs for the plasma-mediacenter, https://bugs.kde.org/buglist.cgi?cmdtype=runnamed&namedcmd=plasma-mediacenter bugs some of them are marked as junior jobs which are easy to fix. For example : https://bugs.kde.org/show_bug.cgi?id=346406 If you require any help use the IRC or this mailing list to get help. I am available on #plasma and #kde-devel channel on Freenode network. Thanks! -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: kbuildsycoca5 crashing
On Sun, May 10, 2015 at 5:43 PM, Jeremy Whiting wrote: > Somehow kbuildsycoca5 is crashing here lately. I nuked my whole kde > prefix (/usr/local) and rebuilt with packaged qt from my distro > (arch). But kbuildsycoca5 is crashing every time I run it with some > issue in QByteArray. Has anyone seen this lately/before or know how I > can get past it? One of my config files broken or something? (I miss > the days of ~/.kde where I could move that out of the way to figure > out issues like this...) Here's a backtrace of the crash. Currently > running in a gnome terminal in a gnome session to test and such while > the rest of kde builds... Is your /home/jeremy/.cache/ksycoca5 owned by root or something? -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: planetKDE blog.
Hello! On Mon, Dec 1, 2014 at 5:16 PM, anu mittal wrote: > Hi > I filed a new bug for adding my blog to planet kde with the details > mentioned, two days ago and the link is- > > https://bugs.kde.org/show_bug.cgi?id=341412 > But no action has been taken till now, is there any correction required or I > have to wait. > Regards. I've added your blog to Planet KDE Thanks! -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: planetKDE blog.
Hello! On Wed, Nov 26, 2014 at 7:27 PM, anu mittal wrote: > Can anybody please help me by telling what all details are needed in planet > kde blog.I have filed a bug at add your feeds,now how should i proceed? Can you give the URL to bug report? Thanks! -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 120486: Don't concatenate QLatin1String and std::string
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120486/#review67909 --- Ship it! Ship It! - Bhushan Shah On Oct. 4, 2014, 6:24 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120486/ > --- > > (Updated Oct. 4, 2014, 6:24 p.m.) > > > Review request for Baloo and Emmanuel Pescosta. > > > Repository: baloo > > > Description > --- > > This is was a regression introduced by > 29b8dda21857e30693282f16c0e5df12ac337098 causing a build failure. Using > QString::fromStdString for printing the fileIndexDbPath > > > Diffs > - > > src/file/lib/filefetchjob.cpp 1bb7ddf > > Diff: https://git.reviewboard.kde.org/r/120486/diff/ > > > Testing > --- > > Compiles. > > > Thanks, > > Kai Uwe Broulik > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 118628: Make tests behave more like frameworks.
> On June 10, 2014, 5:46 p.m., Bhushan Shah wrote: > > CMakeLists.txt, line 64 > > <https://git.reviewboard.kde.org/r/118628/diff/1/?file=279885#file279885line64> > > > > hmm what about using ecm_add_test? > > Michael Palimaka wrote: > That's already used in autotests/CMakeLists.txt > > Bhushan Shah wrote: > So I think just passing BUILD_TESTING=false should not compile tests.. > and it seems this is not required. > > Michael Palimaka wrote: > Sure, but then Qt5Test becomes mandatory regardless of whether > BUILD_TESTING is set or not. hmm, Yeah.. Go ahead then.. - Bhushan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118628/#review59672 --- On June 9, 2014, 10:41 p.m., Michael Palimaka wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/118628/ > --- > > (Updated June 9, 2014, 10:41 p.m.) > > > Review request for Baloo. > > > Repository: kfilemetadata > > > Description > --- > > Make tests behave more like frameworks, by respecting the BUILD_TESTING > option from ECM and only locating QtTest when necessary. The default > behaviour remains the same. > > > Diffs > - > > CMakeLists.txt aa2b0864ca8b2126ffcabf5cbad28b06dbb682b2 > autotests/CMakeLists.txt 95c3e302122d3b9a01f70e74812c2b374ac46023 > > Diff: https://git.reviewboard.kde.org/r/118628/diff/ > > > Testing > --- > > Tests pass/are ignored with the appropriate build option. > > > Thanks, > > Michael Palimaka > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 118628: Make tests behave more like frameworks.
> On June 10, 2014, 5:46 p.m., Bhushan Shah wrote: > > CMakeLists.txt, line 64 > > <https://git.reviewboard.kde.org/r/118628/diff/1/?file=279885#file279885line64> > > > > hmm what about using ecm_add_test? > > Michael Palimaka wrote: > That's already used in autotests/CMakeLists.txt So I think just passing BUILD_TESTING=false should not compile tests.. and it seems this is not required. - Bhushan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118628/#review59672 --- On June 9, 2014, 10:41 p.m., Michael Palimaka wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/118628/ > --- > > (Updated June 9, 2014, 10:41 p.m.) > > > Review request for Baloo. > > > Repository: kfilemetadata > > > Description > --- > > Make tests behave more like frameworks, by respecting the BUILD_TESTING > option from ECM and only locating QtTest when necessary. The default > behaviour remains the same. > > > Diffs > - > > CMakeLists.txt aa2b0864ca8b2126ffcabf5cbad28b06dbb682b2 > autotests/CMakeLists.txt 95c3e302122d3b9a01f70e74812c2b374ac46023 > > Diff: https://git.reviewboard.kde.org/r/118628/diff/ > > > Testing > --- > > Tests pass/are ignored with the appropriate build option. > > > Thanks, > > Michael Palimaka > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 118628: Make tests behave more like frameworks.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118628/#review59672 --- CMakeLists.txt <https://git.reviewboard.kde.org/r/118628/#comment41577> hmm what about using ecm_add_test? - Bhushan Shah On June 9, 2014, 10:41 p.m., Michael Palimaka wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/118628/ > --- > > (Updated June 9, 2014, 10:41 p.m.) > > > Review request for Baloo. > > > Repository: kfilemetadata > > > Description > --- > > Make tests behave more like frameworks, by respecting the BUILD_TESTING > option from ECM and only locating QtTest when necessary. The default > behaviour remains the same. > > > Diffs > - > > CMakeLists.txt aa2b0864ca8b2126ffcabf5cbad28b06dbb682b2 > autotests/CMakeLists.txt 95c3e302122d3b9a01f70e74812c2b374ac46023 > > Diff: https://git.reviewboard.kde.org/r/118628/diff/ > > > Testing > --- > > Tests pass/are ignored with the appropriate build option. > > > Thanks, > > Michael Palimaka > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Need help with crash in allTransfer function in KGet.
Hello,
I am currently working on new KGet engine, and plasma widget. I am having
problem in sources function,
It looks like this,
QStringList KGetEngine::sources() const
{
QStringList sources;
//sources << "KGet";
QList trans = KGet::allTransfers();
foreach (TransferHandler *handler, trans) {
sources << handler->dest().fileName();
}
return sources;
}
But KGet::allTransfers function crashes. Here is crash report :
Application: Plasma Engine Explorer (plasmaengineexplorer), signal:
Segmentation fault
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[KCrash Handler]
#6 0xae960ca8 in QList (l=..., this=0xbfe42150) at
/usr/include/qt4/QtCore/qlist.h:122
#7 QForeachContainer (t=..., this=0xbfe42150) at
/usr/include/qt4/QtCore/qglobal.h:2365
#8 TransferTreeModel::transferGroups (this=0x0) at
/home/bshah/kdesrc/kde/kdenetwork/kget/core/transfertreemodel.cpp:450
#9 0xae94b14c in KGet::allTransfers () at
/home/bshah/kdesrc/kde/kdenetwork/kget/core/kget.cpp:660
#10 0xaea100e0 in KGetEngine::sources (this=0x9af19f8) at
/home/bshah/kdesrc/kde/kdenetwork/kget/plasma/engine/kgetengine.cpp:65
#11 0x0805418e in _start ()
Thanks,
Bhushan
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
