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
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
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
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
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
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.
> >
> >
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
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
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
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
> > >
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.
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.
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
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
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 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
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
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,
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
51 matches
Mail list logo