Michael Banck wrote:
On Sun, Dec 09, 2007 at 11:31:27PM +0100, Luk Claes wrote:
Please don't answer when you don't have read the whole thread... It was
already very clearly mentioned that the team decided to file with
severity important instead...
Please don't CC me on replies, I am
On Sat, Dec 08, 2007 at 06:39:15PM +0100, Raphael Hertzog wrote:
I don't agree with this. In a team, it's difficult to notice that one
member disappeared. And lack of involvement in one package doesn't mean
being completely MIA. As co-maintainer I wouldn't want to remove someone
if I'm not
Michael Banck wrote:
On Sat, Dec 08, 2007 at 06:39:15PM +0100, Raphael Hertzog wrote:
I don't agree with this. In a team, it's difficult to notice that one
member disappeared. And lack of involvement in one package doesn't mean
being completely MIA. As co-maintainer I wouldn't want to remove
On Sun, Dec 09, 2007 at 11:31:27PM +0100, Luk Claes wrote:
Please don't answer when you don't have read the whole thread... It was
already very clearly mentioned that the team decided to file with
severity important instead...
Please don't CC me on replies, I am subscribed.
cheers,
Michael
Hi Mario,
* Mario Iseli [EMAIL PROTECTED] [2007-12-06 21:33]:
[...]
Team maintenance
If one package of the person is maintained in a team, at the step where we
send
the prod-mail we file a Bug of severity serious against the package,
requesting that the person is being
Nico Golde wrote:
Hi Mario,
* Mario Iseli [EMAIL PROTECTED] [2007-12-06 21:33]:
[...]
Team maintenance
If one package of the person is maintained in a team, at the step where we
send
the prod-mail we file a Bug of severity serious against the package,
requesting that
Hi Luk,
* Luk Claes [EMAIL PROTECTED] [2007-12-08 18:21]:
Nico Golde wrote:
Hi Mario,
* Mario Iseli [EMAIL PROTECTED] [2007-12-06 21:33]:
[...]
What is the purpose of this? If the package is well
maintained I think it's really
questionable that an inactive co-maintainer justifies a
On Sat, 08 Dec 2007, Nico Golde wrote:
To make sure packages don't end up with only inactive (co-)maintainers.
That could be avoided if you check that every maintainer of
the package is MIA.
A MIA-check is not something instantaneous. It takes several months. So
it's not really possible...
Nico Golde wrote:
Hi Luk,
* Luk Claes [EMAIL PROTECTED] [2007-12-08 18:21]:
Nico Golde wrote:
Hi Mario,
* Mario Iseli [EMAIL PROTECTED] [2007-12-06 21:33]:
[...]
What is the purpose of this? If the package is well
maintained I think it's really
questionable that an inactive
Hi Raphael,
* Raphael Hertzog [EMAIL PROTECTED] [2007-12-08 18:42]:
On Sat, 08 Dec 2007, Nico Golde wrote:
To make sure packages don't end up with only inactive (co-)maintainers.
That could be avoided if you check that every maintainer of
the package is MIA.
A MIA-check is not
On Saturday 8 December 2007 18:20, Luk Claes wrote:
Nico Golde wrote:
Hi Mario,
* Mario Iseli [EMAIL PROTECTED] [2007-12-06 21:33]:
[...]
Team maintenance
If one package of the person is maintained in a team, at the step where
we send the prod-mail we file a Bug
On Sat, 8 Dec 2007 06:39:15 pm Raphael Hertzog wrote:
On Sat, 08 Dec 2007, Nico Golde wrote:
To make sure packages don't end up with only inactive (co-)maintainers.
That could be avoided if you check that every maintainer of
the package is MIA.
A MIA-check is not something
On Sat, 8 Dec 2007 06:39:15 pm Raphael Hertzog wrote:
On Sat, 08 Dec 2007, Nico Golde wrote:
To make sure packages don't end up with only inactive (co-)maintainers.
That could be avoided if you check that every maintainer of
the package is MIA.
A MIA-check is not something
Steffen Joeris wrote:
On Sat, 8 Dec 2007 06:39:15 pm Raphael Hertzog wrote:
On Sat, 08 Dec 2007, Nico Golde wrote:
To make sure packages don't end up with only inactive (co-)maintainers.
That could be avoided if you check that every maintainer of
the package is MIA.
A MIA-check is not
At least use important. I actually don't care, if there is a bug or not for
the issue. But I do care about the testing migration. We do have DDs, who are
doing work only during the weekend (which is perfectly acceptable). So if you
write an RC bug on monday, this might hold up the testing
15 matches
Mail list logo
