Re: migrating gtk

[Emmanuele Bassi]

On 16 April 2018 at 19:32, Emmanuele Bassi  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.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: migrating gtk

[Emmanuele Bassi]

Hi all;

it's time for an update.

On 2 February 2018 at 14:04, Matthias Clasen 
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.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: migrating gtk

[Bastien Nocera]

On Sat, 2018-02-10 at 16:43 +0100, Salvatore De Paolis wrote:
> On Thu, 08 Feb 2018 02:00:16 +
> Sriram Ramkrishna  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
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: migrating gtk

[Emmanuele Bassi]

On 10 February 2018 at 21:26, Kristian Rietveld  wrote:
>
>> On 05 Feb 2018, at 11:37, Emmanuele Bassi  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
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: migrating gtk

[Kristian Rietveld]

> On 05 Feb 2018, at 11:37, Emmanuele Bassi  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
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: migrating gtk

[Salvatore De Paolis]

On Thu, 08 Feb 2018 02:00:16 +
Sriram Ramkrishna  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
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: migrating gtk

[Sriram Ramkrishna]

On Tue, Feb 6, 2018 at 8:31 AM Matthias Clasen 
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
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: migrating gtk

[Matthias Clasen]

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
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: migrating gtk

[Alberto Ruiz]

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 :

> > 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  wrote:
> > On 5 February 2018 at 13:19, Morten Welinder  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 
> wrote:
> >>> On 4 February 2018 at 20:52, Morten Welinder 
> 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"?
> 

Re: migrating gtk

[Morten Welinder]

> 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  wrote:
> On 5 February 2018 at 13:19, Morten Welinder  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  wrote:
>>> On 4 February 2018 at 20:52, Morten Welinder  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 

Re: migrating gtk

[Ross Burton]

On 5 February 2018 at 14:15, Emmanuele Bassi  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
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: migrating gtk

[Emmanuele Bassi]

On 5 February 2018 at 13:19, Morten Welinder  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  wrote:
>> On 4 February 2018 at 20:52, Morten Welinder  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
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: migrating gtk

[Morten Welinder]

> 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  wrote:
> On 4 February 2018 at 20:52, Morten Welinder  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
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

> On 4 February 2018 at 20:52, Morten Welinder  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
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: migrating gtk

[Emmanuele Bassi]

On 4 February 2018 at 20:52, Morten Welinder  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
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: migrating gtk

[Morten Welinder]

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
 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
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: migrating gtk

[Emmanuele Bassi]

On 2 February 2018 at 15:04, Matthias Clasen  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
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list