On 10/04/2016 10:25 AM, Ian Stakenvicius wrote:
> On 20/08/16 08:30 PM, Daniel Campbell wrote:
>> On 08/15/2016 12:42 PM, Rich Freeman wrote:
>>> 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
norm
On 20/08/16 08:30 PM, Daniel Campbell wrote:
> On 08/15/2016 12:42 PM, Rich Freeman wrote:
>> 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 sta
On 08/15/2016 12:42 PM, Rich Freeman wrote:
> 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 y
Strict compliance with the handbook would seem to forbid having a stable
package depend on an unstable package, and if you have to downgrade a
dependency and it causes a cascade, I would opine, that, perhaps, the
package in question should not have been stabilized to begin with.
That said, I as a
On 08/15/2016 03:21 AM, Kristian Fiskerstrand wrote:
> Better than developers marking it fixed without it hitting stable as too
> many are doing today.
Totally guilty of that one, sorry!
I think adding a status would be great. We could have CONFIRMED and even
RESOLVED still, but the goalpost could
El mié, 17-08-2016 a las 09:07 -0400, Rich Freeman escribió:
> I'm not sure I agree. If it is scripted, then isn't it just a few
> more cpu cycles?
Well... until I see that script, I won't trust it. We are for a long
time supposedly allowing people to move things to testing after 90 days
and that
On Wed, Aug 17, 2016 at 4:50 AM, Pacho Ramos wrote:
>
> El lun, 15-08-2016 a las 15:27 -0400, Rich Freeman escribió:
> > [...]
> > Well, I wasn't suggesting that breaking the depgraph is great. Just
> > that I think it is better than calling things stable which aren't.
> >
> > A better approach i
El lun, 15-08-2016 a las 15:01 -0500, William Hubbs escribió:
> [...]
> 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 o
El lun, 15-08-2016 a las 15:27 -0400, Rich Freeman escribió:
> [...]
> Well, I wasn't suggesting that breaking the depgraph is great. Just
> that I think it is better than calling things stable which aren't.
>
> A better approach is a script that does the keyword cleanup.
>
> So, if you want to
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
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
> >
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 amongst developers.
> >Will a workfl
On Sun, 14 Aug 2016 23:35:58 +0200
Kristian Fiskerstrand 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 amongst developers.
>Will a workf
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
>
> TESTREQ was incidentally my first thought. Only needs me to study how mu
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
TESTREQ was incidentally my first thought. Only needs me to study how much
that's already used
and whether or not existing bugs with that flag meet
On Sun, Aug 14, 2016 at 11:35:58PM +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.
Sign me up!
>
> Some initial items
On August 14, 2016 5:49:48 PM EDT, Kent Fredric wrote:
>On Sun, 14 Aug 2016 22:45:07 +0100
>Ciaran McCreesh wrote:
>
>> What's a Working Group, and how is it related to a Project? Shouldn't
>> there be a GLEP to define what a Working Group is first?
>
>So if a group of people wanted to write su
On Sun, 14 Aug 2016 22:57:31 +0100
Ciaran McCreesh wrote:
> I'm not sure what a group is. Is it anything like a herd?
Its a thing you get when more than one person does a thing.
pgpMXkRM4x5eF.pgp
Description: OpenPGP digital signature
On Sun, 14 Aug 2016 17:50:58 -0400
"Anthony G. Basile" wrote:
> On 8/14/16 5:45 PM, Ciaran McCreesh wrote:
> > 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 recommen
On 14/08/16 22:49, Kent Fredric wrote:
> On Sun, 14 Aug 2016 22:45:07 +0100
> Ciaran McCreesh wrote:
>
>> What's a Working Group, and how is it related to a Project? Shouldn't
>> there be a GLEP to define what a Working Group is first?
> So if a group of people wanted to write such a GLEP ... woul
On 8/14/16 5:45 PM, Ciaran McCreesh wrote:
> 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 me
On Sun, 14 Aug 2016 22:45:07 +0100
Ciaran McCreesh wrote:
> What's a Working Group, and how is it related to a Project? Shouldn't
> there be a GLEP to define what a Working Group is first?
So if a group of people wanted to write such a GLEP ... would they have
to be part of a defined Project fir
On 08/14/2016 11:45 PM, Ciaran McCreesh wrote:
> 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 Counci
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.
What's a Working Group, and how is it rela
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 the WG look into is
* The b.g.o workflow, bugs should not be considered fixe
58 matches
Mail list logo
