On Mon, 17 Feb 2014 21:47:42 +0100
Jeroen Roovers wrote:
> On Mon, 17 Feb 2014 19:46:43 +0100
> Tom Wijsman 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 get
On Mon, 17 Feb 2014 19:46:43 +0100
Tom Wijsman 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 since it keeps
On Sun, 16 Feb 2014 14:50:41 -0600
William Hubbs 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 wrote:
> >
> > > El dom, 16-02-2014 a las 00:37 +0100, Jeroen Roovers escribió:
> > > [...]
> > > > > If we want a separa
On Sun, 2014-02-16 at 09:03 -0500, Rich Freeman wrote:
> On Sun, Feb 16, 2014 at 3:41 AM, Pacho Ramos 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 th
On Sun, Feb 16, 2014 at 06:58:47PM +0100, Tom Wijsman wrote:
> On Sun, 16 Feb 2014 09:41:03 +0100
> Pacho Ramos 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 projec
On Sun, 16 Feb 2014 15:46:23 +0100
Jeroen Roovers 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 refere
On Sun, 16 Feb 2014 09:41:03 +0100
Pacho Ramos 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 or some
On Sun, 16 Feb 2014 15:04:30 +0100
Jeroen Roovers wrote:
> On Sun, 16 Feb 2014 09:00:16 +0100
> Tom Wijsman 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 bl
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.
>
> Howeve
On Sun, 16 Feb 2014 14:48:57 +0100
Jeroen Roovers wrote:
> On Sun, 16 Feb 2014 08:23:27 +0100
> Tom Wijsman 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 respon
On Sun, 16 Feb 2014 15:53:57 +0100
Pacho Ramos 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 for,
On Sun, 16 Feb 2014 09:38:20 -0500
Rich Freeman 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. My sense is
El dom, 16-02-2014 a las 15:46 +0100, Jeroen Roovers escribió:
> On Sun, 16 Feb 2014 15:18:42 +0100
> Pacho Ramos 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, i
On Sun, 16 Feb 2014 15:18:42 +0100
Pacho Ramos 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 its stabilizati
On Sun, Feb 16, 2014 at 9:31 AM, Jeroen Roovers wrote:
> On Sun, 16 Feb 2014 09:22:49 -0500
> Rich Freeman 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.
I
On Sun, 16 Feb 2014 09:22:49 -0500
Rich Freeman 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 STABLEREQ gets stal
On Sun, 16 Feb 2014 09:03:31 -0500
Rich Freeman 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 and removed
t
On Sun, Feb 16, 2014 at 8:48 AM, Jeroen Roovers 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 maintainer
> c
El dom, 16-02-2014 a las 09:03 -0500, Rich Freeman escribió:
> On Sun, Feb 16, 2014 at 3:41 AM, Pacho Ramos 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 ab
On Sun, 16 Feb 2014 09:00:16 +0100
Tom Wijsman 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 another arch a
On Sun, Feb 16, 2014 at 3:41 AM, Pacho Ramos 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 assigned to a
On Sun, 16 Feb 2014 08:23:27 +0100
Tom Wijsman 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
> >
> > H
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
On Sat, 15 Feb 2014 19:05:56 -0600
William Hubbs 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 wrote:
> >
> > > The problem with this is, what if it is more than one arch team?
> > > Which one do you assign it t
On Sun, 16 Feb 2014 00:37:03 +0100
Jeroen Roovers wrote:
> On Sat, 15 Feb 2014 16:53:22 -0600
> William Hubbs 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 te
On Sat, 15 Feb 2014 16:53:22 -0600
William Hubbs 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 handles this, or
On Sat, 15 Feb 2014 10:18:32 -0500
Rich Freeman 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 counter-argumen
On Sat, 15 Feb 2014 14:30:21 +0100
Jeroen Roovers wrote:
> On Sat, 15 Feb 2014 11:41:57 +0100
> Tom Wijsman 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 t
On Sun, Feb 16, 2014 at 12:37:03AM +0100, Jeroen Roovers wrote:
> On Sat, 15 Feb 2014 16:53:22 -0600
> William Hubbs 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 ar
On Sat, 15 Feb 2014 16:53:22 -0600
William Hubbs 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 (because maybe the
m
On Sat, Feb 15, 2014 at 02:30:21PM +0100, Jeroen Roovers wrote:
> On Sat, 15 Feb 2014 11:41:57 +0100
> Tom Wijsman 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
On Sat, Feb 15, 2014 at 11:41:57AM +0100, Tom Wijsman wrote:
> On Sat, 15 Feb 2014 01:28:55 +0100
> Jeroen Roovers wrote:
>
> > On Fri, 14 Feb 2014 19:59:58 +0100
> > Tom Wijsman wrote:
> >
> > > > And that can work without a problem if we have a mechanism
> > > > in place to relieve maintainer
On Sat, Feb 15, 2014 at 8:30 AM, Jeroen Roovers wrote:
> On Sat, 15 Feb 2014 11:41:57 +0100
> Tom Wijsman 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 wi
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, 15 Feb 2014 11:41:57 +0100
Tom Wijsman 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 responsibility to deal w
On Sat, 15 Feb 2014 01:28:55 +0100
Jeroen Roovers wrote:
> On Fri, 14 Feb 2014 19:59:58 +0100
> Tom Wijsman 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 assign those bug to the
On Fri, 14 Feb 2014 19:59:58 +0100
Tom Wijsman 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 assign those bug to the arch team, this
> idea came up at FOSDEM; it won't solve the lack of manp
28.01.2014 20:33, "Paweł Hajdan, Jr." пишет:
> Here's a proposal that may address concerns from the long "rfc:
> revisiting our stabilization policy" thread.
>
> It seems at least one of the problems is that with old ebuilds being
> stable on slow arches but not the more recent ebuilds, it is a
>
On Tue, Jan 28, 2014 at 12:23 PM, Jeroen Roovers wrote:
> On Tue, 28 Jan 2014 08:33:05 -0800
> ""Paweł Hajdan, Jr."" wrote:
>
>> Why not allow maintainers to drop redundant stable and even ~arch
>> keywords from their packages?
>
> This is standard practice already.
If there is still pain then m
On Tue, 28 Jan 2014 08:33:05 -0800
""Paweł Hajdan, Jr."" wrote:
> Why not allow maintainers to drop redundant stable and even ~arch
> keywords from their packages?
This is standard practice already.
jer
On Tue, 28 Jan 2014 08:33:05 -0800
""Paweł Hajdan, Jr."" wrote:
> Why not allow maintainers to drop redundant stable and even ~arch
> keywords from their packages?
We already do that to a great extent; only removing the last keyword
present is a bad idea, because in that case the package would n
On 28/01/14 11:33 AM, "Paweł Hajdan, Jr." wrote:
> Here's a proposal that may address concerns from the long "rfc:
> revisiting our stabilization policy" thread.
>
> It seems at least one of the problems is that with old ebuilds being
> stable on slow arches but not the more recent ebuilds, it is
Here's a proposal that may address concerns from the long "rfc:
revisiting our stabilization policy" thread.
It seems at least one of the problems is that with old ebuilds being
stable on slow arches but not the more recent ebuilds, it is a
maintenance burden to keep supporting the old ebuilds eve
43 matches
Mail list logo
