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
On 01/16/2014 05:27 PM, Sergey Popov wrote:
>
> Thanks, for the proposal. IIRC, there was similar backroom agreement in
> some minor arches, look at how armin76 stabilized packages earlier -
> sometimes he drops vast amount of keywords on ia64/sparc/m68k to
> unstable in stabilization requests.
>
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 Wed, 15 Jan 2014 23:59:49 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> There was previous discussion of destable-keywording the kernel. How
> has that gone?
That was for vanilla-sources only, because that has restricted to only
the latest upstream version; as that makes the version chan
Tom Wijsman posted on Wed, 15 Jan 2014 01:28:09 +0100 as excerpted:
>> Another option (and I don't mean to step on any toes or call anyone out
>> here, these are just examples) may be to just deprecate stabilizing
>> certain software. Packages such as the stuff in app-vim/ or app-emacs/
>> or some
Michael Orlitzky posted on Tue, 14 Jan 2014 19:50:30 -0500 as excerpted:
> As I mentioned in a reply to William, right now I can decide when stuff
> is broken and keyword the newer versions. The proposal is to force me
> onto the new versions, which is strictly worse from my perspective.
Force??
Rich Freeman posted on Wed, 15 Jan 2014 07:51:49 -0500 as excerpted:
> Given constrained manpower the options basically are some variation on:
> 1. Status quo - for some packages stable gets REALLY old, and likely has
> problems that maintainers ignore. You can't force somebody to maintain
> som
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
28 matches
Mail list logo
