diff options
Diffstat (limited to 'meeting-logs/20160814.txt')
| -rw-r--r-- | meeting-logs/20160814.txt | 433 |
1 files changed, 433 insertions, 0 deletions
diff --git a/meeting-logs/20160814.txt b/meeting-logs/20160814.txt new file mode 100644 index 0000000..3eb1995 --- /dev/null +++ b/meeting-logs/20160814.txt @@ -0,0 +1,433 @@ +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 |