Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-28 Thread expose
Robin H. Johnson wrote:
 Taking into account the other reasonable input, how about the name of
 attribute 'automatic-bug' ?
Well, to complicate things even further, if you approach that from a semantic 
angle, automatic-bug is just as wrong as  the others, since no bug is 
automatically created...
Yet I am fine with (almost) anything that gives the user the idea of what it 
is all about: Bugzilla.
Therefore terms like bug, assignment, and maybe something like automatic are 
good choices.

So, although there's the cc-problem, I so agree with what Matti Bickel wrote
 I would like assign somewhere in the name, but i'd be fine with your
 proposal as well.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-28 Thread expose
Ned Ludd wrote:
 I don't see anything wrong with how it was proposed originally using
 contact=0

The reason why contact isn't perfect was given by Mart leio Raudsepp yet, 
namely:
 contact=0 in metadata.xml in this context means that the automatic
 reassigning should not assign to that maintainer, but when a user looks
 whom to ask specific questions from and sees contact=0 he/she will
 understand he/she is not to contact that person as the value is zero,
 but Daniel wants them to contact precisely him in that case.
 A different keyword might be better for that reason.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-28 Thread Flammie Pirinen
2007-04-27, Robin H. Johnson sanoi:

 On Fri, Apr 27, 2007 at 10:32:25AM +0200, Jan Kundr?t wrote:
  AFAIK the preferred way of specifying boolean values in XML is to
  use contact=contact, not contact=1.
 I can't find this described anywhere in the XML specification
 http://www.w3.org/TR/REC-xml/
 
 Have you got a reference for it?

That tradition stems from SGML, and in SGML it was also possible to
minimize this kind of true values by telling attribute without value.
The habit has carried over to XML even though it doesn't support
attribute minimization. The reference can be found in the SGML handbook
if you wish, I suppose.
-- 
Flammie, Gentoo Linux Documentation’s Finnish head translator
and FlameEyes’ bot http://dev.gentoo.org/~flammie.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-27 Thread Jan Kundrát
Robin H. Johnson wrote:
 In terms of implementing this in the DTD, I'm going to specify that
 'contact=1' (or whatever name we settle on) is the default, so that we
 don't break validation of any existing metadata:
 
 !ATTLIST maintainer
   contact   (0|1)   1   -- should this maintainer be used by 
 -- automatic processes?
  
 
 In light of the above, how about 'automatic=0'? 

AFAIK the preferred way of specifying boolean values in XML is to use
contact=contact, not contact=1.

Speaking of name, I'd try to include string bug somewhere in the
attribute name, like bugzilla-auto-assignment or something...

Cheers,
-jkt

-- 
cd /local/pub  more beer  /dev/mouth



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-27 Thread expose
Robin H. Johnson wrote:
 [...] the attribute should only indicate if the maintainer entry should be
 used for any automatic process at all, not how to use it. 
Oh, I thought you were talking about the name of the variable.

 I intend that the first non-excluded maintainer entry is the one used
 for the automatic process.
This could even make the need for contact=0|1 unneccessary (since at least 
one bugzilla account should be a valid assignee), yet it's of course better 
to still have it anyway.

 In light of the above, how about 'automatic=0'?
Kind of what I proposed, though I'd include assign and/or as  
Jan jkt Kundrát proposed bug somewhere in the variable name.
Like... AutoBugAssign=whatever or so.


Daniel
--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-27 Thread Nguyen Thai Ngoc Duy

On 4/26/07, Joshua Jackson [EMAIL PROTECTED] wrote:

Nguyen Thai Ngoc Duy wrote:
 On 4/26/07, Robin H. Johnson [EMAIL PROTECTED] wrote:
 Case 2 - Metadata contains a single maintainer
 --
 - The herd field is not used.
 - The maintainer address is used as the bugzilla assignee.
 This is important for all the herds that have aliases that are NOT the
 same as their herd name!
 This diverges from existing manual practice, to avoid unnecessary
 duplicate mail, and means that existing metadata may need a cleanup.

 It should take devaway into account.

why? Seriously, dev-away != dev retired... having it take devaway into
account is pointless in my opinion as it won't improve it being properly
assigned...as it'll be covered in other cases, and its not like there's
not bugs for all of us dev's that have not sat there for a month or so,
at some point


I meant if a maintainer is away, his/her herd should be assignee with
him/her CCed.

--
Duy
--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-27 Thread Jakub Moc

On 4/27/07, Nguyen Thai Ngoc Duy [EMAIL PROTECTED] wrote:

On 4/26/07, Joshua Jackson [EMAIL PROTECTED] wrote:
 Nguyen Thai Ngoc Duy wrote:
  It should take devaway into account.
 
 why? Seriously, dev-away != dev retired... having it take devaway into
 account is pointless in my opinion as it won't improve it being properly
 assigned...as it'll be covered in other cases, and its not like there's
 not bugs for all of us dev's that have not sat there for a month or so,
 at some point

I meant if a maintainer is away, his/her herd should be assignee with
him/her CCed.


Eh; if the maintainer has been away for months (a.k.a MIA), then
yeah... otherwise, no reason for this if someone's away for a week.
Sorry to disappoint you and others here, but the scripts will lack
artificial intelligence and frankly I don't see what exactly are you
expecting from this whole thing. Anyway, good luck. ;)

--
Jakub Moc
Email: [EMAIL PROTECTED]
--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-27 Thread Ned Ludd
On Thu, 2007-04-26 at 22:01 -0700, Robin H. Johnson wrote:
 On Fri, Apr 27, 2007 at 02:33:50AM +0200, Danny van Dyk wrote:
   Both 'assign' and 'cc' (and derivations thereof are not suitable).
  notification=assignment|cc|none ?
 This is to answer expose's question as well, but the attribute should
 only indicate if the maintainer entry should be used for any automatic
 process at all, not how to use it.
 
 One of the reasons is that multiple maintainers each with
 notification=assignment obviously won't work, and it's non-trivial to
 validate via the DTD (yes, DTDs suck compared to XSchema, I know).
 
 I intend that the first non-excluded maintainer entry is the one used
 for the automatic process.
 
 In terms of implementing this in the DTD, I'm going to specify that
 'contact=1' (or whatever name we settle on) is the default, so that we
 don't break validation of any existing metadata:
 
 !ATTLIST maintainer
   contact   (0|1)   1   -- should this maintainer be used by 
 -- automatic processes?
  
 
 In light of the above, how about 'automatic=0'?

Please keep with your original idea of letting maintainers opt out vs
some of the ideas proposed in this thread where maintainers have to opt
in as I'm sure the metadata.xml files wont be updated by enough people
to really gain the benefit of what we are trying to do here if they have
to do opt in.

Thanks.

 
-- 
Ned Ludd [EMAIL PROTECTED]

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-27 Thread Robin H. Johnson
On Fri, Apr 27, 2007 at 10:32:25AM +0200, Jan Kundr?t wrote:
 AFAIK the preferred way of specifying boolean values in XML is to use
 contact=contact, not contact=1.
I can't find this described anywhere in the XML specification
http://www.w3.org/TR/REC-xml/

Have you got a reference for it?

 Speaking of name, I'd try to include string bug somewhere in the
 attribute name, like bugzilla-auto-assignment or something...
I'll follow this up in solar's post.

-- 
Robin Hugh Johnson
Gentoo Linux Developer  Council Member
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpdEutQU03CJ.pgp
Description: PGP signature


Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-27 Thread Robin H. Johnson
On Fri, Apr 27, 2007 at 08:57:27AM -0700, Ned Ludd wrote:
  In light of the above, how about 'automatic=0'?
 Please keep with your original idea of letting maintainers opt out vs
 some of the ideas proposed in this thread where maintainers have to opt
 in as I'm sure the metadata.xml files wont be updated by enough people
 to really gain the benefit of what we are trying to do here if they have
 to do opt in.
Err, nowhere in here have I said it was going to be opt-in.

Taking into account the other reasonable input, how about the name of
attribute 'automatic-bug' ?

'automatic-bug=1' will be implied by the DTD, and developers will have
to explicitly opt-out by including 'automatic-bug=0' in their
maintainer entries.

-- 
Robin Hugh Johnson
Gentoo Linux Developer  Council Member
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpAnqHwj7xmg.pgp
Description: PGP signature


Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-27 Thread Matti Bickel
Robin H. Johnson [EMAIL PROTECTED] wrote:
 Taking into account the other reasonable input, how about the name of
 attribute 'automatic-bug' ?

I would like assign somewhere in the name, but i'd be fine with your
proposal as well.
-- 
Regards, Matti Bickel
Encrypted/Signed Email preferred


pgpqjgvmTCCXj.pgp
Description: PGP signature


Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-27 Thread Jan Kundrát
Robin H. Johnson wrote:
 Have you got a reference for it?

That's how it is in XHTML, so I thought it's common practice in XML as
well. That probably isn't true, so sorry for noise.

Cheers,
-jkt

-- 
cd /local/pub  more beer  /dev/mouth



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Planning for automatic assignment of bugs

2007-04-26 Thread Robin H. Johnson
So as a not-so-brief follow-up to solar's email, here is a brief
proposal on the automatic assignment stuff, incl. one spot that we might
need to add an attribute to metadata.xml.

Assignment process, triggering:
===
Auto-assignment will be be applied/available in the following cases:
1. New bugs created with the guided process, having a Product equal to
   'Gentoo Linux' and a component not equal to 'Eclasses and Profiles'.
2. Open bugs will have a new action available: 'Reassign by metadata',
   with a text input field. The text field will be auto-filled with a
   package atom $CAT/$PN by parsing the summary line. Using the action
   will provide the package atom to the next stage.

If multiple package atoms are present in a summary line, the first one
wins.

Assignment process, after the package is known:
===

We have a package spec now, so we can find who to assign the bug to.

Objectives in this section are to reduce unwanted duplicate mail, while
still preserving the data in metadata for non-automated usage.

Case 1 - Metadata contains only a herd
--
- The herd will have @gentoo.org appended, and this must be a valid
  bugzilla account.

Case 2 - Metadata contains a single maintainer
--
- The herd field is not used.
- The maintainer address is used as the bugzilla assignee. 
This is important for all the herds that have aliases that are NOT the
same as their herd name!
This diverges from existing manual practice, to avoid unnecessary
duplicate mail, and means that existing metadata may need a cleanup.

Case 3 - Metadata contains multiple maintainers
---
- Follow case 2 first.
- Further maintainer addresses are used in the CC field.

Case 4 - Metadata contains multiple maintainers, some special
-
- Follow case 3 first.
- If a maintainer is listed in the metadata for special reasons (eg only
  for some special patch), they should include the 'contact=0' attribute
  on their maintainer element AND have a role element present
  describing why.
- This also allows for cases where the herd address should be used as
  the assignee, and the maintainer does NOT want a duplicate CC.

Comments etc welcome.

-- 
Robin Hugh Johnson
Gentoo Linux Developer  Council Member
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpAyHvIg8bhS.pgp
Description: PGP signature


Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-26 Thread Robin H. Johnson
Correction to the previous email, this replaces the old Case #1:

On Thu, Apr 26, 2007 at 12:40:06PM -0700, Robin H. Johnson wrote:
 Case 1 - Metadata contains only a herd
 --
- The herd will looked up in herds.xml, and the email from herds.xml
  must be a valid bugzilla account.

-- 
Robin Hugh Johnson
Gentoo Linux Developer  Council Member
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgplFLWZWmMYz.pgp
Description: PGP signature


Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-26 Thread Dan Meltzer
On Thursday 26 April 2007 3:40:06 pm Robin H. Johnson wrote:
 So as a not-so-brief follow-up to solar's email, here is a brief
 proposal on the automatic assignment stuff, incl. one spot that we might
 need to add an attribute to metadata.xml.

 Assignment process, triggering:
 ===
 Auto-assignment will be be applied/available in the following cases:
 1. New bugs created with the guided process, having a Product equal to
'Gentoo Linux' and a component not equal to 'Eclasses and Profiles'.
 2. Open bugs will have a new action available: 'Reassign by metadata',
with a text input field. The text field will be auto-filled with a
package atom $CAT/$PN by parsing the summary line. Using the action
will provide the package atom to the next stage.

 If multiple package atoms are present in a summary line, the first one
 wins.

 Assignment process, after the package is known:
 ===

 We have a package spec now, so we can find who to assign the bug to.

 Objectives in this section are to reduce unwanted duplicate mail, while
 still preserving the data in metadata for non-automated usage.

 Case 1 - Metadata contains only a herd
 --
 - The herd will have @gentoo.org appended, and this must be a valid
   bugzilla account.

 Case 2 - Metadata contains a single maintainer
 --
 - The herd field is not used.
 - The maintainer address is used as the bugzilla assignee.
 This is important for all the herds that have aliases that are NOT the
 same as their herd name!
 This diverges from existing manual practice, to avoid unnecessary
 duplicate mail, and means that existing metadata may need a cleanup.

 Case 3 - Metadata contains multiple maintainers
 ---
 - Follow case 2 first.
 - Further maintainer addresses are used in the CC field.

 Case 4 - Metadata contains multiple maintainers, some special
 -
 - Follow case 3 first.
 - If a maintainer is listed in the metadata for special reasons (eg only
   for some special patch), they should include the 'contact=0' attribute
   on their maintainer element AND have a role element present
   describing why.
 - This also allows for cases where the herd address should be used as
   the assignee, and the maintainer does NOT want a duplicate CC.

 Comments etc welcome.

Sounds good... one suggestion I have is to try and detect new ebuild 
submissions and resassign them to m-w automatically as well.  maybe a 
checkbox this is a new ebuild or some other way to automatically detect it?
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-26 Thread expose
Dan Meltzer wrote:
 Sounds good... one suggestion I have is to try and detect new ebuild
 submissions and resassign them to m-w automatically as well.  maybe a
 checkbox this is a new ebuild or some other way to automatically detect
 it?
Why not introduce a Case 5 which is similar to:
1. None of the other Cases worked
2. There is a package atom in the summary line
(2a. Words like ebuild new occur somewhere)
3. Check wether the package matches a class of packages
4. If it doesnt match any classes, leave it to the wranglers.

package classes would be something like:
If the package is of the games-* category assign it to the games herd.
If the package matches */*python* assign it to $whoever

Unless the specifications for a package were not met correctly, or the 
submitter did not include a atom in the summery as expected, the checkbox 
shouldn't be needed, because the bug should be assigned by either one of 
cases 1 to 4. If it isnt, case 5 (or whatever else automatic handling for 
new-ebuilds) should be suiteable for trying to fix it anyway.

Comments?
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-26 Thread Nguyen Thai Ngoc Duy

On 4/26/07, Robin H. Johnson [EMAIL PROTECTED] wrote:

Case 2 - Metadata contains a single maintainer
--
- The herd field is not used.
- The maintainer address is used as the bugzilla assignee.
This is important for all the herds that have aliases that are NOT the
same as their herd name!
This diverges from existing manual practice, to avoid unnecessary
duplicate mail, and means that existing metadata may need a cleanup.


It should take devaway into account.

--
Duy
--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-26 Thread Joshua Jackson
Nguyen Thai Ngoc Duy wrote:
 On 4/26/07, Robin H. Johnson [EMAIL PROTECTED] wrote:
 Case 2 - Metadata contains a single maintainer
 --
 - The herd field is not used.
 - The maintainer address is used as the bugzilla assignee.
 This is important for all the herds that have aliases that are NOT the
 same as their herd name!
 This diverges from existing manual practice, to avoid unnecessary
 duplicate mail, and means that existing metadata may need a cleanup.

 It should take devaway into account.

why? Seriously, dev-away != dev retired... having it take devaway into
account is pointless in my opinion as it won't improve it being properly
assigned...as it'll be covered in other cases, and its not like there's
not bugs for all of us dev's that have not sat there for a month or so,
at some point



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-26 Thread Daniel Drake

Robin H. Johnson wrote:

Case 2 - Metadata contains a single maintainer
--
- The herd field is not used.
- The maintainer address is used as the bugzilla assignee. 


At least for some packages I'm involved with, this will result in me 
deleting myself from metadata.xml (but I'd rather not do so).


I like these bugs to go to the herd, not me directly. I get the bug mail 
anyway (I'm in the herd) but sometimes other herd members who see the 
mail jump in and help resolve the bug, for which I'm very grateful.


That aside, I like having myself in the metadata alongside the herd, to 
point out that I am the primary maintainer within the herd for the 
package in question. It is also useful for others so that when they have 
questions about the package, they know who to approach on IRC or whatever.


Apart from those small concerns, I like the idea of what you are proposing.

Thanks,
Daniel

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-26 Thread expose
Joshua Jackson wrote:
 Nguyen Thai Ngoc Duy wrote:
  On 4/26/07, Robin H. Johnson [EMAIL PROTECTED] wrote:
  Case 2 - Metadata contains a single maintainer
  --
  - The herd field is not used.
  - The maintainer address is used as the bugzilla assignee.
  This is important for all the herds that have aliases that are NOT the
  same as their herd name!
  This diverges from existing manual practice, to avoid unnecessary
  duplicate mail, and means that existing metadata may need a cleanup.
 
  It should take devaway into account.

 why? Seriously, dev-away != dev retired... having it take devaway into
 account is pointless in my opinion as it won't improve it being properly
 assigned...as it'll be covered in other cases, and its not like there's
 not bugs for all of us dev's that have not sat there for a month or so,
 at some point
I think it is important that someone has a look at the bugs submitted.
For instance, a submitter might not behave correctly, and submit a security 
issue to Gentoo Linux instead of Gentoo Security. Or the submitter does not 
even recognize it is a security issue, or might be or become one.
In that case the bug would sit there until the dev it was automatically 
assigned to is back again (which could take quite some time).

Another (minor) reason, might be, that bugs could be assigned to the wrong 
person, because of whatsoever reason, and that dev is unavailable.
This bug would sit there and wait to be reassigned until the dev comes back, 
who will reassign it to the correct dev, who in turn will mark it 
as dublicate because someone else useing the correct format for the summary 
submitted it yet and the submitter of our first bug feels demotivated :-)

Maybe it is for those and similar reasons which can easily be made up better 
to leave bugs which would otherwise be automatically assigned to devs which 
are unavailable to the bug-wranglers, or maybe better:
Automatically assign but manually review them to emulate the first glance the 
unavailable dev would have taken.

Obviously, there should not be too many bugs which would be automatically 
assigned to developers which are away anyway.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-26 Thread expose
Daniel Drake wrote:
 That aside, I like having myself in the metadata alongside the herd, to
 point out that I am the primary maintainer within the herd for the
 package in question. It is also useful for others so that when they have
 questions about the package, they know who to approach on IRC or whatever.
As far as I understand it, wouldnt making you the first maintainer in the list 
but adding 'contact=0' and a comment that you are the primary maintainer 
within the herd, and then following the herd as the maintainer the bug is to 
be actually assigned to fix this?
Naturally most users will read your comment first as it is at the top of the 
file, thus know that you are the one to be contacted in case of random 
questions, but the herd will still be the bugzilla account the bug is 
assigned to.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-26 Thread Mart Raudsepp
On Thu, 2007-04-26 at 15:16 -0700, Robin H. Johnson wrote:
 On Thu, Apr 26, 2007 at 05:46:24PM -0400, Daniel Drake wrote:
   Robin H. Johnson wrote:
   Case 2 - Metadata contains a single maintainer
   --
   - The herd field is not used.
   - The maintainer address is used as the bugzilla assignee. 
   At least for some packages I'm involved with, this will result in me 
   deleting myself from metadata.xml (but I'd rather not do so).
  
   I like these bugs to go to the herd, not me directly. I get the bug mail 
   anyway (I'm in the herd) but sometimes other herd members who see the mail 
   jump in and help resolve the bug, for which I'm very grateful.
 This is handled by a later case in the proposal.
 Simply interest a maintainer element with the herd email address, and
 add the contact=0 attribute to your maintainer element in the file.
 
   That aside, I like having myself in the metadata alongside the herd, to 
   point out that I am the primary maintainer within the herd for the package 
   in question. It is also useful for others so that when they have questions 
   about the package, they know who to approach on IRC or whatever.
 This is exactly the reason that I proposed the contact=0 attribute - for
 some of the packages that I maintain, I do not want the bugs assigned
 directly to me, but to the herd instead. While for others I _do_ want
 the duplicate.

Could contact be named differently then?

contact=0 in metadata.xml in this context means that the automatic
reassigning should not assign to that maintainer, but when a user looks
whom to ask specific questions from and sees contact=0 he/she will
understand he/she is not to contact that person as the value is zero,
but Daniel wants them to contact precisely him in that case.
A different keyword might be better for that reason.

Good proposal otherwise!
I do have some reservations due to no human looking over new bugs
(before they get reassigned to a possibly otherwise busy maintainer), as
someone already has expressed, but we can always try it out and see how
it goes, I think.

Regards,
Mart Raudsepp

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-26 Thread Robin H. Johnson
On Fri, Apr 27, 2007 at 02:57:59AM +0300, Mart Raudsepp wrote:
  This is exactly the reason that I proposed the contact=0 attribute - for
  some of the packages that I maintain, I do not want the bugs assigned
  directly to me, but to the herd instead. While for others I _do_ want
  the duplicate.
 Could contact be named differently then?
'autocontact' then?
Both 'assign' and 'cc' (and derivations thereof are not suitable).

 I do have some reservations due to no human looking over new bugs
 (before they get reassigned to a possibly otherwise busy maintainer), as
 someone already has expressed, but we can always try it out and see how
 it goes, I think.
This happens already, simply observe the bugs that pile up for
understaffed herds, or developers that are AWOL.

-- 
Robin Hugh Johnson
Gentoo Linux Developer  Council Member
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpRBQa9lmZpD.pgp
Description: PGP signature


Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-26 Thread expose
Mart Raudsepp wrote:
 Could contact be named differently then?

 contact=0 in metadata.xml in this context means that the automatic
 reassigning should not assign to that maintainer, but when a user looks
 whom to ask specific questions from and sees contact=0 he/she will
 understand he/she is not to contact that person as the value is zero,
 but Daniel wants them to contact precisely him in that case.
 A different keyword might be better for that reason.
Good point.
AutoAssign=FALSE
NoAutoAssignment=TRUE
etc might be better.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-26 Thread expose
Robin H. Johnson wrote:
 Both 'assign' and 'cc' (and derivations thereof are not suitable).
Why not?
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-26 Thread Danny van Dyk
Am Freitag, 27. April 2007 schrieb Robin H. Johnson:
 On Fri, Apr 27, 2007 at 02:57:59AM +0300, Mart Raudsepp wrote:
   This is exactly the reason that I proposed the contact=0
   attribute - for some of the packages that I maintain, I do not
   want the bugs assigned directly to me, but to the herd instead.
   While for others I _do_ want the duplicate.
 
  Could contact be named differently then?

 'autocontact' then?
 Both 'assign' and 'cc' (and derivations thereof are not suitable).
notification=assignment|cc|none ?

Danny
-- 
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-26 Thread Andrej Kacian
On Thu, 26 Apr 2007 17:24:06 -0700
Robin H. Johnson [EMAIL PROTECTED] wrote:

 On Fri, Apr 27, 2007 at 02:57:59AM +0300, Mart Raudsepp wrote:
   This is exactly the reason that I proposed the contact=0 attribute - for
   some of the packages that I maintain, I do not want the bugs assigned
   directly to me, but to the herd instead. While for others I _do_ want
   the duplicate.  
  Could contact be named differently then?  
 'autocontact' then?
 Both 'assign' and 'cc' (and derivations thereof are not suitable).

How about 'possessive'? :)

-- 
Andrej

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Planning for automatic assignment of bugs

2007-04-26 Thread Robin H. Johnson
On Fri, Apr 27, 2007 at 02:33:50AM +0200, Danny van Dyk wrote:
  Both 'assign' and 'cc' (and derivations thereof are not suitable).
 notification=assignment|cc|none ?
This is to answer expose's question as well, but the attribute should
only indicate if the maintainer entry should be used for any automatic
process at all, not how to use it.

One of the reasons is that multiple maintainers each with
notification=assignment obviously won't work, and it's non-trivial to
validate via the DTD (yes, DTDs suck compared to XSchema, I know).

I intend that the first non-excluded maintainer entry is the one used
for the automatic process.

In terms of implementing this in the DTD, I'm going to specify that
'contact=1' (or whatever name we settle on) is the default, so that we
don't break validation of any existing metadata:

!ATTLIST maintainer
  contact   (0|1)   1   -- should this maintainer be used by 
-- automatic processes?
 

In light of the above, how about 'automatic=0'?

-- 
Robin Hugh Johnson
Gentoo Linux Developer  Council Member
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpcmSEkc0ZuK.pgp
Description: PGP signature