Re: is a BSL licensed service acceptable for sysadminy use cases?

2021-06-09 Thread Bhushan Shah
On Thursday, 27 May, 2021 12:55:01 AM IST Anna “CyberTailor” wrote:
> So you can use old sentry versions, which are open source.

If you are referring to old snapshot of old sentry version then I would say it 
is fairly impossible to use it given using old sentry version would also mean 
that we need to use older API version and it also means older libraries for 
client side (for sending data). It is basically a dep hell which is impossible 
to overcome.

With my sysadmin hat on, I would absolutely oppose to having installation of 3 
year old unmaintained software (and its equally outdated dependencies) that 
are guranteed to get no upates whatsover on our servers in productions.

Regards.

signature.asc
Description: This is a digitally signed message part.


Re: The status of freenode (the IRC network used by KDE)

2021-05-19 Thread Bhushan Shah
Hi Christian,

First of all thank you very much for your work, and transparency to report 
this. ❤️

On Wednesday, 19 May, 2021 2:04:26 PM IST Christian wrote:
> I tried my very best both to not drag KDE into this situation plus to keep
> the network running as I helped running it for the past 10 years, and to
> keep your data safe in the hands of the volunteers that curated it for
> decades.

Personally speaking at moment I am not concerned about public development 
channels *that much*, but rather private channels including those used by 
sysadmin, board and other teams should be first priority.

We should, either migrate them to new IRC network or migrate them to different 
platform and in addition disconnect bridges with other networks for example, 
matrix/telegram temporarily.

And yes, what is recommended by other staffers regarding your personal data/
password/email also stands.


Thanks.




Gitlab feedback and discussion

2020-10-01 Thread Bhushan Shah
Hello community members,

Recently we realized that there is no specific place to discuss various
issues with KDE's GitLab instance. So I have created (well re-used) a
channel where this can be done.

You can join on,

- IRC #kde-invent
- Telegram https://t.me/kdeinvent
- Matrix #kde-invent:kde.org

This is a place to discuss the issues and feedback related to the KDE's
GitLab instance, how we can improve it further.

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


Information regarding upcoming Gitlab Migration: clarifications

2020-04-29 Thread Bhushan Shah
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

2020-04-28 Thread Bhushan Shah
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

2020-04-28 Thread Bhushan Shah
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

2020-04-27 Thread Bhushan Shah
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

2020-04-27 Thread Bhushan Shah
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

2020-04-27 Thread Bhushan Shah
On Mon, Apr 27, 2020 at 06:02:19PM +0530, Piyush Aggarwal wrote:
> How long do redirects like this one work? If they will keep working
> indefinitely, then maybe we can have all the repos at flat URLs for once
> and then move them to respective subgroups? That way we will have access to
> our simple URLs through a redirect as I mentioned before, and also the
> ability to manage the Invent as recommended by sysadmins.

Documentation says that redirect will stay as long as original name is
not claimed by the new group, user or project.

However there's multiple problems with the workflow of moving something
to the KDE/ namespace first and then to respective group.

- There will be empty KDE/ group visible which would be confusing for
  visitors
- Workflow of the importing repository becomes complicated without any
  advantage IMO. For instance to import bshah/kframework into
  frameworks/ I've to first transfer it's ownership to KDE and then
  transfer it's ownership to frameworks/ group.
- But most importantly, this breaks with the non-unique leaf repository
  names feature offered by the proposed structure. So, There could be
  maui/documentation and wikitolearn/documentation. But we would have
  single KDE/documentation redirect

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

2020-04-27 Thread Bhushan Shah
Hello

On Mon, Apr 27, 2020 at 02:10:11PM +0200, Boudewijn Rempt wrote:
> On maandag 27 april 2020 03:40:01 CEST Bhushan Shah wrote:
> 
> > [1] 
> > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> 
> Maybe it would make sense to keep a kde top-level group for some of the 
> bigger projects that really don't fit in a category -- I don't think Krita 
> fits in the graphics group, since we never ever do anything with any of the 
> other repositories in that category.

Slightly off-topic, but, in general idea is that we want to get away
from the KDE is software, and more towards KDE is community and people,
having a KDE/ namespace is step backward IMHO.

> I have to admit, I also dread updating instructions and checkouts everywhere 
> from invent.kde.org/kde/krita to invent.kde.org/graphics/krita...

You don't really have to update the URL, since this project was already
on invent.kde.org we would be doing a move, which would automatically
add a redirect, so while if you want to update, it is fine, it won't be
breaking any of existing links/setups.

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

2020-04-27 Thread Bhushan Shah
[adding sysad...@kde.org in CC, please make sure you keep it in CC]

On Mon, Apr 27, 2020 at 02:03:48PM +0200, Ingo Klöcker wrote:
> On Montag, 27. April 2020 13:19:07 CEST Ben Cooksley wrote:
> > That requires that you know it exists. We have 1,043 mainline
> > repositories at the moment, which translates to 53 pages of projects
> > under a flat structure system.
> > Reality is nobody is going to page through that looking for something.
> 
> I have to disagree. Whenever I'm looking for a project I browse
> https://projects.kde.org/ (aka https://cgit.kde.org/).
> Using a simple Ctrl+F in my browser allowed me to find what I was looking for 
> rather easily.
> 
> Having to look into *several* subgroups (because I guess we all know from 
> experience that any categorization into several groups never matches our 
> expectation) would have been a pain in the ass.
> 
> 
> > Please also see my point regarding listing merge requests at the group
> > level
> 
> This argument only holds if the subgroups match development teams. It does 
> already break down if e.g. a KDE PIM developer wants to see merge requests 
> for 
> PIM related frameworks and for PIM applications.
> 
> I have experienced exactly this problem at work were we have put repos of 
> unrelated projects into different groups. It was extremely inconvenient that, 
> while working on more than one project at the same time, I couldn't see all 
> MRs I'm interested in on a single page.
> 
> IMNSHO the groups in GitLab are not the right solution for gathering all 
> repos 
> some dev team, let alone individual devs, is/are interested in, because the 
> assumption that different dev teams are interested in *disjoint* sets of 
> repos 
> is simply wrong. Moreover, the assumption that all members of some dev team 
> are interested in exactly the same repos is equally wrong (even if most team 
> members are probably interested in most of the same repos).
> 
> And while the mapping group to dev team might make sense for something like 
> plasma or frameworks or KDE PIM, I sure that it makes less or no sense for 
> groups like graphics were different teams are working on different 
> applications in the same group.
> 
> 
> > - you can see an example of what a flat structure ends up
> > looking like at https://gitlab.gnome.org/GNOME
> > 
> > For those projects that span multiple repositories, you have just
> > denied them any chance or ability to see a listing of everything
> > related to their wider project.
> 
> 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.

> The sad truth is that, AFAIK, GitLab lacks an n-to-m association of repos to 
> user groups (e.g. dev teams). GitLab's 1-to-n association of repos to a 
> single 
> group is insufficient for us (while it's sufficient for most users of 
> gitlab.com).
> 
> Regards,
> Ingo



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

2020-04-27 Thread Bhushan Shah
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

2020-04-26 Thread Bhushan Shah
[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


Unused scratch/clones repositories cleanup

2020-04-25 Thread Bhushan Shah
Hello community,

Curently there's about 1400 repositories in total under the, scratch/
and clones/ namespace.

https://cgit.kde.org/scratch/
https://cgit.kde.org/clones/

I am sure many people are using some of this repositories, but some are
fairly inactive and unused. We would like to ask community members to
go through their own personal repositories and clean-up the unused
repositories. Instructions on how to delete or trash personal
repositories can be found at:

https://community.kde.org/Sysadmin/GitKdeOrgManual#Deleting_personal_repositories

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


Help with sorting out unmaintained repos in the playground

2020-04-05 Thread Bhushan Shah
Hello community,

In preparation for upcoming move of KDE repositories to Gitlab we
sysadmins wants to move the unused/inactive repositories to
unmaintained/.

Current list of all repositories: https://phabricator.kde.org/T12916

We need your help with sorting out what is maintained and what is not.
So please comment in task.

Thanks,
Bhushan for KDE sysadmin team

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


conf.kde.in 2019 call for papers extended

2019-11-07 Thread Bhushan Shah
Hello everyone!

conf.kde.in 2019 call for participation has been extended uptil 15th
Nov 2019.

conf.kde.in 2019 will happen at Maharaja Agrasen Institute of
Technology, Delhi, 17-18-19 January. If you wish to present your work
on KDE community, please submit talk at the following page.

https://conf.kde.org/users/sign_in?conference_acronym=cki2020=en

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: Invent/gitlab, issues and bugzilla

2019-07-04 Thread Bhushan Shah
Everyone, let's take a step back.

Original discussion was, if project X can use gitlab issues instead of
bugzilla? If the developers/maintainers prefer?

Potential arguments to which are either,

- No they can't because we forbid it in our manifesto or code of conduct
  or policies
- No they can't because it makes life of other developer harder
- No they can't because it makes life of other user harder

As we stand neither of this arguments apply ... We have no written point
in KDE manifesto which allows community to force a developer tool of
their choice on new or existing project, as long as tool or service is
hosted within KDE infrastructure and doesn't cost sysadmins or community
resources/time maintaining that service. It is important have this
freedom, otherwise next day someone can come up with idea that all
projects should use cmake or autotools or qmake, because all of KDE
community should be using same buildsystem.

- Gitlab is hosted on KDE infrastructure and each KDE contributors can
  access the service using their KDE identity account.
- Gitlab service is/will be actively maintained by KDE sysadmin team and
  using it as bugzilla is not going to cost KDE e.V. any extra money.

If developer/maintainer collectively thinks that using gitlab as bug
tracker makes their life easier instead of depending on bugzilla I don't
understand why other developers would have a problem with that? It's not
making their life difficult at all if they want to contribute, as
mentioned in earlier point Gitlab is accessible to all users and
developers.

As for users, let users decide? I mean we can't speak for all of our
userbase confidently that they love bugzilla and will stop reporting
bugs for other components if certain other project/application starts
using Gitlab for bugtracking, can either of you?

On Wed, Jul 03, 2019 at 08:37:34PM +0200, Boudewijn Rempt wrote:
> Besides, it's already too easy to make a bug report. Getting more bug
> reports is not a priority for me; at this I would prefer to have less
> interaction between developers and users than more, because we're
> going crazy right now.

This is your personal opinion.

> And that's the important thing. Bugzilla is a developer tool, not a
> user tool. We must have easy tools to triage, query, sort, modify sets
> of reports. Bugzilla isn't perfect for that either, but the options
> gitlab gives for handling issues are so limited.

If bugzilla is developer tool, gitlab is also developer tool, let
developer or maintainer decide how to best use it.

On Thu, Jul 04, 2019 at 10:20:34AM +0200, Boudewijn Rempt wrote:
> On the other hand, we also need to use tools that make our work
> possible. Me being able to do my work, my developers being able to do
> their work is also important. These tools are not for marketing, they
> are for making the development process go better. And not just for
> newcomers, but also for the people actually shouldering the load of
> triaging ~150 reports a month.

If Kaidan, Calindori or Plasma Mobile uses the Gitlab for issue reporting
because of either a) choice of maintainer or b) choice of specific
sub-community, that decision doesn't affect krita, okular or other KDE
applications.

> I disagree. I'm fine with modernizing bugzilla to bugzilla 6. But
> gitlab's issues feature is not powerful enough to handle the amound of
> bug reports I have to handle. In other words, I cannot do my work with
> gitlab's issues feature. It might look more modern, but it just
> doesn't have the power. 

This is your personal opinion.

On Thu, Jul 04, 2019 at 10:39:15AM +0200, Christoph Cullmann wrote:
> In our company we multiple times reviewed bug trackers (for migrating
> from Bugzilla), but none actually had a good enough feature set to be
> considered, beside perhaps Jira (which is non-free/open).
> 
> I would wait for the Bugzilla 6 release to judge if the UI arrives in
> the 21th century before making any decisions what to use. Just that
> GitLab is more modern doesn't give it all the features one needs.

This is your personal opinion.

In general, I respect everyone's personal opinion that bugzilla at
moment superior to the gitlab issues, but at same time I also want to
respect other developers opinion/choices as long as they abide by the
KDE manifesto written and supported by our community.

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: Invent/gitlab, issues and bugzilla

2019-07-03 Thread Bhushan Shah
On Tue, Jul 02, 2019 at 11:09:41PM +0200, Albert Astals Cid wrote:
> That makes no sense, we incubated projects before we were on gitlab, saying 
> "oh no, if people can't use gitlab issues the incubation will collapse" is a 
> bit alarmist IMGO

Not my point at all, I am not saying Gitlab issues would be cause which
makes the incubation fail. I am saying that if we continue with such
twisted policy which denies access to service A already present because
service B is used by rest of community is what will make incubation
fail.

To expand, What I am saying is, 

- KDE Incubates a project
- We have a two differet things for some thing, let's take example of
  build.kde.org and Gitlab CI.
- We introduce a rule that people can't use Gitlab CI despite being
  there and force them to use build.kde.org

That kind of rules are not getting us anywhere. If it was case of
someone using Travis CI instead of build.kde.org, we can ask them to not
use it or enforce it. But if both services are hosted on KDE
infrastructure, requires no further maintainence or other KDE
contributors are able to access the service, just because one piece of
software is broken or requires change (drkonqi) denying projects use of
Gitlab Issues is not a good idea.

Projects come to KDE because they find our community attractive, in hope
that they get more contributors, but if we want to stick with some old
infrastructure, and actively deny them usage of something new, then they
better be on infrastructre outside of KDE.

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: Invent/gitlab, issues and bugzilla

2019-07-02 Thread Bhushan Shah
Hello,

Thanks Luigi for starting discussion,

Adding little bit of context on why this discussion is needed. This
discussion was triggered by calindori getting included in the KDE group
on gitlab.

Calindori previously was developed fully on gitlab and would prefer to
use gitlab for as many things as it can. I've also incubated Kaidan[1]
which was using self-hosted gitlab infrastructure, and have total of
approximately 200+ issues before incubating into KDE, with multiple
contributors.

Now we have following options,

a) force these repositories to use bugzilla instead of gitlab till we
   come up with the solution to drkonqi problem.
b) open a bugzilla product for compatibility with drkonqi and keep using
   gitlab for internal issues/bugs.

I think solution b is least invasive solution to problem. and on
personal note, I think if we have some infrastructure (gitlab issues)
and if we force projects to not use it. I don't think it makes much
sense.. and if it is our stance then we better close incubator
projects..

Again this is my personal opinion and doesn't represent the KDE
community's or KDE Sysadmin team's opinion.

Thanks.

On Tue, Jul 02, 2019 at 02:55:41PM +0200, Luigi Toscano wrote:
> Hi,
> 
> one of the main point of the gitlab migration has been so far the replacement
> for phabricator. We didn't discuss about bug tracking.
> 
> Despite this, I've seen a few projects using issues as replacement for 
> bugzilla.
> 
> 
> We can all debate which is better, whether bugzilla or the gitlab issues, but
> please consider that:
> 
> - having to ways to report a bug makes like of everyone more complicated for
> users reporting bug who need to find the proper place, and for bug triager
> 
> - drkonqi still continue to report to bugzilla. Future versions of drkonqi can
> be fixed to support the new system and we would need also a proxy for older
> versions of drkonqi, but until such thing exist, a migration is out of 
> question.
> 
> 
> My suggestion right now is to disable issues completely, or if they need to be
> enable to allow us to replace phabricator tasks, then to reduce their scope to
> this.
> 
> -- 
> 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: Google Season of Docs

2019-03-12 Thread Bhushan Shah
Hello Albert,

On Tue, Mar 12, 2019 at 12:25:45AM +0100, Albert Astals Cid wrote:
> *Important for us* Valorie has mentioned she doesn't have the spare cycles to 
> lead this, she can lend a helping hand but if we want to part of this we need 
> an admin. 
> 
> Volunteers?

As said elsewhere, happy to take a lead here for adminstrative tasks.

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

2018-11-06 Thread Bhushan Shah
[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


Phabricator BoF(?)

2018-06-28 Thread Bhushan Shah
Hello,

At akademy one of thing I had in mind was to organize the phabricator
BoF. To discuss,

- Any improvements we can make with current phabricator workflow?
- Any improvements/suggestions we (sysadmins) can forward to upstream?
- How better we can make use of phabricator features
- More...

but seeing as there are limited slots for BoF are available, is there
any interest about this?

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: Participation of KDE in GCI 2018

2017-10-23 Thread Bhushan Shah
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: Big Hairy Audacious Goal: Privacy Software

2017-09-21 Thread Bhushan Shah
Hi Sebastian,

On Fri, Aug 18, 2017 at 06:14:22PM +0200, Sebastian Kügler wrote:
> "In 5 years, KDE software enables and promotes privacy"

Can you please submit this goal to goal settings phabricator board just
like other ideas?

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: Ambitious KDE Goal: Briding the Gap

2017-09-21 Thread Bhushan Shah
On Sun, Aug 20, 2017 at 01:39:59PM +0200, Jos van den Oever wrote:
> I feel like I should join in as well in pitching ambitious ideas for KDE.

Can you please submit this to goal settings phabricator board just like
other ideas?

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: KDE at Qt World Summit 2017 - let's make it the best yet!

2017-08-09 Thread Bhushan Shah
On Tue, Aug 8, 2017 at 10:48 PM, Eike Hein <h...@kde.org> wrote:
> - Helpers! Who wants to be an awesome person and go to QtWS and rep
>   KDE there? Who can make it to Berlin in the timeframe? (I know
>   there's a KDE Edu sprint and a Blue Systems dev sprint going on,
>   so no excuses! :P)
>
>   Everyone interested and willing to commit please speak up, or get
>   in touch with me directly. You will be able to express a pre-
>   ference for booth and talk chairing duty which we'll try to
>   respect when drawing up the duty roster. You'll get lots of karma
>   bonus points if you're willing to help with booth setup and tear
>   down.

I would like to join, I'll be able to help with booth duties (demo,
and possibly teardown, I won't arrive in Berlin that early to help
with initial setup)

>
>   There will be a limit to how many people we can send, so please
>   don't be upset if we can't bring you along in the end. But please
>   do try!
>
>   If travel/accomodation expenses would be the only thing keeping
>   you, get in touch and we can look into that.
>
> - Figure out what we want to show at the booth this year. Who wants
>   to make cool demo loops or slides?

/me want to help with that, possibly I will make demo loop for plasma mobile

>
> - Make promo materials. We'll need to review and update our posters
>   (if anyone has the 2015/2016 posters, please link them in reply)
>   and flyers. And do it early enough so we can get them refined and
>   printed in time. Jens Reuterberg has promised to help make things
>   look great!
>
>
> Cheers,
> Eike



-- 
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: Official "Going to Akademy" banner by Ivan Čukić

2016-08-18 Thread Bhushan Shah
On Fri, Aug 19, 2016 at 11:09 AM, Valorie Zimmerman
<valorie.zimmer...@gmail.com> wrote:
>
> Bhushan, do you see the image in my post? The only post on Planet
> where I see the image displayed was on Ken Vermette's blog. When I
> checked his source I could see that he uploaded the image and linked
> to that, rather than using the HTML snippet given to us on

Yes I do see the image in both your post and on planet.. maybe try
different browser?

-- 
Bhushan Shah

http://blog.bshah.in
IRC Nick : bshah on Freenode


Re: Official "Going to Akademy" banner by Ivan Čukić

2016-08-18 Thread Bhushan Shah
On Fri, Aug 19, 2016 at 8:50 AM, Valorie Zimmerman
<valorie.zimmer...@gmail.com> wrote:
> I used it in my blog post, but it's broken and I don't know why. I see
> others who used it on the Planet also broken. Thoughts?
>
> Valorie
>
> link: 
> http://linuxgrandma.blogspot.com/2016/08/wee-akademy-and-qtcon-approaching.html

What do you mean by broken?

-- 
Bhushan Shah

http://blog.bshah.in
IRC Nick : bshah on Freenode


Re: [kde-community] Register for QtCon

2016-08-05 Thread Bhushan Shah
On Fri, Aug 5, 2016 at 4:50 PM, Jos van den Oever <j...@vandenoever.info> wrote:
> I did not see anywhere to put in dietary restrictions in the registration
> form.

You can adjust it in "My profile"

-- 
Bhushan Shah

http://blog.bshah.in
IRC Nick : bshah on Freenode
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] QtCon CfP published

2016-05-18 Thread Bhushan Shah

On Wednesday, May 18, 2016 12:05:25 AM IST, Sivan Greenberg wrote:

 As I see the deadline has passed and I missed it (I was under a strong flu
for the last 2 weeks) is there room to ask for extension to submit mine ?


Actually deadline was extended, and new deadline is 22nd May

Thanks

--
Bhushan Shah

http://bhush9.github.io
IRC Nick : bshah on Freenode
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Distribution outreach program: Where do we go from here?

2016-02-13 Thread Bhushan Shah
On Sun, Feb 14, 2016 at 3:27 AM, Thomas Pfeiffer
<thomas.pfeif...@kde.org> wrote:
> Does that make sense to you guys?
> And most importantly: Who'd be up for joining the program team?

Count me in. :-)

-- 
Bhushan Shah

http://bhush9.github.io
IRC Nick : bshah on Freenode
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Should we allow non-KDE projects to participate in GSoC under KDE?

2016-02-04 Thread Bhushan Shah
On Thu, Feb 4, 2016 at 4:08 PM, Ivan Čukić <ivan.cu...@kde.org> wrote:
> I am *very* against giving our slots to non-kde projects. We already
> had problems with this a few years ago, I would rather avoid the
> unpleasantries that happened back then.

Just FTR, we don't give away our own slots, but we ask for slots after
we decide how many projects we are going to select.

-- 
Bhushan Shah

http://bhush9.github.io
IRC Nick : bshah on Freenode
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

[kde-community] GCI tasks needed

2015-12-05 Thread Bhushan Shah
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
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Write our own pull request bot?

2015-09-20 Thread Bhushan Shah
On Sun, Sep 20, 2015 at 8:20 PM, Martin Klapetek
<martin.klape...@gmail.com> wrote:
>
> Gnome in their years history of github mirroring had 4 pull requests
> (it was mentioned in the other thread...one of the others).

Sorry no [1]

https://github.com/pulls?utf8=%E2%9C%93=is%3Aopen+is%3Apr+org%3Agnome



-- 
Bhushan Shah

http://bhush9.github.io
IRC Nick : bshah on Freenode
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] What is a GitHub pull request exactly?

2015-09-20 Thread Bhushan Shah
On Sun, Sep 20, 2015 at 6:33 PM, Riccardo Iaconelli <ricca...@kde.org> wrote:
> exactly, as soon as we could.
> But not all tools simply are technical alternatives. Can we replace Facebook?
> Sure, we could join Diaspora. But we would be missing out on the community
> already present on Facebook. Reasons for being on github are not technical,
> they are promotional.

We don't need to replace Facebook.. tada.

Facebook is not part of our development nor anything.. So lets not
compare with facebook.. When we talk about github and do our reviews
there. It will be recorded there and if github goes down we will loose
our data. Also in case we need to relicense stuff it would be
impossible to track down contributor from github.

-- 
Bhushan Shah

http://bhush9.github.io
IRC Nick : bshah on Freenode
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Official KDE mirror on github

2015-09-19 Thread Bhushan Shah
On Sat, Sep 19, 2015 at 2:06 PM, Sune Vuorela <nos...@vuorela.dk> wrote:
> I personally feel a bit fucked over right now. All this started with a
> KDE github mirror and *just a mirror*. No pull requests. No bugtracker.
> No nothing else. Just a mirror. And it was repeatedly said in the thread
> that it would be just a mirror. Just a mirror.

And when we say mirror and if we start to accept pull request there it
will also complicate the sysadmin work if I know correctly

How would git.kde.org will stay up-to-date if you merged pull request
on github? This is one of the reason currently sysadmin allows pushes
on just git.kde.org and not on anongit.kde.org

When we say mirror its just mirror and just supposed to replicate our
git repository.

-- 
Bhushan Shah

http://bhush9.github.io
IRC Nick : bshah on Freenode
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Official KDE mirror on github

2015-08-17 Thread Bhushan Shah
On Mon, Aug 17, 2015 at 12:54 PM, Jos van den Oever
j...@vandenoever.info wrote:
 There is a (non-standard) instruction for robots.txt which reduces the crawl-
 frequency.
 E.g. Crawl-delay: 10 says only 10 requests per second are allowed.
 Neither projects.kde.org nor quickgit.kde.org are using this atm.

  
 http://stackoverflow.com/questions/17377835/robots-txt-what-is-the-proper-format-for-a-crawl-delay-for-multiple-user-agent

 If we do not let search engines index our primary product (source code), then
 it's not strange that people cannot find it.

There is no point in allowing to index whole source codes IMO. But as
sandsmark mentioned above there should be one page of where to find
source code, how to get it, and how to contribute further and that
should be indexed.

-- 
Bhushan Shah

http://bhush9.github.io
IRC Nick : bshah on Freenode
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Official KDE mirror on github

2015-08-17 Thread Bhushan Shah
Hi,

Thank you for starting this thread.

On Mon, Aug 17, 2015 at 12:24 PM, Jos Poortvliet
jospoortvl...@gmail.com wrote:
 On Monday 17 August 2015 07:46:44 Martin Graesslin wrote:
 Hi community,

 over the last months I observed the following:
 * people not finding our git repositories
 * people being surprised that our code is not on github
 * some projects starting to use github in addition to our own
 infrastructure


In my opinion first two are too wrong arguments to begin with.. If our
repositories can not be found from outside then it requires
improvement from our side. Putting source code on Github is not going
to solve this problem. Even if people will use github to search
projects eventually they will have to use our infrastructure to
contribute. And about people being surprised that our code is not on
Github, it is really clear that Github is _not_ standard place to get
open source software.



 I'd say the main benefit of Github is that it makes it easy for the many
 developers used to it to do a pull request - effectively widening our
 potential contributor base. Some might send in one or two minor pull
 requests, not being interested in becoming regular contributors, others might
 be convinced, after a few patches, to join KDE and then get on our
 infrastructure.

On other side it will be hard project management wise to monitor two
places for new patches/contributions.. and eventually people will
start to report bugs or issues there and that is going to be mess.. It
will be like someone fixes bug on our infrastructure just to realize
in end that someone sent pull requests on github.

Also there are some problems with Github that I am sure going to make
our sysadmins life little bit harder, like email address verification
and stuffs like that. We have seen this problems when importing code
from the Github.

So, In short IMO there is nothing wrong with having Github mirror but
that should be read-only and we should have real reason to do it.
Currently sysadmins are reworking our git infrastructure. So lets wait
little bit and see how it goes and then think of this.

Thanks!

-- 
Bhushan Shah

http://bhush9.github.io
IRC Nick : bshah on Freenode
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Your KDE highlight of 2014?

2014-12-20 Thread Bhushan Shah
On Fri, Dec 19, 2014 at 3:38 PM, Lydia Pintscher ly...@kde.org wrote:
 2014 is coming to an end. This gives us some time for reflection. What
 are your KDE highlights of 2014? A team that kicked ass? A really good
 release? An event where you made great new friends? Something entirely
 different?

Personal highlight for me was conf.kde.in 2014 and Akademy, as well as
Mentoring programs. GSoC, Season of KDE and Google code in. It was
nice experience participating in Google Summer of Code 2014 as student
and then sharing same knowledge by mentoring Season of KDE and Google
code in.

I just 3 this community. Lets hope we will rock upcoming year 2015.

-- 
Bhushan Shah

http://bhush9.github.io
IRC Nick : bshah on Freenode
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community