path: root/meeting-logs/20160814.txt

2016-08-14 20:59:45<@K_F>  4 1) Roll call
2016-08-14 20:59:58 * K_F is here
2016-08-14 21:00:08 * dilfridge feeds blueness a razz berry
2016-08-14 21:00:08 * rich0 is here
2016-08-14 21:00:12 * dilfridge here
2016-08-14 21:00:17 * WilliamH here
2016-08-14 21:00:34 * blueness here
2016-08-14 21:00:36 * ulm here
2016-08-14 21:01:04 * jlec here
2016-08-14 21:01:27<@K_F> So, the only non-standard item on today's agenda is 2) Discussion on the state of the stable tree[0]
2016-08-14 21:01:35<@K_F> https://archives.gentoo.org/gentoo-project/message/fb5d6fe4d6f84eeb5fedff2e968675fb
2016-08-14 21:01:54<@K_F> WilliamH: since you proposed the item, do you want to have a short introduction on what your focus is?
2016-08-14 21:02:04<@WilliamH> K_F: sure.
2016-08-14 21:02:37<@WilliamH> K_F: Basically, our stable tree is firmly stuck in the past, because arch teams, including amd64 these days, are having difficulty keeping up.
2016-08-14 21:03:00<@WilliamH> My focus isn't on getting rid of arch teams or changing what they do.
2016-08-14 21:03:28<@WilliamH> Our past decision on the  issue was that after a package sits in ~, with an open stable request for 90 days,
2016-08-14 21:03:36<@WilliamH> and no arch teams respond,
2016-08-14 21:03:48<@WilliamH> the maintainer can remove the old stable version.
2016-08-14 21:04:01<@WilliamH> That hasn't played well because it breaks the depgraph etc.
2016-08-14 21:04:18<@blueness> WilliamH: i can speak for ppc/ppc64, arm and mips
2016-08-14 21:04:54<@WilliamH> blueness: ok, I want to say one more thing first. :-)
2016-08-14 21:04:58<@blueness> sure
2016-08-14 21:05:34<@WilliamH> blueness: What I'm interested in finding is a way for maintainers to move forward after  stable reqs sit around for a long time so that the stable tree can be more current...
2016-08-14 21:05:56<@WilliamH> maybe allowing maintainers to stabilize the newer versions where the older versions are stable...
2016-08-14 21:05:56<@rich0> In the case of amd64, maintainers are already allowed to stabilize as long as the general requirements are met.
2016-08-14 21:06:08<@K_F> I have a few questions to that, but blueness was first so go ahead :)
2016-08-14 21:06:16<@ulm> rich0: we could generalise that rule to all archs
2016-08-14 21:06:19<@WilliamH> blueness: go for it.
2016-08-14 21:06:41<@blueness> i was just saying that i can speak for those teams, but i don’t have much to add specifically
2016-08-14 21:06:44<@ulm> i.e. if the maintainer has access to such a machine, he's allowed to stabilise himself
2016-08-14 21:07:07<@WilliamH> ulm: That's actually not even officially a rule for amd64.
2016-08-14 21:07:08<@blueness> personally i’d like to schedule packages for auto stabilization and then just walk away
2016-08-14 21:07:12<@blueness> ie automate
2016-08-14 21:07:18<@dilfridge> I can add a small datapoint -
2016-08-14 21:07:19<@rich0> ulm: access to such a machine would be the tricky part for all but amd64, but I'm fine with generalizing if they actually test it.
2016-08-14 21:07:34<@dilfridge> ALLARCHES does not work as designed, since most arch teams happily ignore it
2016-08-14 21:07:43< Blackb|rd> The thing about auto-stabilization is that the threshold matters. is 1.2->1.3 significant or not? That very much depends on the package.
2016-08-14 21:07:47<@WilliamH> ulm: the dev manual says that everything goes through the arch teams.
2016-08-14 21:07:48<@jlec> I maintained quite a bunch of packages and I really liked to offload the stabilization to another team
2016-08-14 21:07:51<@ulm> rich0: well, the maintainer cannot declare that things are stable without actually testing it
2016-08-14 21:07:56<@dilfridge> which, then, adds to the load of subsequent arches
2016-08-14 21:08:15<@jlec> Automated testing would be a good step towards simplification
2016-08-14 21:08:41<@blueness> jlec: automation may be difficult because the dependency tree is deep
2016-08-14 21:08:42<@rich0> dilfridge: one solution to the ALLARCHES problem might be automation.  If some bot notices one arch stable, it auto-stabilizes the rest.
2016-08-14 21:08:56<@dilfridge> rich0: yes, that is doable
2016-08-14 21:09:02<@K_F> My question/comment is to the way of, the impact of this seems to be very dependent on context so I'm not sure a single solution can necessarily work, but there are several things I'd like to discuss about stable tree in general. very important thing is what impact does keeping the old version vs the new version have on stability, say for a server application
2016-08-14 21:09:09< Blackb|rd> jlec: that depends on hw availability which is basically zero for most fringe archs
2016-08-14 21:09:14<@jlec> blueness: we could at least automate testing like the arch teams aredoing it right now
2016-08-14 21:09:16<@dilfridge> rich0: right now I occasionally do that from the maintainer point of view
2016-08-14 21:09:21<@rich0> In general I'm open to doing things to reduce barriers to testing and stabilization, but I'm not a fan of skipping testing.
2016-08-14 21:09:22<@K_F> should we have same treatment for apache/nginx/etc as for a leaf-application in the tree?
2016-08-14 21:10:06<@K_F> and is the primary issue with the stable tree that applications aren't being stabilized quick enough, or actual bugs being allowed into the stable tree to begin with?
2016-08-14 21:10:17<@jlec> Blackb|rd: true, but at least x86/amd64 could benefit
2016-08-14 21:10:25<@K_F> in which case, will automation or quick stabilization by maintainer have a positive or negative contribution on the issue
2016-08-14 21:11:03<@WilliamH> My question about "fringe" arches is, should they be marked stable in their profiles?
2016-08-14 21:11:09<@K_F> for a lot of cases I'm in favor of allowing maintainer to stabilize, presuming that the maintainer is actually a person that is expected to USE the application more than you can expect others
2016-08-14 21:11:27<@dilfridge> WilliamH: that's yet another question
2016-08-14 21:11:29<@K_F> so they should be most aware of current issues, tracking upstream bugtracker and VCS already
2016-08-14 21:11:40<@dilfridge> and "stable profile" is actually completely unrelated to "stable testing"
2016-08-14 21:12:08<@WilliamH> dilfridge: stable profile means that repoman by default complains if their depgraph is broken.
2016-08-14 21:12:12< Blackb|rd> WilliamH: the problem wiht "not stable" is that is the equivalent of "moribund"
2016-08-14 21:12:16<@rich0> WilliamH: what will de-stabilizing the minor archs solve?
2016-08-14 21:12:29<@rich0> Are you concerned about burden on maintainers?
2016-08-14 21:12:32<@dilfridge> WilliamH: yes, and I think that might be useful even for ~arch only arches
2016-08-14 21:12:44<@dilfridge> so we need to redefine and improve that portage feature,
2016-08-14 21:12:51<@WilliamH> rich0: correct.
2016-08-14 21:12:54<@dilfridge> but it has nothing to do with out current arch testing problem
2016-08-14 21:13:05<@WilliamH> True, maybe that's a red herring...
2016-08-14 21:13:11<@WilliamH> dilfridge: ^^
2016-08-14 21:13:19<@jlec> With the small size of our dev team "stable" becomes really important, because we cannot guarantee that ~arch packages are well looked after and bugs are fixed. On the other hand, if bugs are fixed in arch, we need ot bring it stable
2016-08-14 21:13:27<@dilfridge> f.ex., it would make sense to keep the ~mips tree consistent
2016-08-14 21:13:31<@WilliamH> So let's go back to the arch testing...
2016-08-14 21:13:36<@dilfridge> but there is no "profile setting" for that
2016-08-14 21:13:44<@WilliamH> K_F: I need to clarify your position.
2016-08-14 21:14:09<@WilliamH> K_F: You are talking about allowing maintainers to stabilize.
2016-08-14 21:14:10< Blackb|rd> And from a personnel POV, I have been keeping Alpha mostly-current mostly by myself. While not sustainable, it also means that the effort for keeping an arch somewhat-current is not insurmountable
2016-08-14 21:14:23<@K_F> jlec: yes, that is a sub-point of mine: I'd like us to consider a formal suggestion that bugs should normally not be marked as resolved/fixed before a version including the fix has been included in the stable tree. In the interim the InVCS keyword is used to mark a fix having been applied to non-stable.
2016-08-14 21:14:38<@WilliamH> K_F: are you saying that maintainers can stable on any arch or just the ones they have access to?
2016-08-14 21:14:41<@K_F> jlec: but we can come back to that later on, along with ulm's suggestion
2016-08-14 21:14:45<@dilfridge> A] The current bugzilla usage is b0rken, since me and many others close bugs when the fix is in ~arch - for the simple reason that I dont want to keep a huge number of "unresolved bugs" until arch teams wake up
2016-08-14 21:14:59<@K_F> WilliamH: they have access to directly or via gentoo infra made available for the purpose
2016-08-14 21:15:13<@K_F> or for that matter non-gentoo infra
2016-08-14 21:15:13<@blueness> how hard would it be to write a utility that finds ebuilds that are ~arch, older than 1 month, and email the maintainers periodic reminders to stabilize them?
2016-08-14 21:15:23<@dilfridge> suggestion for A] -> introduce a new status TESTING (instead of the InVCS keyword)
2016-08-14 21:15:35< Blackb|rd> dilfridge: would it be useful to discern solved-in-~ vs. soved in stabvle?
2016-08-14 21:15:44<@ulm> there is TEST-REQUEST already
2016-08-14 21:15:45<@dilfridge> then a bug goes CONFIRMED -> TESTING -> RESOLVED FIXED
2016-08-14 21:16:01<@WilliamH> ulm: that's also resolved.
2016-08-14 21:16:05<@jlec> dilfridge: or we could have a procedure to add the package automatically to an official stabilization backlog
2016-08-14 21:16:08<@K_F> dilfridge: that can be worth discussing, but atm we have the InVCS for the purpose and it should be used until another suggestion is in place
2016-08-14 21:16:20<@WilliamH> ulm: maybe that's ok though... because then it would go to resolved/fixed
2016-08-14 21:16:20<@K_F> dilfridge: but if it works better for workflow to have another status, I'm fine with that
2016-08-14 21:16:25<@jlec> Currently testing means we send the fix back to user to test
2016-08-14 21:16:26<@dilfridge> K_F: it's not going to be used, since noone wants his open bugs list to explode
2016-08-14 21:16:29<@K_F> the main issue is the bug should not simply be marked resolved
2016-08-14 21:16:44<@K_F> dilfridge: its easy to filter out in search, I have different lists for with and without it myself
2016-08-14 21:16:46<@jlec> We will not change this behaviour
2016-08-14 21:16:51<@ulm> WilliamH: sure, since bug resolution is independent of stable status
2016-08-14 21:16:52<@dilfridge> Blackb|rd: that's what I propose
2016-08-14 21:16:54<@jlec> We need to come up with somethign new
2016-08-14 21:17:02<@WilliamH> K_F:  you have to mark it resolved/test-request
2016-08-14 21:17:13<@WilliamH> K_F: which makes sense...
2016-08-14 21:17:20<@ulm> especially, stable status is arch dependent, whereas bug resolution (usually) isn't
2016-08-14 21:17:22<@WilliamH> K_F: then it would go to resolved/fixed
2016-08-14 21:17:22<@K_F> jlec: yes, I believe we need to introduce a new status entry called NEED_STABILIATION or something else explicit if we go that route
2016-08-14 21:17:25<@dilfridge> ulm: RESOLVED TEST-REQUEST means "I need more data, cant do anything now"
2016-08-14 21:17:39<@ulm> that's NEEDINFO
2016-08-14 21:18:00<@dilfridge> well a variant of that, but yes essentially it's a close relative
2016-08-14 21:18:22<@jlec> To me TEST-REQUEST means , I fixed it, please test if the fix helps you as well
2016-08-14 21:18:28<@blueness> RESOLVED TEST-REQUEST means you think the issue is resolved but would like testing
2016-08-14 21:18:29<@dilfridge> "here's a patch, I have no clue if it works, tell me!"
2016-08-14 21:18:36<@jlec> So normally I leave it like this if nothing comes back
2016-08-14 21:18:41<@ulm> jlec: right, and TEST-REQUEST says that the fix is in the tree
2016-08-14 21:18:42<@jlec> Too many bugs to fix
2016-08-14 21:18:47<@jlec> yes
2016-08-14 21:18:52<@jlec> but not stable
2016-08-14 21:18:56 * WilliamH agrees with blueness
2016-08-14 21:19:11<@K_F> yeah, we shouldn't overload current workflow to mean anything else
2016-08-14 21:19:15<@rich0> I think there are a lot of ideas, and they probably should be pursued on thier own merits/etc.
2016-08-14 21:19:18<@dilfridge> so how about, for clarification let's rename TEST-REQUEST to TESTING ?
2016-08-14 21:19:33<@rich0> Incrementally they would probably help.
2016-08-14 21:19:33<@dilfridge> to make clear "it's resolved in testing"
2016-08-14 21:19:34<@jlec> no
2016-08-14 21:19:35<@K_F> dilfridge: is there actually a need to rename it?
2016-08-14 21:19:47<@K_F> dilfridge: TEST-REQUEST seems more intuitive to users
2016-08-14 21:19:51<@WilliamH> No, there's no need to rename
2016-08-14 21:19:51<@dilfridge> yes, since everyone seems to have a different idea what it means
2016-08-14 21:20:12<@jlec> We need something new. Anyttihng close to what we have will not owrk, because people will abuse to have the same behaviour as right now
2016-08-14 21:20:27<@blueness> dilfridge: you just need a better explanation in the tip on bugzilla
2016-08-14 21:20:29<@dilfridge> in my opinion it's similar to RESOLVED OBSOLETE, it's not clear if the issue is actually resolved but maybe someone will test
2016-08-14 21:20:45<@K_F> TEST-REQUEST
2016-08-14 21:20:46<@K_F>     The bug is thought to be fixed, but we would like someone who is affected to verify the fix. If the bug is not actually fixed, then the report should be reopened and more details posted (explaining why people believe the bug is not actually fixed). 
2016-08-14 21:20:48 * WilliamH agrees w/ blueness 
2016-08-14 21:21:04<@K_F> the description seems rather non-ambiguative to me
2016-08-14 21:21:09<@ulm> we could use RESOLVED -> CLOSED when the ebuild enters stable
2016-08-14 21:21:19<@dilfridge> K_F: ok but this ^ has no relation to ~arch statis
2016-08-14 21:21:27<@WilliamH> True.
2016-08-14 21:21:27<@K_F> dilfridge: I'm not saying it is, or should be
2016-08-14 21:21:44<@K_F> but I wouldn't want to overload the old behavior, as having that is useful in the workflow
2016-08-14 21:21:44<@WilliamH> let's go back to moving packages to stable...
2016-08-14 21:22:06<@WilliamH> Right now, things can set infinitely waiting for arch teams to wake up and move them to stable.
2016-08-14 21:22:26<@blueness> i’m not sure how this helps with stabilization
2016-08-14 21:22:29<@blueness> i’d like to think about what proceedure we could use to automate stabilization
2016-08-14 21:22:30<@blueness> i did a lot of stabilizations for ppc/ppc64 in 2012 and it was boooooring
2016-08-14 21:22:31<@K_F> WilliamH: right, and whether that is an issue or not depends on context, e.g is this a library that is required to add another package?
2016-08-14 21:22:31<@blueness> i fatigued quickly and probably made lots of mistakes
2016-08-14 21:22:34<@WilliamH> Is that stil what we want?
2016-08-14 21:22:34<@jlec> We need an easy marker devs can set when closing the bug
2016-08-14 21:22:48<@dilfridge> see Perl... 5.22.2 is supposed to go stable for ages (also sec fix), soon we'll have 5.22.3 with the next bunch of sec fixes
2016-08-14 21:23:39<@WilliamH> Also, see as an example, the kmod stablereq that is open.
2016-08-14 21:23:40<@K_F> blueness: the problem I see with automating stabilization is that upstreams don't necessarily have sufficient unit tests written, so it'd require a lot of downstream work, in particular for GUI applications
2016-08-14 21:24:14<@K_F> blueness: as I don't consider stable process to be build-testing only
2016-08-14 21:24:30<@WilliamH> K_F: imo, that's what the wait in ~arch is for.
2016-08-14 21:24:34<@blueness> K_F: we might have to compromise
2016-08-14 21:24:58<@K_F> blueness: and then it comes back to what is the consequence of waiting, is it other packages being held up, or simply stable being a bit behind
2016-08-14 21:25:17<@K_F> my personal opinion is having an older version that is bug-free and security-wise good, is no issue in itself
2016-08-14 21:25:19<@dilfridge> as long as something is moving, I have no problem with a slightly antiquated stable
2016-08-14 21:25:25<@blueness> K_F: we could semi automate
2016-08-14 21:25:27<@blueness> so
2016-08-14 21:25:32<@dilfridge> just now the ~arch versions are usually more bug-free
2016-08-14 21:25:43<@ulm> I suspect that on some arches waiting for one month doesn't even ensure that even a single user has run the package
2016-08-14 21:25:43<@blueness> a utility would scan the tree for 1 month old ~arch foreach arch
2016-08-14 21:25:48<@WilliamH> K_F: ^^
2016-08-14 21:26:00<@K_F> dilfridge: which is bad, but I belive that comes down to making a statement on closing bugs before it hits stable as we've already started discussing
2016-08-14 21:26:01<@blueness> it would then find all the deps that also need to be stabilized
2016-08-14 21:26:09<@blueness> and email that list to the maintainers
2016-08-14 21:26:10<@K_F> dilfridge: not simply auto-stabilizing more
2016-08-14 21:26:15<@blueness> just that alone would speed things up
2016-08-14 21:26:36<@K_F> blueness: more tools to that extent can only be a good thing
2016-08-14 21:26:37<@dilfridge> here's more food for thought
2016-08-14 21:26:38<@blueness> i personally am lost on all my pkgs that need stabilization
2016-08-14 21:26:58<@WilliamH> That's my problem too. I'm as guilty as the next guy of not filing stablereqs
2016-08-14 21:27:02<@dilfridge> B] ALLARCHES isnt working since arch teams are ignoring it, to the disadvantage of the next arch team down the line
2016-08-14 21:27:06<@blueness> K_F: then in ppc/ppc64 i could just feed that list to anohter utility and if the build boom done
2016-08-14 21:27:10<@dilfridge> sorry said that already
2016-08-14 21:27:29<@dilfridge> but we could automatize that, true
2016-08-14 21:27:37<@K_F> blueness: if build-testing is only criteria.. which is a big "if"
2016-08-14 21:27:54<@dilfridge> C] does anyone know what the status of the GSoC project is? it's kinda relevant...
2016-08-14 21:28:09<@jlec> no
2016-08-14 21:28:30<@dilfridge> sigh
2016-08-14 21:28:31<@K_F> blueness: in that case, I'd expect a different treatment for a patch release vs a minor/major release, but with upstreams not doing proper branching, that itself is difficult to gauge and to a great extent is maintainer discretion as they should know best by following the package development closely
2016-08-14 21:28:48 * dilfridge drops GSoC and pulls the flush
2016-08-14 21:29:02<@K_F> dilfridge: I'm getting the update emails at least
2016-08-14 21:29:20<@blueness> K_F: generating a list and even automating the compile-test part of it is a step in the right direction
2016-08-14 21:29:49<@WilliamH> I've also heard maintainers say they don't stabilize unless someone asks them to.
2016-08-14 21:29:56<@K_F> "The week was spent in testing, running the deployed server 24x7 with stabilization requests automated to be triggered on Travis CI every 15 minutes for around 4 days. I am currently working on creating an automated overlay of all ebuilds that are successfully stabilized, as well as completing the documentation of the code."
2016-08-14 21:30:31<@K_F> blueness: that is what the GSoC project is doing
2016-08-14 21:30:38<@blueness> K_F: yep
2016-08-14 21:30:40<@blueness> sounds good
2016-08-14 21:30:54<@blueness> we should hijack this person :)
2016-08-14 21:30:54<@WilliamH> it doesn't need to worry about overlays.
2016-08-14 21:31:09<@blueness> WilliamH: well right now he has to work in overlays
2016-08-14 21:31:16<@WilliamH> blueness: True.
2016-08-14 21:32:07<@WilliamH> I guess what I'm asking for is a way to stabilize newer versions on all arches where an older version is stable if the arch teams don't wake up and do it in a reasonable amount of time.
2016-08-14 21:32:19<@K_F> WilliamH: that is a bit worrying, if they have known issues in bug reports that should not have been marked closed without stabilization, and they don't stabilize, the state of stable tree is negatively affected
2016-08-14 21:32:26<@blueness> K_F: is his work bound to just amd64?
2016-08-14 21:32:45<@K_F> WilliamH: so not allowing a resolve fixed before it being in stable tree should incentivize maintainers to create stablereqs
2016-08-14 21:33:01<@K_F> blueness: afaik atm only amd64, but that should be possible to extend
2016-08-14 21:33:10<@K_F> need to start somewhere
2016-08-14 21:33:31<@WilliamH> The devmanual should be updated probably with any new guidelines we come up with.
2016-08-14 21:33:32<@blueness> K_F: travis ci may not permit ppc64 etc
2016-08-14 21:33:46<@K_F> I guess it'd be similar to debian buildhosts etc and checking the build status
2016-08-14 21:34:10<@K_F> blueness: well, if the control machine is running on a different host than the actual build host that should be able to fix anyways, shouldn't it?
2016-08-14 21:34:34<@dilfridge> right
2016-08-14 21:34:36<@K_F> could use one control for all arches in theory, and parse logs etc
2016-08-14 21:34:45<@dilfridge> we're effectively talking about an official tinderbox system
2016-08-14 21:34:45<@blueness> K_F: not sure
2016-08-14 21:34:51<@K_F> dilfridge: right
2016-08-14 21:35:31<@K_F> on that note I'd like to add that toralf is doing a great job on it for amd64 already
2016-08-14 21:35:50<@WilliamH> K_F: agreed, he is.
2016-08-14 21:36:21<@dilfridge> yes, he is
2016-08-14 21:36:31<@dilfridge> so the interesting question is
2016-08-14 21:36:50<@dilfridge> if tinderboxing is to become such a central part of all our workflow
2016-08-14 21:37:00<@ulm> my impression is that he's mainly finding broken reverse dependencies
2016-08-14 21:37:13<@K_F> ulm: that is a good thing to fix on its own, though
2016-08-14 21:37:14<@ulm> but not so many original issues
2016-08-14 21:37:19<@ulm> K_F: sure
2016-08-14 21:37:21<@dilfridge> can we do that with only "inofficial systems"?
2016-08-14 21:37:40<@K_F> dilfridge: my perspective on that is no, if we are to go that route it would need to be official gentoo infra
2016-08-14 21:37:56 * dilfridge suggests we then pass on to the open floor.
2016-08-14 21:38:09<@K_F> dilfridge: bugs with council involvement etc first
2016-08-14 21:38:16<@dilfridge> hrhr
2016-08-14 21:38:29<@K_F> dilfridge: but you propose we don't make any actual resolutions today and keep it open for discussion on -dev?
2016-08-14 21:38:40<@dilfridge> that wasnt fully serious
2016-08-14 21:38:46<@WilliamH> Also, I do think we need to clarify the devmanual wrt stabilization.
2016-08-14 21:38:51<@WilliamH> https://devmanual.gentoo.org/keywording/index.html
2016-08-14 21:39:05<@WilliamH> states that only arch teams can do it.
2016-08-14 21:39:18<@dilfridge> I also like the suggestion by jmorgan to found a project / group / taskforce to work out solutions
2016-08-14 21:39:37<@WilliamH> We even have a separate glep that says x86 is like all other arches.
2016-08-14 21:39:55<@blueness> K_F: dilfridge yeah let’s generate discussion on -dev
2016-08-14 21:40:06<@WilliamH> In the meantime, what do we do?
2016-08-14 21:40:16<@dilfridge> only discussion on -dev probably doesnt help
2016-08-14 21:40:53<@K_F> dilfridge: well, it'd be in preparation for another council meeting in order to have some concrete voting points
2016-08-14 21:41:00<@blueness> WilliamH: i suggest we think of some well defined workflow
2016-08-14 21:41:07<@K_F> such as not allowing to close bugs as being resolved fixed before it is in stable
2016-08-14 21:41:08<@blueness> and then bring it foward to -dev
2016-08-14 21:41:11<@dilfridge> yes, but after some brainwork
2016-08-14 21:41:28<@K_F> but what workflow is best for that, if people don't like the current InVCS and would like a separate status entry, is good to discuss
2016-08-14 21:41:34<@WilliamH> K_F: I don't think that can apply for hosted projects.
2016-08-14 21:41:54<@WilliamH> K_F: actually it doesn't.
2016-08-14 21:41:55<@K_F> WilliamH: that should be a separate project, so not impact the package part of things
2016-08-14 21:42:10<@K_F> WilliamH: but correct, it should be limited to the scope of the Gentoo repository/tree
2016-08-14 21:42:34<@K_F> although that will likely require a few duplicate bug reports, filing stable requests etc
2016-08-14 21:42:42<@K_F> but a good thing to discuss on -dev
2016-08-14 21:43:26<@WilliamH> K_F: so what do we do in the meantimne w/ stuck stable requests... like the one I cited...
2016-08-14 21:43:51<@blueness> WilliamH: what do you suggest we do?
2016-08-14 21:43:55<@dilfridge> I fear that making more patchwork out of policies doesnt help...
2016-08-14 21:43:57<@K_F> WilliamH: it depends on what issue the "stuck stable request" cause, which at this point seems to be a per-request basis
2016-08-14 21:44:17<@WilliamH> dilfridge: true, what do you suggest?
2016-08-14 21:45:25<@dilfridge> continue this discussion outside the meeting for more "radical solutions", including more interested parties
2016-08-14 21:45:30<@K_F> well, I don't believe we'll come to any conclusions today, so I propose I write an email to -dev over next few days to start a thread on discussion on a few related issues, and then we can bring it back up on a later meeting
2016-08-14 21:45:45<@dilfridge> come up with some ideas, propose them on -dev
2016-08-14 21:45:52<@K_F> with specific questions to vote on
2016-08-14 21:45:56<@dilfridge> and develop some new system until the next council meeting
2016-08-14 21:46:01<@dilfridge> so we can vote on it
2016-08-14 21:46:32<@WilliamH> Let's go for that. I do think our policy is a mess, it should be much more simple than it is.
2016-08-14 21:46:33<@dilfridge> but it needs to be realistic, so anything requiring gentoostats is (for now) off the table :P
2016-08-14 21:46:45 * WilliamH agrees with dilfridge 
2016-08-14 21:47:05<@WilliamH> We can't depend on vaporware.
2016-08-14 21:47:55<@dilfridge> kent\n also had some nice ideas on the list, but they are one order of magnitude larger than what we can do in a month...
2016-08-14 21:47:59<@K_F> so, anyone want to bring up something else on this matter in this meeting, or should be move on to next agenda item?
2016-08-14 21:48:15<@K_F> s/be/we/
2016-08-14 21:48:21-!- mode/#gentoo-council [+o blueness] by ChanServ
2016-08-14 21:48:21<@jlec> we should move on.
2016-08-14 21:48:26<@dilfridge> K_F: shall we make some sort of resolution to start up a stabilization task force? :)
2016-08-14 21:48:36<@dilfridge> like jmorgan suggested...
2016-08-14 21:49:07<@K_F> dilfridge: I'm not sure if I'm ready for any funded approach yet, but setting up a workgroup to come with a proposal to council would be fine with me. I'd even volunteer to run it
2016-08-14 21:49:24<@dilfridge> whee a volunteer :D
2016-08-14 21:49:32<@WilliamH> ;-)
2016-08-14 21:50:04<@WilliamH> K_F: I don't think we need a vote for that, just go for it. :-)
2016-08-14 21:50:16<@K_F> WilliamH: well, a vote would be good to get a mandate to work on it
2016-08-14 21:50:24<@K_F> but depends on how bureaucratic we want to be
2016-08-14 21:50:40 * WilliamH doesn't see anyone objecting...
2016-08-14 21:51:16<@K_F> if nobody is objecting I can set up such a working group, to come back with a proposal for the council at a later meeting (not necessarily next one, depends on the discussions etc) and write up a short report with discussion items etc
2016-08-14 21:51:29<@dilfridge> ++
2016-08-14 21:51:34<@K_F> and start it off asking for participants on -dev (and -dev-announce) MLs 
2016-08-14 21:51:40<@ulm> +1
2016-08-14 21:52:07<@rich0> ++
2016-08-14 21:52:17<@WilliamH> ++
2016-08-14 21:52:35<@K_F> ok, sounds good then. next item: Bugs with council participation[1]
2016-08-14 21:52:51 * dilfridge sneaks off
2016-08-14 21:52:51<@K_F> https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&email2=council%40gentoo.org&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&list_id=3253044&query_format=advanced
2016-08-14 21:52:58<@K_F> dilfridge: bye
2016-08-14 21:53:10<@K_F> I don't actually see any bugs we haven't discussed previously or that seems to merit action at this point
2016-08-14 21:53:20<@K_F> anyone disagree and would like to discuss any?
2016-08-14 21:53:48<@jlec> no, We have seen them before
2016-08-14 21:54:15<@blueness> sounds good
2016-08-14 21:54:15<@blueness> i don’t want to discuss games
2016-08-14 21:54:28 * dilfridge back
2016-08-14 21:54:39<@K_F> I'm opening up the floor then for the last agenda item
2016-08-14 21:54:45<@dilfridge> actually w/r to games a lot is happening, so no worry there
2016-08-14 21:54:45<@ulm> well, some of these bugs require e.g. infra action
2016-08-14 21:55:01<@K_F> ok, holding off on that, ulm any particular you'd like to discuss?
2016-08-14 21:55:06<@WilliamH> dilfridge: yeah, wizardedit is doing a lot of games work for one. :-)
2016-08-14 21:55:09<@ulm> but nothing has happened since several months
2016-08-14 21:55:25<@K_F> ulm: would that be bug 565566 ?
2016-08-14 21:55:28< willikins> K_F: https://bugs.gentoo.org/565566 "New ChangeLogs are in chronological order"; Gentoo Infrastructure, CVS/SVN/Git; CONF; patrick:infra-bugs
2016-08-14 21:55:43<@ulm> K_F: right
2016-08-14 21:55:50<@WilliamH> That's waiting for infra
2016-08-14 21:55:57<@K_F> and bug 577722
2016-08-14 21:55:59< willikins> K_F: https://bugs.gentoo.org/577722 "Multiple packages have broken Manifest"; Gentoo Infrastructure, CVS/SVN/Git; CONF; patrick:infra-bugs
2016-08-14 21:56:15<@dilfridge> that is a really annoying one
2016-08-14 21:56:20<@K_F> of those two, if we are to discuss, the latter is likely most important to fix, as it causes user brakage
2016-08-14 21:56:42<@K_F> but afaik there have been some action by infra to mitigate it already, including the clock skew requirements
2016-08-14 21:56:44<@WilliamH> That's also waiting for infra I think?
2016-08-14 21:57:30<@dilfridge> it's a bit like "waiting for a complicated solution to be deployed while most breakage would be removed by just dropping stuff", right?
2016-08-14 21:57:47<@WilliamH> dilfridge: I think so...
2016-08-14 21:57:50<@K_F> dilfridge: dropping?
2016-08-14 21:57:52<@ulm> same for changelogs
2016-08-14 21:57:57<@K_F> well, for changelogs, yes
2016-08-14 21:57:58<@dilfridge> dropping changelogs
2016-08-14 21:58:02<@K_F> but not for broken manifests
2016-08-14 21:58:03<@WilliamH> changelogs are supposed to be dropped.
2016-08-14 21:58:14<@WilliamH> We made that decision before the migration.
2016-08-14 21:58:33<@K_F> although if the issue with manifests is historical, maybe touching the full repo would remove all the old issues, and the git time skew requirement removes further issues?
2016-08-14 21:58:33<@ulm> I mean, if I read "pending having a good historical conversion of CVS->Git" then that sounds like it will never happen
2016-08-14 21:58:59<@dilfridge> the git skew requirement is a pain if you work with the laptop
2016-08-14 21:59:01<@K_F> (touching full repo for manifests anyways)
2016-08-14 21:59:08<@K_F> dilfridge: works fine for me
2016-08-14 21:59:55<@K_F> granted I do rather forceful ntp synch from time to time getting back from hibernation, and don't see much issue with that, anything that requires accurate cron etc is running on stable architecture
2016-08-14 22:00:03<@WilliamH> dilfridge: can you explain more about that? I'm thinking that all you have to do is use npt?
2016-08-14 22:00:17<@WilliamH> mtp *
2016-08-14 22:00:26<@dilfridge> 1) I prefer my machine without open ports, since it ends up on all sorts of networks
2016-08-14 22:00:48<@dilfridge> 2) I can't do automated ntpdate, since at a random point in time it's not clear if the laptop has a network
2016-08-14 22:01:24<@dilfridge> well I probably could if I just ignore the errors :/
2016-08-14 22:01:25<@K_F> dilfridge: well, I do it in script while bringing up VPN, at which point I'm sure I have a network and have logged into it etc
2016-08-14 22:01:57<@dilfridge> and then you push your previous commits and poof ....
2016-08-14 22:02:21<@dilfridge> (or not?)
2016-08-14 22:02:26 * dilfridge confuserated
2016-08-14 22:02:31<@dilfridge> anyway
2016-08-14 22:02:35<@K_F> works fine, but I bring up VPN for things early in process anyways
2016-08-14 22:02:36<@dilfridge> this is not so important for now
2016-08-14 22:02:48<@K_F> but I don't see us comming up with a resolution for any of these bugs today
2016-08-14 22:03:05<@K_F> and it is being worked on as I've seen, so don't believe council action is merited at this point
2016-08-14 22:03:19<@K_F> but it is annoying
2016-08-14 22:03:24<@K_F> if it is user breaking 
2016-08-14 22:04:04<@K_F> so, anyone have anything to add, or should be move on to open floor?
2016-08-14 22:05:20<@jlec> let's move on
2016-08-14 22:05:30<@K_F> 4) Open floor
2016-08-14 22:05:44<@K_F> any member of the community want to add something to the discussion or bring up any issues for debate?
2016-08-14 22:06:07<@dilfridge> do we want to talk about the maintainer-needed additions to the tree today, or do we put it on the agenda for next time?
2016-08-14 22:06:24<@K_F> point of procedure, nothing will be decided in open floor, if something requires a vote it should be brought up during call for agenda items for a proper council preparation
2016-08-14 22:06:31<@dilfridge> ok
2016-08-14 22:06:50<@K_F> but we can have an informal discussion on it if no other member has anything to bring up at this time
2016-08-14 22:07:14<@K_F> (member of the community, not restricted to council)
2016-08-14 22:07:34<@WilliamH> I don't know what the additions were, but it has never been cool to drop a package directly in with maintainer-needed status.
2016-08-14 22:07:43<@K_F> WilliamH: ++
2016-08-14 22:07:51<@dilfridge> WilliamH++
2016-08-14 22:08:19<@jlec> There is a typical candidate for this behaviour
2016-08-14 22:08:19<@K_F> dilfridge: that specific commit you're thinking of was reverted, right?
2016-08-14 22:08:28<@dilfridge> yes, by me
2016-08-14 22:08:28<@rich0> Agree.  I think that is basically existing policy.
2016-08-14 22:09:46<@blueness> i’m a bit confused, can you guys give me context, what pkg was dropped directly to maintainer-needed and what is the correct procedure?
2016-08-14 22:09:59<@K_F> blueness: not dropped to, new package added
2016-08-14 22:10:11<@blueness> oh added directly to maintainer-needed!
2016-08-14 22:10:15<@blueness> yeah that’s just wierd
2016-08-14 22:10:18<@WilliamH> blueness: right, a new package was added to the tree, but with no maintainer.
2016-08-14 22:10:49<@blueness> why would anyone add a package with no maintainer, that’s like adding lint on purpose
2016-08-14 22:11:04<@WilliamH> blueness: when something new is added, someone, or a project, is supposed to sign up to maintain it.
2016-08-14 22:11:25<@WilliamH> blueness: hang on I'll look for the commit hash
2016-08-14 22:11:26<@blueness> WilliamH: of course, i’m just wonder why this isn’t common sense
2016-08-14 22:11:35<@WilliamH> blueness: who knows...
2016-08-14 22:11:40<@blueness> i mean there might be some reason i don’t know
2016-08-14 22:13:13<@ulm> common sense is also to announce it in the ML if maintainership is dropped
2016-08-14 22:13:32<@WilliamH> blueness: the hash is 2d5acbfd
2016-08-14 22:13:34<@K_F> well, I think we agree that it is bad practice to add it, and if someone wants/needs a package in tree they should be willing to maintain it
2016-08-14 22:13:47<@ulm> by extension it would follow that adding a package directly as m-n should be announced too :/
2016-08-14 22:13:51<@ulm> which is absurd
2016-08-14 22:13:51<@blueness> WilliamH: yeah i know what that’s all about now
2016-08-14 22:14:17<@blueness> K_F: we can ask for it to be made a repoman check
2016-08-14 22:14:24<@blueness> no initial commit with m-n
2016-08-14 22:14:43<@blueness> we could open a bug right now against portage
2016-08-14 22:14:46<@K_F> blueness: yes, we already discussed that a bit earlier, but as it is in line with current policy I don't think we need a council vote on it
2016-08-14 22:14:53<@K_F> we can jusdt open a bug requesting it to repoman
2016-08-14 22:14:57<@dilfridge> yes, such a repoman addon is good
2016-08-14 22:15:00<@WilliamH> Isn't there already a bug?
2016-08-14 22:15:14< kensington> bug #590972
2016-08-14 22:15:16< willikins> kensington: https://bugs.gentoo.org/590972 "repoman should prevent people from adding a new package with a metadata.xml pointing to maintained-needed directly"; Portage Development, Repoman; CONF; pacho:dev-portage
2016-08-14 22:15:25<@K_F> kensington: thanks
2016-08-14 22:15:29<@dilfridge> (if people object because of overlays, the check could always only run for repository gentoo)
2016-08-14 22:15:37<@K_F> dilfridge: yup
2016-08-14 22:15:40<@WilliamH> Also, this should only apply if the repo name is gentoo
2016-08-14 22:16:04<@WilliamH> Actually don't we have a way to do repo-based checks already?
2016-08-14 22:16:10<@WilliamH> or was that not implemented?
2016-08-14 22:16:23<@dilfridge> no clue, that info got lost somewhere
2016-08-14 22:16:26<@blueness> i’m opening a bug now
2016-08-14 22:16:36<@blueness> oh never mind
2016-08-14 22:16:54<@jlec> WilliamH: I think this something coming with the new repoman way of creating checks
2016-08-14 22:17:10<@K_F> blueness: it is a bug, dol-sen requests a nod from council on it, which I believe we can give without a formal vote if we agree it doesn't change existing interprentation of policies
2016-08-14 22:17:10<@WilliamH> blueness: ?
2016-08-14 22:17:15< [Arfrever]> Infra-side check at time of 'git push' would be more effective.
2016-08-14 22:17:47<@K_F> it was also noted that that specific commit was not commited using repoman anyways
2016-08-14 22:17:54<@WilliamH> [Arfrever]: that comes after you run repoman.
2016-08-14 22:18:08<@dilfridge> K_F: yes... a bit sad but irrelevant...
2016-08-14 22:18:49<@blueness> WilliamH: i was going to open a bug against repoman but realized there was one already open
2016-08-14 22:18:51<@K_F> adding too much complexity to the git checks sounds a bit suboptimal, should use distributed resources for a bunch of these
2016-08-14 22:19:06<@K_F> and it was pointed out that e.g virtuals can have reasons for this 
2016-08-14 22:19:21<@K_F> so will require a bit of granularity
2016-08-14 22:19:23<@ulm> repoman is much preferrable to a git check IMHO
2016-08-14 22:20:13<@K_F> I'll give a nod on the bug from council at least, to say that implementing it in repoman is OK
2016-08-14 22:20:15< [Arfrever]> An evil committer could simply not use repoman for committing or locally change his version of repoman to disable this check in metadata.xml.
2016-08-14 22:20:39<@K_F> [Arfrever]: yes, but that is a separate issue and we have channels of handling that
2016-08-14 22:20:51 * WilliamH agrees with K_F 
2016-08-14 22:20:53<@dilfridge> Evil committers get handled eventually.
2016-08-14 22:20:55<@ulm> evil committers can do much worse things than omitting a maintainer entry
2016-08-14 22:21:18<@WilliamH> evil committers are a separate issue.
2016-08-14 22:21:21<@K_F> evil commits would get around a git check anyways, but using a two-step process
2016-08-14 22:21:38<@K_F> first add, then drop, as long as we allow dropping in general
2016-08-14 22:22:33<@K_F> ok, if there is nothing more to discuss on that matter. Anyone else wants something brought up?
2016-08-14 22:23:59<@K_F> lets give the question a minute or two, if nothing comes up we'll close the meeting
2016-08-14 22:24:06<@ulm> K_F: thanks for chairing :)
2016-08-14 22:24:27<@WilliamH> Thanks folks. :-)
2016-08-14 22:24:37<@dilfridge> Thanks everyone!
2016-08-14 22:25:34<@K_F> ok, seems others are fine
2016-08-14 22:25:35<@jlec> thanks
2016-08-14 22:25:37 * K_F bangs gavel
2016-08-14 22:25:57<@WilliamH> So can I stable openrc-0.21.3 on amd64 myself then?
2016-08-14 22:26:12<@rich0> WilliamH: yes, as long as you've tested it on a stable system
2016-08-14 22:26:36<@WilliamH> rich0: I run mostly stable.
2016-08-14 22:27:20<@jlec> Could someone have a look into app-misc/vit?
2016-08-14 22:27:20<@WilliamH> K_F: good luck with the stabilization task force... come back with something... :-)
2016-08-14 22:27:29<@K_F> WilliamH: will do :)
2016-08-14 22:27:29<@jlec> Looks like straight to m-n
2016-08-14 22:28:52<@K_F> jlec: I'd open a bug report to maintainer adding it requesting adding maintainer
2016-08-14 22:29:28<@K_F> s/maintainer/developer/
2016-08-14 22:29:44<@K_F> bug 591112
2016-08-14 22:29:47< willikins> K_F: https://bugs.gentoo.org/591112 "app-misc/vit: package added with no maintainer"; Gentoo Linux, Current packages; CONF; mgorny:qa
2016-08-14 22:30:05<@K_F> so that is already being handled by qa
2016-08-14 22:30:20<@WilliamH> Is that a gui?
2016-08-14 22:30:43<@K_F> WilliamH: seems to be a console frontend to taskwarrior
2016-08-14 22:31:09<@WilliamH> oh ok nvm, I don't know what  taskwarrior is.
2016-08-14 22:31:59<@K_F> WilliamH: http://taskwarrior.org/
2016-08-14 22:32:34<@K_F> WilliamH: TODO/Task manager