Re: Proposal for using gitlab for kdereview process
https://community.kde.org/Goals/All_about_the_Apps On Wed, Feb 7, 2024 at 11:16 PM Friedrich W. H. Kossebau wrote: > > Long time ago, but perhaps there are still memories... > > Am Dienstag, 4. Juli 2023, 14:32:59 CET schrieb Jonathan Riddell: > > I've gone ahead an updated the Sanity checklist > > Having come across the checklist items > > * Passing KDE neon build > * App packages in Flatpak, Snap, AppImages and Windows etc as appropriate > > I tried to understand the background & motivation, but only found this "I've > gone ahead an updated" here and the diff from your edit on 4 July 2023: > https://community.kde.org/index.php? > title=ReleasingSoftware=next=97120 > > I assume this was the result of some community discussion. If so I failed to > witness and now fail to find it. Could you help me to get more insight into > the previous discussion here? > > Cheers > Friedrich > >
Re: Proposal for using gitlab for kdereview process
Long time ago, but perhaps there are still memories... Am Dienstag, 4. Juli 2023, 14:32:59 CET schrieb Jonathan Riddell: > I've gone ahead an updated the Sanity checklist Having come across the checklist items * Passing KDE neon build * App packages in Flatpak, Snap, AppImages and Windows etc as appropriate I tried to understand the background & motivation, but only found this "I've gone ahead an updated" here and the diff from your edit on 4 July 2023: https://community.kde.org/index.php? title=ReleasingSoftware=next=97120 I assume this was the result of some community discussion. If so I failed to witness and now fail to find it. Could you help me to get more insight into the previous discussion here? Cheers Friedrich
Re: Proposal for using gitlab for kdereview process
I've gone ahead an updated the Sanity checklist and updated the kde review policy to ask people to make an Issue on gitlab labelled "KDE Review Request" https://community.kde.org/Policies/Application_Lifecycle#kdereview So you can now find kdereview requests at https://invent.kde.org/dashboard/issues?sort=created_date=opened_name[]=KDE+Review+Request Which is linked from https://community.kde.org/Policies/Application_Lifecycle#kdereview I'll open Issues for outstanding kdereview projects. Jonathan On Mon, 19 Jun 2023 at 19:55, Jonathan Riddell wrote: > Seems using issues is more intuitive so I'll ask for a global group label > for issues and update the process docs for kdereview and incubator. > > Incubator suggestion is here > https://discuss.kde.org/t/proposal-kde-invent-based-incubator-process/ > > Jonathan > > > On Wed, 1 Mar 2023 at 08:27, David Redondo wrote: > >> So there are two new kdereview requests using gitlab issues now instead >> of my >> more complicated idea of merge requests. I imagined a MR to have >> advantages >> for codereview but an issue seems to be less complicated (no need to have >> an >> empty orphan branch, etc..), so maybe we should go with that. >> >> David >> >> >>
Re: Proposal for using gitlab for kdereview process
Seems using issues is more intuitive so I'll ask for a global group label for issues and update the process docs for kdereview and incubator. Incubator suggestion is here https://discuss.kde.org/t/proposal-kde-invent-based-incubator-process/ Jonathan On Wed, 1 Mar 2023 at 08:27, David Redondo wrote: > So there are two new kdereview requests using gitlab issues now instead of > my > more complicated idea of merge requests. I imagined a MR to have > advantages > for codereview but an issue seems to be less complicated (no need to have > an > empty orphan branch, etc..), so maybe we should go with that. > > David > > >
Re: Proposal for using gitlab for kdereview process
So there are two new kdereview requests using gitlab issues now instead of my more complicated idea of merge requests. I imagined a MR to have advantages for codereview but an issue seems to be less complicated (no need to have an empty orphan branch, etc..), so maybe we should go with that. David
Re: Proposal for using gitlab for kdereview process
Overall I think it makes sense. The key players are all already on GitLab and it's where we do code review for established projects. Nate On 2/22/23 00:59, David Redondo wrote: Am Samstag, 18. Februar 2023, 12:02:38 CET schrieben Sie: I'm not convinced more paper work is going to help us increase the number of participants in the review process (which is imho the big issue), Hi Albert, I don't think it's will be paperwork, usually the mentioned checklist was the first thing Harald links to people and is already mentioned on the kdereview wiki page as things people will look at. but if you're willing to document all this properly I'm happy to give it a try and be proven wrong :) I will try to write something then for the wiki if noone objects. David
Re: Proposal for using gitlab for kdereview process
Am Samstag, 18. Februar 2023, 12:02:38 CET schrieben Sie: > > I'm not convinced more paper work is going to help us increase the number of > participants in the review process (which is imho the big issue), Hi Albert, I don't think it's will be paperwork, usually the mentioned checklist was the first thing Harald links to people and is already mentioned on the kdereview wiki page as things people will look at. > but if you're willing to document all this properly I'm happy to give it a try and be proven wrong :) I will try to write something then for the wiki if noone objects. David
Re: Proposal for using gitlab for kdereview process
El divendres, 17 de febrer de 2023, a les 8:53:54 (CET), David Redondo va escriure: > Hi, > > I observed that participation in kdereview is fairly low. Usually only the > same few people participate (I have to admit this does not include me > either). Further follow up to their comments tends sometimes to be slow or > is missed. Sometimes it fizzles out completely. > I think nowadays we have better tools to streamline the whole process, which > we are familiar with and make the barrier to participation lower. My idea > is to use Gitlab which we use for normal code review also for the kdereview > process. For example it could be as follows > - Announce the intention to go through kdereview as usual to kde-core-devel > - Create a MR in your project's repo from master branch into an empty > kdereview branch > - Could copy the sanity checklist [1] as task list and check things there > - Reviewers can leave review comments in the familiar web interface > - Commits that fix review comments are pushed to master branch and so update > the code seen in the MR > - Once the reviewers are satisfied and their feedback incorporated, they > approve the MR and it can be closed > > Thoughts? I'm not convinced more paper work is going to help us increase the number of participants in the review process (which is imho the big issue), but if you're willing to document all this properly I'm happy to give it a try and be proven wrong :) Cheers, Albert > > David > > > > [1] https://community.kde.org/ReleasingSoftware#Sanity_Checklist
Re: Proposal for using gitlab for kdereview process
On 2/17/23 08:53, David Redondo wrote: Hi, I observed that participation in kdereview is fairly low. Usually only the same few people participate (I have to admit this does not include me either). Further follow up to their comments tends sometimes to be slow or is missed. Sometimes it fizzles out completely. I think nowadays we have better tools to streamline the whole process, which we are familiar with and make the barrier to participation lower. My idea is to use Gitlab which we use for normal code review also for the kdereview process. For example it could be as follows - Announce the intention to go through kdereview as usual to kde-core-devel - Create a MR in your project's repo from master branch into an empty kdereview branch - Could copy the sanity checklist [1] as task list and check things there - Reviewers can leave review comments in the familiar web interface - Commits that fix review comments are pushed to master branch and so update the code seen in the MR - Once the reviewers are satisfied and their feedback incorporated, they approve the MR and it can be closed Thoughts? David [1] https://community.kde.org/ReleasingSoftware#Sanity_Checklist Hi, I definitely like the idea of a more structured approach to the review, e.g. by following a checklist. Currently it feels somewhat ad-hoc and arbitrary what people suggest (or don't suggest), and it's not always clear what's "required" to pass and what's more of an optional suggestion. Cheers Nico
Proposal for using gitlab for kdereview process
Hi, I observed that participation in kdereview is fairly low. Usually only the same few people participate (I have to admit this does not include me either). Further follow up to their comments tends sometimes to be slow or is missed. Sometimes it fizzles out completely. I think nowadays we have better tools to streamline the whole process, which we are familiar with and make the barrier to participation lower. My idea is to use Gitlab which we use for normal code review also for the kdereview process. For example it could be as follows - Announce the intention to go through kdereview as usual to kde-core-devel - Create a MR in your project's repo from master branch into an empty kdereview branch - Could copy the sanity checklist [1] as task list and check things there - Reviewers can leave review comments in the familiar web interface - Commits that fix review comments are pushed to master branch and so update the code seen in the MR - Once the reviewers are satisfied and their feedback incorporated, they approve the MR and it can be closed Thoughts? David [1] https://community.kde.org/ReleasingSoftware#Sanity_Checklist
