[gentoo-dev] Gentoo Bugday

[gentoo-dev] Gentoo Bugday

[Pavlos Ratis]

Hello everyone,

I would like to announce you a new try to 'revive' the Bugday event.
As most of the open source projects have their own bugday, I thought
it would be great to have this event back.  For those who don't know,
its a monthly 24h event that takes place in #gentoo-bugs. Its goal is
to close as many bugs as possible . You don't have to be a Gentoo
expert to participate. Those days are a great way to start joining the
Gentoo community, improving Bugzilla's and Wiki's quality and looking
for a mentor to begin the recruitment process. The upcoming bugday
event is this Saturday and I hope this event will continue in the next
months. I have created a wiki page for the event[1] and I added some
guidelines. I have also created a related blog post about the
event[2].

I have listed some maintainer-wanted and maintainer-need bugs and
Bugzilla admins also re-enabled the bugday flag. I would like to ask
the Gentoo project teams to start using this flag to their bugs that
think that are good to start and enable the flag at them. It would be
great to a have a really big list with 'good to start' bugs.

It's the first time after a long time that this event will take place,
so I am looking forward to your participation both users and
developers and your feedback.

[1] http://wiki.gentoo.org/wiki/Bugday
[2] http://blog.dastergon.gr/gentoo-bugday/

Thanks,
Pavlos

Re: [gentoo-dev] Gentoo Bugday

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

On 2/26/13 4:39 PM, Pavlos Ratis wrote:
> I would like to announce you a new try to 'revive' the Bugday event.

This is excellent! Thank you for your work on this.

> I have listed some maintainer-wanted and maintainer-need bugs and
> Bugzilla admins also re-enabled the bugday flag. I would like to ask
> the Gentoo project teams to start using this flag to their bugs that
> think that are good to start and enable the flag at them. It would be
> great to a have a really big list with 'good to start' bugs.

I'm going to look over chromium@ bugs, but consider also arch testing
bugs (STABLEREQ) relevant - just avoid people making too much noise.

1-2 success reports are enough, and the more testing we can get before
actually stabilizing, the better.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

[gentoo-dev] Re: Gentoo Bugday

[Michael Palimaka]

On 27/02/2013 11:39, Pavlos Ratis wrote:
> Hello everyone,
>
> I would like to announce you a new try to 'revive' the Bugday event.
> As most of the open source projects have their own bugday, I thought
> it would be great to have this event back.  For those who don't know,
> its a monthly 24h event that takes place in #gentoo-bugs. Its goal is
> to close as many bugs as possible . You don't have to be a Gentoo
> expert to participate. Those days are a great way to start joining the
> Gentoo community, improving Bugzilla's and Wiki's quality and looking
> for a mentor to begin the recruitment process. The upcoming bugday
> event is this Saturday and I hope this event will continue in the next
> months. I have created a wiki page for the event[1] and I added some
> guidelines. I have also created a related blog post about the
> event[2].
>
> I have listed some maintainer-wanted and maintainer-need bugs and
> Bugzilla admins also re-enabled the bugday flag. I would like to ask
> the Gentoo project teams to start using this flag to their bugs that
> think that are good to start and enable the flag at them. It would be
> great to a have a really big list with 'good to start' bugs.
>
> It's the first time after a long time that this event will take place,
> so I am looking forward to your participation both users and
> developers and your feedback.
>
> [1] http://wiki.gentoo.org/wiki/Bugday
> [2] http://blog.dastergon.gr/gentoo-bugday/
>
> Thanks,
> Pavlos
>
>

Hi,

Thanks for your work, it will be great to see Bugday happening again.

What about the old bugday webpage[1]? It seems a bit broken at the 
moment, but may be useful to get running again.
Is the code available somewhere? Who has access to the login in the footer?

Best regards,
Michael

[1] http://bugday.gentoo.org/

Re: [gentoo-dev] Re: Gentoo Bugday

[Alec Warner]

On Tue, Feb 26, 2013 at 7:14 PM, Michael Palimaka <kensington@gentoo.org> wrote:
> On 27/02/2013 11:39, Pavlos Ratis wrote:
>>
>> Hello everyone,
>>
>> I would like to announce you a new try to 'revive' the Bugday event.
>> As most of the open source projects have their own bugday, I thought
>> it would be great to have this event back.  For those who don't know,
>> its a monthly 24h event that takes place in #gentoo-bugs. Its goal is
>> to close as many bugs as possible . You don't have to be a Gentoo
>> expert to participate. Those days are a great way to start joining the
>> Gentoo community, improving Bugzilla's and Wiki's quality and looking
>> for a mentor to begin the recruitment process. The upcoming bugday
>> event is this Saturday and I hope this event will continue in the next
>> months. I have created a wiki page for the event[1] and I added some
>> guidelines. I have also created a related blog post about the
>> event[2].
>>
>> I have listed some maintainer-wanted and maintainer-need bugs and
>> Bugzilla admins also re-enabled the bugday flag. I would like to ask
>> the Gentoo project teams to start using this flag to their bugs that
>> think that are good to start and enable the flag at them. It would be
>> great to a have a really big list with 'good to start' bugs.
>>
>> It's the first time after a long time that this event will take place,
>> so I am looking forward to your participation both users and
>> developers and your feedback.
>>
>> [1] http://wiki.gentoo.org/wiki/Bugday
>> [2] http://blog.dastergon.gr/gentoo-bugday/
>>
>> Thanks,
>> Pavlos
>>
>>
>
> Hi,
>
> Thanks for your work, it will be great to see Bugday happening again.
>
> What about the old bugday webpage[1]? It seems a bit broken at the moment,
> but may be useful to get running again.
> Is the code available somewhere? Who has access to the login in the footer?

antarus@flycatcher /var/svnroot/bugday $ grep svnbugday /etc/group
svnbugday:x:4005:gurligebis

It is there, but only gurligebis has r/w. We should migrate it to
git.o.g.o if possible (all the secrets should be in a separate
infra-owned repo, basically.)

I have no idea who has access to login.

>
> Best regards,
> Michael
>
> [1] http://bugday.gentoo.org/
>
>

Re: [gentoo-dev] Gentoo Bugday

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 27/02/13 01:39, Pavlos Ratis wrote:
> I would like to announce you a new try to 'revive' the Bugday
> event.
I don't have anything to add. I just wanted to express my support. I'm
told that it is useful to be supportive of people and that they like that.

- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlEtzOYACgkQRtClrXBQc7VrSQD+J3sQ2tqw5D5s94ai8JLAXI0s
XiXL18moheG57UJP3jMA/2lCVV8iAEtpoTh9oSvT6Difbe7G/H5dECnzibB7bsk0
=Y5pt
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Gentoo Bugday

[Theo Chatzimichos]

[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]

On Tuesday 26 of February 2013 22:28:13 Alec Warner wrote:
> On Tue, Feb 26, 2013 at 7:14 PM, Michael Palimaka <kensington@gentoo.org> 
wrote:
> > On 27/02/2013 11:39, Pavlos Ratis wrote:
> >> Hello everyone,
> >> 
> >> I would like to announce you a new try to 'revive' the Bugday event.
> >> As most of the open source projects have their own bugday, I thought
> >> it would be great to have this event back.  For those who don't know,
> >> its a monthly 24h event that takes place in #gentoo-bugs. Its goal is
> >> to close as many bugs as possible . You don't have to be a Gentoo
> >> expert to participate. Those days are a great way to start joining the
> >> Gentoo community, improving Bugzilla's and Wiki's quality and looking
> >> for a mentor to begin the recruitment process. The upcoming bugday
> >> event is this Saturday and I hope this event will continue in the next
> >> months. I have created a wiki page for the event[1] and I added some
> >> guidelines. I have also created a related blog post about the
> >> event[2].
> >> 
> >> I have listed some maintainer-wanted and maintainer-need bugs and
> >> Bugzilla admins also re-enabled the bugday flag. I would like to ask
> >> the Gentoo project teams to start using this flag to their bugs that
> >> think that are good to start and enable the flag at them. It would be
> >> great to a have a really big list with 'good to start' bugs.
> >> 
> >> It's the first time after a long time that this event will take place,
> >> so I am looking forward to your participation both users and
> >> developers and your feedback.
> >> 
> >> [1] http://wiki.gentoo.org/wiki/Bugday
> >> [2] http://blog.dastergon.gr/gentoo-bugday/
> >> 
> >> Thanks,
> >> Pavlos
> > 
> > Hi,
> > 
> > Thanks for your work, it will be great to see Bugday happening again.
> > 
> > What about the old bugday webpage[1]? It seems a bit broken at the moment,
> > but may be useful to get running again.
> > Is the code available somewhere? Who has access to the login in the
> > footer?
> 
> antarus@flycatcher /var/svnroot/bugday $ grep svnbugday /etc/group
> svnbugday:x:4005:gurligebis
> 
> It is there, but only gurligebis has r/w. We should migrate it to
> git.o.g.o if possible (all the secrets should be in a separate
> infra-owned repo, basically.)
> 
> I have no idea who has access to login.
> 
> > Best regards,
> > Michael
> > 
> > [1] http://bugday.gentoo.org/

I already sent a tarball with the code to Pavlos, let him decide if he wants 
to move it to git.overlays.g.o or replace it with something else

Theo

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Bugday

[Peter Stuge]

Alexander Berntsen wrote:
> > I would like to announce you a new try to 'revive' the Bugday
> > event.
> 
> I don't have anything to add. I just wanted to express my support.

Yeah! Me too! :)


//Peter

Re: [gentoo-dev] Re: Gentoo Bugday

[Pavlos Ratis]

Unfortunately I didn't have much time to 'refresh' the  website. As
Theo said, he gave me the code of the site but I think it would be
great to have something new. If anyone wants to join, ping me on irc.
We could create a new repo at our Github and start developing. Also if
you want to add new ideas for the Bugday feel free to touch the wiki
page. :)

On Wed, Feb 27, 2013 at 12:19 PM, Theo Chatzimichos
<tampakrap@gentoo.org> wrote:
> On Tuesday 26 of February 2013 22:28:13 Alec Warner wrote:
>> On Tue, Feb 26, 2013 at 7:14 PM, Michael Palimaka <kensington@gentoo.org>
> wrote:
>> > On 27/02/2013 11:39, Pavlos Ratis wrote:
>> >> Hello everyone,
>> >>
>> >> I would like to announce you a new try to 'revive' the Bugday event.
>> >> As most of the open source projects have their own bugday, I thought
>> >> it would be great to have this event back.  For those who don't know,
>> >> its a monthly 24h event that takes place in #gentoo-bugs. Its goal is
>> >> to close as many bugs as possible . You don't have to be a Gentoo
>> >> expert to participate. Those days are a great way to start joining the
>> >> Gentoo community, improving Bugzilla's and Wiki's quality and looking
>> >> for a mentor to begin the recruitment process. The upcoming bugday
>> >> event is this Saturday and I hope this event will continue in the next
>> >> months. I have created a wiki page for the event[1] and I added some
>> >> guidelines. I have also created a related blog post about the
>> >> event[2].
>> >>
>> >> I have listed some maintainer-wanted and maintainer-need bugs and
>> >> Bugzilla admins also re-enabled the bugday flag. I would like to ask
>> >> the Gentoo project teams to start using this flag to their bugs that
>> >> think that are good to start and enable the flag at them. It would be
>> >> great to a have a really big list with 'good to start' bugs.
>> >>
>> >> It's the first time after a long time that this event will take place,
>> >> so I am looking forward to your participation both users and
>> >> developers and your feedback.
>> >>
>> >> [1] http://wiki.gentoo.org/wiki/Bugday
>> >> [2] http://blog.dastergon.gr/gentoo-bugday/
>> >>
>> >> Thanks,
>> >> Pavlos
>> >
>> > Hi,
>> >
>> > Thanks for your work, it will be great to see Bugday happening again.
>> >
>> > What about the old bugday webpage[1]? It seems a bit broken at the moment,
>> > but may be useful to get running again.
>> > Is the code available somewhere? Who has access to the login in the
>> > footer?
>>
>> antarus@flycatcher /var/svnroot/bugday $ grep svnbugday /etc/group
>> svnbugday:x:4005:gurligebis
>>
>> It is there, but only gurligebis has r/w. We should migrate it to
>> git.o.g.o if possible (all the secrets should be in a separate
>> infra-owned repo, basically.)
>>
>> I have no idea who has access to login.
>>
>> > Best regards,
>> > Michael
>> >
>> > [1] http://bugday.gentoo.org/
>
> I already sent a tarball with the code to Pavlos, let him decide if he wants
> to move it to git.overlays.g.o or replace it with something else
>
> Theo

Re: [gentoo-dev] Re: Gentoo Bugday

[Peter Stuge]

Pavlos Ratis wrote:
> Unfortunately I didn't have much time to 'refresh' the  website. As
> Theo said, he gave me the code of the site but I think it would be
> great to have something new. If anyone wants to join, ping me on irc.
> We could create a new repo at our Github and start developing.

Don't start developing, plz work on bugs instead.


//Peter

Re: [gentoo-dev] Gentoo Bugday

[Roy Bamford]

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

On 2013.02.27 00:39, Pavlos Ratis wrote:
> Hello everyone,
> 
> I would like to announce you a new try to 'revive' the Bugday event.
> As most of the open source projects have their own bugday, I thought
> it would be great to have this event back.  For those who don't know,
> its a monthly 24h event that takes place in #gentoo-bugs. Its goal is
> to close as many bugs as possible . You don't have to be a Gentoo
> expert to participate. Those days are a great way to start joining 
> the
> Gentoo community, improving Bugzilla's and Wiki's quality and looking
> for a mentor to begin the recruitment process. The upcoming bugday
> event is this Saturday and I hope this event will continue in the 
> next
> months. I have created a wiki page for the event[1] and I added some
> guidelines. I have also created a related blog post about the
> event[2].
> 
> I have listed some maintainer-wanted and maintainer-need bugs and
> Bugzilla admins also re-enabled the bugday flag. I would like to ask
> the Gentoo project teams to start using this flag to their bugs that
> think that are good to start and enable the flag at them. It would be
> great to a have a really big list with 'good to start' bugs.
> 
> It's the first time after a long time that this event will take 
> place,
> so I am looking forward to your participation both users and
> developers and your feedback.
> 
> [1] http://wiki.gentoo.org/wiki/Bugday
> [2] http://blog.dastergon.gr/gentoo-bugday/
> 
> Thanks,
> Pavlos
> 
> 

Pavlos,

I used to do a forums announce for the old bugday.  That can be revived 
too if you want.  The old bugday ran to a calender, so the announces 
went up a week beforehand.

Are you goings to stick to the first Saturday in the month ?

Good luck with the revived bugday.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: Gentoo Bugday

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]

On Wed, 27 Feb 2013 20:00:44 +0100
Peter Stuge <peter@stuge.se> wrote:

> Pavlos Ratis wrote:
> > Unfortunately I didn't have much time to 'refresh' the  website. As
> > Theo said, he gave me the code of the site but I think it would be
> > great to have something new. If anyone wants to join, ping me on
> > irc. We could create a new repo at our Github and start developing.
> 
> Don't start developing, plz work on bugs instead.
> 
> 
> //Peter
> 

Then who will develop useful tools to handle bugs more efficiently?

While we're at this topic; I could use a duplicate finder for bug
wrangling to spare other devs from coming across the same bug again,
also a build log parser that only show the relevant bits that matter
so I don't have to waste time grepping for keywords that appear in
file names as well, not to forget about compressed build logs, and for
assigning bugs an integrated herds.xml lookup would be pretty useful...

Using these tools I could process bugs in half the time; and those are
mostly just tools on the bug wrangling side, the dev and ebuild side
could also use some more tools. If nobody wrote tools, we wouldn't have
Bugzilla, Mailing List Daemons and Portage; back in the old days...

Also, your response is quite funny if you consider his sole two bugs
are one low priority bug that's 3 years old and has been reassigned a
few times because it's not worth fixing (aka "not an actual problem"),
the other one is actually for a tool called "recruiting.gentoo.org".

I'd rather see this dev continue developing than wasting time on bugs,
this reminds me that I should do some short term development myself
instead of wasting a lot of time long term; even if I don't end up
benefiting of the cost, any person that follows my footsteps will.


With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Gentoo Bugday

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]

Tom Wijsman wrote:
> > > We could create a new repo at our Github and start developing.
> > 
> > Don't start developing, plz work on bugs instead.
> 
> Then who will develop useful tools to handle bugs more efficiently?

Don't get me wrong: I am not hating on useful tools!

I am saying that working on tools is orthogonal to working on open bugs.


> his sole two bugs

Is there a rule in Gentoo that forbids a dev to fix a bug assigned to
someone else? That would make absolutely no sense to me.

No wonder then, that there are several bugs with no activity for
months after I have committed fixed ebuilds to my overlay and
mentioned that in a comment.

He has become a developer so why would he not be able to take
neccessary action to close bugs, even if they haven't been assigned
to him?

- But Peter, you say, don't you see - that would lead to more fixed bugs!

Orly? How is that bad?


(I'm obviously assuming that all developers (but not infra) are
equally competent, since that's the model taught by recruitment.)


> short term
..
> long term

Yes, life is tradeoff. In my experience development of tools is
rather a long term thing, while a day of working on bugs is more
short term. A day short, to be exact. :)

If there are numerous unactionable bugs then perhaps skip them on
that day, and work on shiny bulk processing tools the next day.


Just my 2. But never mind. I guess I'm not supposed to participate
in the bugday anyway. Good for me! :)


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] Re: Gentoo Bugday

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 3464 bytes --]

On Wed, 27 Feb 2013 22:30:38 +0100
Peter Stuge <peter@stuge.se> wrote:

> Tom Wijsman wrote:
> > > > We could create a new repo at our Github and start developing.
> > > 
> > > Don't start developing, plz work on bugs instead.
> > 
> > Then who will develop useful tools to handle bugs more efficiently?
> 
> Don't get me wrong: I am not hating on useful tools!

That's not an answer to my question.

> I am saying that working on tools is orthogonal to working on open
> bugs.

And I am saying that working on tools that help you work on open bugs is
not orthogonal to fixing open bugs, it helps you fix them efficiently.

> > his sole two bugs
> 
> Is there a rule in Gentoo that forbids a dev to fix a bug assigned to
> someone else? That would make absolutely no sense to me.
>
> No wonder then, that there are several bugs with no activity for
> months after I have committed fixed ebuilds to my overlay and
> mentioned that in a comment.

Yes, one shall not commit on packages other developers maintain
without the permission to do such thing. But let's assume the horribly
"attaching a patch" approach (save two files, compare them, bla...)...

Can you write me a tool that shows these kinds of bugs, easily submit
patches to them and follow up on whether the developer commits them or
retires at one or another point? I don't do any of this for my bugs. 

I could state that working on bugs assigned to someone else is
orthogonal to fixing your own bugs.

> He has become a developer so why would he not be able to take
> neccessary action to close bugs, even if they haven't been assigned
> to him?

Because it isn't as simple as you make it seem like, as stated above.

> - But Peter, you say, don't you see - that would lead to more fixed
> bugs!
> 
> Orly? How is that bad?

Y u no serious? U mad?

> (I'm obviously assuming that all developers (but not infra) are
> equally competent, since that's the model taught by recruitment.)

Competence is irrelevant to this discussion, competency is to be
assumed. Though, since you want to discuss this; note that with the
right tools incompetent developers can become more competent, instead
of having no clue where to start they can efficiently start on
something right away and finish it in a timely matter.

> > short term
> ..
> > long term
> 
> Yes, life is tradeoff. In my experience development of tools is
> rather a long term thing, while a day of working on bugs is more
> short term. A day short, to be exact. :)

What experience are you even talking about? Did you write a tool that
handles upon bugs, build logs or something else that applies to the
daily Gentoo Dev process?

> If there are numerous unactionable bugs then perhaps skip them on
> that day, and work on shiny bulk processing tools the next day.

So, we need another tool to mark and bulk process unactionable bugs! Or
at least plan and write the searches for our lovely Bugzilla to do so,
oh, and also CC a ton of people with this madness while we're at it.

> Just my 2. But never mind. I guess I'm not supposed to participate
> in the bugday anyway. Good for me! :)

It's only a day short. The other six days are free to work on tools...


With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Gentoo Bugday

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 6521 bytes --]

Tom Wijsman wrote:
> I am saying that working on tools that help you work on open bugs is
> not orthogonal to fixing open bugs, it helps you fix them efficiently.

Sure, but on the bugday itself it sounds on the name like the idea is
to work on bugs with currently available tools, rather than work on
tools to work on bugs .. some other time.


> > Is there a rule in Gentoo that forbids a dev to fix a bug
> > assigned to someone else? That would make absolutely no sense to
> > me.
> >
> > No wonder then, that there are several bugs with no activity for
> > months after I have committed fixed ebuilds to my overlay and
> > mentioned that in a comment.
> 
> Yes, one shall not commit on packages other developers maintain
> without the permission to do such thing.

This is basically stupid.

Anyway, commit is one thing, but fixing bugs can be done while still
respecting that rule. I would however make this simple suggestion:

On bugdays every bugfix [optionally for bugs inactive for x days] is
fair game for every developer to commit.

Those who feel threatened by other people touching their bits might
pay more attention to bugs then. It would also promote more
acceptance of other fixing their stuff. I know that several (many?)
developers give blanket permission, and I think that's good, but I
think it's really broken that they have to at all. Back to bugday..


> But let's assume the horribly "attaching a patch" approach (save
> two files, compare them, bla...)...

Yes, web apps are supremely inefficient shitty tools. I'm very happy
to be able to simply refer to my overlay when I have fixed something.

I do try to also attach fixed files, but I don't always manage.


> Can you write me a tool that shows these kinds of bugs, easily submit
> patches to them and follow up on whether the developer commits them or
> retires at one or another point? I don't do any of this for my bugs.

Bugzilla implicitly does much of that for you already, if you tell it
to send you email for all changes on bugs you have the raw data in
email form, which may be easier to work with sans SQL access to the
bugzilla database. That works really well for me to follow any bugs
that I am interested in, and it's pretty easy to search in email and
see what has happened when, and how much is still open (different
folders).

Submitting patches, no I think that's too broken on the web, and that
something more powerful like an overlay could be used instead - at
the very least for fixes from developers.


> I could state that working on bugs assigned to someone else is
> orthogonal to fixing your own bugs.

Sure - but if all one's own bugs are low priority perhaps it's more
useful on bugday to work on bugs assigned to someone else, if they
aren't doing it themselves.


> > He has become a developer so why would he not be able to take
> > neccessary action to close bugs, even if they haven't been assigned
> > to him?
> 
> Because it isn't as simple as you make it seem like, as stated above.

For several bugs that I have fixed, it is precisely that simple.
Fixes have been ready for months and just need to be committed.
I'd dare to call it outright trivial.

They still aren't committed.

Finding them easily? Well maybe a search query that orders by last
activity weighted by severity, number of attachments and fulltext
search for "fixed" would be a start? I guess that's easy to do even
in bugzilla's web interface?


> > - But Peter, you say, don't you see - that would lead to more fixed
> > bugs!
> > 
> > Orly? How is that bad?
> 
> Y u no serious? U mad?

Not mat, I am being serious - I guess that the uncommitted fixes
mean lack of attention to bugs, which I completely understand. I
further guess that the bugday is an initiative to attend to bugs.

So any developer who wants to help could close bugs by comitting
fixes from others, fixes that are already in bugzilla. I guess the
few bugs that I have done this for are not unique in Gentoo's
bugzilla, likely there are lots of other bugs just like mine, where
users have contributed fixes for stuff that they have run into and it
still hasn't gotten committed, nor reviewed. At least one of "my"
bugs is even UNCONFIRMED. It's almost mocking the entire bugzilla. :)


> > (I'm obviously assuming that all developers (but not infra) are
> > equally competent, since that's the model taught by recruitment.)
> 
> Competence is irrelevant to this discussion, competency is to be
> assumed.

I agree that it is to be assumed, but I think it is relevant because
I believe that fear of incompetence is the reason why developers feel
threatened by commits from others, so it supports the idea that at
the very least on bugday it would be fine for everyone to commit
everything. (Again, I am assuming that all fixes are correct.)


> Though, since you want to discuss this; note that with the
> right tools incompetent developers can become more competent,
> instead of having no clue where to start they can efficiently
> start on something right away and finish it in a timely matter.

Absolutely agreed! Tools are awesome and important. I just think
that *on* bugday everyone should be working on bugs instead.


> > > short term
> > ..
> > > long term
> > 
> > Yes, life is tradeoff. In my experience development of tools is
> > rather a long term thing, while a day of working on bugs is more
> > short term. A day short, to be exact. :)
> 
> What experience are you even talking about?

Decades of developing tools and working on bugs.


> daily Gentoo Dev process?

How could I, I'm not a dev, remember?

And from the outside, becoming one doesn't look super attractive..


> > If there are numerous unactionable bugs then perhaps skip them on
> > that day, and work on shiny bulk processing tools the next day.
> 
> So, we need another tool to mark and bulk process unactionable bugs! Or
> at least plan and write the searches for our lovely Bugzilla to do so,
> oh, and also CC a ton of people with this madness while we're at it.

I guess the low level stuff is there - bugzilla surely has some RPC
API, and someone mentioned pybugz which is perhaps a little bit
higher level. So maybe that is already possible.


> It's only a day short. The other six days are free to work on tools...

I think we are in agreement actually - my point is about the bugday.


Thanks!

//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] Re: Gentoo Bugday

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 7499 bytes --]

On Thu, 28 Feb 2013 01:20:01 +0100
Peter Stuge <peter@stuge.se> wrote:

> Sure, but on the bugday itself it sounds on the name like the idea is
> to work on bugs with currently available tools, rather than work on
> tools to work on bugs .. some other time.

Neither of us did suggest such thing.

> > Yes, one shall not commit on packages other developers maintain
> > without the permission to do such thing.
> 
> This is basically stupid.

But that's just the way it is, because random committing makes no sense.

> Anyway, commit is one thing, but fixing bugs can be done while still
> respecting that rule. I would however make this simple suggestion:
> 
> On bugdays every bugfix [optionally for bugs inactive for x days] is
> fair game for every developer to commit.

It works this way for packages (retirement, etc...), but for bugs this
introduces the random committing effect; just because you keep one bug
around for a package and fix all others doesn't mean someone else can
suddenly come and take that bug, fix and apply it blindly.

> Those who feel threatened by other people touching their bits might
> pay more attention to bugs then.

Again more easily said than done, time is limited; not every bug can be
fixed, some require too much effort for what they are worth, ...

> It would also promote more acceptance of other fixing their stuff. I
> know that several (many?) developers give blanket permission, and I
> think that's good, but I think it's really broken that they have to
> at all. Back to bugday..

This model has been in place for years, it's not easily changed.

> > But let's assume the horribly "attaching a patch" approach (save
> > two files, compare them, bla...)...
> 
> Yes, web apps are supremely inefficient shitty tools. I'm very happy
> to be able to simply refer to my overlay when I have fixed something.
>
> ...
>
> Submitting patches, no I think that's too broken on the web, and that
> something more powerful like an overlay could be used instead - at
> the very least for fixes from developers.

That's just moving the extra effort to the person who receives your
patch; who now has to obtain the overlay, sync the overlay, obtain the
file from the overlay and diff that file against his local file to
obtain the actual patch. And if it's not done in a timely manner, too
much may have changed already which makes generating a clean patch hard
and therefore will need them to spent time to figure out which code
actually belongs to the patch. Overlays weren't meant for this...

> I do try to also attach fixed files, but I don't always manage.

I do try to generate patches from overlays, but I don't always manage.

> > Can you write me a tool that shows these kinds of bugs, easily
> > submit patches to them and follow up on whether the developer
> > commits them or retires at one or another point? I don't do any of
> > this for my bugs.
> 
> Bugzilla implicitly does much of that for you already, if you tell it
> to send you email for all changes on bugs you have the raw data in
> email form, which may be easier to work with sans SQL access to the
> bugzilla database. That works really well for me to follow any bugs
> that I am interested in, and it's pretty easy to search in email and
> see what has happened when, and how much is still open (different
> folders).

How exactly does Bugzilla show these kinds of bugs?

Submitting patches or using overlays, it makes no difference.

Following the bug through mail exactly doesn't show retirement, unless
you CC yourself on a ton of bugs and want to maintain these individual
CCs into archive folders where you look up the oldest mails (because
not every CC is one you want to archive), and you also have to
consider that you don't get mails for changes you commit to the bug.
Sum that up and it's not a reliable approach, unless you write a tool.

> > I could state that working on bugs assigned to someone else is
> > orthogonal to fixing your own bugs.
> 
> Sure - but if all one's own bugs are low priority perhaps it's more
> useful on bugday to work on bugs assigned to someone else, if they
> aren't doing it themselves.

Those bugs are often of equal priority, and I have nothing against
that; I'm just stating that it's much harder to fix other people's
bugs, this is due to the inefficiency that comes along, without tools
being written to aid in this process it'll continue that way.

> > > He has become a developer so why would he not be able to take
> > > neccessary action to close bugs, even if they haven't been
> > > assigned to him?
> > 
> > Because it isn't as simple as you make it seem like, as stated
> > above.
> 
> For several bugs that I have fixed, it is precisely that simple.
> Fixes have been ready for months and just need to be committed.
> I'd dare to call it outright trivial.
>
> They still aren't committed.

"just" being the whole overlay process I outlined above? Not trivial.

> Finding them easily? Well maybe a search query that orders by last
> activity weighted by severity, number of attachments and fulltext
> search for "fixed" would be a start? I guess that's easy to do even
> in bugzilla's web interface?

Still needs you to write this search query for it to become useful as
a tool (a tool doesn't necessarily have to be a script or a program).

> So any developer who wants to help could close bugs by comitting
> fixes from others, fixes that are already in bugzilla. I guess the
> few bugs that I have done this for are not unique in Gentoo's
> bugzilla, likely there are lots of other bugs just like mine, where
> users have contributed fixes for stuff that they have run into and it
> still hasn't gotten committed, nor reviewed. At least one of "my"
> bugs is even UNCONFIRMED. It's almost mocking the entire bugzilla. :)

I can't find them, I don't have the right tools or search query.

Will you link them all to us this Saturday on IRC? :(

> Absolutely agreed! Tools are awesome and important. I just think
> that *on* bugday everyone should be working on bugs instead.

Agreed, but that's not today or tomorrow, just 4 days of a month.

> > So, we need another tool to mark and bulk process unactionable
> > bugs! Or at least plan and write the searches for our lovely
> > Bugzilla to do so, oh, and also CC a ton of people with this
> > madness while we're at it.
> 
> I guess the low level stuff is there - bugzilla surely has some RPC
> API, and someone mentioned pybugz which is perhaps a little bit
> higher level. So maybe that is already possible.

Yeah, it's one more to throw on the list of things to eventually
implement when they start to extremely bother you; maybe I should set
up a Gentoo Project that does nothing but implement these kinds of
tools, "which one to implement first" is then voted by all developers.

> > It's only a day short. The other six days are free to work on
> > tools...
> 
> I think we are in agreement actually - my point is about the bugday.

And mine was not, just in general.

Although I was reading this because I might look into helping out on
such website, later on; which you probably have figured out by now...


With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Gentoo Bugday

[Pavlos Ratis]

@neddyseagoon: Yeah it would be great to have it back, I think the day
should remain as is. Every first Saturday of every month. Thanks.

@TomWij and Peter: Well guys, I think you should not expand the topic
so much, lets stay to the bugday. As I said in my first post, bugday's
goal is to close as many bugs as possible and not to create new tools.
We can create tools(small scripts) in the future that can help us
before the bugday. But in the bugday as an event we should concentrate
on closing bugs.


On Thu, Feb 28, 2013 at 3:07 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Thu, 28 Feb 2013 01:20:01 +0100
> Peter Stuge <peter@stuge.se> wrote:
>
>> Sure, but on the bugday itself it sounds on the name like the idea is
>> to work on bugs with currently available tools, rather than work on
>> tools to work on bugs .. some other time.
>
> Neither of us did suggest such thing.
>
>> > Yes, one shall not commit on packages other developers maintain
>> > without the permission to do such thing.
>>
>> This is basically stupid.
>
> But that's just the way it is, because random committing makes no sense.
>
>> Anyway, commit is one thing, but fixing bugs can be done while still
>> respecting that rule. I would however make this simple suggestion:
>>
>> On bugdays every bugfix [optionally for bugs inactive for x days] is
>> fair game for every developer to commit.
>
> It works this way for packages (retirement, etc...), but for bugs this
> introduces the random committing effect; just because you keep one bug
> around for a package and fix all others doesn't mean someone else can
> suddenly come and take that bug, fix and apply it blindly.
>
>> Those who feel threatened by other people touching their bits might
>> pay more attention to bugs then.
>
> Again more easily said than done, time is limited; not every bug can be
> fixed, some require too much effort for what they are worth, ...
>
>> It would also promote more acceptance of other fixing their stuff. I
>> know that several (many?) developers give blanket permission, and I
>> think that's good, but I think it's really broken that they have to
>> at all. Back to bugday..
>
> This model has been in place for years, it's not easily changed.
>
>> > But let's assume the horribly "attaching a patch" approach (save
>> > two files, compare them, bla...)...
>>
>> Yes, web apps are supremely inefficient shitty tools. I'm very happy
>> to be able to simply refer to my overlay when I have fixed something.
>>
>> ...
>>
>> Submitting patches, no I think that's too broken on the web, and that
>> something more powerful like an overlay could be used instead - at
>> the very least for fixes from developers.
>
> That's just moving the extra effort to the person who receives your
> patch; who now has to obtain the overlay, sync the overlay, obtain the
> file from the overlay and diff that file against his local file to
> obtain the actual patch. And if it's not done in a timely manner, too
> much may have changed already which makes generating a clean patch hard
> and therefore will need them to spent time to figure out which code
> actually belongs to the patch. Overlays weren't meant for this...
>
>> I do try to also attach fixed files, but I don't always manage.
>
> I do try to generate patches from overlays, but I don't always manage.
>
>> > Can you write me a tool that shows these kinds of bugs, easily
>> > submit patches to them and follow up on whether the developer
>> > commits them or retires at one or another point? I don't do any of
>> > this for my bugs.
>>
>> Bugzilla implicitly does much of that for you already, if you tell it
>> to send you email for all changes on bugs you have the raw data in
>> email form, which may be easier to work with sans SQL access to the
>> bugzilla database. That works really well for me to follow any bugs
>> that I am interested in, and it's pretty easy to search in email and
>> see what has happened when, and how much is still open (different
>> folders).
>
> How exactly does Bugzilla show these kinds of bugs?
>
> Submitting patches or using overlays, it makes no difference.
>
> Following the bug through mail exactly doesn't show retirement, unless
> you CC yourself on a ton of bugs and want to maintain these individual
> CCs into archive folders where you look up the oldest mails (because
> not every CC is one you want to archive), and you also have to
> consider that you don't get mails for changes you commit to the bug.
> Sum that up and it's not a reliable approach, unless you write a tool.
>
>> > I could state that working on bugs assigned to someone else is
>> > orthogonal to fixing your own bugs.
>>
>> Sure - but if all one's own bugs are low priority perhaps it's more
>> useful on bugday to work on bugs assigned to someone else, if they
>> aren't doing it themselves.
>
> Those bugs are often of equal priority, and I have nothing against
> that; I'm just stating that it's much harder to fix other people's
> bugs, this is due to the inefficiency that comes along, without tools
> being written to aid in this process it'll continue that way.
>
>> > > He has become a developer so why would he not be able to take
>> > > neccessary action to close bugs, even if they haven't been
>> > > assigned to him?
>> >
>> > Because it isn't as simple as you make it seem like, as stated
>> > above.
>>
>> For several bugs that I have fixed, it is precisely that simple.
>> Fixes have been ready for months and just need to be committed.
>> I'd dare to call it outright trivial.
>>
>> They still aren't committed.
>
> "just" being the whole overlay process I outlined above? Not trivial.
>
>> Finding them easily? Well maybe a search query that orders by last
>> activity weighted by severity, number of attachments and fulltext
>> search for "fixed" would be a start? I guess that's easy to do even
>> in bugzilla's web interface?
>
> Still needs you to write this search query for it to become useful as
> a tool (a tool doesn't necessarily have to be a script or a program).
>
>> So any developer who wants to help could close bugs by comitting
>> fixes from others, fixes that are already in bugzilla. I guess the
>> few bugs that I have done this for are not unique in Gentoo's
>> bugzilla, likely there are lots of other bugs just like mine, where
>> users have contributed fixes for stuff that they have run into and it
>> still hasn't gotten committed, nor reviewed. At least one of "my"
>> bugs is even UNCONFIRMED. It's almost mocking the entire bugzilla. :)
>
> I can't find them, I don't have the right tools or search query.
>
> Will you link them all to us this Saturday on IRC? :(
>
>> Absolutely agreed! Tools are awesome and important. I just think
>> that *on* bugday everyone should be working on bugs instead.
>
> Agreed, but that's not today or tomorrow, just 4 days of a month.
>
>> > So, we need another tool to mark and bulk process unactionable
>> > bugs! Or at least plan and write the searches for our lovely
>> > Bugzilla to do so, oh, and also CC a ton of people with this
>> > madness while we're at it.
>>
>> I guess the low level stuff is there - bugzilla surely has some RPC
>> API, and someone mentioned pybugz which is perhaps a little bit
>> higher level. So maybe that is already possible.
>
> Yeah, it's one more to throw on the list of things to eventually
> implement when they start to extremely bother you; maybe I should set
> up a Gentoo Project that does nothing but implement these kinds of
> tools, "which one to implement first" is then voted by all developers.
>
>> > It's only a day short. The other six days are free to work on
>> > tools...
>>
>> I think we are in agreement actually - my point is about the bugday.
>
> And mine was not, just in general.
>
> Although I was reading this because I might look into helping out on
> such website, later on; which you probably have figured out by now...
>
>
> With kind regards,
>
> Tom Wijsman (TomWij)
> Gentoo Developer
>
> E-mail address  : TomWij@gentoo.org
> GPG Public Key  : 6D34E57D
> GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-dev] Re: Gentoo Bugday

[Sergey Popov]

[-- Attachment #1: Type: text/plain, Size: 495 bytes --]

28.02.2013 01:30, Peter Stuge пишет:
> Tom Wijsman wrote:
>> his sole two bugs
> 
> Is there a rule in Gentoo that forbids a dev to fix a bug assigned to
> someone else? That would make absolutely no sense to me.

Without primary contact to bug's assignee(personally, of, if bug is
assigned to project - to member of this project) - no, it's not good.
Exception - maintainer-needed@ bugs.

-- 
Best regards, Sergey Popov
Gentoo Linux Developer
Desktop-effects project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] Re: Gentoo Bugday

[Pavlos Ratis]

From now we are have and an event g+ page :
https://plus.google.com/events/cnevit57nm91ulji4bj4vt7910s  :)

On Thu, Feb 28, 2013 at 1:33 PM, Sergey Popov <pinkbyte@gentoo.org> wrote:
> 28.02.2013 01:30, Peter Stuge пишет:
>> Tom Wijsman wrote:
>>> his sole two bugs
>>
>> Is there a rule in Gentoo that forbids a dev to fix a bug assigned to
>> someone else? That would make absolutely no sense to me.
>
> Without primary contact to bug's assignee(personally, of, if bug is
> assigned to project - to member of this project) - no, it's not good.
> Exception - maintainer-needed@ bugs.
>
> --
> Best regards, Sergey Popov
> Gentoo Linux Developer
> Desktop-effects project lead
>

Re: [gentoo-dev] Re: Gentoo Bugday

[Roy Bamford]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

On 2013.02.28 02:14, Pavlos Ratis wrote:
> @neddyseagoon: Yeah it would be great to have it back, I think the 
> day
> should remain as is. Every first Saturday of every month. Thanks.
[snip]


Pavlos,

https://forums.gentoo.org/viewtopic-t-952608.html


Poke me the weekend before bugday and I'll do the forums announce.
Eventually, it will be a habit.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]