[prev in list] [next in list] [prev in thread] [next in thread]
List: gtk-devel
Subject: Re: migrating gtk
From: Carlos Soriano <csoriano () gnome ! org>
Date: 2018-02-05 13:17:59
Message-ID: CAFGeHnCyhzd+C6Su=7d_drWCxj0XPS=ic28su6fQ18TOkLQmyg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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 <ebassi@gmail.com> wrote:
> On 4 February 2018 at 20:52, Morten Welinder <mortenw@gnome.org> 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
>
[Attachment #5 (text/html)]
<div dir="ltr"><div><div>Hey Matthias,<br><br></div>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+.</div><div><br></div><div>Just to double check, the idea of having a \
different repo/project for each gtk version was discussed but didn't pass right?</div><div \
class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div \
class="gmail_extra">Carlos Soriano<br clear="all"></div><div class="gmail_extra"> <br><div \
class="gmail_quote">On 5 February 2018 at 11:37, Emmanuele Bassi <span dir="ltr"><<a \
href="mailto:ebassi@gmail.com" target="_blank">ebassi@gmail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span class="">On 4 February 2018 at 20:52, Morten Welinder <<a \
href="mailto:mortenw@gnome.org">mortenw@gnome.org</a>> wrote:<br> > As a general \
principle, you should only ask bug reporters to do work if you<br> > intend to do something \
with the answer. Or, with other words, it really is<br> > not nice to keep asking "is \
that bug still there?" until they get tired of the<br> > busywork and leave in \
disgust.<br> <br>
</span>The busywork meaning "attaching a patch and iterating over it"?<br>
Considering that you usually stop short of the first step I have to<br>
ask you: what kind of "busywork" have you ever experienced?<br>
<br>
Of course if we get a positive response that the bug is still there<br>
we're going to migrate it and keep track of it.<br>
<span class=""><br>
> With that in mind, I believe it is much nicer to just leave the old bugs there.<br>
<br>
</span>The old bugs will be left there, but closed, so we don't need to check<br>
two bug lists, and split the maintenance resources even more.<br>
<span class=""><br>
> We never got around to solving the reporter's problem, but at least we did<br>
> not add to the pain by asking them to do work and report back, only to<br>
> ignore the result of that. Doing that is quite rude.<br>
<br>
</span>Of course it is, that's why we generally don't do that — except,<br>
maybe, for rude bug reporters.<br>
<br>
Ciao,<br>
Emmanuele.<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
gtk-devel-list mailing list<br>
<a href="mailto:gtk-devel-list@gnome.org">gtk-devel-list@gnome.org</a><br>
<a href="https://mail.gnome.org/mailman/listinfo/gtk-devel-list" rel="noreferrer" \
target="_blank">https://mail.gnome.org/<wbr>mailman/listinfo/gtk-devel-<wbr>list</a><br> \
</div></div></blockquote></div><br></div></div>
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic