public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev]  Re: Bugzilla etiquette suggestions
Date: Mon, 13 Feb 2006 02:50:25 -0700	[thread overview]
Message-ID: <pan.2006.02.13.09.50.19.347815@cox.net> (raw)
In-Reply-To: 43EFC3BD.7080902@gentoo.org

Daniel Drake posted <43EFC3BD.7080902@gentoo.org>, excerpted below,  on
Sun, 12 Feb 2006 23:24:45 +0000:

> Henrik Brix Andersen wrote:
[Danial Drake wrote...]
>>> 3. Always record contributions by name
>>>
>>> If you commit something in response to a bug report that has been filed, 
>>> always thank the user by full name (and bug number) in the ChangeLog and 
>>> commit message.
>>>
>>> This also applies for [...] version bump requests/submissions. Might
>>> sound pointless for 'trivial' reports/requests but it is important to
>>> credit the user if they have gone to the trouble of filing a bug.
>> 
>> I don't really get this part. Why should I give credit to someone else
>> for providing a fix for a bug which I already fixed myself locally?
> 
> Maybe not if you have already done the work. I was thinking more of the
> scenario, upstream does a release. You are on the mailing list so you
> know about the new version. You decide you'll bump it in portage
> tomorrow.
> 
> Overnight, someone files a request for a version bump. Maybe they attach
> a new ebuild or state that the existing one needs bumping.
> 
> Even though you knew about it, I was suggesting that you credit the user
> for filing the bug.

I don't recall where I read it, but it sounded reasonable to me then, and
deals with a possible issue, so I'll repeat it.  Somewhere I read
a recommendation for bump requests, addressed to users thinking of making
one, suggesting that they give the devs a week or two to do the bump
themselves, as they likely know about it because they are following the
list for that app, since they are the Gentoo maintainer for it, and just
need time to get something worked up and tested locally.  If after two
weeks, the bump isn't in portage, /then/ it's time to post the bug about
it.

Now, two weeks may be a bit long, but I'd say a week, anyway, of course
depending on the app (something big like gcc or gnome/kde bumps would be
different, but they are often in the tree even before the package is
publicly released and sources publicly available -- good job!).

I'd /not/ really wish to encourage version bump requests "overnight". 
That's  jumping the gun, and indeed, could encourage "first post" like
behavior.

What I'd do with such bugs is thank the user, but say next time, please
give me a few days, at least a week (or whatever a dev feels comfortable
with for that package, again, it'll vary) -- if it's /just/ a bump
request.  If I take over a week (or whatever), then maybe I need
reminding, so let me know!  OTOH, if the bug includes "I tried bumping the
last ebuild to use the new sources and it worked fine", or "... and it
broke at <whatever>", that's far more valuable than just a bump request,
and I'd treat it so.  (In fact, that sounds like possible AT/HT material,
maybe ultimately leading to a new dev, to me.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list



  parent reply	other threads:[~2006-02-13  9:53 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-12 21:11 [gentoo-dev] Bugzilla etiquette suggestions Daniel Drake
2006-02-12 21:43 ` Henrik Brix Andersen
2006-02-12 23:24   ` Daniel Drake
2006-02-13  0:57     ` Ferris McCormick
2006-02-13  8:09       ` Ciaran McCreesh
2006-02-13  9:50     ` Duncan [this message]
2006-02-13 16:11       ` [gentoo-dev] " Daniel Drake
2006-02-13 17:17         ` [gentoo-dev] " Duncan
2006-02-16 11:02       ` [gentoo-dev] " Michael Cummings
2006-02-13 10:51     ` [gentoo-dev] " Diego 'Flameeyes' Pettenò
2006-02-13 16:30       ` Daniel Drake
2006-02-12 22:53 ` [gentoo-dev] " Duncan
2006-02-12 23:39   ` Daniel Drake
2006-02-13  8:13   ` Ciaran McCreesh
2006-02-13 17:26     ` Richard Fish
2006-02-14  2:54       ` lnxg33k
2006-02-13 18:39   ` Simon Stelling
2006-02-13 18:49     ` Ciaran McCreesh
2006-02-13 19:00       ` Patrick McLean
2006-02-13 19:06         ` Marien Zwart
2006-02-13 19:07       ` Grobian
2006-02-13 19:21         ` Ciaran McCreesh
2006-02-13 19:29           ` Grobian
2006-02-13 20:02             ` Carsten Lohrke
2006-02-13 20:13               ` Grobian
2006-02-13 19:36       ` Diego 'Flameeyes' Pettenò
2006-02-14 13:03     ` [gentoo-dev] " Duncan
2006-02-14 13:18       ` Stephen P. Becker
2006-02-15  7:48         ` [gentoo-dev] " Duncan
2006-02-12 22:58 ` [gentoo-dev] " Marien Zwart
2006-02-12 23:32   ` Daniel Drake
2006-02-13  8:16     ` Ciaran McCreesh
2006-02-13 19:12       ` Donnie Berkholz
2006-02-13  4:06 ` Ned Ludd
2006-02-17 14:20   ` Shyam Mani
2006-02-17 14:11 ` Shyam Mani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=pan.2006.02.13.09.50.19.347815@cox.net \
    --to=1i5t5.duncan@cox.net \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox