Re: #wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree)

[Kent Fredric]

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 workflow change to introduce a new status, e.g RESOLVED
> >NeedsStable (name for illustration purpose only) incentivize
> >developers to not close bugs before it is fixed?  

Also, if its already stable, the fix may go directly into stable.

Does this need to also spend time in "NeedsStable" state?

I'd assume not. But this is going to need clear definitions and lots of usecase
writeups.


pgpCeF7kdMHJT.pgp
Description: OpenPGP digital signature

#wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree)

[Kent Fredric]

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 workflow change to introduce a new status, e.g RESOLVED
>NeedsStable (name for illustration purpose only) incentivize
>developers to not close bugs before it is fixed?

Here you're essentially marking "RESOLVED" to be "Fixed In Stable"

There's a problem I have here with this: If we have a keyword that in effect is
intended to say "This bug is fixed in stable", the problem there is there's no
way, at least, not in the context of the bug, or the bug metadata, to draw
anything meaningful from that.

Because "Stable" is in my estimation typically not a single state.

We like to presume it is, but the reality is a significant number of packages
have "mixed" stability states.

And the stability process itself is also arch specific, and so they don't
all stabilize together, some, languishing by months.

So: "NeedsStable"(sic) means what exactly?

And if "Resolved" is "Stable is done", what does that mean?

Does "NeedsStable" mean "All arches that are deemed stable need to be stabilized
for this bug"?

What about packages that don't have any stable version, and are not anywhere
on a prioritization for stabilization?

What about packages that are stable only on a few arches?

The lack of bugs having an "affected platforms" field as such makes reverse
searching for such things when you're touching a bug needlessly complicated.

You can at best approximate it by searching for cc@ properties, but that only
matters for packages that are *currently* pending keywording.

And I doubt people are going to be CCing arches for every bug that "NeedsStable"

You can I guess create some form of referential integrity, where you have to
assign every bug that gets fixed to a stable request in order to ensure its 
completion.

But that's getting into problems of causality, needing to assign a stability
request to a bug before stabilization is needed just to determine "which arches"

This sort of stuff makes me feel bugzilla is entirely the wrong platform for
handling stabilizations and keywords :/



pgp3j2uNQ5aDJ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Jason Zaman]

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 much 
> that's already used
> and whether or not existing bugs with that flag meet that description or not.
> 
> 
> However, a distinction between IN_PROGRESS and RESO/TESTREQ is not possible 
> here,
> because "in git" means "You'll get it if you sync >1h from now"

Oh, I meant this is for our policy stuff. which is in
hardened-refpolicy.git and then every few weeks we make a release and
bump all the packages in sec-policy/selinux-*. For things that do not
need an actual release we just skip INPROG and go straight to TESTREQ
when we fix the ebuild in the tree.

The important part to me is that RESO/FIXED should only mean fixed when
the problem is fixed in the stable tree too. There has to be another
state before FIXED that is for ~arch. If the package is not stable on
any arch then of course it is FIXED as soon as ~arch is fixed.

> IN_PROGRESS can thus only mean something about it being worked on but not yet 
> pushed
> to the main git repo. (ie: overlays, private repos)
> 
> But I would rather it part of the primary resolution path, not a mere 
> property of the resolution type.
> 
> Because its easier to say:
> 
> UNCONFIRMED -> CONFIRMED -> INPROGRESS -> INVCS -> STABLE
> 
> Than
> 
> UNCONFIRMED -> CONFIRMED -> INPROGRESS -> (RESOLVED/TESTREQ) -> 
> (RESOLVED/FIXED)

They are roughly equivalent, yeah. But I prefer TESTREQ because its
easier to see in the bug list page. You can of course choose which items
are shown in the list in bugzilla but resolution is already there so no
need to add an extra column.

-- Jason

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Jason Zaman]

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 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 varying degree amongst developers.
>Will a workflow change to introduce a new status, e.g RESOLVED
>NeedsStable (name for illustration purpose only) incentivize
>developers to not close bugs before it is fixed?

In selinux we do:
UNCONFIRMED/CONFIRMED == not fixed yet
IN_PROGRESS == we've put the fix in the git repo
RESO/TESTREQ == new release and in ~arch
RESO/FIXED == the fix is stable now

Both Swift and I use stable so having things stabilized is important and
we dont close bugs till they are actually stable lest we forget later.
Our saved search for selinux bugs lists all bugs that are not RESO/FIXED
or VERIFIED, so RESO/TESTREQ still shows up.

-- Jason

>  * Are there ways to reduce the stabilization lag of packages
>  - looking into the effectiveness of ALLARCHES and its use
>  - possibility for maintainer to stabilize packages themselves for
>architectures they have access to (including whether there might
>be a need for changes to gentoo infrastructure to facilitate
>this)
>  - Tinderboxing / Automatic tools build test packages and reverse
>dependencies in order to assist in stabilization
Toralf runs one. Zorry is working on an auto tinderbox too.

-- Jason

> Other suggestions are up to the WG to come up with and write up a final
> report to the council with the summary of these discussions.
> 
> 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.
> 
> -- 
> Kristian Fiskerstrand
> OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> 

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-08-14 23:59 UTC

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2016-08-14 23:59 UTC.

Removals:
dev-libs/mingw-libgnurx  20160813-12:32 dilfridge4ef0633
dev-perl/cache-mmap  20160810-16:12 mgorny   1d5ceec
dev-qt/qtquick1  20160814-11:10 mgorny   8a16421
kde-apps/kgamma  20160809-07:01 johu 43fc375
kde-apps/ksnapshot   20160814-11:12 mgorny   4047253
www-client/luakit20160810-16:13 mgorny   2963b7d

Additions:
dev-libs/libpcre-debian  20160812-22:05 chewi2746de8
dev-libs/mingw-libgnurx  20160810-09:47 vapier   2d5acbf
dev-python/blockdiag 20160809-21:58 dolsen   ced3cb2
dev-python/jsonref   20160809-22:01 dolsen   da96a8a
dev-python/pyicu 20160810-15:08 marecki  87bd745
dev-python/pyjade20160809-22:02 dolsen   a903155
dev-python/ramlfications 20160809-22:17 dolsen   c1a8f12
dev-python/txgithub  20160809-22:07 dolsen   661c66b
dev-python/txrequests20160809-22:05 dolsen   cfffec5
dev-qt/qt3d  20160812-18:36 kensington   24262cb
dev-qt/qtcharts  20160812-18:36 kensington   24262cb
dev-qt/qtdatavis3d   20160812-18:36 kensington   24262cb
dev-qt/qtquickcontrols2  20160812-18:36 kensington   24262cb
dev-qt/qtscxml   20160812-18:36 kensington   24262cb
dev-util/buildbot-console-view   20160809-21:42 dolsen   ab3ca71
dev-util/buildbot-pkg20160809-21:29 dolsen   3f1a63d
dev-util/buildbot-waterfall-view 20160809-21:44 dolsen   b8ef96c
dev-util/buildbot-worker 20160809-21:50 dolsen   1f6e4e9
dev-util/buildbot-www20160809-21:32 dolsen   8fa079f
mate-extra/mate-user-guide   20160811-06:39 NP-Hardass   5703011
media-sound/pamix20160810-16:39 polynomial-c afdee62
sys-apps/hponcfg 20160814-14:40 whissi   c0bf277
sys-apps/qdirstat20160809-17:55 monsieurp547e52a
sys-block/f3 20160814-15:18 whissi   5923229
sys-block/hpssacli   20160812-19:01 whissi   0fe2f15
sys-block/storcli20160812-19:30 whissi   5c1fd2e

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
kde-apps/ksnapshot,removed,mgorny,20160814-11:12,4047253
dev-qt/qtquick1,removed,mgorny,20160814-11:10,8a16421
dev-libs/mingw-libgnurx,removed,dilfridge,20160813-12:32,4ef0633
www-client/luakit,removed,mgorny,20160810-16:13,2963b7d
dev-perl/cache-mmap,removed,mgorny,20160810-16:12,1d5ceec
kde-apps/kgamma,removed,johu,20160809-07:01,43fc375
Added Packages:
sys-block/f3,added,whissi,20160814-15:18,5923229
sys-apps/hponcfg,added,whissi,20160814-14:40,c0bf277
dev-libs/libpcre-debian,added,chewi,20160812-22:05,2746de8
sys-block/storcli,added,whissi,20160812-19:30,5c1fd2e
sys-block/hpssacli,added,whissi,20160812-19:01,0fe2f15
dev-qt/qt3d,added,kensington,20160812-18:36,24262cb
dev-qt/qtcharts,added,kensington,20160812-18:36,24262cb
dev-qt/qtdatavis3d,added,kensington,20160812-18:36,24262cb
dev-qt/qtquickcontrols2,added,kensington,20160812-18:36,24262cb
dev-qt/qtscxml,added,kensington,20160812-18:36,24262cb
mate-extra/mate-user-guide,added,NP-Hardass,20160811-06:39,5703011
media-sound/pamix,added,polynomial-c,20160810-16:39,afdee62
dev-python/pyicu,added,marecki,20160810-15:08,87bd745
dev-libs/mingw-libgnurx,added,vapier,20160810-09:47,2d5acbf
sys-apps/qdirstat,added,monsieurp,20160809-17:55,547e52a
dev-util/buildbot-worker,added,dolsen,20160809-21:50,1f6e4e9
dev-util/buildbot-waterfall-view,added,dolsen,20160809-21:44,b8ef96c
dev-util/buildbot-console-view,added,dolsen,20160809-21:42,ab3ca71
dev-util/buildbot-www,added,dolsen,20160809-21:32,8fa079f
dev-util/buildbot-pkg,added,dolsen,20160809-21:29,3f1a63d
dev-python/ramlfications,added,dolsen,20160809-22:17,c1a8f12
dev-python/txgithub,added,dolsen,20160809-22:07,661c66b
dev-python/txrequests,added,dolsen,20160809-22:05,cfffec5
dev-python/pyjade,added,dolsen,20160809-22:02,a903155
dev-python/jsonref,added,dolsen,20160809-22:01,da96a8a
dev-python/blockdiag,added,dolsen,20160809-21:58,ced3cb2

Done.

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Chris Reffett]

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 such a GLEP ... would they have
>to be part of a defined Project first, or would they form a Working
>Group, and then be stuck in a recursive loop needing themselves
>defined before they can define themselves?

Friendly reminder that anyone may submit a GLEP, it doesn't need to be on 
behalf of an official group. If memory serves, there isn't even a requirement 
that the submitter/"champion" even be a Gentoo dev. So although there is a 
theoretical recursion issue, in practice it's a silly question.

creffett
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Kent Fredric]

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

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Anthony G. Basile]

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 meeting.
> 
> 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?
> 

Seriously?!  You mean a group of devs can't just get together to
brainstorm a problem across projects?

Anyhow, Kristian, I'm in.  Put me on the cc list.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Kristian Fiskerstrand]

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 Council meeting.
> 
> 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?
> 

For this purpose it is an ad-hoc collaboration amongst developers to
come up with recommendations to an already existing project on a limited
set of questions. What would a GLEP contribute?

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Ciaran McCreesh]

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 related to a Project? Shouldn't
there be a GLEP to define what a Working Group is first?

-- 
Ciaran McCreesh

[gentoo-dev] New Working Group established to evaluate the stable tree

[Kristian Fiskerstrand]

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 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 workflow change to introduce a new status, e.g RESOLVED
   NeedsStable (name for illustration purpose only) incentivize
   developers to not close bugs before it is fixed?

 * Are there ways to reduce the stabilization lag of packages
 - looking into the effectiveness of ALLARCHES and its use
 - possibility for maintainer to stabilize packages themselves for
   architectures they have access to (including whether there might
   be a need for changes to gentoo infrastructure to facilitate
   this)
 - Tinderboxing / Automatic tools build test packages and reverse
   dependencies in order to assist in stabilization

Other suggestions are up to the WG to come up with and write up a final
report to the council with the summary of these discussions.

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.

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] repoman: fix erroneous LICENSE.syntax (bug 591184)

[Zac Medico]

On 08/14/2016 08:18 AM, Brian Dolbec wrote:
> On Sat, 13 Aug 2016 16:00:59 -0700
> Zac Medico  wrote:
> 
>> X-Gentoo-bug: 591184
>> X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=591184
>> ---
>>  .../pym/repoman/modules/scan/depend/_depend_checks.py| 16
>> +++- 1 file changed, 7 insertions(+), 9 deletions(-)
> 
> looks good, thanks for the fast fix Zac.
> 

Pushed:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=99d8cdc0e9b011d39ae8537169ce2ca70a4e5f83
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] [PATCH] repoman: fix erroneous LICENSE.syntax (bug 591184)

[Brian Dolbec]

On Sat, 13 Aug 2016 16:00:59 -0700
Zac Medico  wrote:

> X-Gentoo-bug: 591184
> X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=591184
> ---
>  .../pym/repoman/modules/scan/depend/_depend_checks.py| 16
> +++- 1 file changed, 7 insertions(+), 9 deletions(-)
> 
> diff --git
> a/repoman/pym/repoman/modules/scan/depend/_depend_checks.py
> b/repoman/pym/repoman/modules/scan/depend/_depend_checks.py index
> 3f6c93e..f0ae863 100644 ---
> a/repoman/pym/repoman/modules/scan/depend/_depend_checks.py +++
> b/repoman/pym/repoman/modules/scan/depend/_depend_checks.py @@ -27,7
> +27,7 @@ def check_slotop(depstr, is_valid_flag, badsyntax, mytype,
> token_class=portage.dep.Atom) except
> portage.exception.InvalidDependString as e: my_dep_tree = None
> - badsyntax.append(str(e))
> + badsyntax.append((mytype, str(e)))
>  
>   def _traverse_tree(dep_tree, in_any_of):
>   # leaf
> @@ -67,7 +67,7 @@ def _depend_checks(ebuild, pkg, portdb, qatracker,
> repo_metadata): "java-pkg-opt-2" in ebuild.inherited,
>   inherited_wxwidgets_eclass = "wxwidgets" in ebuild.inherited
>   # operator_tokens = set(["||", "(", ")"])
> - type_list, badsyntax = [], []
> + badsyntax = []
>   for mytype in Package._dep_keys + ("LICENSE", "PROPERTIES",
> "PROVIDE"): mydepstr = ebuild.metadata[mytype]
>  
> @@ -83,7 +83,7 @@ def _depend_checks(ebuild, pkg, portdb, qatracker,
> repo_metadata): is_valid_flag=pkg.iuse.is_valid_flag,
> token_class=token_class) except portage.exception.InvalidDependString
> as e: atoms = None
> - badsyntax.append(str(e))
> + badsyntax.append((mytype, str(e)))
>  
>   if atoms and mytype.endswith("DEPEND"):
>   if runtime and \
> @@ -156,13 +156,11 @@ def _depend_checks(ebuild, pkg, portdb,
> qatracker, repo_metadata): check_missingslot(atom, mytype,
> ebuild.eapi, portdb, qatracker, ebuild.relative_path, ebuild.metadata)
>  
> - type_list.extend([mytype] * (len(badsyntax) -
> len(type_list))) -
>   if runtime:
>   check_slotop(mydepstr,
> pkg.iuse.is_valid_flag, badsyntax, mytype, qatracker,
> ebuild.relative_path) 
> - for m, b in zip(type_list, badsyntax):
> + for m, b in badsyntax:
>   if m.endswith("DEPEND"):
>   qacat = "dependency.syntax"
>   else:
> @@ -171,9 +169,9 @@ def _depend_checks(ebuild, pkg, portdb,
> qatracker, repo_metadata): qacat, "%s: %s: %s" %
> (ebuild.relative_path, m, b)) 
>   # data required for some other tests
> - badlicsyntax = len([z for z in type_list if z == "LICENSE"])
> - badprovsyntax = len([z for z in type_list if z == "PROVIDE"])
> - baddepsyntax = len(type_list) != badlicsyntax + badprovsyntax
> + badlicsyntax = len([z for z in badsyntax if z[0] ==
> "LICENSE"])
> + badprovsyntax = len([z for z in badsyntax if z[0] ==
> "PROVIDE"])
> + baddepsyntax = len(badsyntax) != badlicsyntax + badprovsyntax
>   badlicsyntax = badlicsyntax > 0
>   #badprovsyntax = badprovsyntax > 0
>  

looks good, thanks for the fast fix Zac.

-- 
Brian Dolbec 

Re: [gentoo-dev] Empty project: LXDE

[Pacho Ramos]

El sáb, 13-08-2016 a las 22:39 -0700, Hanno Böck escribió:
> Ok, so it seems I'm currently the only one interested.
> 
> While the wiki page lists no other devs, there are two more devs
> listed
> in the email alias, yet they haven't replied to my questions whether
> they consider themselve still part of the project.
> 
> I'll take over the project now and will start committing latest
> upstream
> updates piece by piece.
> 
> Not sure if there's any long term future for LXDE, but for the time
> being I'll take care of it.
> 

When looking to bugs assigned to the team I found some people willing
to help via proxy-maint too... you should be CCed by me in that bug
report for being aware :)

Thanks for joining the team!