On Sun, 16 Feb 2014 14:50:41 -0600
William Hubbs willi...@gentoo.org wrote:
On Sun, Feb 16, 2014 at 06:58:47PM +0100, Tom Wijsman wrote:
On Sun, 16 Feb 2014 09:41:03 +0100
Pacho Ramos pa...@gentoo.org wrote:
El dom, 16-02-2014 a las 00:37 +0100, Jeroen Roovers escribió:
[...]
On Mon, 17 Feb 2014 19:46:43 +0100
Tom Wijsman tom...@gentoo.org wrote:
It allows undermanned arch teams to prioritize
Oh, so you're still assuming an understaffed team somehow manages
to do some work in an appropriate time frame. It's getting old.
Apparently understaffed isn't the right word
On Mon, 17 Feb 2014 21:47:42 +0100
Jeroen Roovers j...@gentoo.org wrote:
On Mon, 17 Feb 2014 19:46:43 +0100
Tom Wijsman tom...@gentoo.org wrote:
It allows undermanned arch teams to prioritize
Oh, so you're still assuming an understaffed team somehow manages
to do some work in an
On Sun, 16 Feb 2014 00:37:03 +0100
Jeroen Roovers j...@gentoo.org wrote:
On Sat, 15 Feb 2014 16:53:22 -0600
William Hubbs willi...@gentoo.org wrote:
The problem with this is, what if it is more than one arch team?
Which one do you assign it to?
Oh the fun we had in the past when bugs
On Sat, 15 Feb 2014 19:05:56 -0600
William Hubbs willi...@gentoo.org wrote:
On Sun, Feb 16, 2014 at 12:37:03AM +0100, Jeroen Roovers wrote:
On Sat, 15 Feb 2014 16:53:22 -0600
William Hubbs willi...@gentoo.org wrote:
The problem with this is, what if it is more than one arch team?
El dom, 16-02-2014 a las 00:37 +0100, Jeroen Roovers escribió:
[...]
If we want a separate assignee for old stabilizations, what about a
separate project that handles this, or maybe we could assign the bugs
to m-n or something until the arch teams catch up?
Again, where is the man power
On Sun, 16 Feb 2014 08:23:27 +0100
Tom Wijsman tom...@gentoo.org wrote:
While it was not explained here, the idea can also move the actual
maintenance of the ebuild to the arch team; such that it becomes
the arch team's responsibility to deal with it, or rather don't
deal with it
On Sun, Feb 16, 2014 at 3:41 AM, Pacho Ramos pa...@gentoo.org wrote:
Also, keeping the bugs assigned to package maintainers will still allow
them to try to get that pending bugs fixed (or resolved in some way) as
they will take care more about that specific package status. If we get
that bugs
On Sun, 16 Feb 2014 09:00:16 +0100
Tom Wijsman tom...@gentoo.org wrote:
In this case the maintainer isn't needed on the bug anymore.
You can't simply drop your old toys when you get bored with them.
You're leaving a mess in the tree and blaming others. You have achieved
nothing else.
Or when
El dom, 16-02-2014 a las 09:03 -0500, Rich Freeman escribió:
On Sun, Feb 16, 2014 at 3:41 AM, Pacho Ramos pa...@gentoo.org wrote:
Also, keeping the bugs assigned to package maintainers will still allow
them to try to get that pending bugs fixed (or resolved in some way) as
they will take
On Sun, Feb 16, 2014 at 8:48 AM, Jeroen Roovers j...@gentoo.org wrote:
The (slightly rhetorical) question was how an understaffed team could
be realistically expected to start maintaining ebuilds. Your entire
reply missed that point.
The answer to the question is that you can't. A package
On Sun, 16 Feb 2014 09:03:31 -0500
Rich Freeman ri...@gentoo.org wrote:
Well, that depends on your perspective. If they fix them by deleting
the old version, then whether they've made things better or worse is a
matter of philosophy.
When you've cut the understaffed arch team out of the loop
On Sun, 16 Feb 2014 09:22:49 -0500
Rich Freeman ri...@gentoo.org wrote:
Well, they can assign the burden to an understaffed team if the team
wants them to.
Achieving nothing in the process, even if the understaffed team
actually responds.
Perhaps an intermediate solution is that when a
On Sun, Feb 16, 2014 at 9:31 AM, Jeroen Roovers j...@gentoo.org wrote:
On Sun, 16 Feb 2014 09:22:49 -0500
Rich Freeman ri...@gentoo.org wrote:
Well, they can assign the burden to an understaffed team if the team
wants them to.
Achieving nothing in the process, even if the understaffed team
On Sun, 16 Feb 2014 15:18:42 +0100
Pacho Ramos pa...@gentoo.org wrote:
I think that, if they delete del old version without breaking the tree
(and, then, moving the package to testing for that arch), the
situation is improved. But, if the bug is assigned to the same team
that cannot handle
El dom, 16-02-2014 a las 15:46 +0100, Jeroen Roovers escribió:
On Sun, 16 Feb 2014 15:18:42 +0100
Pacho Ramos pa...@gentoo.org wrote:
I think that, if they delete del old version without breaking the tree
(and, then, moving the package to testing for that arch), the
situation is
On Sun, 16 Feb 2014 09:38:20 -0500
Rich Freeman ri...@gentoo.org wrote:
Basically that one version of the package is now maintained by the
arch team. Yes, I know they won't maintain it. The only people that
impacts are those who use the arch, who are free to join the arch
team and help out.
On Sun, 16 Feb 2014 15:53:57 +0100
Pacho Ramos pa...@gentoo.org wrote:
In this case:
- Versions that are not stabilized because arch team doesn't have
the man power to do that.
As above, package.mask would be a good intermediate solution,
communicating the problem to the arch users
On Sun, 16 Feb 2014 14:48:57 +0100
Jeroen Roovers j...@gentoo.org wrote:
On Sun, 16 Feb 2014 08:23:27 +0100
Tom Wijsman tom...@gentoo.org wrote:
While it was not explained here, the idea can also move the
actual maintenance of the ebuild to the arch team; such that it
becomes the
On Sun, Feb 16, 2014 at 09:38:20AM -0500, Rich Freeman wrote:
Well, if they make no choice then the maintainer deletes the package.
That's what you want, right? The package would only stay around if
the minor arch asked them to. If they don't do that, then nobody can
complain.
However, I
On Sun, 16 Feb 2014 15:04:30 +0100
Jeroen Roovers j...@gentoo.org wrote:
On Sun, 16 Feb 2014 09:00:16 +0100
Tom Wijsman tom...@gentoo.org wrote:
In this case the maintainer isn't needed on the bug anymore.
You can't simply drop your old toys when you get bored with them.
You're leaving
On Sun, 16 Feb 2014 09:41:03 +0100
Pacho Ramos pa...@gentoo.org wrote:
El dom, 16-02-2014 a las 00:37 +0100, Jeroen Roovers escribió:
[...]
If we want a separate assignee for old stabilizations, what about
a separate project that handles this, or maybe we could assign
the bugs to m-n
On Sun, 16 Feb 2014 15:46:23 +0100
Jeroen Roovers j...@gentoo.org wrote:
But, I guess there are two major cases:
- Versions that cannot be stabilized due they not working on that
arch any longer
It's probably a good idea to package.mask the affected versions on the
arch profile(s) (with
On Sun, Feb 16, 2014 at 06:58:47PM +0100, Tom Wijsman wrote:
On Sun, 16 Feb 2014 09:41:03 +0100
Pacho Ramos pa...@gentoo.org wrote:
El dom, 16-02-2014 a las 00:37 +0100, Jeroen Roovers escribió:
[...]
If we want a separate assignee for old stabilizations, what about
a separate
On Sun, 2014-02-16 at 09:03 -0500, Rich Freeman wrote:
On Sun, Feb 16, 2014 at 3:41 AM, Pacho Ramos pa...@gentoo.org wrote:
Also, keeping the bugs assigned to package maintainers will still allow
them to try to get that pending bugs fixed (or resolved in some way) as
they will take care
On Sat, 15 Feb 2014 01:28:55 +0100
Jeroen Roovers j...@gentoo.org wrote:
On Fri, 14 Feb 2014 19:59:58 +0100
Tom Wijsman tom...@gentoo.org wrote:
And that can work without a problem if we have a mechanism
in place to relieve maintainers of those bugs.
Such mechanism could be to
On Sat, 15 Feb 2014 11:41:57 +0100
Tom Wijsman tom...@gentoo.org wrote:
Assigning bugs so arch teams is cosmetic at best.
s|so|to|
While it was not explained here, the idea can also move the actual
maintenance of the ebuild to the arch team; such that it becomes the
arch team's
El sáb, 15-02-2014 a las 14:30 +0100, Jeroen Roovers escribió:
[...]
The only reasonable course of action is to start dropping stable
keywords for $ARCH, after a reasonable timeout. It gets tricky if this
involves removing many keywords on dependencies, but if that's what you
have to do to
On Sat, Feb 15, 2014 at 8:30 AM, Jeroen Roovers j...@gentoo.org wrote:
On Sat, 15 Feb 2014 11:41:57 +0100
Tom Wijsman tom...@gentoo.org wrote:
While it was not explained here, the idea can also move the actual
maintenance of the ebuild to the arch team; such that it becomes the
arch team's
On Sat, Feb 15, 2014 at 11:41:57AM +0100, Tom Wijsman wrote:
On Sat, 15 Feb 2014 01:28:55 +0100
Jeroen Roovers j...@gentoo.org wrote:
On Fri, 14 Feb 2014 19:59:58 +0100
Tom Wijsman tom...@gentoo.org wrote:
And that can work without a problem if we have a mechanism
in place to
On Sat, Feb 15, 2014 at 02:30:21PM +0100, Jeroen Roovers wrote:
On Sat, 15 Feb 2014 11:41:57 +0100
Tom Wijsman tom...@gentoo.org wrote:
Assigning bugs so arch teams is cosmetic at best.
s|so|to|
While it was not explained here, the idea can also move the actual
maintenance of the
On Sat, 15 Feb 2014 16:53:22 -0600
William Hubbs willi...@gentoo.org wrote:
The problem with this is, what if it is more than one arch team? Which
one do you assign it to?
Oh the fun we had in the past when bugs got assigned to one arch team
with a few others CC'd and no maintainer in sight
On Sun, Feb 16, 2014 at 12:37:03AM +0100, Jeroen Roovers wrote:
On Sat, 15 Feb 2014 16:53:22 -0600
William Hubbs willi...@gentoo.org wrote:
The problem with this is, what if it is more than one arch team? Which
one do you assign it to?
Oh the fun we had in the past when bugs got
On Sat, 15 Feb 2014 14:30:21 +0100
Jeroen Roovers j...@gentoo.org wrote:
On Sat, 15 Feb 2014 11:41:57 +0100
Tom Wijsman tom...@gentoo.org wrote:
Assigning bugs so arch teams is cosmetic at best.
s|so|to|
While it was not explained here, the idea can also move the actual
On Sat, 15 Feb 2014 10:18:32 -0500
Rich Freeman ri...@gentoo.org wrote:
Many objected to removal since old with minor issues is better than
new that doesn't work at all on some archs, or so the argument goes.
TL;DR: The opposite exists, I think we should draw a bar in the middle.
So goes the
On Sat, 15 Feb 2014 16:53:22 -0600
William Hubbs willi...@gentoo.org wrote:
The problem with this is, what if it is more than one arch team? Which
one do you assign it to?
The fastest gun in the west.
If we want a separate assignee for old stabilizations, what about a
separate project that
36 matches
Mail list logo
