On 2016-08-15 22:54, Jack Morgan wrote:
Following up to my email from a year ago
We do have some people in the community who are interested in sparc. In
fact, we have one kernel developer who would like to get multilib
working.
In addition, I have two who are interested in helping by bei
Arch team,
I'm currently listed as arch lead and probably shouldn't be. We need to
have the annual team meeting to elect one. I'm going to step down as
current arch lead. I'll still work on both ppc and ppc64 but need to
give someone else a chance.
Current members are...
Lead(s) Jack Morgan (j
Following up to my email from a year ago
I've been out for several months and getting back to working on Gentoo.
I'd like to provide an update on sparc status...
On 05/17/15 08:36, Jack Morgan wrote:
> All,
>
> I wanted to send out an update on the Sparc arch team status. My overall
> plan i
Following up to my email from a year ago
I've been out for several months and getting back to working on Gentoo.
I'd like to provide an update on ia64 status...
On 05/17/15 08:04, Jack Morgan wrote:
> All,
>
> I wanted to send out an update on the IA64 arch team status. Currently,
> we are o
On Mon, 15 Aug 2016 09:37:33 -0400
Rich Freeman wrote:
>
> Today developers tend to use views that exclude resolved bugs.
> Perhaps tomorrow they'll tend to use views that exclude bugs that are
> resolved or waiting for stabilization. Perhaps these views will
> become the defaults.
Can bugzill
On Mon, 15 Aug 2016 21:30:04 +0200
"Andreas K. Hüttel" wrote:
> 2) *If* we introduce a "Fixed-in" and maybe an "Introduced-in" field in
> Bugzilla, which gives a precise $CATEGORY/$PVR where a problem is resolved or
> introduced, the extraction of fixed or non-fixed bugs might even be
> automa
On Mon, 15 Aug 2016 15:03:08 +0200
Kristian Fiskerstrand wrote:
> Could you please elaborate a bit? In particular from perspective of (i)
> integration into current workflow, (ii) complexity in application
> maintenance/hosting (iii) cost/benefit considerations
Biggest irritation is that "bugs t
On Mon, Aug 15, 2016 at 4:01 PM, William Hubbs wrote:
> This works unless you are talking about packages in @system.
> I do see core packages on these arches also languish in ~ for months
> with open stable requests.
>
> The only way to handle one of those would be to remove the old version
> and
On Mon, Aug 15, 2016 at 03:27:43PM -0400, Rich Freeman wrote:
> On Mon, Aug 15, 2016 at 3:12 PM, William Hubbs wrote:
> > On Mon, Aug 15, 2016 at 02:33:52PM -0400, Rich Freeman wrote:
> >> I'd rather see maintainers just yank the last stable package and break
> >> the depgraph and let the arch tea
On Mon, Aug 15, 2016 at 3:30 PM, Andreas K. Hüttel wrote:
> 1) Stabilization is a simpler and much more formalized process compared to
> normal bug resolution.
> * There is one version to be stabilized.
> * One precise package version
Can you clarify what this means? Do you mean that at any time
On Sun, 14 Aug 2016 23:35:58 +0200
Kristian Fiskerstrand wrote:
> During the latest Council meeting it was determined to set up a new
> Working Group to come up with recommendations for improving the state
> of the stable tree at a later Council meeting.
>
> Some initial items it was suggested t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Montag, 15. August 2016, 15:03:08 schrieb Kristian Fiskerstrand:
> On 08/15/2016 02:49 PM, Dirkjan Ochtman wrote:
> > On Mon, Aug 15, 2016 at 6:29 AM, Kent Fredric wrote:
> >> This sort of stuff makes me feel bugzilla is entirely the wrong platfo
On Mon, Aug 15, 2016 at 3:12 PM, William Hubbs wrote:
> On Mon, Aug 15, 2016 at 02:33:52PM -0400, Rich Freeman wrote:
>> I'd rather see maintainers just yank the last stable package and break
>> the depgraph and let the arch teams deal with the cleanup than have
>> them mark stuff stable without a
On 08/15/2016 03:18 PM, Andreas K. Hüttel wrote:
> Am Sonntag, 14. August 2016, 23:57:31 schrieb Ciaran McCreesh:
>>
>> I'm not sure what a group is. Is it anything like a herd?
>
> It's a set with a binary operator, with following fulfilled:
> * closed with respect to the operation
THIS IS PART
Am Sonntag, 14. August 2016, 23:57:31 schrieb Ciaran McCreesh:
>
> I'm not sure what a group is. Is it anything like a herd?
It's a set with a binary operator, with following fulfilled:
* closed with respect to the operation
* the operation is associative
* there is a neutral element for the ope
On Mon, Aug 15, 2016 at 02:33:52PM -0400, Rich Freeman wrote:
> I'm fine with maintainers de-keywording packages on their own
> initiative. However, if a maintainer hasn't even built a package on
> an arch, they shouldn't be stabilizing it on that arch. That would
> make the concept of stable mea
On Mon, Aug 15, 2016 at 1:31 PM, William Hubbs wrote:
> I want to elaborate a bit more on this.
>
> On Mon, Aug 15, 2016 at 11:12:41AM -0500, William Hubbs wrote:
>> On Mon, Aug 15, 2016 at 04:50:38PM +0200, Kristian Fiskerstrand wrote:
>> > On 08/15/2016 04:49 PM, Kristian Fiskerstrand wrote:
>>
On Mon, Aug 15, 2016 at 3:25 PM, Kristian Fiskerstrand wrote:
>> very different process from handling bugs and feature requests. It
>> would be great if we had tooling that focuses on these instead of
>> trying to fit into the bug tracker. It would entail a different
>
> I'm not sure I agree on th
I want to elaborate a bit more on this.
On Mon, Aug 15, 2016 at 11:12:41AM -0500, William Hubbs wrote:
> On Mon, Aug 15, 2016 at 04:50:38PM +0200, Kristian Fiskerstrand wrote:
> > On 08/15/2016 04:49 PM, Kristian Fiskerstrand wrote:
> > > On 08/15/2016 04:19 PM, William Hubbs wrote:
> > >> I'm ver
On Mon, Aug 15, 2016 at 04:50:38PM +0200, Kristian Fiskerstrand wrote:
> On 08/15/2016 04:49 PM, Kristian Fiskerstrand wrote:
> > On 08/15/2016 04:19 PM, William Hubbs wrote:
> >> I'm very much for this as well. Themaintainer should be able to
> >> stabilize on all arches after the timeout. That wo
On Mon, 15 Aug 2016 09:40:39 -0400
Rich Freeman wrote:
> On Mon, Aug 15, 2016 at 3:55 AM, Brian Dolbec
> wrote:
> >
> > I have some trouble with not being able to close bugs as resolved
> > when the fixes have been released. But I do see that the majority
> > of what is being discussed relates
On 08/15/2016 04:49 PM, Kristian Fiskerstrand wrote:
> On 08/15/2016 04:19 PM, William Hubbs wrote:
>> I'm very much for this as well. Themaintainer should be able to
>> stabilize on all arches after the timeout. That would solve the primary
>> concern I have about the stable tree lagging.
>
> It
On 08/15/2016 04:19 PM, William Hubbs wrote:
> I'm very much for this as well. Themaintainer should be able to
> stabilize on all arches after the timeout. That would solve the primary
> concern I have about the stable tree lagging.
It depends on the context, if it is not security related or fixin
On 08/15/2016 09:25 AM, Kristian Fiskerstrand wrote:
On 08/15/2016 03:15 PM, Dirkjan Ochtman wrote:
On Mon, Aug 15, 2016 at 3:03 PM, Kristian Fiskerstrand wrote:
Could you please elaborate a bit? In particular from perspective of (i)
integration into current workflow, (ii) complexity in applic
On Mon, Aug 15, 2016 at 10:00:12AM +0200, Pacho Ramos wrote:
> El dom, 14-08-2016 a las 23:35 +0200, Kristian Fiskerstrand escribió:
> > * Are there ways to reduce the stabilization lag of packages
> > - looking into the effectiveness of ALLARCHES and its use
> > - possibility for mainta
On Mon, Aug 15, 2016 at 3:55 AM, Brian Dolbec wrote:
>
> I have some trouble with not being able to close bugs as resolved when
> the fixes have been released. But I do see that the majority of what is
> being discussed relates to pkg ebuilds more than it does to coding
> projects. In that sense
On Mon, Aug 15, 2016 at 8:24 AM, Michael Orlitzky wrote:
>
> If we have to wait for a fix to hit stable before I can close a bug, who
> should I assign it to? I don't want 200 bugs, that I can do literally
> nothing about, assigned to me for years while I wait for them to get
> stabilized. It's al
On 08/15/2016 03:15 PM, Dirkjan Ochtman wrote:
> On Mon, Aug 15, 2016 at 3:03 PM, Kristian Fiskerstrand
> wrote:
>> Could you please elaborate a bit? In particular from perspective of (i)
>> integration into current workflow, (ii) complexity in application
>> maintenance/hosting (iii) cost/benefi
As was previously announced on 2015-06-24 [1], depend.php.eclass was
deprecated.
The tree is now clear of its use.
The eclass will be removed in 30 days.
All overlays are advised to update their ebuilds at this time.
Thank you,
Brian Evans
[1]
https://archives.gentoo.org/gentoo-dev-announce/m
On Mon, Aug 15, 2016 at 3:03 PM, Kristian Fiskerstrand wrote:
> Could you please elaborate a bit? In particular from perspective of (i)
> integration into current workflow, (ii) complexity in application
> maintenance/hosting (iii) cost/benefit considerations
Well, I think stabilization (and, to
On 08/15/2016 02:49 PM, Dirkjan Ochtman wrote:
> On Mon, Aug 15, 2016 at 6:29 AM, Kent Fredric wrote:
>> This sort of stuff makes me feel bugzilla is entirely the wrong platform for
>> handling stabilizations and keywords :/
>
> I very much agree; some kind of minimal web app/API would probably b
On Mon, Aug 15, 2016 at 6:29 AM, Kent Fredric wrote:
> This sort of stuff makes me feel bugzilla is entirely the wrong platform for
> handling stabilizations and keywords :/
I very much agree; some kind of minimal web app/API would probably be better.
Cheers,
Dirkjan
On 08/14/2016 05:35 PM, Kristian Fiskerstrand wrote:
>
> Some initial items it was suggested the WG look into is
> * The b.g.o workflow, bugs should not be considered fixed until the
>fix has reached the stable tree. Today the InVCS keyword exists for
>this purpose, but it is used to vary
On 08/15/2016 12:37 AM, Kent Fredric wrote:
On Mon, 15 Aug 2016 16:29:43 +1200
Kent Fredric wrote:
* The b.g.o workflow, bugs should not be considered fixed until the
fix has reached the stable tree. Today the InVCS keyword exists for
this purpose, but it is used to varying degree among
On 08/14/2016 11:35 PM, Kristian Fiskerstrand wrote:
> I've volunteered to chair such as working group. If you want to
> participate in it please respond to this thread. Additionally I've set
> up #gentoo-wg-stable as a place of coordination.
we now have an alias wg-sta...@gentoo.org that can be u
On 08/15/2016 09:55 AM, Brian Dolbec wrote:
>
> For me IN_PROGRESS means the problem is being worked on, not that a fix
> has been posted/committed anywhere.
Indeed
> INVCS is once the fix has been
> committed to the source repo and not anything to do with an ebuild from
> the coders perspect
On Mon, 15 Aug 2016 00:55:50 -0700
Brian Dolbec wrote:
> For me IN_PROGRESS means the problem is being worked on, not that a fix
> has been posted/committed anywhere. INVCS is once the fix has been
> committed to the source repo and not anything to do with an ebuild from
> the coders perspective
El lun, 15-08-2016 a las 10:00 +0200, Pacho Ramos escribió:
> El dom, 14-08-2016 a las 23:35 +0200, Kristian Fiskerstrand escribió:
> >
> > During the latest Council meeting it was determined to set up a new
> > Working Group to come up with recommendations for improving the
> > state
> > of
[...]
El dom, 14-08-2016 a las 23:35 +0200, Kristian Fiskerstrand escribió:
> During the latest Council meeting it was determined to set up a new
> Working Group to come up with recommendations for improving the state
> of
> the stable tree at a later Council meeting.
>
> Some initial items it was sugge
On Mon, 15 Aug 2016 12:05:43 +0800
Jason Zaman wrote:
> On Mon, Aug 15, 2016 at 03:53:26PM +1200, Kent Fredric wrote:
> > On Mon, 15 Aug 2016 11:45:22 +0800
> > Jason Zaman wrote:
> >
> > > IN_PROGRESS == we've put the fix in the git repo
> > > RESO/TESTREQ == new release and in ~arch
> >
40 matches
Mail list logo
