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
88 matches
Mail list logo
