migrating gtk

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

migrating gtk

Matthias Clasen-2
Hey Carlos,

we discussed gitlab migration for gtk here at the hackfest. Our conclusions were as follows:

* We want to migrate the git repository as soon as possible
* For bugs:
  * Do a sweep now, close all >5 year old bugs, needinfo all >1 old ones
  * Wait a few weeks, then close the needinfoed bugs that didn't get a response
  * Triage the rest
  * Migrate what's left at the end

Does this sound plausible to you ?

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: migrating gtk

Emmanuele Bassi
On 2 February 2018 at 15:04, Matthias Clasen <[hidden email]> wrote:

> Hey Carlos,
>
> we discussed gitlab migration for gtk here at the hackfest. Our conclusions
> were as follows:
>
> * We want to migrate the git repository as soon as possible
> * For bugs:
>   * Do a sweep now, close all >5 year old bugs, needinfo all >1 old ones
>   * Wait a few weeks, then close the needinfoed bugs that didn't get a
> response
>   * Triage the rest
>   * Migrate what's left at the end
>
> Does this sound plausible to you ?

Additionally, it would be great if we could set up the GTK+ issue
tracker on GitLab with all the tags coming from Bugzilla before we
start migrating issues — i.e. run the bztogl script to create all the
tags, and bail out right before it starts migrating the issues.

Ciao,
 Emmanuele.

--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: migrating gtk

Morten Welinder-2
In reply to this post by Matthias Clasen-2
As a general principle, you should only ask bug reporters to do work if you
intend to do something with the answer.  Or, with other words, it really is
not nice to keep asking "is that bug still there?" until they get tired of the
busywork and leave in disgust.

With that in mind, I believe it is much nicer to just leave the old bugs there.
We never got around to solving the reporter's problem, but at least we did
not add to the pain by asking them to do work and report back, only to
ignore the result of that.  Doing that is quite rude.

Morten








On Fri, Feb 2, 2018 at 9:04 AM, Matthias Clasen
<[hidden email]> wrote:

> Hey Carlos,
>
> we discussed gitlab migration for gtk here at the hackfest. Our conclusions
> were as follows:
>
> * We want to migrate the git repository as soon as possible
> * For bugs:
>   * Do a sweep now, close all >5 year old bugs, needinfo all >1 old ones
>   * Wait a few weeks, then close the needinfoed bugs that didn't get a
> response
>   * Triage the rest
>   * Migrate what's left at the end
>
> Does this sound plausible to you ?
>
> _______________________________________________
> gtk-devel-list mailing list
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: migrating gtk

Emmanuele Bassi
On 4 February 2018 at 20:52, Morten Welinder <[hidden email]> wrote:
> As a general principle, you should only ask bug reporters to do work if you
> intend to do something with the answer.  Or, with other words, it really is
> not nice to keep asking "is that bug still there?" until they get tired of the
> busywork and leave in disgust.

The busywork meaning "attaching a patch and iterating over it"?
Considering that you usually stop short of the first step I have to
ask you: what kind of "busywork" have you ever experienced?

Of course if we get a positive response that the bug is still there
we're going to migrate it and keep track of it.

> With that in mind, I believe it is much nicer to just leave the old bugs there.

The old bugs will be left there, but closed, so we don't need to check
two bug lists, and split the maintenance resources even more.

> We never got around to solving the reporter's problem, but at least we did
> not add to the pain by asking them to do work and report back, only to
> ignore the result of that.  Doing that is quite rude.

Of course it is, that's why we generally don't do that — except,
maybe, for rude bug reporters.

Ciao,
 Emmanuele.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: migrating gtk

Carlos Soriano
Hey Matthias,

Sounds good. In the short experience with the migration it looks like it worked well to be as strict as possible, meaning, migrating the only the most relevant bugs. I would also take the opportunity to ack/nack pending patches if that is possible for gtk+.

Just to double check, the idea of having a different repo/project for each gtk version was discussed but didn't pass right?

Cheers,
Carlos Soriano

On 5 February 2018 at 11:37, Emmanuele Bassi <[hidden email]> wrote:
On 4 February 2018 at 20:52, Morten Welinder <[hidden email]> wrote:
> As a general principle, you should only ask bug reporters to do work if you
> intend to do something with the answer.  Or, with other words, it really is
> not nice to keep asking "is that bug still there?" until they get tired of the
> busywork and leave in disgust.

The busywork meaning "attaching a patch and iterating over it"?
Considering that you usually stop short of the first step I have to
ask you: what kind of "busywork" have you ever experienced?

Of course if we get a positive response that the bug is still there
we're going to migrate it and keep track of it.

> With that in mind, I believe it is much nicer to just leave the old bugs there.

The old bugs will be left there, but closed, so we don't need to check
two bug lists, and split the maintenance resources even more.

> We never got around to solving the reporter's problem, but at least we did
> not add to the pain by asking them to do work and report back, only to
> ignore the result of that.  Doing that is quite rude.

Of course it is, that's why we generally don't do that — except,
maybe, for rude bug reporters.

Ciao,
 Emmanuele.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: migrating gtk

Morten Welinder-2
In reply to this post by Emmanuele Bassi
> Considering that you usually stop short of the first step I have to
> ask you: what kind of "busywork" have you ever experienced?

Here's a sample:
https://bugzilla.gnome.org/show_bug.cgi?id=694627#c7

Yes, that was you.  What did you really gain from asking that
question, other than verifying that I read my email?

The more typical sample -- not recently practiced by gtk+ -- is mass
moving of bugs into NEEDINFO with a note saying something like
"This bug was reported for version x.y. Please test if it still applies.  If
we get no response, this bug will be closed in 30 days."

The reason I call that busywork is that you can actually do as asked
only to repeat the whole thing in a year when no-one has looked at
in the meantime.  And repeat it a year after that.  And multiply all that
by the number of open bugs you have.

Quite frankly, the rational response to such periodic requests is to
simply answer "the bug is still there" without going through the work
of checking.  That's rational for the bug reporter because it preserves
the investment of time that was put into reporting the bug without
spending more maintaining an large portfolio of open bugs.

I understand that there can be a desire to close bugs unfixed.  What I
object to is sending them through NEEDINFO and then ignoring them.
That route should be reserved for bugs you intend to work on as soon
as the requested info arrives and for cases where you believe the bug
is actually fixed, but just want confirmation from the reporter.

> Of course it is, that's why we generally don't do that — except,
> maybe, for rude bug reporters.

You really don't like to be called out, do you?  (And, yes, I know I am
occasionally and deliberately rude.  The email you responded to was
not rude; it's just that you don't take criticism well, if at all.)

I hope we can agree that bug reporters are volunteer contributors to
the project and that they should be treated with respect.

Morten








On Mon, Feb 5, 2018 at 5:37 AM, Emmanuele Bassi <[hidden email]> wrote:

> On 4 February 2018 at 20:52, Morten Welinder <[hidden email]> wrote:
>> As a general principle, you should only ask bug reporters to do work if you
>> intend to do something with the answer.  Or, with other words, it really is
>> not nice to keep asking "is that bug still there?" until they get tired of the
>> busywork and leave in disgust.
>
> The busywork meaning "attaching a patch and iterating over it"?
> Considering that you usually stop short of the first step I have to
> ask you: what kind of "busywork" have you ever experienced?
>
> Of course if we get a positive response that the bug is still there
> we're going to migrate it and keep track of it.
>
>> With that in mind, I believe it is much nicer to just leave the old bugs there.
>
> The old bugs will be left there, but closed, so we don't need to check
> two bug lists, and split the maintenance resources even more.
>
>> We never got around to solving the reporter's problem, but at least we did
>> not add to the pain by asking them to do work and report back, only to
>> ignore the result of that.  Doing that is quite rude.
>
> Of course it is, that's why we generally don't do that — except,
> maybe, for rude bug reporters.
>
> Ciao,
>  Emmanuele.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: migrating gtk

Emmanuele Bassi
On 5 February 2018 at 13:19, Morten Welinder <[hidden email]> wrote:
>> Considering that you usually stop short of the first step I have to
>> ask you: what kind of "busywork" have you ever experienced?
>
> Here's a sample:
> https://bugzilla.gnome.org/show_bug.cgi?id=694627#c7
>
> Yes, that was you.  What did you really gain from asking that
> question, other than verifying that I read my email?

I gained the fact that you read your email and if you're still
experiencing the issue, or if it was accidentally fixed in the ~4
years between your original report and me going through the open bugs
of gobject-introspection. That's why it was marked as NEEDINFO.

As soon as you replied, the bug was reinstated as NEW and will be
migrated to the gobject-introspection repository on gitlab.gnome.org.

> The more typical sample -- not recently practiced by gtk+ -- is mass
> moving of bugs into NEEDINFO with a note saying something like
> "This bug was reported for version x.y. Please test if it still applies.  If
> we get no response, this bug will be closed in 30 days."

Which is what Matthias has said we're going to do in the email you
replied to — and it's also implied in the NEEDINFO state as it's used
by GNOME projects.

> The reason I call that busywork is that you can actually do as asked
> only to repeat the whole thing in a year when no-one has looked at
> in the meantime.  And repeat it a year after that.  And multiply all that
> by the number of open bugs you have.

Oh, I'm sorry you're *so* inconvenienced by volunteers trying to get
the bug count under control, and cannot replicate every single set up
from 5 years ago.

> Quite frankly, the rational response to such periodic requests is to
> simply answer "the bug is still there" without going through the work
> of checking.

So, you're basically just making shit up?

That's *really* great to know, because now I won't feel compelled at
all to act on bug reports coming from you.

Next time, either don't bother, or just be a decent human being, and
answer "I don't know".

>  That's rational for the bug reporter because it preserves
> the investment of time that was put into reporting the bug without
> spending more maintaining an large portfolio of open bugs.

That's the "rational" thing to do if you're just abusing the ecosystem
you're taking advantage of.

Again, that's a great thing to know.

>> Of course it is, that's why we generally don't do that — except,
>> maybe, for rude bug reporters.
>
> You really don't like to be called out, do you?  (And, yes, I know I am
> occasionally and deliberately rude.  The email you responded to was
> not rude; it's just that you don't take criticism well, if at all.)

Your behaviour on this mailing list, and on Bugzilla, has been
consistently rude, inconsiderate, and plain abusive of the patience
and effort that volunteers put in the platform you're consuming.

You've been called out before, multiple times, about this.

Of course, you can now spin it the way you want it, and say it's me
that doesn't like being called out. I'll just remember it for the next
time you open a bug, explaining what *I* have to do, without even
bothering to attach a patch. Or reply "this bug still exists" without
testing it, because you're too busy with your own stuff.

Ciao,
 Emmanuele.

> On Mon, Feb 5, 2018 at 5:37 AM, Emmanuele Bassi <[hidden email]> wrote:
>> On 4 February 2018 at 20:52, Morten Welinder <[hidden email]> wrote:
>>> As a general principle, you should only ask bug reporters to do work if you
>>> intend to do something with the answer.  Or, with other words, it really is
>>> not nice to keep asking "is that bug still there?" until they get tired of the
>>> busywork and leave in disgust.
>>
>> The busywork meaning "attaching a patch and iterating over it"?
>> Considering that you usually stop short of the first step I have to
>> ask you: what kind of "busywork" have you ever experienced?
>>
>> Of course if we get a positive response that the bug is still there
>> we're going to migrate it and keep track of it.
>>
>>> With that in mind, I believe it is much nicer to just leave the old bugs there.
>>
>> The old bugs will be left there, but closed, so we don't need to check
>> two bug lists, and split the maintenance resources even more.
>>
>>> We never got around to solving the reporter's problem, but at least we did
>>> not add to the pain by asking them to do work and report back, only to
>>> ignore the result of that.  Doing that is quite rude.
>>
>> Of course it is, that's why we generally don't do that — except,
>> maybe, for rude bug reporters.
>>
>> Ciao,
>>  Emmanuele.



--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: migrating gtk

Ross Burton
On 5 February 2018 at 14:15, Emmanuele Bassi <[hidden email]> wrote:
I gained the fact that you read your email and if you're still
experiencing the issue, or if it was accidentally fixed in the ~4
years between your original report and me going through the open bugs
of gobject-introspection. That's why it was marked as NEEDINFO.

For what its worth we do this in the Yocto bugzilla too.  Bugs get pushed to NEEDINFO if the assignee can't replicate/understand/etc, and the reporter will get about two months of pings to provide more useful information. If there's silence then the bug is closed.

Ross

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: migrating gtk

Morten Welinder-2
In reply to this post by Emmanuele Bassi
> Your behaviour on this mailing list, and on Bugzilla, has been
> consistently rude, inconsiderate, and plain abusive of the patience
> and effort that volunteers put in the platform you're consuming.

You have absolutely no respect for the work of other volunteers to the gtk+
project or for people whose opinions aren't aligned with you.  You put a high
value on your own disruptive work, and a value of zero on anyone else.

So, yeah, I don't like you.  And you probably don't like me.

Morten








On Mon, Feb 5, 2018 at 9:15 AM, Emmanuele Bassi <[hidden email]> wrote:

> On 5 February 2018 at 13:19, Morten Welinder <[hidden email]> wrote:
>>> Considering that you usually stop short of the first step I have to
>>> ask you: what kind of "busywork" have you ever experienced?
>>
>> Here's a sample:
>> https://bugzilla.gnome.org/show_bug.cgi?id=694627#c7
>>
>> Yes, that was you.  What did you really gain from asking that
>> question, other than verifying that I read my email?
>
> I gained the fact that you read your email and if you're still
> experiencing the issue, or if it was accidentally fixed in the ~4
> years between your original report and me going through the open bugs
> of gobject-introspection. That's why it was marked as NEEDINFO.
>
> As soon as you replied, the bug was reinstated as NEW and will be
> migrated to the gobject-introspection repository on gitlab.gnome.org.
>
>> The more typical sample -- not recently practiced by gtk+ -- is mass
>> moving of bugs into NEEDINFO with a note saying something like
>> "This bug was reported for version x.y. Please test if it still applies.  If
>> we get no response, this bug will be closed in 30 days."
>
> Which is what Matthias has said we're going to do in the email you
> replied to — and it's also implied in the NEEDINFO state as it's used
> by GNOME projects.
>
>> The reason I call that busywork is that you can actually do as asked
>> only to repeat the whole thing in a year when no-one has looked at
>> in the meantime.  And repeat it a year after that.  And multiply all that
>> by the number of open bugs you have.
>
> Oh, I'm sorry you're *so* inconvenienced by volunteers trying to get
> the bug count under control, and cannot replicate every single set up
> from 5 years ago.
>
>> Quite frankly, the rational response to such periodic requests is to
>> simply answer "the bug is still there" without going through the work
>> of checking.
>
> So, you're basically just making shit up?
>
> That's *really* great to know, because now I won't feel compelled at
> all to act on bug reports coming from you.
>
> Next time, either don't bother, or just be a decent human being, and
> answer "I don't know".
>
>>  That's rational for the bug reporter because it preserves
>> the investment of time that was put into reporting the bug without
>> spending more maintaining an large portfolio of open bugs.
>
> That's the "rational" thing to do if you're just abusing the ecosystem
> you're taking advantage of.
>
> Again, that's a great thing to know.
>
>>> Of course it is, that's why we generally don't do that — except,
>>> maybe, for rude bug reporters.
>>
>> You really don't like to be called out, do you?  (And, yes, I know I am
>> occasionally and deliberately rude.  The email you responded to was
>> not rude; it's just that you don't take criticism well, if at all.)
>
> Your behaviour on this mailing list, and on Bugzilla, has been
> consistently rude, inconsiderate, and plain abusive of the patience
> and effort that volunteers put in the platform you're consuming.
>
> You've been called out before, multiple times, about this.
>
> Of course, you can now spin it the way you want it, and say it's me
> that doesn't like being called out. I'll just remember it for the next
> time you open a bug, explaining what *I* have to do, without even
> bothering to attach a patch. Or reply "this bug still exists" without
> testing it, because you're too busy with your own stuff.
>
> Ciao,
>  Emmanuele.
>
>> On Mon, Feb 5, 2018 at 5:37 AM, Emmanuele Bassi <[hidden email]> wrote:
>>> On 4 February 2018 at 20:52, Morten Welinder <[hidden email]> wrote:
>>>> As a general principle, you should only ask bug reporters to do work if you
>>>> intend to do something with the answer.  Or, with other words, it really is
>>>> not nice to keep asking "is that bug still there?" until they get tired of the
>>>> busywork and leave in disgust.
>>>
>>> The busywork meaning "attaching a patch and iterating over it"?
>>> Considering that you usually stop short of the first step I have to
>>> ask you: what kind of "busywork" have you ever experienced?
>>>
>>> Of course if we get a positive response that the bug is still there
>>> we're going to migrate it and keep track of it.
>>>
>>>> With that in mind, I believe it is much nicer to just leave the old bugs there.
>>>
>>> The old bugs will be left there, but closed, so we don't need to check
>>> two bug lists, and split the maintenance resources even more.
>>>
>>>> We never got around to solving the reporter's problem, but at least we did
>>>> not add to the pain by asking them to do work and report back, only to
>>>> ignore the result of that.  Doing that is quite rude.
>>>
>>> Of course it is, that's why we generally don't do that — except,
>>> maybe, for rude bug reporters.
>>>
>>> Ciao,
>>>  Emmanuele.
>
>
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: migrating gtk

Alberto Ruiz-4
Hi everyone,

can we please stop the ad hominems and stick to constructive suggestions to improve things please? this is becoming disgusting and is a poor display of community dynamics

Thank you.

2018-02-05 16:36 GMT+01:00 Morten Welinder <[hidden email]>:
> Your behaviour on this mailing list, and on Bugzilla, has been
> consistently rude, inconsiderate, and plain abusive of the patience
> and effort that volunteers put in the platform you're consuming.

You have absolutely no respect for the work of other volunteers to the gtk+
project or for people whose opinions aren't aligned with you.  You put a high
value on your own disruptive work, and a value of zero on anyone else.

So, yeah, I don't like you.  And you probably don't like me.

Morten








On Mon, Feb 5, 2018 at 9:15 AM, Emmanuele Bassi <[hidden email]> wrote:
> On 5 February 2018 at 13:19, Morten Welinder <[hidden email]> wrote:
>>> Considering that you usually stop short of the first step I have to
>>> ask you: what kind of "busywork" have you ever experienced?
>>
>> Here's a sample:
>> https://bugzilla.gnome.org/show_bug.cgi?id=694627#c7
>>
>> Yes, that was you.  What did you really gain from asking that
>> question, other than verifying that I read my email?
>
> I gained the fact that you read your email and if you're still
> experiencing the issue, or if it was accidentally fixed in the ~4
> years between your original report and me going through the open bugs
> of gobject-introspection. That's why it was marked as NEEDINFO.
>
> As soon as you replied, the bug was reinstated as NEW and will be
> migrated to the gobject-introspection repository on gitlab.gnome.org.
>
>> The more typical sample -- not recently practiced by gtk+ -- is mass
>> moving of bugs into NEEDINFO with a note saying something like
>> "This bug was reported for version x.y. Please test if it still applies.  If
>> we get no response, this bug will be closed in 30 days."
>
> Which is what Matthias has said we're going to do in the email you
> replied to — and it's also implied in the NEEDINFO state as it's used
> by GNOME projects.
>
>> The reason I call that busywork is that you can actually do as asked
>> only to repeat the whole thing in a year when no-one has looked at
>> in the meantime.  And repeat it a year after that.  And multiply all that
>> by the number of open bugs you have.
>
> Oh, I'm sorry you're *so* inconvenienced by volunteers trying to get
> the bug count under control, and cannot replicate every single set up
> from 5 years ago.
>
>> Quite frankly, the rational response to such periodic requests is to
>> simply answer "the bug is still there" without going through the work
>> of checking.
>
> So, you're basically just making shit up?
>
> That's *really* great to know, because now I won't feel compelled at
> all to act on bug reports coming from you.
>
> Next time, either don't bother, or just be a decent human being, and
> answer "I don't know".
>
>>  That's rational for the bug reporter because it preserves
>> the investment of time that was put into reporting the bug without
>> spending more maintaining an large portfolio of open bugs.
>
> That's the "rational" thing to do if you're just abusing the ecosystem
> you're taking advantage of.
>
> Again, that's a great thing to know.
>
>>> Of course it is, that's why we generally don't do that — except,
>>> maybe, for rude bug reporters.
>>
>> You really don't like to be called out, do you?  (And, yes, I know I am
>> occasionally and deliberately rude.  The email you responded to was
>> not rude; it's just that you don't take criticism well, if at all.)
>
> Your behaviour on this mailing list, and on Bugzilla, has been
> consistently rude, inconsiderate, and plain abusive of the patience
> and effort that volunteers put in the platform you're consuming.
>
> You've been called out before, multiple times, about this.
>
> Of course, you can now spin it the way you want it, and say it's me
> that doesn't like being called out. I'll just remember it for the next
> time you open a bug, explaining what *I* have to do, without even
> bothering to attach a patch. Or reply "this bug still exists" without
> testing it, because you're too busy with your own stuff.
>
> Ciao,
>  Emmanuele.
>
>> On Mon, Feb 5, 2018 at 5:37 AM, Emmanuele Bassi <[hidden email]> wrote:
>>> On 4 February 2018 at 20:52, Morten Welinder <[hidden email]> wrote:
>>>> As a general principle, you should only ask bug reporters to do work if you
>>>> intend to do something with the answer.  Or, with other words, it really is
>>>> not nice to keep asking "is that bug still there?" until they get tired of the
>>>> busywork and leave in disgust.
>>>
>>> The busywork meaning "attaching a patch and iterating over it"?
>>> Considering that you usually stop short of the first step I have to
>>> ask you: what kind of "busywork" have you ever experienced?
>>>
>>> Of course if we get a positive response that the bug is still there
>>> we're going to migrate it and keep track of it.
>>>
>>>> With that in mind, I believe it is much nicer to just leave the old bugs there.
>>>
>>> The old bugs will be left there, but closed, so we don't need to check
>>> two bug lists, and split the maintenance resources even more.
>>>
>>>> We never got around to solving the reporter's problem, but at least we did
>>>> not add to the pain by asking them to do work and report back, only to
>>>> ignore the result of that.  Doing that is quite rude.
>>>
>>> Of course it is, that's why we generally don't do that — except,
>>> maybe, for rude bug reporters.
>>>
>>> Ciao,
>>>  Emmanuele.
>
>
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list



--
Cheers,
Alberto Ruiz

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: migrating gtk

Matthias Clasen-2
In reply to this post by Morten Welinder-2
I will ignore the childish name-calling here and just state that as far as I am concerned,
the bugs you file are donations to the project. What we do with them is up to us. If we decide
to fix them, good for you. If not, that's tough and annoying, but lets face it: there is an infinite
number of bug reporters out there, and only a handful of people who spend their free time trying
to keep up with it, so some bugs will always go unfixed, that is just reality.


_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: migrating gtk

Sriram Ramkrishna


On Tue, Feb 6, 2018 at 8:31 AM Matthias Clasen <[hidden email]> wrote:
I will ignore the childish name-calling here and just state that as far as I am concerned,
the bugs you file are donations to the project. What we do with them is up to us. If we decide
to fix them, good for you. If not, that's tough and annoying, but lets face it: there is an infinite
number of bug reporters out there, and only a handful of people who spend their free time trying
to keep up with it, so some bugs will always go unfixed, that is just reality.



Much as I would hate to extend this conversation beyond what was said; I felt compelled to comment.  I feel like this is not a very positive message to send to the overall community.

While brutally true, there is an underlying messaging that encourages a "why bother?" response from potential contributors.  I am sure that is not that the intent but messaging is important. 

While none of you are PR people and tend to dispense with messaging in lieu of fortright conversations - I would like to point out that if we want to increase resources for GTK+ and not be a small group of overworked core GTK+ people the first step is ensure that we are a community worth investing time and effort in.

Every contributor who takes an actionable step and reports a bug is a potential future core contributor.  Please remember that.  A person who attempts to fix a bug with a patch is even more valuable.

Cheers,
sri

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: migrating gtk

Salvatore De Paolis-6
On Thu, 08 Feb 2018 02:00:16 +0000
Sriram Ramkrishna <[hidden email]> wrote:

> Every contributor who takes an actionable step and reports a bug is a
> potential future core contributor.  Please remember that.  A person who
> attempts to fix a bug with a patch is even more valuable.

It's a waste of time, I just received today a bug I reported from 2010. Sadly
I prefer to move to some other project which cares of application developers.
Maybe one day GTK+ will be fine, maybe not.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: migrating gtk

Kristian Rietveld-4
In reply to this post by Emmanuele Bassi

> On 05 Feb 2018, at 11:37, Emmanuele Bassi <[hidden email]> wrote:
>
> Of course if we get a positive response that the bug is still there
> we're going to migrate it and keep track of it.
>
>> With that in mind, I believe it is much nicer to just leave the old bugs there.
>
> The old bugs will be left there, but closed, so we don't need to check
> two bug lists, and split the maintenance resources even more.


What about old bugs that will not receive a response right now / in the very near future? Can these still be migrated at a later point? I gather there’s a script to do this on a case-by-case basis?

And I assume all data in bugzilla.gnome.org will remain accessible for quite some time to come? This is an important archive of information.



regards,

-kris.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: migrating gtk

Emmanuele Bassi
On 10 February 2018 at 21:26, Kristian Rietveld <[hidden email]> wrote:

>
>> On 05 Feb 2018, at 11:37, Emmanuele Bassi <[hidden email]> wrote:
>>
>> Of course if we get a positive response that the bug is still there
>> we're going to migrate it and keep track of it.
>>
>>> With that in mind, I believe it is much nicer to just leave the old bugs there.
>>
>> The old bugs will be left there, but closed, so we don't need to check
>> two bug lists, and split the maintenance resources even more.
>
>
> What about old bugs that will not receive a response right now / in the very near future? Can these still be migrated at a later point? I gather there’s a script to do this on a case-by-case basis?

The script only moves open bugs; moving closed bugs for GTK would be
quite a move, and would not really preserve the history anyway,
because the bug numbers would be different, and because the
projects/products would not match.

If a bug does not receive any feedback in the allotted time, then
it'll stay on Bugzilla.

> And I assume all data in bugzilla.gnome.org will remain accessible for quite some time to come? This is an important archive of information.

Yes, Bugzilla will remain available for existing bug for the
foreseeable future. Even in case we closed down Bugzilla for good, we
have plans to turn it into a static website, for archival purposes.

Ciao,
 Emmanuele.

--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: migrating gtk

Bastien Nocera
In reply to this post by Salvatore De Paolis-6
On Sat, 2018-02-10 at 16:43 +0100, Salvatore De Paolis wrote:

> On Thu, 08 Feb 2018 02:00:16 +0000
> Sriram Ramkrishna <[hidden email]> wrote:
>
> > Every contributor who takes an actionable step and reports a bug is
> > a
> > potential future core contributor.  Please remember that.  A person
> > who
> > attempts to fix a bug with a patch is even more valuable.
>
> It's a waste of time, I just received today a bug I reported from
> 2010. Sadly
> I prefer to move to some other project which cares of application
> developers.
> Maybe one day GTK+ will be fine, maybe not.

For those playing at home, it's this one:
https://bugzilla.gnome.org/show_bug.cgi?id=584402

Maybe re-testing and reopening the bug if it still applies would be
useful. I'm not going to blame you for giving up, but patches inside
the comments, and no clear test case for the bug means it's very very
time-consuming to reproduce let alone fix.

This problem is going to apply to more projects than just GTK+,
especially those with nearly 2000 bugs opened against them.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: migrating gtk

Emmanuele Bassi
In reply to this post by Matthias Clasen-2
Hi all;

it's time for an update.

On 2 February 2018 at 14:04, Matthias Clasen <[hidden email]> wrote:
Hey Carlos,

we discussed gitlab migration for gtk here at the hackfest. Our conclusions were as follows:

* We want to migrate the git repository as soon as possible

The repository was migrated successfully, and we've been using it for the past two months. There is a redirect in place for git.gnome.org URLs that will automatically take you to gitlab.gnome.org for GTK; the only thing that changed is the Git push URL for people that have the commit bit set and a GNOME Git account.

Switching to GitLab allowed us to benefit from things like automated CI (build and tests) for branches and merge requests; we're also building Flatpak versions of gtk-demo and gtk-widget-factory on master, so you can ask other people to immediately test your changes without having to rebuild GTK and deal with its dependencies. Also on the CI side, we have a Windows CI runner, which means that master is currently build tested using MSYS2. It would be stellar if we could get a MSVC and a macOS runners as well.

* For bugs:
  * Do a sweep now, close all >5 year old bugs, needinfo all >1 old ones

This has been done.
 
  * Wait a few weeks, then close the needinfoed bugs that didn't get a response
  * Triage the rest

We waited 2 months, and now all the bugs left in NEEDINFO state have been closed.

Additionally, we've set up redirections so that going to Bugzilla to file a new issue will automatically send you to the Issues page on GitLab.

  * Migrate what's left at the end

We're in the process of migrating: https://gitlab.gnome.org/Infrastructure/GitLab/issues/228

This will take a while once it starts; I'll send another email to the list to notify when the process starts and ends.

Ciao,
 Emmanuele.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: migrating gtk

Emmanuele Bassi
On 16 April 2018 at 19:32, Emmanuele Bassi <[hidden email]> wrote:

  * Migrate what's left at the end

We're in the process of migrating: https://gitlab.gnome.org/Infrastructure/GitLab/issues/228

This will take a while once it starts; I'll send another email to the list to notify when the process starts and ends.

Quick addendum: do **not** migrate open bugs manually from Bugzilla to GitLab.

If a bug is still open, it will be automatically migrated, with all comments and attachments, to GitLab, and the old issue in Bugzilla will be closed with a link to the new location.

If a bug has been closed already as part of the Bugzilla clean up, you can open a new issue in GitLab manually, linking to the old issue in Bugzilla.

Ciao,
 Emmanuele.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list