Re: Maintainer away tracking
o > o > If there was some way to indicate that something o > o > required action by me, o > o o like say, a ticket assigned or CC'd to you? ;-) o > o > Is that true? If I, at a minimum, look at all e-mails cc'd to me, will that o > be sufficent to make sure I'm not holding anyone up? If not, maybe that o > would be a good policy. I'm pretty sure there are tasks that don't require o > tickets, so, I don't think that's enough, but maybe that would work... o o You can also query the Trac database to find cc'ed tickets: o http://trac.macosforge.org/projects/macports/query?cc=$EMAIL o o If you are set on CC for a ticket, Trac also sends the mail with your email o address in the CC header. If you are the reporter or assignee, your email o address is in the To header. This requires polling. Is there a "push" way to ensure that you know about any tickets for your ports? Can we guarantee that the maintainer(s) are listed as CC's (I can't think of a situation where they shouldn't be). -- Sal smile. -- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Maintainer away tracking
Salvatore Domenick Desiano wrote: o > If there was some way to indicate that something o > required action by me, o o like say, a ticket assigned or CC'd to you? ;-) Is that true? If I, at a minimum, look at all e-mails cc'd to me, will that be sufficent to make sure I'm not holding anyone up? If not, maybe that would be a good policy. I'm pretty sure there are tasks that don't require tickets, so, I don't think that's enough, but maybe that would work... You can also query the Trac database to find cc'ed tickets: http://trac.macosforge.org/projects/macports/query?cc=$EMAIL If you are set on CC for a ticket, Trac also sends the mail with your email address in the CC header. If you are the reporter or assignee, your email address is in the To header. Maybe, if someone is about to clarify the 72 hour rule, they could add "the 72 hours begins when the maintainer has been directly e-mailed regarding the change". Right, this should be added. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Maintainer away tracking
o > If there was some way to indicate that something o > required action by me, o o like say, a ticket assigned or CC'd to you? ;-) Is that true? If I, at a minimum, look at all e-mails cc'd to me, will that be sufficent to make sure I'm not holding anyone up? If not, maybe that would be a good policy. I'm pretty sure there are tasks that don't require tickets, so, I don't think that's enough, but maybe that would work... Maybe, if someone is about to clarify the 72 hour rule, they could add "the 72 hours begins when the maintainer has been directly e-mailed regarding the change". Then I'll update my filters. As for the vacation page, I also would not advertise being on "vacation", but I don't mind if anyone else does. -- Sal smile. -- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Maintainer away tracking
On Mar 17, 2008, at 10:26 AM, Rainer Müller wrote: In addition, ports that are seriously broken (ie, don't build, security vulnerability, distfile no longer available) can be fixed to work (without major changes) without waiting for the timeout already. These points are not exactly clarified in the guide. # A critical port is broken that affects many users. Doesn't sound like 'missing distfile' or 'doesn't build' to me. I can't find another section regarding committing without maintainers' acknowledgment. I don't recall where it was documented, but it had been discussed on the mailing lists (perhaps quite a while ago). It may have even been in the old darwinports committer information. A committer may make a minimal change to a port that is broken in order to fix it without waiting for the 72hr timeout (it's good to still ping the maintainer, though). If it's not documented anywhere anymore, we should probably get the documentation updated. I don't see the additional speed benefit as worth the extra book keeping. The extra book keeping is done my each individual maintainer. So not much work for a maintainers themself. it's still extra work ;-) That said, I'm not going to object if others want to use it (I do know that I don't really plan on advertising to the world any time I may be going away on vacation). Hm, why not? You are not going to be around for any work on MacPorts, so tell the project about it. If we know you are just away for a few days, someone could also hold on committing not-so- important tickets until the known date at which you are back. ... because I feel that the 72 hour timeout is sufficient, and I don't like the idea of a public place where people could get a good indication that my house is probably empty. -- Daniel J. Luke ++ | * [EMAIL PROTECTED] * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ PGP.sig Description: This is a digitally signed message part ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Maintainer away tracking
Daniel J. Luke wrote: On Mar 17, 2008, at 9:37 AM, Rainer Müller wrote: So, this proposal was out now for about a week and nobody replied. If you don't like it, please tell me at least why you think it is not a good idea. We already have the 72 hour timeout, the option of putting 'openmaintainer' on our ports or having co-maintainers who can also commit. Exactly, we have to wait 72h even if the person in question will not respond anyway. In addition, ports that are seriously broken (ie, don't build, security vulnerability, distfile no longer available) can be fixed to work (without major changes) without waiting for the timeout already. These points are not exactly clarified in the guide. # A critical port is broken that affects many users. Doesn't sound like 'missing distfile' or 'doesn't build' to me. I can't find another section regarding committing without maintainers' acknowledgment. I don't see the additional speed benefit as worth the extra book keeping. The extra book keeping is done my each individual maintainer. So not much work for a maintainers themself. That said, I'm not going to object if others want to use it (I do know that I don't really plan on advertising to the world any time I may be going away on vacation). Hm, why not? You are not going to be around for any work on MacPorts, so tell the project about it. If we know you are just away for a few days, someone could also hold on committing not-so-important tickets until the known date at which you are back. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Maintainer away tracking
On Mar 17, 2008, at 9:37 AM, Rainer Müller wrote: So, this proposal was out now for about a week and nobody replied. If you don't like it, please tell me at least why you think it is not a good idea. We already have the 72 hour timeout, the option of putting 'openmaintainer' on our ports or having co-maintainers who can also commit. In addition, ports that are seriously broken (ie, don't build, security vulnerability, distfile no longer available) can be fixed to work (without major changes) without waiting for the timeout already. I don't see the additional speed benefit as worth the extra book keeping. That said, I'm not going to object if others want to use it (I do know that I don't really plan on advertising to the world any time I may be going away on vacation). -- Daniel J. Luke ++ | * [EMAIL PROTECTED] * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ PGP.sig Description: This is a digitally signed message part ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Maintainer away tracking
On Mar 17, 2008, at 9:52 AM, Salvatore Domenick Desiano wrote: If there was some way to indicate that something required action by me, like say, a ticket assigned or CC'd to you? ;-) -- Daniel J. Luke ++ | * [EMAIL PROTECTED] * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ PGP.sig Description: This is a digitally signed message part ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Maintainer away tracking
As a maintainer who is sometimes "away", I like the idea in principle, but I think there may be a simpler problem that will affect whether this is necesary. The volume on the MP lists has gone up astronomically of late, meaning that I have to shunt my MP email into a folder and read it itermittently. If there was some way to indicate that something required action by me, I would be much more responsive. I can't think of anything particularly good, but perhaps a standard prefix of "action: username" that I can filter for... As for the proposal, it seems fine, since people can easily opt out. I tend to think that people won't use it, but I see no harm in it. I would, however, like to be a more responsive maintainer, so it would be nice if there were some standard way to see which of the MP e-mails I really need to read, and which can wait for a week or so. -- Sal smile. On Mon, 17 Mar 2008, Rainer Müller wrote: o Rainer Müller wrote: o > It happens from time to time that some maintainer is busy with work or o > school, has to move, is on vacation or attends some other event which o > prevents him from taking action on new tickets. o > o > So I want to setup a new wiki page (like MaintainerAway) where anybody can o > add himself with a small explanation how long he is going to be away and o > maybe also why. o > o > If someone adds himself onto this wiki page all of his/her ports will be o > treated like if they have openmaintainer on them, so anybody can commit o > updates without explicit permission. This should be taken like a temporarily o > openmaintainer status. Or the maintainer could also add someone else who o > should take care of his/her ports for this time. o > o > The main advantage would be that the 72h delay does not have to pass as the o > maintainer will not answer anyway. o o So, this proposal was out now for about a week and nobody replied. If you o don't like it, please tell me at least why you think it is not a good idea. o o Normally if I get no reply on a proposal, I would just take this as "no o objections". But this time it is important that you as developers and o maintainers are going to accept and use it. Therefore it would have been nice o to get some replies what you think about this topic. o o Now it seems like nobody cares about it. Do you think we don't need this at o all? Do you think nobody would use it? Or do you have another better solution? o o Rainer o ___ o macports-users mailing list o [EMAIL PROTECTED] o http://lists.macosforge.org/mailman/listinfo/macports-users o o -- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Maintainer away tracking
Rainer Müller wrote: It happens from time to time that some maintainer is busy with work or school, has to move, is on vacation or attends some other event which prevents him from taking action on new tickets. So I want to setup a new wiki page (like MaintainerAway) where anybody can add himself with a small explanation how long he is going to be away and maybe also why. If someone adds himself onto this wiki page all of his/her ports will be treated like if they have openmaintainer on them, so anybody can commit updates without explicit permission. This should be taken like a temporarily openmaintainer status. Or the maintainer could also add someone else who should take care of his/her ports for this time. The main advantage would be that the 72h delay does not have to pass as the maintainer will not answer anyway. So, this proposal was out now for about a week and nobody replied. If you don't like it, please tell me at least why you think it is not a good idea. Normally if I get no reply on a proposal, I would just take this as "no objections". But this time it is important that you as developers and maintainers are going to accept and use it. Therefore it would have been nice to get some replies what you think about this topic. Now it seems like nobody cares about it. Do you think we don't need this at all? Do you think nobody would use it? Or do you have another better solution? Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
