23 Jan
2013
23 Jan
'13
8:44 a.m.
Hi all
I've just spent some time to adjust settings of new trackers on sf.net.
I also think we could change more, but that's where I'd like to hear
your opinion.
Changes done:
- reenabled mail notifications to mailing lists
- adjusted themes tracker to reduce number of states:
- open - new issue
- assigned - somebody is working on that
- closed - theme was accepted
- rejected - theme was rejected
- removed priority and group from themes tracker
I think similar simplification would be useful for other trackers as
well, my proposals:
Patches tracker
- states:
- open - new issue
- assigned - somebody is working on that
- fixed - patch accepted, waiting for release
- closed - patch accepted and in release
- rejected - patch was rejected
- remove priority
- remove group (does this ever has usable value when reported?)
Features tracker
- states:
- open - new issue
- assigned - somebody is working on that
- fixed - feature implemented, waiting for release
- closed - feature implemented and in release
- rejected - feature was rejected
- remove priority (voting is more useful here IMHO)
- remove group (I think it was also not much used)
Bug tracker
- states:
- open - new issue
- assigned - somebody is working on that
- fixed - feature implemented, waiting for release
- closed - feature implemented and in release
- rejected - feature was rejected
- rename group to Version and make it free text field, this anyway in
most cases just informational field
- add milestone field, which will record version where the bug has been
fixed or is scheduled to be fixed
- are we using priority here for anything else than indicating fixed
but not yet released issues? If not, it should be dropped.
Please share your comments.
--
Michal Čihař | http://cihar.com | http://phpmyadmin.net
23 Jan
23 Jan
9:06 a.m.
2013/1/23 Michal Čihař <michal(a)cihar.com>om>:
Please share your comments.
I agree with the proposal.
We could add milestones to patches as well, to indicate in which
version they are added.
Same for feature requests (but I'm not very sure on that one).
--
Kind regards,
Dieter Adriaenssens
11:36 a.m.
Hi
Dne Wed, 23 Jan 2013 15:06:39 +0100
Dieter Adriaenssens <dieter.adriaenssens(a)gmail.com> napsal(a):
2013/1/23 Michal Čihař <michal(a)cihar.com>om>:
Well the problem here is that milestone list needs to be manually
populated and maintaining one list is much less work than maintaining
three of them...
--
Michal Čihař | http://cihar.com | http://phpmyadmin.net
Please share your comments.
I agree with the proposal.
We could add milestones to patches as well, to indicate in which
version they are added.
Same for feature requests (but I'm not very sure on that one).
24 Jan
24 Jan
4:11 a.m.
2013/1/23 Michal Čihař <michal(a)cihar.com>om>:
Hi
Dne Wed, 23 Jan 2013 15:06:39 +0100
Dieter Adriaenssens <dieter.adriaenssens(a)gmail.com> napsal(a):
I was assuming milestones were shared between trackers, but they are
not, unfortunately.
Maintaining this would mean triple work... :s
If there would be an api to create milestones, we could script it on
the release of a new version, but there is not. [0]
[0] Well, there is an API, but it is readonly :
https://sourceforge.net/apps/trac/sourceforge/wiki/API
--
Kind regards,
Dieter Adriaenssens
2013/1/23 Michal Čihař <michal(a)cihar.com>om>:
Well the problem here is that milestone list needs to be manually
populated and maintaining one list is much less work than maintaining
three of them... Please share your comments.
I agree with the proposal.
We could add milestones to patches as well, to indicate in which
version they are added.
Same for feature requests (but I'm not very sure on that one).
1:07 p.m.
Hi
Dne Thu, 24 Jan 2013 10:11:59 +0100
Dieter Adriaenssens <dieter.adriaenssens(a)gmail.com> napsal(a):
I was assuming milestones were shared between
trackers, but they are
not, unfortunately.
Maintaining this would mean triple work... :s
If there would be an api to create milestones, we could script it on
the release of a new version, but there is not. [0]
Or maybe it would be better to have just one tracker and identify type
by tags or special field?
--
Michal Čihař | http://cihar.com | http://phpmyadmin.net
25 Jan
25 Jan
6:16 a.m.
2013/1/24 Michal Čihař <michal(a)cihar.com>om>:
Hi
Dne Thu, 24 Jan 2013 10:11:59 +0100
Dieter Adriaenssens <dieter.adriaenssens(a)gmail.com> napsal(a):
Sounds good, the handling of all those (bugs, feature requests,
patches) follows the same workflow, so setting up (and maintaining) 3
identical trackers is not efficient. Having bugs and feature requests
in the same tracker makes sense. Each type having a different
tag/category.
Adding patches to the same tracker can be a bit confusing at first,
but then again, since our repo is on github, we receive most patches
as a pull request, anyway.
--
Kind regards,
Dieter Adriaenssens
I was assuming milestones were shared between
trackers, but they are
not, unfortunately.
Maintaining this would mean triple work... :s
If there would be an api to create milestones, we could script it on
the release of a new version, but there is not. [0]
Or maybe it would be better to have just one tracker and identify type
by tags or special field? 
7:52 a.m.
Michal Čihař a écrit :
Hi
Dne Thu, 24 Jan 2013 10:11:59 +0100
Dieter Adriaenssens <dieter.adriaenssens(a)gmail.com> napsal(a):
I think this would confuse users. Besides, how would you name this tracker?
--
Marc Delisle
http://infomarc.info
I was assuming milestones were shared between
trackers, but they are
not, unfortunately.
Maintaining this would mean triple work... :s
If there would be an api to create milestones, we could script it on
the release of a new version, but there is not. [0]
Or maybe it would be better to have just one tracker and identify type
by tags or special field?
8 a.m.
Hi
Dne Fri, 25 Jan 2013 07:52:52 -0500
Marc Delisle <marc(a)infomarc.info> napsal(a):
I think this would confuse users. Besides, how would
you name this tracker?
For example "Issues". I don't think it's that confusing - most free
software project do have just one tracker.
--
Michal Čihař | http://cihar.com | http://phpmyadmin.net
8:02 a.m.
Michal Čihař a écrit :
Hi
Dne Fri, 25 Jan 2013 07:52:52 -0500
Marc Delisle <marc(a)infomarc.info> napsal(a):
Yes, but have they been on sf.net since 2001? Anyway, we have the excuse
of switching to a new interface.
I'm not absolutely against merging trackers.
--
Marc Delisle
http://infomarc.info
I think this would confuse users. Besides, how
would you name this tracker?
For example "Issues". I don't think it's that confusing - most free
software project do have just one tracker.
8:12 a.m.
2013/1/25 Marc Delisle <marc(a)infomarc.info>fo>:
Michal Čihař a écrit :
Changing the instructions on the website/wiki and maybe dedicate a
news item on it should do the trick.
I can mention this on my talk next week, as well.
--
Kind regards,
Dieter Adriaenssens
Hi
Dne Fri, 25 Jan 2013 07:52:52 -0500
Marc Delisle <marc(a)infomarc.info> napsal(a):
Yes, but have they been on sf.net since 2001? Anyway, we have the excuse
of switching to a new interface. I think this would confuse users. Besides, how
would you name this tracker?
For example "Issues". I don't think it's that confusing - most free
software project do have just one tracker.
30 Jan
30 Jan
4:42 a.m.
Hi
Dne Fri, 25 Jan 2013 08:02:33 -0500
Marc Delisle <marc(a)infomarc.info> napsal(a):
Michal Čihař a écrit :
Well I would not propose merging without new interface, but maybe we
can persuade sf.net to adjust tickets tool to support shared set of
milestones?
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
Hi
Dne Fri, 25 Jan 2013 07:52:52 -0500
Marc Delisle <marc(a)infomarc.info> napsal(a):
Yes, but have they been on sf.net since 2001? Anyway, we have the excuse
of switching to a new interface. I think this would confuse users. Besides, how
would you name this tracker?
For example "Issues". I don't think it's that confusing - most free
software project do have just one tracker.
7:31 a.m.
Michal Čihař a écrit :
Hi
Dne Fri, 25 Jan 2013 08:02:33 -0500
Marc Delisle <marc(a)infomarc.info> napsal(a):
Maybe, but on [0] they have 851 tickets.
[0] https://sourceforge.net/p/allura/tickets/?source=navbar
--
Marc Delisle
http://infomarc.info
Michal Čihař a écrit :
Well I would not propose merging without new interface, but maybe we
can persuade sf.net to adjust tickets tool to support shared set of
milestones? Hi
Dne Fri, 25 Jan 2013 07:52:52 -0500
Marc Delisle <marc(a)infomarc.info> napsal(a):
Yes, but have they been on sf.net since
2001? Anyway, we have the excuse
of switching to a new interface. I think this would confuse users. Besides, how
would you name this tracker?
For example "Issues". I don't think
it's that confusing - most free
software project do have just one tracker.
8:45 a.m.
Hi
Dne Wed, 30 Jan 2013 07:31:25 -0500
Marc Delisle <marc(a)infomarc.info> napsal(a):
Michal Čihař a écrit :
Well their issue tracker is full of useful feature requests, so it
would probably take some time...
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
Well I would not propose merging without new
interface, but maybe we
can persuade sf.net to adjust tickets tool to support shared set of
milestones?
Maybe, but on [0] they have 851 tickets.
23 Jan
23 Jan
10:22 a.m.
Michal Čihař a écrit :
Hi all
I've just spent some time to adjust settings of new trackers on sf.net.
I also think we could change more, but that's where I'd like to hear
your opinion.
Changes done:
- reenabled mail notifications to mailing lists
- adjusted themes tracker to reduce number of states:
- open - new issue
- assigned - somebody is working on that
- closed - theme was accepted
- rejected - theme was rejected
- removed priority and group from themes tracker
I think similar simplification would be useful for other trackers as
well, my proposals:
Patches tracker
- states:
- open - new issue
- assigned - somebody is working on that
- fixed - patch accepted, waiting for release
- closed - patch accepted and in release
- rejected - patch was rejected
- remove priority
- remove group (does this ever has usable value when reported?)
Features tracker
- states:
- open - new issue
- assigned - somebody is working on that
- fixed - feature implemented, waiting for release
- closed - feature implemented and in release
- rejected - feature was rejected
- remove priority (voting is more useful here IMHO)
- remove group (I think it was also not much used)
Bug tracker
- states:
- open - new issue
- assigned - somebody is working on that
- fixed - feature implemented, waiting for release
- closed - feature implemented and in release
- rejected - feature was rejected
- rename group to Version and make it free text field, this anyway in
most cases just informational field
- add milestone field, which will record version where the bug has been
fixed or is scheduled to be fixed
- are we using priority here for anything else than indicating fixed
but not yet released issues? If not, it should be dropped.
Please share your comments.
Michal,
what happens for tickets having a state which gets deleted?
--
Marc Delisle
http://infomarc.info
11:33 a.m.
Hi
Dne Wed, 23 Jan 2013 10:22:05 -0500
Marc Delisle <marc(a)infomarc.info> napsal(a):
what happens for tickets having a state which gets
deleted?
I don't know what would happen, but I would like to mass-change states
before to new ones (I already did that for themes).
--
Michal Čihař | http://cihar.com | http://phpmyadmin.net
11:57 a.m.
Michal Čihař a écrit :
Hi all
I've just spent some time to adjust settings of new trackers on sf.net.
I also think we could change more, but that's where I'd like to hear
your opinion.
Changes done:
- reenabled mail notifications to mailing lists
- adjusted themes tracker to reduce number of states:
- open - new issue
- assigned - somebody is working on that
- closed - theme was accepted
- rejected - theme was rejected
- removed priority and group from themes tracker
I think similar simplification would be useful for other trackers as
well, my proposals:
Patches tracker
- states:
- open - new issue
- assigned - somebody is working on that
- fixed - patch accepted, waiting for release
- closed - patch accepted and in release
- rejected - patch was rejected
- remove priority
- remove group (does this ever has usable value when reported?)
Features tracker
- states:
- open - new issue
- assigned - somebody is working on that
- fixed - feature implemented, waiting for release
- closed - feature implemented and in release
- rejected - feature was rejected
- remove priority (voting is more useful here IMHO)
- remove group (I think it was also not much used)
Bug tracker
- states:
- open - new issue
- assigned - somebody is working on that
- fixed - feature implemented, waiting for release
- closed - feature implemented and in release
- rejected - feature was rejected
- rename group to Version and make it free text field, this anyway in
most cases just informational field
Do you mean in the left panel? I guess this should be renamed Milestone.
- add milestone field, which will record version where
the bug has been
fixed or is scheduled to be fixed
We already see Milestone in the bug tickets.
- are we using priority here for anything else than
indicating fixed
but not yet released issues? If not, it should be dropped.
I agree.
--
Marc Delisle
http://infomarc.info
24 Jan
24 Jan
1:17 p.m.
Hi
Dne Wed, 23 Jan 2013 11:57:48 -0500
Marc Delisle <marc(a)infomarc.info> napsal(a):
Sorry for choosing confusing names, what I would like to track is
version where issue was seen - to be filled in by user and version
where the issue has been fixed, which would be filled in by developer.
--
Michal Čihař | http://cihar.com | http://phpmyadmin.net
- rename group
to Version and make it free text field, this anyway in
most cases just informational field
Do you mean in the left panel? I guess this should be renamed Milestone.
- add milestone field, which will record version
where the bug has been
fixed or is scheduled to be fixed
We already see Milestone in the bug tickets.
25 Jan
25 Jan
7:54 a.m.
Michal Čihař a écrit :
Hi
Dne Wed, 23 Jan 2013 11:57:48 -0500
Marc Delisle <marc(a)infomarc.info> napsal(a):
Sorry for choosing confusing names, what I would like to track is
version where issue was seen - to be filled in by user and version
where the issue has been fixed, which would be filled in by developer.
I see. I also find that Milestone is confusing.
--
Marc Delisle
http://infomarc.info
- rename
group to Version and make it free text field, this anyway in
most cases just informational field
Do you mean in the left panel? I guess this
should be renamed Milestone.
- add milestone field, which will record version
where the bug has been
fixed or is scheduled to be fixed
We already see Milestone in the bug tickets.
23 Jan
23 Jan
10:46 p.m.
On Wed, Jan 23, 2013 at 7:14 PM, Michal Čihař <michal(a)cihar.com> wrote:
Hi all
I've just spent some time to adjust settings of new trackers on sf.net.
I also think we could change more, but that's where I'd like to hear
your opinion.
Changes done:
- reenabled mail notifications to mailing lists
Hi Michal,
Looks like there is a permission issue with the tracker mailing list. I got
a bounce notification when I added a new bug. See the extract.
<extract>
Your mail to 'Phpmyadmin-trk-bugs' with the subject
[phpmyadmin:bugs] #3782 Code-mirrored text areas and scrollbars
Is being held until the list moderator can review it for approval.
The reason it is being held:
Post by non-member to a members-only list
<end-extract>
--
Thanks and Regards,
Madhura Jayaratne
24 Jan
24 Jan
8:15 a.m.
Madhura Jayaratne a écrit :
On Wed, Jan 23, 2013 at 7:14 PM, Michal Čihař
<michal(a)cihar.com> wrote:
Madhura,
can you subscribe madhuracj(a)users.sf.net to the phpmyadmin-trk-bugs list?
--
Marc Delisle
http://infomarc.info
Hi all
I've just spent some time to adjust settings of new trackers on sf.net.
I also think we could change more, but that's where I'd like to hear
your opinion.
Changes done:
- reenabled mail notifications to mailing lists
Hi Michal,
Looks like there is a permission issue with the tracker mailing list. I got
a bounce notification when I added a new bug. See the extract.
<extract>
Your mail to 'Phpmyadmin-trk-bugs' with the subject
[phpmyadmin:bugs] #3782 Code-mirrored text areas and scrollbars
Is being held until the list moderator can review it for approval.
The reason it is being held:
Post by non-member to a members-only list
<end-extract>
8:55 a.m.
On Thu, Jan 24, 2013 at 6:45 PM, Marc Delisle <marc(a)infomarc.info> wrote:
Madhura,
can you subscribe madhuracj(a)users.sf.net to the phpmyadmin-trk-bugs list?
Marc,
Well, I have done that.
However we can not expect everyone who submits a bug report to have
subscribed to the phpmyadmin-trk-bugs list. So they will all receive bounce
notifications.
--
Thanks and Regards,
Madhura Jayaratne
1:08 p.m.
Hi
Dne Thu, 24 Jan 2013 19:25:22 +0530
Madhura Jayaratne <madhura.cj(a)gmail.com> napsal(a):
Well, I have done that.
However we can not expect everyone who submits a bug report to have
subscribed to the phpmyadmin-trk-bugs list. So they will all receive bounce
notifications.
I've adjusted mailing list settings to accept these notifications
without need to subscribe.
--
Michal Čihař | http://cihar.com | http://phpmyadmin.net
4196
days inactive
4203
days old
21 comments
4 participants
participants (4)
-
Dieter Adriaenssens -
Madhura Jayaratne -
Marc Delisle -
Michal Čihař