72 hours are not enough for maintainers?
Hi, MacPorts Guide says "The maintainer should apply the patches and close the ticket within 72 hours." "If the maintainer does not respond within 72 hours, you or another committer may review the patches and update the port." But actually this is not always the case. So I started to consider 72 hours restriction is not realistic so this part of guideline should be modified to be more practical. Any comments?
js wrote:
Hi,
MacPorts Guide says
"The maintainer should apply the patches and close the ticket within 72 hours." "If the maintainer does not respond within 72 hours, you or another committer may review the patches and update the port."
But actually this is not always the case. So I started to consider 72 hours restriction is not realistic so this part of guideline should be modified to be more practical.
Any comments?
Depends upon what side of the coin you are on. Sometimes I want to get a fix in for another port and waiting 3 days seems like forever. Other times I miss an email for an update on my port, but I don't typically mind somebody else fixing it. I can always change the fix after it goes in and increment the revision. So three days seems like a reasonable middle-ground. Blair -- Blair Zajac, Ph.D. http://www.orcaware.com/svn/
Hi Blair, If Maintainers think so, that's fine with me. I just guessed 72 hours are not practical to accept for maintainers. On 2/16/08, Blair Zajac <blair@orcaware.com> wrote:
js wrote:
Hi,
MacPorts Guide says
"The maintainer should apply the patches and close the ticket within 72 hours." "If the maintainer does not respond within 72 hours, you or another committer may review the patches and update the port."
But actually this is not always the case. So I started to consider 72 hours restriction is not realistic so this part of guideline should be modified to be more practical.
Any comments?
Depends upon what side of the coin you are on. Sometimes I want to get a fix in for another port and waiting 3 days seems like forever. Other times I miss an email for an update on my port, but I don't typically mind somebody else fixing it. I can always change the fix after it goes in and increment the revision.
So three days seems like a reasonable middle-ground.
Blair
-- Blair Zajac, Ph.D. http://www.orcaware.com/svn/
I would prefer a week, as I often may not get a chance to look at anything in MacPorts except on weekends.
Me too. Sometimes I try to have some time with my family on weekends, so maybe two weeks will be better. If "js" starts using a realname when writing emails, I'd probably offer him maintainer rights, so he can help us fixing tickets. Kind regards Thomas Randall Wood wrote:
I would prefer a week, as I often may not get a chance to look at anything in MacPorts except on weekends.
I think this really begins to stretch the notion of "maintainer". He wants a week, you want two weeks, some other maintainers will probably say they want a month, before long you have a lot of ports being held hostage behind long-lived locks for no reason other than the fact that people want the ability to claim sole maintainership of ports AND take long vacations. I'm not saying that volunteers should not be allowed to take a few weeks off when they want to - they're volunteers and should be able to take any amount of time off - I'm saying that taking time off and having hard locks in the ports collection are not concepts that work well in combination. Any successful project either has a dedicated team of volunteers checking their queues at least 2 or 3 times a week with hard locks, or it has more relaxed volunteers and soft locks that time out relatively quickly. We have subversion, changes can always be reviewed and backed out if necessary, and it's far better to err on the side of not frustrating people who want to contribute. This lesson has been learned repeatedly in other open source projects. I think 72 hours is a very reasonable time out period. If you're that attached to your ports, chances are very good that you'll be checking your trac queue more often than this anyway, and if you're not that attached to them, then why be concerned if someone else makes changes? - Jordan On Feb 21, 2008, at 2:57 AM, Thomas Reifferscheid wrote:
Me too. Sometimes I try to have some time with my family on weekends, so maybe two weeks will be better.
If "js" starts using a realname when writing emails, I'd probably offer him maintainer rights, so he can help us fixing tickets.
Kind regards Thomas
Randall Wood wrote:
I would prefer a week, as I often may not get a chance to look at anything in MacPorts except on weekends.
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
On Thu, Feb 21, 2008 at 08:52:34AM -0800, Jordan K. Hubbard wrote:
I think this really begins to stretch the notion of "maintainer". He wants a week, you want two weeks, some other maintainers will probably say they want a month, before long you have a lot of ports being held hostage behind long-lived locks for no reason other than the fact that people want the ability to claim sole maintainership of ports AND take long vacations.
I'm not saying that volunteers should not be allowed to take a few weeks off when they want to - they're volunteers and should be able to take any amount of time off - I'm saying that taking time off and having hard locks in the ports collection are not concepts that work well in combination. Any successful project either has a dedicated team of volunteers checking their queues at least 2 or 3 times a week with hard locks, or it has more relaxed volunteers and soft locks that time out relatively quickly. We have subversion, changes can always be reviewed and backed out if necessary, and it's far better to err on the side of not frustrating people who want to contribute. This lesson has been learned repeatedly in other open source projects.
I think 72 hours is a very reasonable time out period. If you're that attached to your ports, chances are very good that you'll be checking your trac queue more often than this anyway, and if you're not that attached to them, then why be concerned if someone else makes changes?
I agree - 72 hours is a decent window of time. I just used this for a few updates I wanted in, and for one of the changes I was able to converse with the maintainer and got a "go ahead, I'm way too busy right now" as well. I'd like to see an improvement in maintainer notification, some way for trac to grok the maintainers of a port a ticket is filed against and send them an email without having a human properly assign the ticket or fill in the CC: field. I have no idea if there are even hooks in trac to make that possible.... -eric
Jordan K. Hubbard wrote:
I think 72 hours is a very reasonable time out period. If you're that attached to your ports, chances are very good that you'll be checking your trac queue more often than this anyway, and if you're not that attached to them, then why be concerned if someone else makes changes?
I think 72 hours is good. And if you go on vacation and can't maintain your ports for some time, there is always the possibility to announce that on macports-dev@. So either someone else can take care of the regarding tickets/ports or to get some extra time on tickets in order to fix them when he/she gets back. Rainer
On Feb 21, 2008, at 11:31, Eric Hall wrote:
I'd like to see an improvement in maintainer notification, some way for trac to grok the maintainers of a port a ticket is filed against and send them an email without having a human properly assign the ticket or fill in the CC: field. I have no idea if there are even hooks in trac to make that possible....
I suggested that before too, but then jmpp pointed out that we don't capture the information "what port is this ticket for?" anywhere in the ticket. We don't have a field for that. Many people put the affected port name somewhere in the ticket title, but many don't, and those that do don't always put it in a consistent place. I don't know if we can reliably just try to find any portname in the ticket title. Also, many reporters report problems against the port they're trying to install, rather than against the dependency which actually failed.
I suggest giving non-maintainers the permission to change "Assigned to" field. Once tickets are properly assigned, all you have to do is to look at "My tickets". In addition to that, How abount sending reminder to macports-dev when there're tickets unchanged more than a few weeks? Trac's backend is RDBMS so checking ticket state should be easy. On 2/22/08, Ryan Schmidt <ryandesign@macports.org> wrote:
On Feb 21, 2008, at 11:31, Eric Hall wrote:
I'd like to see an improvement in maintainer notification, some way for trac to grok the maintainers of a port a ticket is filed against and send them an email without having a human properly assign the ticket or fill in the CC: field. I have no idea if there are even hooks in trac to make that possible....
I suggested that before too, but then jmpp pointed out that we don't capture the information "what port is this ticket for?" anywhere in the ticket. We don't have a field for that. Many people put the affected port name somewhere in the ticket title, but many don't, and those that do don't always put it in a consistent place. I don't know if we can reliably just try to find any portname in the ticket title. Also, many reporters report problems against the port they're trying to install, rather than against the dependency which actually failed.
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
On Feb 22, 2008, at 07:18, js wrote:
On 2/22/08, Ryan Schmidt wrote:
On Feb 21, 2008, at 11:31, Eric Hall wrote:
I'd like to see an improvement in maintainer notification, some way for trac to grok the maintainers of a port a ticket is filed against and send them an email without having a human properly assign the ticket or fill in the CC: field. I have no idea if there are even hooks in trac to make that possible....
I suggested that before too, but then jmpp pointed out that we don't capture the information "what port is this ticket for?" anywhere in the ticket. We don't have a field for that. Many people put the affected port name somewhere in the ticket title, but many don't, and those that do don't always put it in a consistent place. I don't know if we can reliably just try to find any portname in the ticket title. Also, many reporters report problems against the port they're trying to install, rather than against the dependency which actually failed.
I suggest giving non-maintainers the permission to change "Assigned to" field.
It seems to me like that would be a good idea too. But I'm not sure what all the implications of that would be.
Once tickets are properly assigned, all you have to do is to look at "My tickets".
Assuming reporters assign tickets correctly, sure.
In addition to that, How abount sending reminder to macports-dev when there're tickets unchanged more than a few weeks? Trac's backend is RDBMS so checking ticket state should be easy.
I know I have old tickets. Some need planning, some are waiting for upstream fixes, some are not very important but are still open because they're still unresolved. I don't need lots of emails nagging me about these. I have enough of an email problem as it is. Also, macports-dev is not a place to send automated emails; it's a place for discussing the development of MacPorts. For automated mails we have other lists, like macports-changes and macports-tickets.
I suggest giving non-maintainers the permission to change "Assigned to" field.
It seems to me like that would be a good idea too. But I'm not sure what all the implications of that would be.
According to Trac doc[1], if I had TICKET_CHGPROP, I could modify ticket properties except description field, cc field add/remove. Who cares if I wrongly change priority, components or version etc. [1]http://trac.edgewall.org/wiki/TracPermissions
Once tickets are properly assigned, all you have to do is to look at "My tickets".
Assuming reporters assign tickets correctly, sure.
That might encourage reporters to open ticket carefully, I hope.
In addition to that, How abount sending reminder to macports-dev when there're tickets unchanged more than a few weeks? Trac's backend is RDBMS so checking ticket state should be easy.
I know I have old tickets. Some need planning, some are waiting for upstream fixes, some are not very important but are still open because they're still unresolved. I don't need lots of emails nagging me about these. I have enough of an email problem as it is. Also, macports-dev is not a place to send automated emails; it's a place for discussing the development of MacPorts. For automated mails we have other lists, like macports-changes and macports-tickets.
Just add a update on those tickets. Reporters would be happy to see their ticket updated. And you are right. macports-tickets would be better.
participants (8)
-
Blair Zajac
-
Eric Hall
-
Jordan K. Hubbard
-
js
-
Rainer Müller
-
Randall Wood
-
Ryan Schmidt
-
Thomas Reifferscheid