PokiPoki in KDEReview
Hi y'all! I'd like to see PokiPoki go through KDEReview and eventually end up releasing as an extragear library. PokiPoki is a framework that aims to make persistent objects as trivial to use as possible and provides other sugar functionality on top of simply persisting objects, such as an undo/redo stack. >From a code overview, PokiPoki is split into two main parts: libpokipoki and pokic. libpokipoki is a small helper library that provides types used by pokic while pokic is a code generator that consumes .pokipoki files to generate a header-only library that can be included in a project. libpokipoki is authored in C++ for obvious reasons, while pokic is authored in Go due to the extensive text templating system used for code generation and the lexer in the stdlib used for reading pokipoki files. poki-compiler/parser/output.go will probably be the file that needs most looking at, as it's responsible for the code generation. Cheers, -- Carson Black
Re: Git merge workflow: reverse it?
On Wednesday, 26 August 2020 10:32:24 CEST Ingo Klöcker wrote: > Boud, please don't look with your Krita glasses on other projects. Well, this goes two ways, and when people argue for a certain workflow as the KDE workflow, then I'll have to note that that workflow only is fine for repositories that don't see much work. It is not best practice; it's make-do. It's the same with the retirement of createtarball in favor of releaseme: the releaseme workflow of creating a tarball from a branch and only then tagging is wrong for actively maintained projects. It's the same with keeping translations in svn instead of in the project repository. While we can recognize they make life simpler for people tasked making regular releases of a whole bunch of repositories that change very little, we'll also have to recognize that these policies deviate from what is seen as best practice in the rest of the world. > In my opinion, there can't be a one-size-fits-all git merge workflow/policy. Sure -- but I feel that not everyone in this thread actually realizes that -- that there are people who think that all of KDE does one thing, and that it's the best way of doing things for all the variety in KDE. My idea of a normal development and release workflow is: * An MR either for master or stable * A new MR for the other branch, or cherry-picking if simple enough * When releasing setting a tag * Which generates a tarball from the repo -- for which reason the repo should include the translations * Copying the resulting tarball from invent to files.kde.org -- preferably with a KDE generated signature so I don't have to do that myself. * Start the binary builds (although, ideally, that would also be done automatically on the setting of a tag...) -- https://www.krita.org
Re: Git merge workflow: reverse it?
On Mittwoch, 26. August 2020 09:59:16 CEST Boudewijn Rempt wrote: > On Tuesday, 25 August 2020 23:44:02 CEST you wrote: > > Or you can merge stable to master and be sure you won't forget anything. > > Of course if master changed a lot you can't (easily) do that. But we > > have a lot of repos that don't change very often and merging stable to > > master works very well with them. > > ... > > > The problem is we don't always have a maintainer. A lot of apps are > > community-maintained and if we wouldn't merge stable to master before a > > new release we would reintroduce fixed bugs quite often. > > Basically, what you're saying is that KDE releases a lot of software that > just basically never changes, and apart from some translation work is > actually unmaintained. No. "Doesn't change very often" doesn't mean unmaintained. It could also mean feature-complete (at least from the point of view of the maintainer). The only significant work that still happens is bug fixing. > I don't think that those projects, or rather repositories, since if there's > no work being done, it's hard to see that as a project, should shape > policy. I agree to a certain point because unless the bug is really critical the maintainer could choose to fix the bug only in master. > If a repo can get by with just merging stable to master, I don't think it's > seeing meaningful development -- why should it even be released? Because some bugs were fixed? Boud, please don't look with your Krita glasses on other projects. A small application like Spectacle or something even smaller like the recently proposed markdownpart certainly has very different requirements on project management and software engineering than a large application like Krita. In particular, a small, more or less feature-complete application doesn't require large scale refactoring which would make merging stable to master a painful process. I can see that for Krita merging stable to master isn't a viable workflow. In my opinion, there can't be a one-size-fits-all git merge workflow/policy. Apparently, Krita does already deviate from the current "KDE-wide" "fix in stable and merge stable to master" policy that is challenged in this thread. In my opinion, the decision which policy (of maybe two sensible policies we can agree on) to use for a project should be left to the ones who are doing the work, i.e. for small, largely one-developer (== maintainer) projects it should be left to their maintainer. As for the release managers, they should simply take what's there. Merging stable to master shouldn't be part of their job, in my opinion. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Git merge workflow: reverse it?
On Tuesday, 25 August 2020 23:16:52 CEST Elvis Angelaccio wrote: > Now: > * Test the fix on stable > * Push to stable > * Merge stable to master > > After: > * Test the fix on master > * Push to master > * Test the fix on stable > * Cherry-pick to stable > > In the second model I need to test twice because I can't change the > stable branch without testing. > Er... You don't even test master after merging something to it? -- https://www.krita.org
Re: Git merge workflow: reverse it?
On Tuesday, 25 August 2020 23:44:02 CEST you wrote: > Or you can merge stable to master and be sure you won't forget anything. > Of course if master changed a lot you can't (easily) do that. But we > have a lot of repos that don't change very often and merging stable to > master works very well with them. ... > The problem is we don't always have a maintainer. A lot of apps are > community-maintained and if we wouldn't merge stable to master before a > new release we would reintroduce fixed bugs quite often. Basically, what you're saying is that KDE releases a lot of software that just basically never changes, and apart from some translation work is actually unmaintained. I don't think that those projects, or rather repositories, since if there's no work being done, it's hard to see that as a project, should shape policy. If a repo can get by with just merging stable to master, I don't think it's seeing meaningful development -- why should it even be released? -- https://www.krita.org
