RE: make mkpatches broken

RE: make mkpatches broken

[Ian Pratt]

 > > I think there's still an outstanding question as to whther its 
> > possible to configure bugzilla to enable anonymous bug 
> sumbissions (no 
> > login). If so, we'll go with bugzilla to enable 
> crosslinking with other bugzillas.
> > If not, I porpose to just go with the Trac server we already have.
> > 
> > Anyone know?
> 
> Unfortunately, I couldn't find a way to do that. Bugzilla 
> seems to require a user login (email/pw).  All of the 
> documentation also suggests so. The two bugzillas I've worked 
> with (OSDL's and IBM internal) are set up to require a login.
> 
> You could set up a dummy login account and a default mailing 
> list as the email if needed, would that be sufficient for 
> your needs? From what I can see, it's important to be able to 
> exchange email with the submitter, so having it be a genuine 
> email is useful. Is an anonymous login a showstopper?
> Is the issue supporting the submitter login accounts?

Several of the the team are of the strong view that requiring users to
create an account and login to submit a bug means that many bugs don't
get submitted out of laziness. 

I guess the simplest hack would just be to change the bugzilla login
dialogue such that it tells people to login with an acount called 'bug'
password 'bug' if they don't want to create a real account.

Other than this, I'm not aware of any strong preference of Trac over
Bugzilla. It would be good to hear if other people have strong views
either way.

Ian


Perhaps we could get around this by having a default account (with a
/dev/null email) and tell people to login o

RE: make mkpatches broken

[Jeremy Katz]

On Wed, 2005-04-20 at 00:56 +0100, Ian Pratt wrote:
> Several of the the team are of the strong view that requiring users to
> create an account and login to submit a bug means that many bugs don't
> get submitted out of laziness. 

The problem in this case is that if they're too lazy to create an
account, they're going to be too lazy to provide you all the information
you need on the first time around and/or provide follow-up.  It's hard
enough even with people who go to the effort of creating an account.

You also help to avoid the issue of bugtracker spamming with this -- I
haven't actually seen bugtracker spam, but wiki spam is getting more and
more common (thus having more and more wikis requiring account
creation).  But this is just hypothetical on my part.

> I guess the simplest hack would just be to change the bugzilla login
> dialogue such that it tells people to login with an acount called 'bug'
> password 'bug' if they don't want to create a real account.

This might be an (albeit hacky) workable way to deal with the "problem".
And gives an easy way to shut it down if it does get abused.

> Other than this, I'm not aware of any strong preference of Trac over
> Bugzilla. It would be good to hear if other people have strong views
> either way.

My preference towards bugzilla is mostly due to
a) everyone else in the world uses it, so people are used to it
b) some tools are starting to be written that nicely talk to bugzillas
and give you nicer ways to get the data than using web forms using, eg,
the XML-RPC support and other things

Jeremy

Re: make mkpatches broken

[Nivedita Singhvi]

Ian Pratt wrote:

> Several of the the team are of the strong view that requiring users to
> create an account and login to submit a bug means that many bugs don't
> get submitted out of laziness. 

That does happen, and it would be nice to make it as
easy as possible.

> I guess the simplest hack would just be to change the bugzilla login
> dialogue such that it tells people to login with an acount called 'bug'
> password 'bug' if they don't want to create a real account.

Right. Note that the bugzilla account also requires an email.
Further communication with the submitter then occurs through
this email (more info, status, etc). This avoids the need for
the submitter to include contact information in the bug report.

You would need to set up a dummy email or redirect the anonymous
bug reports to a mailing list. You might have to deal with hit
and runs (i.e. submissions, with submitters never checking the
report/list again). This was a significant disadvantage to
anonymous submissions.

Perhaps you manage by incorporating both in the bug handling
business:
	- a bugzilla with accounts for those who are
	  motivated, and will follow up with testing of
	  patches etc..
	- a mailing list to report bugs on for those
	  who don't want to take the trouble to login
	  (a mailing list that allowed non-submitter posts).
	  You then have the option of having someone
	   enter that report in the bug database if desired..
	  This could be xen-devel, for that matter.


thanks,
Nivedita

Re: make mkpatches broken

[Nivedita Singhvi]

Nivedita Singhvi wrote:

> Right. Note that the bugzilla account also requires an email.
> Further communication with the submitter then occurs through
> this email (more info, status, etc). This avoids the need for
> the submitter to include contact information in the bug report.


Ian Pratt wrote:
>> Perhaps we could get around this by having a default account (with a
>> /dev/null email) and tell people to login o

Ah, sorry, didn't see the last 2 lines of your email..

thanks,
Nivedita (smack..)

RE: make mkpatches broken

[Ian Pratt]

> On a related note, the whole bug tracking system thread seems 
> to have fizzled with what seemed, from what I saw at least, 
> everyone agreeing that a bug tracking system would be nice to 
> have, and "the sooner the better."  Is there a more concrete 
> date by which we can believe the bug tracking system will be 
> available for everyone to use?

I think there's still an outstanding question as to whther its possible
to configure bugzilla to enable anonymous bug sumbissions (no login). If
so, we'll go with bugzilla to enable crosslinking with other bugzillas.
If not, I porpose to just go with the Trac server we already have.

Anyone know?

Ian

Re: make mkpatches broken

[Nivedita Singhvi]

Ian Pratt wrote:

> I think there's still an outstanding question as to whther its possible
> to configure bugzilla to enable anonymous bug sumbissions (no login). If
> so, we'll go with bugzilla to enable crosslinking with other bugzillas.
> If not, I porpose to just go with the Trac server we already have.
> 
> Anyone know?

Unfortunately, I couldn't find a way to do that. Bugzilla
seems to require a user login (email/pw).  All of the
documentation also suggests so. The two bugzillas I've
worked with (OSDL's and IBM internal) are set up to
require a login.

You could set up a dummy login account and a default mailing list
as the email if needed, would that be sufficient for your
needs? From what I can see, it's important to be able to
exchange email with the submitter, so having it be a genuine
email is useful. Is an anonymous login a showstopper?
Is the issue supporting the submitter login accounts?

thanks,
Nivedita

make mkpatches broken

[Paul Larson]

[-- Attachment #1.1: Type: text/plain, Size: 757 bytes --]

I just noticed that make mkpatches seems to be broken in at least
xen-unstable at the moment.  Complains about not having a target for
freebsd since it picks it up in ALLSPARSETREES, but no mk file exists
for it under buildconfigs.  I'm guessing something probably just got
dropped when Kips freebsd stuff was merged?

On a related note, the whole bug tracking system thread seems to have
fizzled with what seemed, from what I saw at least, everyone agreeing
that a bug tracking system would be nice to have, and "the sooner the
better."  Is there a more concrete date by which we can believe the bug
tracking system will be available for everyone to use?

-- 
Thanks,
Paul Larson
plars@linuxtestproject.org
http://www.linuxtestproject.org

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

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: make mkpatches broken

[Kip Macy]

FreeBSD isn't setup as a default target so I didn't stick anything in to tie in.

Is there something I should add to play nicely with others?

On 4/19/05, Paul Larson <plars@linuxtestproject.org> wrote:
> I just noticed that make mkpatches seems to be broken in at least
> xen-unstable at the moment.  Complains about not having a target for
> freebsd since it picks it up in ALLSPARSETREES, but no mk file exists
> for it under buildconfigs.  I'm guessing something probably just got
> dropped when Kips freebsd stuff was merged?
> 
> On a related note, the whole bug tracking system thread seems to have
> fizzled with what seemed, from what I saw at least, everyone agreeing
> that a bug tracking system would be nice to have, and "the sooner the
> better."  Is there a more concrete date by which we can believe the bug
> tracking system will be available for everyone to use?
> 
> --
> Thanks,
> Paul Larson
> plars@linuxtestproject.org
> http://www.linuxtestproject.org
> 
> 
>

Re: make mkpatches broken

[Paul Larson]

[-- Attachment #1.1: Type: text/plain, Size: 717 bytes --]

On Tue, 2005-04-19 at 11:51 -0700, Kip Macy wrote:
> FreeBSD isn't setup as a default target so I didn't stick anything in to tie in.
> 
> Is there something I should add to play nicely with others?
> 
It would appear that it needs a corresponding file under buildconfigs.
The problem is that when you do a make mkpatches, it picks up a list of
targets by looking at all the sparse trees in the base of the xen source
tree.  Since a freebsd sparse tree is there now, it stops the build when
it can't find a valid freebsd-5.3-xen.patch target for building.
Unfortunately, this also seems to be the first in the list.

-- 
Thanks,
Paul Larson
plars@linuxtestproject.org
http://www.linuxtestproject.org

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

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel