<pythonian4000> paulproteus, I disagree. What about e.g. Sugar where the project
name is not what is used for the bug (bug_project_name_format defines what
Project will be used)
<paulproteus> doing that column lengthening now
<paulproteus> pythonian4000: oh...
<paulproteus> Then it's a "Bug tracker name".
<paulproteus> Except when it's not, yargle.
<paulproteus> I think we should "for now" only support bug trackers that do
foreignkey to a project, in the web interface.
<paulproteus> I know that means we don't get to move GNOME Love in, for example,
but really one-project-per-bug-tracker is the common case.
<pythonian4000> So that's only ones that have {project} under
bug_project_nameformat
<paulproteus> Once we focus that way, we can also simplify the form, and then we
can have a different, more complex form for the multiproject case.
-- paulproteus nods
<paulproteus> One easy way to do that is to actually have both be stored in the
same table.
<paulproteus> Since the object supports both.
<paulproteus> Oh, in which case you need project_name... well make it
bug_tracker_name, then, and create a ForeignKey(Project) that can be null...
<paulproteus> And for single-project bug trackers, we auto-generate the
bug_trackername
<paulproteus> (see *this is code review -- should have given it to you earlier :P)
<paulproteus> But it only makes sense as I imagine actually using it, like you
are now
<pythonian4000> Well I
<pythonian4000> 've looked through bugtrackers/bugzilla.py and there is actually
only a few trackers that use the project name as the bug_project_name
<paulproteus> Hmm. I guess that's because most Bugzilla projects are complex.
<paulproteus> Like, "you wouldn't set up Bugzilla if you had only one project
because Bugzilla is such a bear"
<pythonian4000> quite a few use {component} or {product}, and there are also
ones that have their own special methods for determinig what the name is (which
I was originally going to leave as special cases)
<paulproteus> Hmm... I see what you mean.
Part of the original issue here stems from a terminology issue that is being
fixed in issue371. However, as per the discussion below, it would certainly be
useful to have a link between a tracker that we import from, and the projects
that it tracks bugs for.
IRC discussion:
21:51 paulproteus jmaister: re: http://cl.ly/2s25290F452N0i0N223s -- I
would also love a link you can go to that just lists the bug trackers (if any)
for your project
21:51 paulproteus Then the sidebar at http://openhatch.org/+project/Amarok
(for example) would link there
21:51 paulproteus It could even say, "No bug trackers listed for this
project. Do you want to add one?"
21:52 jmaister That makes perfect sense
21:52 pythonian4000 paulproteus, that would probably directly tying a project
to the tracker(s) that supply bugs for it.
21:53 pythonian4000 s/probably/require
21:53 paulproteus Well, the tracker should have (IMHO) a ForeignKey to a
project, yeah.
21:53 jmaister isn't that a good thing?
21:53 pythonian4000 paulproteus, I would say the other way around.
21:53 paulproteus That's good enough for the simple case, and we can worry
about the non-simple case later.
21:53 paulproteus pythonian4000: Right, of course -- the other way
21:54 pythonian4000 It is much more likely that a tracker supply multiple
projects than a project have multiple trackers.
21:54 jmaister It could even be a limitation, not being able to add
trackers for nonexisting projects
21:54 pythonian4000 jmaister, when we add trackers at present for
non-existing projects, it auto-creates them.
21:54 jmaister right
21:55 pythonian4000 E.g. if a tracker ties bugs to project names based on the
"component" field, and a bug appears under a new component, a new project is
created.
21:55 pythonian4000 (This is governed by the bug_project_name_format field.)
21:55 jmaister Auto complete for project name would be cool though.
Makes people sure they spell the project right
21:56 pythonian4000 jmaister, see issue 161 as well.
21:56 sufjan 04Bug https://openhatch.org/bugs/issue161 - title: In
mysite/customs/models.py we use "projectname" when instead we should ForeignKey
to a Project, creator: paulproteus, assignedto: pythonian4000, milestone:
0.11.03, status: chatting
21:56 paulproteus jmaister: I think the common user experience should be
that they come from the project page, fwiw, at which point it's already filled in
21:56 jmaister paulproteus: You rock at making sense today!
21:56 pythonian4000 +1 jmaister
21:56 jmaister (for all I know you probably always do)
21:56 paulproteus Yay a good day.
21:58 jmaister Ok, so the /customs/ is for specially interested people.
It's the edit/add page and implementation with project page that should have
focus. Right?
21:58 pythonian4000 I agree. The whole reason I started this implementation
was to make it easier for people to add new trackers and edit existing ones.
21:59 jmaister So do we need /customs/ at all? Can't we just directly
implement this with the project?
21:59 paulproteus foxfirefey: http://foxfirefey.dreamwidth.org/272059.html
is totally good.
21:59 foxfirefey Aw, kitten.
22:00 foxfirefey He is a good kitten.
22:02 pythonian4000 jmaister, I put it in /customs/ originally because of the
way the codebase was layed out.
22:03 pythonian4000 I.e. /search/ is implemented in mysite.search, /people/
is implemented in mysite.profile, /+projects/ is implemented in mysite.project etc.
22:03 paulproteus I would suggest /+bugtrackers/ for a URL prefix
22:04 pythonian4000 s/bugtrackers/bugimporters/I'm correcting terminology
during asyncification
22:05 paulproteus pythonian4000: For the user, though, seems like they're
adding a bug tracker, no?
22:06 pythonian4000 True...
22:06 pythonian4000 Yes, that is true.
22:06 * pythonian4000 is happy with that.
22:08 jmaister Sorry for being ambigous (?) but what I meant was: Can
the bugtrackers be a subimplementation of a project, or is it so that a tracker
can belong to several projects?
22:09 jmaister ambiguous
22:09 pythonian4000 jmaister, a tracker can belong to several projects.
22:09 jmaister Engrish is hard
22:09 jmaister well, that settles it
22:09 paulproteus <jmaister> i quit
22:09 pythonian4000 E.g. KDE or Gnome bug trackers, which services many
Products or Components.
22:10 jmaister paulproteus: :P
22:11 pythonian4000 Or OLPC and Sugar trackers, which are OSs and so their
various components are separated out into separate projects.
22:11 pythonian4000 ^ On ones like those, issue 328 will be useful.
22:11 sufjan 04Bug https://openhatch.org/bugs/issue328 - title:
Projects should have separate URL/identifying and display names, creator:
pythonian4000, assignedto: pythonian4000, milestone: 0.11.03, status: chatting
22:12 paulproteus Since we're talking about me whipping up the backend in a
day, I would be okay with "for now" only handling single-bug-tracker projects.
22:12 pythonian4000 So that the horribly non-descript in-tracker names can be
kept for the URLs and something else can be displayed.
22:12 paulproteus (FWIW)
22:12 paulproteus It's important to design the beautiful dream, too, so by
all means I think this conversation is good.
22:14 pythonian4000 FWIW the only one that properly works is Google, which is
by definition one-tracker-per-project.
22:14 paulproteus But for now, I think that we can just add a note in the
UI saying "If this is for >1 project, then, uh, add a note on this wiki page"
22:14 pythonian4000 Trac is unimplemented (but as it is the first importer I
am asyncing that will change very soon) and Bugzilla is... well, Bugzilla =D
22:15 pythonian4000 paulproteus, eventually I would hope that the following
would happen:
22:16 pythonian4000 \ several projects exist that happen to have the same
tracker (and by chance have the exact same name as in the tracker ^^)
22:16 pythonian4000 * one project uses this new link to add the tracker,
adding queries that cover the other projects as well.
22:17 pythonian4000 * The importer ties new Bugs for the other projects to
those projects correctly (as is the case currently as long as naming is correct)
22:17 pythonian4000 * Something ties the tracker to the other existing
projects, so their "Add your bug tracker" links now change to point at the same
bug tracker that the first project added.
As I discovered while implementing the asynchronous Bug importer, this would
need to be implemented using a GenericForeignKey from the Content Types
framework. Basically, the three lines for the tracker_type, tracker_id and
tracker lines could be directly copied from Bug to Project.
Comment by paulproteus:
It'd be nicer if we could make these ForeignKey to a Project object.
Comment by paulproteus:
Comment by pythonian4000:
IRC discussion: 21:51 paulproteus jmaister: re: http://cl.ly/2s25290F452N0i0N223s -- I would also love a link you can go to that just lists the bug trackers (if any) for your project 21:51 paulproteus Then the sidebar at http://openhatch.org/+project/Amarok (for example) would link there 21:51 paulproteus It could even say, "No bug trackers listed for this project. Do you want to add one?" 21:52 jmaister That makes perfect sense 21:52 pythonian4000 paulproteus, that would probably directly tying a project to the tracker(s) that supply bugs for it. 21:53 pythonian4000 s/probably/require 21:53 paulproteus Well, the tracker should have (IMHO) a ForeignKey to a project, yeah. 21:53 jmaister isn't that a good thing? 21:53 pythonian4000 paulproteus, I would say the other way around. 21:53 paulproteus That's good enough for the simple case, and we can worry about the non-simple case later. 21:53 paulproteus pythonian4000: Right, of course -- the other way 21:54 pythonian4000 It is much more likely that a tracker supply multiple projects than a project have multiple trackers. 21:54 jmaister It could even be a limitation, not being able to add trackers for nonexisting projects 21:54 pythonian4000 jmaister, when we add trackers at present for non-existing projects, it auto-creates them. 21:54 jmaister right 21:55 pythonian4000 E.g. if a tracker ties bugs to project names based on the "component" field, and a bug appears under a new component, a new project is created. 21:55 pythonian4000 (This is governed by the bug_project_name_format field.) 21:55 jmaister Auto complete for project name would be cool though. Makes people sure they spell the project right 21:56 pythonian4000 jmaister, see issue 161 as well. 21:56 sufjan 04Bug https://openhatch.org/bugs/issue161 - title: In mysite/customs/models.py we use "projectname" when instead we should ForeignKey to a Project, creator: paulproteus, assignedto: pythonian4000, milestone: 0.11.03, status: chatting 21:56 paulproteus jmaister: I think the common user experience should be that they come from the project page, fwiw, at which point it's already filled in 21:56 jmaister paulproteus: You rock at making sense today! 21:56 pythonian4000 +1 jmaister 21:56 jmaister (for all I know you probably always do) 21:56 paulproteus Yay a good day. 21:58 jmaister Ok, so the /customs/ is for specially interested people. It's the edit/add page and implementation with project page that should have focus. Right? 21:58 pythonian4000 I agree. The whole reason I started this implementation was to make it easier for people to add new trackers and edit existing ones. 21:59 jmaister So do we need /customs/ at all? Can't we just directly implement this with the project? 21:59 paulproteus foxfirefey: http://foxfirefey.dreamwidth.org/272059.html is totally good. 21:59 foxfirefey Aw, kitten. 22:00 foxfirefey He is a good kitten. 22:02 pythonian4000 jmaister, I put it in /customs/ originally because of the way the codebase was layed out. 22:03 pythonian4000 I.e. /search/ is implemented in mysite.search, /people/ is implemented in mysite.profile, /+projects/ is implemented in mysite.project etc. 22:03 paulproteus I would suggest /+bugtrackers/ for a URL prefix 22:04 pythonian4000 s/bugtrackers/bugimporters/I'm correcting terminology during asyncification 22:05 paulproteus pythonian4000: For the user, though, seems like they're adding a bug tracker, no? 22:06 pythonian4000 True... 22:06 pythonian4000 Yes, that is true. 22:06 * pythonian4000 is happy with that. 22:08 jmaister Sorry for being ambigous (?) but what I meant was: Can the bugtrackers be a subimplementation of a project, or is it so that a tracker can belong to several projects? 22:09 jmaister ambiguous 22:09 pythonian4000 jmaister, a tracker can belong to several projects. 22:09 jmaister Engrish is hard 22:09 jmaister well, that settles it 22:09 paulproteus <jmaister> i quit 22:09 pythonian4000 E.g. KDE or Gnome bug trackers, which services many Products or Components. 22:10 jmaister paulproteus: :P 22:11 pythonian4000 Or OLPC and Sugar trackers, which are OSs and so their various components are separated out into separate projects. 22:11 pythonian4000 ^ On ones like those, issue 328 will be useful. 22:11 sufjan 04Bug https://openhatch.org/bugs/issue328 - title: Projects should have separate URL/identifying and display names, creator: pythonian4000, assignedto: pythonian4000, milestone: 0.11.03, status: chatting 22:12 paulproteus Since we're talking about me whipping up the backend in a day, I would be okay with "for now" only handling single-bug-tracker projects. 22:12 pythonian4000 So that the horribly non-descript in-tracker names can be kept for the URLs and something else can be displayed. 22:12 paulproteus (FWIW) 22:12 paulproteus It's important to design the beautiful dream, too, so by all means I think this conversation is good. 22:14 pythonian4000 FWIW the only one that properly works is Google, which is by definition one-tracker-per-project. 22:14 paulproteus But for now, I think that we can just add a note in the UI saying "If this is for >1 project, then, uh, add a note on this wiki page" 22:14 pythonian4000 Trac is unimplemented (but as it is the first importer I am asyncing that will change very soon) and Bugzilla is... well, Bugzilla =D 22:15 pythonian4000 paulproteus, eventually I would hope that the following would happen: 22:16 pythonian4000 \ several projects exist that happen to have the same tracker (and by chance have the exact same name as in the tracker ^^) 22:16 pythonian4000 * one project uses this new link to add the tracker, adding queries that cover the other projects as well. 22:17 pythonian4000 * The importer ties new Bugs for the other projects to those projects correctly (as is the case currently as long as naming is correct) 22:17 pythonian4000 * Something ties the tracker to the other existing projects, so their "Add your bug tracker" links now change to point at the same bug tracker that the first project added.
Comment by pythonian4000:
Comment by paulproteus:
Status: resolved Nosy List: paulproteus, pythonian4000 Priority: bug Imported from roundup ID: 161 (view archived page) Last modified: 2011-05-01.08:06:54