- User Since
- Feb 5 2015, 10:18 AM (229 w, 2 h)
Tue, Jun 25
Mon, Jun 24
Addressing dfaure's comments
Did the arc amend locally to reflect the description change, that should address your comment.
Right, that's because in fact I authored this before your own patch. :-)
It was stuck in my own queue because I wanted to validate it with the following commit which I struggled with. I'll change the description.
Sun, Jun 23
This seems very focused on deployments, which is good in itself. Now with my "I work in dev services" hat on, I think the scope should be slightly extended to also encompassing the amount of people looking for KDE related services beyond deployments.
Although, I can't wait to see us switching to Wayland. I think this is slightly too "focused on one tech" as a goal. I'd rather see a lot of Wayland influence in the T11054 and T11057 goals mentioned than having a Wayland goal on its own which would overlook input methods for instance (which is exactly what the people who already switched for good did AFAICT).
I don't think it is *all* doable indeed... but if the author of that goal put some more research effort into it to improve the wording it could become a strong follow-up goal to the on-boarding one. Indeed, helping users to turn into contributors would be really nice. Even though some of the point in there are a bit shoot-to-the-moon like, some others are actually very doable I think and would help a lot. Please, take time to improve it, I think it could pay off. ;-)
I agree with the other comments, and would go even one step further: anything which is aiming at improving performance and at the same time pointing finger to a particular component or framework should come with measurements. That's how profiling anything starts.
That would be a nice follow-up to the privacy goal. The wording still is a bit weak though. I might be slightly confused but I read it a bit like "be more like Qubes" which won't be enough to attract votes to that goal. I'd advise giving more details on how our world would look if the goal was reached. Also I suspect it would work only by further integration with the underlying platform: how would that be achieved? what would be needed or missing? The list of existing libraries fall a bit short there.
I agree with Lydia here, maybe it's too early to get in technical details on how to achieve it. It's maybe better for that one to focus on the constraints we want to have and the success criteria.
Fri, Jun 21
Thu, Jun 20
Stupid me! Adding the missing file.
May 21 2019
May 20 2019
Apr 7 2019
Mar 25 2019
Looks fine to me.
I agree moving the promote implementation in the base class could make sense now. Rather in a separate commit though.
Mar 22 2019
I'm not sure the promotion a problem in practice in this view. Yes, the promoted task would disappear, but you'd have a project appearing instead and its children would still be there I guess. It's what I'd expect.
Mar 19 2019
Mar 18 2019
Makes me wonder if we shouldn't also fix findInboxTopLevel() indeed your improved findTopLevel() makes a better job at verifying the related-to field doesn't contain a broken reference to a parent... which the inbox doesn't (and should). Would be a separate patch I guess.
Hehe, clearly I don't have the use, hence the oversight. Thanks!
It almost asks for unit testing the behavior... but that looks really gruesome to test, so except if you got an idea let's get it merged.
Mar 3 2019
Mar 2 2019
Thanks, I like having dirty and broken data at places.
NameAndDataSourceDialog it is then.
Admittedly I'm confused by some of the changes in the XML
I'd also expect a way to express that a todo has a bunch of contexts? Like we have "withParentUid". You didn't feel that need yet? It's kind of surprising me.
Couples of comments, but they are for different commits, they don't need to be done in this commit.
Feb 3 2019
Feb 1 2019
Jan 29 2019
Slightly torn about that one since we stop checking that we won't die on other data types... But I guess that's a necessary evil for now.