On Sun, 19 Jan 2014 14:31:57 -0800
Christopher Head wrote:
> Right, of course things can become incompatible—but the distro handles
> that by either leaving old enough version of e.g. libraries around
> that the latest stable versions of their reverse dependencies don’t
> break, or, in exceptiona
On Thu, 16 Jan 2014 23:44:42 +0100
Tom Wijsman wrote:
> > If I don’t, why do I care if the package is a year old? I lose none
> > of my time to use the old version, since it does all I want;
>
> This is under the assumption that the old version has no further
> implications, which is a false ass
William Hubbs schrieb:
> When you say "drop keywords" do you mean:
>
> 1) revert the old version back to ~arch or
> 2) remove the old version.
>
> As a maintainer, I would rather do 2, because I do not want to backport
> fixes to the old version.
>
> William
>
With 1) users would still be usin
On Sunday 19 January 2014 04:28:33 Pacho Ramos wrote:
> El dom, 19-01-2014 a las 03:36 -0500, Mike Frysinger escribió:
> > On Friday 17 January 2014 02:02:51 gro...@gentoo.org wrote:
> > > Maybe, a good solution is to introduce a special arch, "noarch", for
> > > such packages (similar to what's do
El dom, 19-01-2014 a las 03:36 -0500, Mike Frysinger escribió:
> On Friday 17 January 2014 02:02:51 gro...@gentoo.org wrote:
> > Maybe, a good solution is to introduce a special arch, "noarch", for such
> > packages (similar to what's done in the rpm world). Then, if a package is
> > ~noarch, it is
On Friday 17 January 2014 02:02:51 gro...@gentoo.org wrote:
> Maybe, a good solution is to introduce a special arch, "noarch", for such
> packages (similar to what's done in the rpm world). Then, if a package is
> ~noarch, it is automatically considered ~arch for all arches. Similar for
> stable. T
On Fri, Jan 17, 2014 at 04:02:27PM +0100, Michał Górny wrote:
> Dnia 2014-01-17, o godz. 14:02:51
> gro...@gentoo.org napisał(a):
>
> > Maybe, a good solution is to introduce a special arch, "noarch", for such
> > packages (similar to what's done in the rpm world). Then, if a package is
> > ~noa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/17/2014 06:08 PM, gro...@gentoo.org wrote:
> On Fri, 17 Jan 2014, Tom Wijsman wrote:
>> On Fri, 17 Jan 2014 16:31:54 +0100 Ulrich Mueller
>> wrote:
On Fri, 17 Jan 2014, grozin wrote:
Maybe, a good solution is to introduce a spec
On Fri, 17 Jan 2014 18:28:41 +
Ciaran McCreesh wrote:
> On Fri, 17 Jan 2014 17:47:58 +0100
> Tom Wijsman wrote:
> > Maybe we can let the package managers only perceive it as keyworded
> > or stable if all of its dependencies are keyworded or stable on the
> > architecture that the user runs.
On Friday 17 of January 2014 13:06:22 gro...@gentoo.org wrote:
| dev-util/kdevelop-php-docs
While of course it doesn't invalidate your entire idea, this particular example
is a kdevelop plugin written in C++ that provides php API documentation
integration.
This tells however that decision to "au
On Fri, 17 Jan 2014 17:47:58 +0100
Tom Wijsman wrote:
> Maybe we can let the package managers only perceive it as keyworded or
> stable if all of its dependencies are keyworded or stable on the
> architecture that the user runs. Then we can have repoman just ignore
> checking dependencies' keyword
On Fri, 17 Jan 2014, Ulrich Mueller wrote:
On Fri, 17 Jan 2014, grozin wrote:
Maybe, a good solution is to introduce a special arch, "noarch", for
such packages (similar to what's done in the rpm world). Then, if a
package is ~noarch, it is automatically considered ~arch for all
arches. Similar
On Fri, 17 Jan 2014, Tom Wijsman wrote:
On Fri, 17 Jan 2014 16:31:54 +0100
Ulrich Mueller wrote:
On Fri, 17 Jan 2014, grozin wrote:
Maybe, a good solution is to introduce a special arch, "noarch", for
such packages (similar to what's done in the rpm world). Then, if a
package is ~noarch, it i
On Fri, 17 Jan 2014 16:31:54 +0100
Ulrich Mueller wrote:
> > On Fri, 17 Jan 2014, grozin wrote:
>
> > Maybe, a good solution is to introduce a special arch, "noarch", for
> > such packages (similar to what's done in the rpm world). Then, if a
> > package is ~noarch, it is automatically cons
> On Fri, 17 Jan 2014, grozin wrote:
> Maybe, a good solution is to introduce a special arch, "noarch", for
> such packages (similar to what's done in the rpm world). Then, if a
> package is ~noarch, it is automatically considered ~arch for all
> arches. Similar for stable. The maintainer sho
Dnia 2014-01-17, o godz. 14:02:51
gro...@gentoo.org napisał(a):
> Maybe, a good solution is to introduce a special arch, "noarch", for such
> packages (similar to what's done in the rpm world). Then, if a package is
> ~noarch, it is automatically considered ~arch for all arches. Similar for
> s
On Fri, Jan 17, 2014 at 2:58 AM, Matt Turner wrote:
> On Thu, Jan 16, 2014 at 11:02 PM, wrote:
>> Maybe, a good solution is to introduce a special arch, "noarch", for such
>> packages (similar to what's done in the rpm world). Then, if a package is
>> ~noarch, it is automatically considered ~arc
On Thu, Jan 16, 2014 at 11:02 PM, wrote:
> Sorry for following up myself,
>
>
> On Fri, 17 Jan 2014, gro...@gentoo.org wrote:
>>
>> OK, let's be conservative. Python and Perl scripts may break on some
>> arches (I'd say it's a rare exception, perhaps 1%, but still). But what
>> about
>>
>> dev-ja
Sorry for following up myself,
On Fri, 17 Jan 2014, gro...@gentoo.org wrote:
OK, let's be conservative. Python and Perl scripts may break on some arches
(I'd say it's a rare exception, perhaps 1%, but still). But what about
dev-java/java-sdk-docs
dev-db/postgresql-docs
sys-kernel/linux-docs
de
On Thu, 16 Jan 2014, Sergey Popov wrote:
3. Also, another interesting question has come up in this thread, that of
non-binary packages. Should we give maintainers the option of
stabilizing them on all arch's themselves?
3. If code is interpreted rather then compiled, it does not matter that
it i
On Thu, 16 Jan 2014 10:20:37 +0400
Sergey Popov wrote:
> It can not go to no result, unless we have no breakages in stable,
> stable REMAINS stable. If it contains old, but working software - then
> it is stable.
An ebuild promoted to stable is because an arch team (or a privileged
maintainer to
On Wed, 15 Jan 2014 23:28:04 -0800
Christopher Head wrote:
> If I need or want a feature or bugfix which isn’t in the newer
> version, I always have the choice to use ~.
Yes.
> If I don’t, why do I care if the package is a year old? I lose none
> of my time to use the old version, since it does
Alan McKinnon wrote:
> > I wrote both "assigning" and "respecting"
>
> I reckon the cardinal rule is "avoid as much as possible having priority
> set by someone who is not solving the problem". I think that comes close
> in my words to what you are saying.
Yes that's exactly what I mean. Thanks f
On 16/01/2014 20:26, Peter Stuge wrote:
> Alan McKinnon wrote:
>> "Respecting bug priority" feels like that corporate BS I have to put up
>> with every day.
>
> Gentoo is incorporated so maybe that fits. ;)
>
> On a more serious note, please try to understand what I meant rather
> than just what
Rich Freeman wrote:
> I get what you're saying, though there is still a cost to leaving the
> bug open to years. In this case it means an old package stays in the
> tree marked as stable. That either costs maintainers the effort to
> keep it work, or they don't bother to keep in working in which
On Thu, Jan 16, 2014 at 01:42:41PM -0500, Rich Freeman wrote:
> On Thu, Jan 16, 2014 at 1:11 PM, Peter Stuge wrote:
> > I certainly don't think the work needs to go away if the work is
> > considered to be important. It's fine to have open bugs for years
> > in the absence of a good solution.
>
>
On Thu, Jan 16, 2014 at 1:11 PM, Peter Stuge wrote:
> I certainly don't think the work needs to go away if the work is
> considered to be important. It's fine to have open bugs for years
> in the absence of a good solution.
I get what you're saying, though there is still a cost to leaving the
bug
Alan McKinnon wrote:
> "Respecting bug priority" feels like that corporate BS I have to put up
> with every day.
Gentoo is incorporated so maybe that fits. ;)
On a more serious note, please try to understand what I meant rather
than just what I wrote.
I wrote both "assigning" and "respecting"; y
Rich Freeman wrote:
> >> As i said earlier, problem begins when we NEED to stabilize
> >> something to prevent breakages and arch teams are slow.
> >
> > Isn't that simply a matter of assigning and respecting priority on
> > bugs properly?
>
> Are you suggesting that we should forbid people from w
On 16/01/2014 19:56, Rich Freeman wrote:
> On Thu, Jan 16, 2014 at 10:54 AM, Peter Stuge wrote:
>> Sergey Popov wrote:
>>> As i said earlier, problem begins when we NEED to stabilize
>>> something to prevent breakages and arch teams are slow.
>>
>> Isn't that simply a matter of assigning and respe
On Thu, Jan 16, 2014 at 10:54 AM, Peter Stuge wrote:
> Sergey Popov wrote:
>> As i said earlier, problem begins when we NEED to stabilize
>> something to prevent breakages and arch teams are slow.
>
> Isn't that simply a matter of assigning and respecting priority on
> bugs properly?
Are you sugg
Sergey Popov wrote:
> As i said earlier, problem begins when we NEED to stabilize
> something to prevent breakages and arch teams are slow.
Isn't that simply a matter of assigning and respecting priority on
bugs properly?
//Peter
pgpNUTerDIRPI.pgp
Description: PGP signature
On Tue, 14 Jan 2014 20:46:04 -0600
William Hubbs wrote:
> s/month/year/
>
> Do you feel the same way then? I have heard of stabilizations taking
> this long before. I just had to try to pick something reasonable for
> the discussion.
>
> I suppose a compromise would be, instead of removing the
15.01.2014 22:33, Thomas Sachau пишет:
> William Hubbs schrieb:
>
>> Thoughts?
>>
>> William
>>
>> [1] http://bugs.gentoo.org/487332
>> [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt
>>
>
> I see 2 cases here:
>
> 1. specific or all arch teams allow maintainers to st
15.01.2014 21:04, Tom Wijsman пишет:
> On Wed, 15 Jan 2014 15:40:20 +0400
> Sergey Popov wrote:
>
>> As i said earlier for similar proposals - the one option that i see
>> here to make all things going better - to recruit more people in arch
>> teams/arch testers. Other options lead us to nowhere
15.01.2014 19:30, William Hubbs пишет:
> On Wed, Jan 15, 2014 at 03:30:39PM +0400, Sergey Popov wrote:
>> 15.01.2014 01:37, William Hubbs пишет:
>>> All,
>>>
>>> It is becoming more and more obvious that we do not have enough manpower
>>> on the arch teams, even some of the ones we consider major a
On Thu, 2014-01-16 at 02:32 +, Robin H. Johnson wrote:
> > In my testing, one known issue was that git on uclibc did (and still
> > doesn't) work properly starting with git 1.8 - so I noted in the bug
> > that this was the case, and to NOT stable it for arm. Unfortunately,
> > someone else on
On Wed, Jan 15, 2014 at 06:58:27PM -0600, Steev Klimaszewski wrote:
> We actually ran into something along this issue with git.
>
> Now, arm is an interesting keyword, because for arm, when something
> needs to be stabled, we have to test armv4, armv5, armv6, armv6
> hardfloat, armv7, armv7 hardfl
On Wed, 2014-01-15 at 13:07 -0600, William Hubbs wrote:
> When you say "drop keywords" do you mean:
>
> 1) revert the old version back to ~arch or
> 2) remove the old version.
>
> As a maintainer, I would rather do 2, because I do not want to backport
> fixes to the old version.
>
> William
>
On Tuesday 14 January 2014 22:37:19 William Hubbs wrote:
> I think we need a global policy that either helps keep the stable tree
> up to date or reverts an architecture to ~ over time if the arch team
> can't keep up.
As a compromise solution for minor archs, it would be nice if there were a
por
On Wed, Jan 15, 2014 at 07:33:45PM +0100, Thomas Sachau wrote:
> William Hubbs schrieb:
>
> > Thoughts?
> >
> > William
> >
> > [1] http://bugs.gentoo.org/487332
> > [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt
> >
>
> I see 2 cases here:
>
> 1. specific or all
William Hubbs schrieb:
> Thoughts?
>
> William
>
> [1] http://bugs.gentoo.org/487332
> [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt
>
I see 2 cases here:
1. specific or all arch teams allow maintainers to stabilize packages on
their own, when they follow the arc
On 01/15/2014 10:57 AM, Tom Wijsman wrote:
> On Wed, 15 Jan 2014 15:33:28 +0400
> Sergey Popov wrote:
>
>> 15.01.2014 06:42, Tom Wijsman пишет:
>>> And for that occasional mis-guess, *boohoo*, the user can just file
>>> a bug; which ironically even happens occasionally for stable
>>> packages.
>>
On Wed, 15 Jan 2014 15:40:20 +0400
Sergey Popov wrote:
> As i said earlier for similar proposals - the one option that i see
> here to make all things going better - to recruit more people in arch
> teams/arch testers. Other options lead us to nowhere, when stable
> will be eliminated or transfor
On Wed, 15 Jan 2014 15:33:28 +0400
Sergey Popov wrote:
> 15.01.2014 06:42, Tom Wijsman пишет:
> > And for that occasional mis-guess, *boohoo*, the user can just file
> > a bug; which ironically even happens occasionally for stable
> > packages.
>
> If we blindly approves increasing of such mis-g
On Wed, Jan 15, 2014 at 03:30:39PM +0400, Sergey Popov wrote:
> 15.01.2014 01:37, William Hubbs пишет:
> > All,
> >
> > It is becoming more and more obvious that we do not have enough manpower
> > on the arch teams, even some of the ones we consider major arch's, to
> > keep up with stabilization
On Wed, Jan 15, 2014 at 4:54 AM, Michał Górny wrote:
>
> 2) has to add package.accept_keywords entry for the package. Which
> means turning a pure stable system into an unsupported mixed-keyword
> system.
As opposed to an unsupported pure stable system or an unsupported pure
unstable system? I d
15.01.2014 03:49, Tom Wijsman пишет:
> On Tue, 14 Jan 2014 15:37:19 -0600
> William Hubbs wrote:
>
>> Thoughts?
>
> In this situation, I see three opposite ends of choices:
>
> 1. "We do nothing"; which means that as a side effect either less
> often a version would be picked for stabilizat
15.01.2014 06:42, Tom Wijsman пишет:
> And for that occasional mis-guess, *boohoo*, the user can just file a
> bug; which ironically even happens occasionally for stable packages.
If we blindly approves increasing of such mis-guesses, then our QA level
in arch teams will down below the apropriate
15.01.2014 01:37, William Hubbs пишет:
> All,
>
> It is becoming more and more obvious that we do not have enough manpower
> on the arch teams, even some of the ones we consider major arch's, to
> keep up with stabilization requests. For example, there is this bug [1],
> which is blocking the stab
15.01.2014 03:11, William Hubbs пишет:
> The status quo is not good, because we are forced to keep old, and
> potentially buggy, versions of software around longer than necessary.
But both of suggested solutions will break the whole idea of stabling.
Dropping packages to unstable on regular basis
15.01.2014 01:37, William Hubbs пишет:
> I want comments wrt two ideas:
>
> 1. I think maintainers should be able to stabilize their packages on arch's
> they have access to. I think this is allowed by some arch teams, but I
> think it would be good to formalize it.
>
> 2. I would like to see the
Dnia 2014-01-14, o godz. 15:37:19
William Hubbs napisał(a):
> I want comments wrt two ideas:
>
> 1. I think maintainers should be able to stabilize their packages on arch's
> they have access to. I think this is allowed by some arch teams, but I
> think it would be good to formalize it.
I think
On Tue, 2014-01-14 at 22:49 -0600, William Hubbs wrote:
> > Also, there is a substantial number of packages which contain only python
> > code (or perl, ruby), or only LaTeX classes, or only documentation. It
> > makes no sense to test them on each arch separately. I think maintainers
> > should
On Wed, Jan 15, 2014 at 5:49 AM, William Hubbs wrote:
>> Also, there is a substantial number of packages which contain only python
>> code (or perl, ruby), or only LaTeX classes, or only documentation. It
>> makes no sense to test them on each arch separately. I think maintainers
>> should be allo
On Tue, Jan 14, 2014 at 10:49:48PM -0600, William Hubbs wrote:
> > Also, there is a substantial number of packages which contain only python
> > code (or perl, ruby), or only LaTeX classes, or only documentation. It
> > makes no sense to test them on each arch separately. I think maintainers
> >
On Wed, Jan 15, 2014 at 10:48:53AM +0700, gro...@gentoo.org wrote:
> On Tue, 14 Jan 2014, William Hubbs wrote:
> > 1. I think maintainers should be able to stabilize their packages on arch's
> > they have access to. I think this is allowed by some arch teams, but I
> > think it would be good to for
On Tue, 14 Jan 2014, William Hubbs wrote:
1. I think maintainers should be able to stabilize their packages on arch's
they have access to. I think this is allowed by some arch teams, but I
think it would be good to formalize it.
+1
Also, there is a substantial number of packages which contain o
On Tue, 14 Jan 2014 21:40:24 -0500
Michael Orlitzky wrote:
> I've written too many emails today, I hereby give up =)
At least you've let your voice be heard against this option. :)
It sets the ground for discussion for people that agree with you.
--
With kind regards,
Tom Wijsman (TomWij)
Ge
On Tue, Jan 14, 2014 at 09:21:51PM -0500, Michael Orlitzky wrote:
> On 01/14/2014 09:09 PM, William Hubbs wrote:
> >
> > After the package has been sitting in ~arch for 90 days with an open
> > stable request with no blockers that the arch team has not taken any
> > action on. We are not talking a
On Tue, 14 Jan 2014 20:09:34 -0600
William Hubbs wrote:
> After the package has been sitting in ~arch for 90 days with an open
> stable request with no blockers that the arch team has not taken any
> action on. We are not talking about randomly yanking package versions,
> just doing something whe
On 01/14/2014 09:34 PM, Tom Wijsman wrote:
>
>> Strictly from a user's perspective. I don't, unless I do, in which
>> case I know that I do, and I could just keyword the thing if I wanted
>> to.
>
> This is the exact same argument as in your other mail, which is your
> point of view; this is unde
On Tue, 14 Jan 2014 21:21:51 -0500
Michael Orlitzky wrote:
> On 01/14/2014 09:09 PM, William Hubbs wrote:
> >
> > After the package has been sitting in ~arch for 90 days with an open
> > stable request with no blockers that the arch team has not taken any
> > action on. We are not talking about
On Tue, 14 Jan 2014 20:36:10 -0500
Michael Orlitzky wrote:
> On 01/14/2014 08:23 PM, Tom Wijsman wrote:
> > On Tue, 14 Jan 2014 20:11:24 -0500
> > Michael Orlitzky wrote:
> >
> >> On 01/14/2014 08:08 PM, Tom Wijsman wrote:
> >>>
> >>> This is under the assumption that the user knows of the stat
On 01/14/2014 09:09 PM, William Hubbs wrote:
>
> After the package has been sitting in ~arch for 90 days with an open
> stable request with no blockers that the arch team has not taken any
> action on. We are not talking about randomly yanking package versions,
> just doing something when arch tea
On Tue, Jan 14, 2014 at 08:36:10PM -0500, Michael Orlitzky wrote:
> On 01/14/2014 08:23 PM, Tom Wijsman wrote:
> > On Tue, 14 Jan 2014 20:11:24 -0500
> > Michael Orlitzky wrote:
> >
> >> On 01/14/2014 08:08 PM, Tom Wijsman wrote:
> >>>
> >>> This is under the assumption that the user knows of the
On 01/14/2014 08:23 PM, Tom Wijsman wrote:
> On Tue, 14 Jan 2014 20:11:24 -0500
> Michael Orlitzky wrote:
>
>> On 01/14/2014 08:08 PM, Tom Wijsman wrote:
>>>
>>> This is under the assumption that the user knows of the state of the
>>> stabilization worsening; if the user is unaware of that change
On Tue, 14 Jan 2014 18:46:06 -0600
William Hubbs wrote:
> If you want to say @system, you have to include all rdepends of
> virtuals in @system and all packages that are dependencies of any
> packages in @system, at least.
>
> Keeping track of that will be difficult at best.
Trying to depclean
On Tue, 14 Jan 2014 20:11:24 -0500
Michael Orlitzky wrote:
> On 01/14/2014 08:08 PM, Tom Wijsman wrote:
> >
> > This is under the assumption that the user knows of the state of the
> > stabilization worsening; if the user is unaware of that change, the
> > "could have done anyway" might be less
On Tue, 14 Jan 2014 19:50:30 -0500
Michael Orlitzky wrote:
> On 01/14/2014 07:13 PM, Tom Wijsman wrote:
> >>
> >> For users, both options are worse than the status quo.
> >
> > When you do nothing then things are bound to get worse, under the
> > assumption that manpower doesn't change as well a
On 01/14/2014 08:08 PM, Tom Wijsman wrote:
>
> This is under the assumption that the user knows of the state of the
> stabilization worsening; if the user is unaware of that change, the
> "could have done anyway" might be less common and first something bad
> would need to happen before they reali
On Tue, 14 Jan 2014 19:47:50 -0500
Michael Orlitzky wrote:
> On 01/14/2014 06:11 PM, William Hubbs wrote:
> >>
> >> For users, both options are worse than the status quo.
> >
> > The first option would start reverting things back to ~ and users
> > would have to unmask them.
> >
> > The second
On 01/14/2014 07:13 PM, Tom Wijsman wrote:
>>
>> For users, both options are worse than the status quo.
>
> When you do nothing then things are bound to get worse, under the
> assumption that manpower doesn't change as well as the assumption that
> the queue fills faster than stabilization bugs ge
On 01/14/2014 06:11 PM, William Hubbs wrote:
>>
>> For users, both options are worse than the status quo.
>
> The first option would start reverting things back to ~ and users would
> have to unmask them.
>
> The second option would introduce new things to stable which may not be
> stable due to
On Wed, Jan 15, 2014 at 01:38:08AM +0100, Tom Wijsman wrote:
> On Wed, 15 Jan 2014 01:06:07 +0100
> "Andreas K. Huettel" wrote:
>
> > Am Mittwoch, 15. Januar 2014, 00:49:28 schrieb Tom Wijsman:
> > > On Tue, 14 Jan 2014 15:37:19 -0600
> > >
> > > William Hubbs wrote:
> > > > Thoughts?
> > >
>
On Tue, 14 Jan 2014 19:17:35 -0500
"Anthony G. Basile" wrote:
> On 01/14/2014 07:06 PM, Andreas K. Huettel wrote:
> > Am Mittwoch, 15. Januar 2014, 00:49:28 schrieb Tom Wijsman:
> >> On Tue, 14 Jan 2014 15:37:19 -0600
> >>
> >> William Hubbs wrote:
> >>> Thoughts?
> >> In this situation, I see t
On Wed, 15 Jan 2014 01:06:07 +0100
"Andreas K. Huettel" wrote:
> Am Mittwoch, 15. Januar 2014, 00:49:28 schrieb Tom Wijsman:
> > On Tue, 14 Jan 2014 15:37:19 -0600
> >
> > William Hubbs wrote:
> > > Thoughts?
> >
> > In this situation, I see three opposite ends of choices:
> >
>
> Here's ano
On Tue, 14 Jan 2014 18:22:51 -0500
Jeff Horelick wrote:
> I think the simplest short-term solution might be to add teams that
> are looking for ArchTesters to the Staffing Needs page on the wiki
Adding a lot of them could make it noisy, I think we could just make
one entry to link to a page that
On 01/14/2014 07:06 PM, Andreas K. Huettel wrote:
Am Mittwoch, 15. Januar 2014, 00:49:28 schrieb Tom Wijsman:
On Tue, 14 Jan 2014 15:37:19 -0600
William Hubbs wrote:
Thoughts?
In this situation, I see three opposite ends of choices:
Here's another idea:
4. Friendly ask the arch teams / ma
On Tue, 14 Jan 2014 17:43:57 -0500
Michael Orlitzky wrote:
> It's attempting to fix a headache with a bullet. The arch teams are
> lagging behind, you're annoyed, I get it. Give 'em hell. But don't
> break stable to make a point.
>
> For users, both options are worse than the status quo.
When yo
On Tue, 14 Jan 2014 16:57:30 -0500
Michael Orlitzky wrote:
> On 01/14/2014 04:37 PM, William Hubbs wrote:
> >
> > 2. I would like to see the policy below applied to all arch's [2].
>
> [ ] Yup
> [X] Nope
For which reason?
I could do
[✓] Yup
[X] Nope
'cause a stable version that's no longer
Am Mittwoch, 15. Januar 2014, 00:49:28 schrieb Tom Wijsman:
> On Tue, 14 Jan 2014 15:37:19 -0600
>
> William Hubbs wrote:
> > Thoughts?
>
> In this situation, I see three opposite ends of choices:
>
Here's another idea:
4. Friendly ask the arch teams / make a policy that @system packages com
On Tue, 14 Jan 2014 15:37:19 -0600
William Hubbs wrote:
> Thoughts?
In this situation, I see three opposite ends of choices:
1. "We do nothing"; which means that as a side effect either less
often a version would be picked for stabilization or stabilizations
will just take longer due to a
On 14 January 2014 18:11, William Hubbs wrote:
> On Tue, Jan 14, 2014 at 05:43:57PM -0500, Michael Orlitzky wrote:
> > On 01/14/2014 05:33 PM, William Hubbs wrote:
> > > On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote:
> > >> On 01/14/2014 04:37 PM, William Hubbs wrote:
> > >>>
>
On Tue, Jan 14, 2014 at 05:43:57PM -0500, Michael Orlitzky wrote:
> On 01/14/2014 05:33 PM, William Hubbs wrote:
> > On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote:
> >> On 01/14/2014 04:37 PM, William Hubbs wrote:
> >>>
> >>> 2. I would like to see the policy below applied to all
On 01/14/2014 05:33 PM, William Hubbs wrote:
> On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote:
>> On 01/14/2014 04:37 PM, William Hubbs wrote:
>>>
>>> 2. I would like to see the policy below applied to all arch's [2].
>>
>> [ ] Yup
>> [X] Nope
>
> The reverse of this would be to
On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote:
> On 01/14/2014 04:37 PM, William Hubbs wrote:
> >
> > 2. I would like to see the policy below applied to all arch's [2].
>
> [ ] Yup
> [X] Nope
The reverse of this would be to let maintainers stabilize on all arch's
after 90 days
On 01/14/2014 04:37 PM, William Hubbs wrote:
>
> 2. I would like to see the policy below applied to all arch's [2].
[ ] Yup
[X] Nope
All,
It is becoming more and more obvious that we do not have enough manpower
on the arch teams, even some of the ones we consider major arch's, to
keep up with stabilization requests. For example, there is this bug [1],
which is blocking the stabilization of several important packages.
I spoke t
89 matches
Mail list logo
