Re: Invent/gitlab, issues and bugzilla

[Ben Cooksley]

On Wed, 3 Jul 2019, 00:56 Luigi Toscano,  wrote:

> Hi,
>

Hi Luigi,


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

Or just apply the 2 year rule - it would mean waiting 2 years after
shipping a Dr Konqi with support for the new way though.


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

The intention originally when we started planning the migration to Gitlab
was that issues within Gitlab would be treated as an equivalent to
Phabricator Tasks - ie. for internal discussions only.

While I know there are people who do want to investigate the possibility of
dropping Bugzilla at some point, that is not something we are pursuing at
this time, and the intention is most certainly for user facing reports to
continue being done using bugs.kde.org (Bugzilla).


> --
> Luigi
>

Regards,
Ben

>

Re: Invent/gitlab, issues and bugzilla

[Jean-Baptiste Mardelle]

On 02.07.19 23:11, Albert Astals Cid wrote:

El dimarts, 2 de juliol de 2019, a les 14:55:41 CEST, Luigi Toscano va escriure:

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.


Having used gitlab issues quiet a lot in the last months for Kdenlive, I 
think it would be sad to completely disable them. Making them accessible 
to project members/developers only seems like a good compromise.


I like to use them as a development coordination tool, and for us it's a 
good replacement for phabricator's boards. I also find them more 
intuitive to use than phabricator, referencing an issue in a commit is 
as simple as putting #issue_number, while I never manage to reference or 
close phabricator tasks/diffs from commit messages despite checking the 
online doc (but that's probably my fault so not a real argument)...


Having the possibility to attach tasks to milestones is also a nice feature.

So +1 for developer only if this has to change.

Thanks, Jean-Baptiste

Sorry for any accidental spam.

[Ryan McCoskrie]

Just made my first submission to Phabricator and it took a few tries to get it 
right. Apologies if this caused a flood of review requests to anyone.

Re: Invent/gitlab, issues and bugzilla

[Albert Astals Cid]

El dimarts, 2 de juliol de 2019, a les 14:55:41 CEST, Luigi Toscano va escriure:
> 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.

+1 either close them or make them be "developer tasks". 

Cheers,
  Albert

> 
> 

Re: Invent/gitlab, issues and bugzilla

[Albert Astals Cid]

El dimarts, 2 de juliol de 2019, a les 15:48:43 CEST, Bhushan Shah va escriure:
> Hello,
> 
> and if it is our stance then we better close incubator
> projects..

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

Cheers,
  Albert

Re: Invent/gitlab, issues and bugzilla

[Christoph Cullmann]

On 2019-07-02 15:14, David Edmundson wrote:


Plasma Mobile projects are not included in bugzilla. So, gitlab issues
is the only "decent" alternative for bug tracking. If we disable
issues, then the only alternative I see is to report issues to
Phabricator, which, from my point of view, should be avoided.


Things can be added to bugzilla.


I think it would be highly appreciated to have just one Bugtracker for 
all
things and until further decisions are made if one wants or not to move 
away

from Bugzilla to just add all needed products/components there.

I think that is easier to understand for bug reporters and makes it much 
easier
to triage bugs that are some more generic framework/library issues 
occuring

in multiple end projects.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Invent/gitlab, issues and bugzilla

[Boudewijn Rempt]

On dinsdag 2 juli 2019 15:48:43 CEST Bhushan Shah wrote:

> b) open a bugzilla product for compatibility with drkonqi and keep using
>gitlab for internal issues/bugs.

One thing I really liked about phabricator tasks was that it was a way to track 
work independent (mostly) of user input. I kind of need to have a barrier 
between what users report and what the Krita developers see, because, well, 
most users cannot create a useful bug report without a lot of hand-holding.

-- 
https://www.krita.org

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

Re: Invent/gitlab, issues and bugzilla

[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: Contributor training feedback data

[Thomas Pfeiffer]

On 6/30/19 11:33 AM, Kenny Duffus wrote:
> On Saturday, 29 June 2019 23:33:13 BST Thomas Pfeiffer wrote:
>> We (the board) have not decided yet which trainings to offer at this
>> year's Akademy (but we have decided that we do want to offer trainings
>> in general!). We've gone through the survey results, thought about what
>> made sense to us as well and where we might find suitable trainers, and
>> are now in the process of trying to find trainers.
>>
> 
> Hi
> 
> Unfortunately this looks like it will result in similar problems with 
> training as last year where many people couldn't attend things they were 
> interested in
> 
> If people don't know well in advance (months) what training there will be 
> and on what days, they can't plan their dates for travel & accommodation 
> at Akademy

Good point. We could speed up the process by getting the community
involved in finding and getting in touch with trainers, so it's not all
on the board.
We'll see if we can find a good process for that.

Cheers,
Thomas

Re: Testbed Discourse Server For Trial discuss.kde.org.uk

[Thomas Pfeiffer]

On 7/1/19 9:02 AM, Valorie Zimmerman wrote:
> Hi all,
> 
> On Sun, Jun 30, 2019 at 10:48 AM Luigi Toscano  > wrote:
> 
> Nate Graham ha scritto:
> > On 6/29/19 4:04 PM, Thomas Pfeiffer wrote:
> >> Hi Jonathan,
> >> Thank you for setting this up!
> >> I've recently had the opportunity to experience Discourse in
> action in
> >> another community, and found it to fulfill most of the things we
> found
> >> lacking in both of our current forum and mailing list software (which
> >> makes sense given that they're both age-old and haven't seen much
> - if
> >> any - exciting feature development in years).
> >> So I (personally, not speaking for the board) would really like us to
> >> test it out and see if we can replace first our forum and
> hopefully some
> >> day Mailman with Discourse.
> >> Thanks,
> >> Thomas
> >>
> >
> > +1, I'm also quite in favor of this. Having used it in other
> communities, I
> > find that it works well as a sort of half-forum-half-mailing-list
> tool that
> > can succeed in replacing both.
> 
> I may have already asked this: do we have a plan to evaluate also
> hyperkitty
> (mailman 3 frontend) before completely replacing also the mailing
> lists? It
> provides a forum-like interface.
> 
> -- 
> Luigi
> 
> 
> I'm using the Mailman 3/hyperkitty for genealogy mail lists at
> Rootsweb.com. I was not in on the setup, which IMO is not done very well
> at Rootsweb, so maybe these comments are unfair.
> 
> So far though, I Do Not Like MM3, or hyperkittly. If there is a way to
> administer lists via the commandline, as we have now with Listadmin,
> I've not found it. Hyperkitty (besides being an extraordinarily bad
> name) is not a good forum replacement at ALL. The search barely works,
> for starters. True, the way our KDE list archives is set up is bad as well. 
> 
> That said, I'm not sold on Discourse. I've tried the one ubuntu has set
> up [1], and have not yet figured out how to get the email interface to
> work correctly. Aha, while clicking around in it I see that they didn't
> enable that feature. I find Discourse hard to move around it. I keep
> having to mess with the URL to get back to Home. So far, old mailman
> lists + IRC/T/Matrix wins. 
> 
> Whether Discourse could replace our KDE forums is an open question.

I haven't really tried Discourse's mailing features yet (apart from
getting digests of new forum messages), all I can say is that the forum
part is far better than our current forum (which isn't even
mobile-friendly at all).
That's why I said "forum first, mailman maybe at some point in the future".

Re: Invent/gitlab, issues and bugzilla

[David Edmundson]

>
> Plasma Mobile projects are not included in bugzilla. So, gitlab issues
> is the only "decent" alternative for bug tracking. If we disable
> issues, then the only alternative I see is to report issues to
> Phabricator, which, from my point of view, should be avoided.
>
Things can be added to bugzilla.

> - --

Re: Invent/gitlab, issues and bugzilla

[Dimitris Kardarakos]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2/7/19 3:55 μ.μ., 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.
> 

Plasma Mobile projects are not included in bugzilla. So, gitlab issues
is the only "decent" alternative for bug tracking. If we disable
issues, then the only alternative I see is to report issues to
Phabricator, which, from my point of view, should be avoided.

- -- 
Dimitris
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE8AvRG3JW8Vphs8uBrh0LWJZuDgwFAl0bWNQACgkQrh0LWJZu
Dgzi7g/+INhX7+oavknxLD+oaHDTqYiYlf2NSu4tU+/5DTka1aAb5+Lab//3fitX
LUBW5Lhi65XOhP5TGSQrKeZ6dNyG6oJARDKqUF4JoBz6Kn3zsVcgZTDySkRxqsoR
5V4BP76br7AFb8eZbvpkjiOutii1O9L0P/ca8jhkBK54gNZmYlF6MkLyBkUz3XyT
sq7d4c2IfvWGjbIvqqR9MJ+zSrAqRAJQsCYcKmOO6vL67P7mP0BPSqlOj1FiVWQZ
IhkpDutx2cuudEbe4ND1Ue/AX0osb5521uTZq0hkf6KP20d7DJU1ESpK07p4ipf7
EYNvWsa5TAdEFotT1NwCbBlBbtik/gMGdV5MyVu1G9tWqsk81mpU1nFvOJF/LKXd
HT7NYjCyC9T8l8+JnbSK5nRPzkN+goOxHRycsfo0spxb4LreT1+71FTcRf+bfL6o
DuLrdXhMYUDN90cg4CuHToln1KE8JWySPq39QYe06JnTaj0MZKxQof8w9O34dTyc
beiksAv8p69r9sqRD8A4SjyJasLmir8TkdbGT1izYBcADFjyO8sZ9dTCcNsVieDu
y3Up0dtPJBtiamFO0JgaghVf43BJu4TWVTgAqvPKiMfDJCUCOFW8RR63t0BhGf4c
b7h6AlccH8Elvm8E6/dqaqTnPRdM/p2/1U4gjSfq0XhTLSRzPcU=
=AdZ6
-END PGP SIGNATURE-


0xDD10816BA7DE60CE.asc
Description: application/pgp-keys


0xDD10816BA7DE60CE.asc.sig
Description: Binary data

Invent/gitlab, issues and bugzilla

[Luigi Toscano]

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