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
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
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
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
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
>
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
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)
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
>
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
>
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
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]
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
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
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
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
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
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
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
>
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
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
> > >
36 matches
Mail list logo