* Project direction with testing changes (branches and patches) @ 2021-08-01 11:50 Christopher Baines 2021-08-04 21:15 ` Ludovic Courtès 2021-08-12 8:04 ` Lars-Dominik Braun 0 siblings, 2 replies; 9+ messages in thread From: Christopher Baines @ 2021-08-01 11:50 UTC (permalink / raw) To: guix-devel, guix-maintainers [-- Attachment #1: Type: text/plain, Size: 3752 bytes --] Hey, This is sort of a followup to [1], at least I think that's the last main email I sent out about testing changes (although I didn't use that term). I did also send out some notes from the Guix Day event back in February 2021 though [2]. 1: https://lists.gnu.org/archive/html/guix-devel/2020-11/msg00583.html 2: https://lists.gnu.org/archive/html/guix-devel/2021-02/msg00125.html Back in early 2020, I managed to start work on the Guix Build Coordinator [3]. That was meant to enable running reliable and performant substitute servers, but also meant to enable the kind of testing and quality assurance work that I had been thinking about, mostly through the perspective of testing patches. 3: https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00323.html Getting the benefits to users didn't go as smoothly as I'd hoped, but since bordeaux.guix.gnu.org [4] launched back in June, there's a chance that the work on the Guix Build Coordinator has benefited users of Guix through improved substitutes. 4: https://guix.gnu.org/en/blog/2021/substitutes-now-also-available-from-bordeauxguixgnuorg/ As I said in [1], I did do some work last year to use the Guix Build Coordinator for testing patches and branches. Unfortunately the setup I'm using is currently not operating, I was having issues with running out of disk space on the main server, and I haven't got around to spending the time/money to resolve that. I want to get another iteration of the patch testing setup working, but recent experiences with working on providing substitutes has made me think that discussing the direction with maintainers and as a project is almost more important. So, I think I've recently switched to thinking about the problem as one of testing changes, rather than just testing patches. Since both patch series, and branches are used to propose changes, I think this makes sense. In abstract, when testing a change, I would break down the problem as follows: - You need to work out what's affected by the change, so that you can assess the impact - Once you know what's effected, you can then build those packages/system tests/... and compare the build statuses and outputs against some baseline - Then there's the general UI component, ideally a first time contributor would be able to take advantage of automatic feedback about a patch they submit. There's multiple other groups of users though, like patch reviewers, and committers for example. I think the first two sub-problems are effectively solved. The Guix Data Service is able to determine the changes between two revisions (assuming it's processed them). The Guix Build Coordinator can then be used to build the relevant packages/system tests, and report that information back to the Guix Data Service. The UI part is much less certain, I've done some work with Patchwork, and I do have some ideas in mind, but there's still more thinking and work to do in this area. Before pressing on though, I think it would be good to know if this is a viable direction? Currently, there's no automated testing of patches, and testing of branches is limited to the information that Cuirass provides on failed builds. What I'm proposing for the future is: using the Guix Data Service together with the Guix Build Coordinator to analyse the effects of changes, whether that be from a patch series or a branch. I realise that I've already been experimenting with this, what I'm mostly referring to here is moving towards this being the documented approach, maintained by the project, not just me. So yes, is this something that people want, or don't want? If you're uncertain and have questions, it would be good to know what those questions are? Thanks, Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 987 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Project direction with testing changes (branches and patches) 2021-08-01 11:50 Project direction with testing changes (branches and patches) Christopher Baines @ 2021-08-04 21:15 ` Ludovic Courtès 2021-08-09 22:09 ` Christopher Baines 2021-08-12 8:04 ` Lars-Dominik Braun 1 sibling, 1 reply; 9+ messages in thread From: Ludovic Courtès @ 2021-08-04 21:15 UTC (permalink / raw) To: Christopher Baines; +Cc: guix-devel, guix-maintainers Hello! Christopher Baines <mail@cbaines.net> skribis: > So, I think I've recently switched to thinking about the problem as one > of testing changes, rather than just testing patches. Since both patch > series, and branches are used to propose changes, I think this makes > sense. > > In abstract, when testing a change, I would break down the problem as > follows: > > - You need to work out what's affected by the change, so that you can > assess the impact > > - Once you know what's effected, you can then build those > packages/system tests/... and compare the build statuses and outputs > against some baseline > > - Then there's the general UI component, ideally a first time > contributor would be able to take advantage of automatic feedback > about a patch they submit. There's multiple other groups of users > though, like patch reviewers, and committers for example. Makes sense to me. I agree that the first problem, seeing what’s affected by a change, is solved, but it’s still hard to get that info. I think we could have a special “skin” for the Guix Data Service to make it easier for people to view specifically this information. IMO the current UI has the upside that it’s generic and exposes all the available information, but it has the downside that it’s generic and exposes all the available information. :-) Or we could extend Julien’s Gitile¹ to include links from commits to lists of changed packages. The UI doesn’t have to be a web UI actually; we could use the Data Service client interface at <https://lists.gnu.org/archive/html/guix-devel/2021-06/msg00228.html> and write a new CLI, Emacs mode (similar to ‘M-x build-farm’), or something. ¹ https://git.lepiller.eu/gitile > I think the first two sub-problems are effectively solved. The Guix Data > Service is able to determine the changes between two revisions (assuming > it's processed them). The Guix Build Coordinator can then be used to > build the relevant packages/system tests, and report that information > back to the Guix Data Service. > > The UI part is much less certain, I've done some work with Patchwork, > and I do have some ideas in mind, but there's still more thinking and > work to do in this area. > > Before pressing on though, I think it would be good to know if this is a > viable direction? I think we desperately need more automation, even more than when you started working on this! I think a first step could be to make info from the Guix Data Service more readily available, as suggested above. And from there we could address #2 and #3. The Patchwork instance you maintain at <https://patches.guix-patches.cbaines.net/project/guix-patches/list/> does a large part of what we want, though the UI is not my favorite I must say. ;-) I wonder if we could again make minimal changes to Mumi so that it includes links to the relevant bits at the Data Service. That’d make it more readily available. WDYT? > Currently, there's no automated testing of patches, and testing of > branches is limited to the information that Cuirass provides on failed > builds. What I'm proposing for the future is: using the Guix Data > Service together with the Guix Build Coordinator to analyse the effects > of changes, whether that be from a patch series or a branch. I realise > that I've already been experimenting with this, what I'm mostly > referring to here is moving towards this being the documented approach, > maintained by the project, not just me. From an administrative standpoint, I very much agree that this sort of infrastructure should be financially supported by the project rather than by an individual, and documented so we can maintain it collectively. Of course that involves a bit of overhead, and sometimes we’re not all responsive when it comes to paperwork or sysadmin (perhaps these are not our preferred activities?), but still, it makes sense to build that collectively. That’s my take. Thanks for the update! Ludo’. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Project direction with testing changes (branches and patches) 2021-08-04 21:15 ` Ludovic Courtès @ 2021-08-09 22:09 ` Christopher Baines 2021-08-10 6:04 ` Mathieu Othacehe 2021-08-10 7:05 ` Ricardo Wurmus 0 siblings, 2 replies; 9+ messages in thread From: Christopher Baines @ 2021-08-09 22:09 UTC (permalink / raw) To: Ludovic Courtès, Ricardo Wurmus; +Cc: guix-devel, guix-maintainers [-- Attachment #1: Type: text/plain, Size: 6583 bytes --] Ludovic Courtès <ludo@gnu.org> writes: > Christopher Baines <mail@cbaines.net> skribis: > >> So, I think I've recently switched to thinking about the problem as one >> of testing changes, rather than just testing patches. Since both patch >> series, and branches are used to propose changes, I think this makes >> sense. >> >> In abstract, when testing a change, I would break down the problem as >> follows: >> >> - You need to work out what's affected by the change, so that you can >> assess the impact >> >> - Once you know what's effected, you can then build those >> packages/system tests/... and compare the build statuses and outputs >> against some baseline >> >> - Then there's the general UI component, ideally a first time >> contributor would be able to take advantage of automatic feedback >> about a patch they submit. There's multiple other groups of users >> though, like patch reviewers, and committers for example. > > Makes sense to me. > > I agree that the first problem, seeing what’s affected by a change, is > solved, but it’s still hard to get that info. I think we could have a > special “skin” for the Guix Data Service to make it easier for people to > view specifically this information. IMO the current UI has the upside > that it’s generic and exposes all the available information, but it has > the downside that it’s generic and exposes all the available > information. :-) > > Or we could extend Julien’s Gitile¹ to include links from commits to > lists of changed packages. > > The UI doesn’t have to be a web UI actually; we could use the Data > Service client interface at > <https://lists.gnu.org/archive/html/guix-devel/2021-06/msg00228.html> > and write a new CLI, Emacs mode (similar to ‘M-x build-farm’), or > something. > > ¹ https://git.lepiller.eu/gitile Indeed, the technical side of detecting changes is solved, but I agree that there's work needed on making that information useful. >> I think the first two sub-problems are effectively solved. The Guix Data >> Service is able to determine the changes between two revisions (assuming >> it's processed them). The Guix Build Coordinator can then be used to >> build the relevant packages/system tests, and report that information >> back to the Guix Data Service. >> >> The UI part is much less certain, I've done some work with Patchwork, >> and I do have some ideas in mind, but there's still more thinking and >> work to do in this area. >> >> Before pressing on though, I think it would be good to know if this is a >> viable direction? > > I think we desperately need more automation, even more than when you > started working on this! > > I think a first step could be to make info from the Guix Data Service > more readily available, as suggested above. And from there we could > address #2 and #3. > > The Patchwork instance you maintain at > <https://patches.guix-patches.cbaines.net/project/guix-patches/list/> > does a large part of what we want, though the UI is not my favorite I > must say. ;-) I wonder if we could again make minimal changes to Mumi > so that it includes links to the relevant bits at the Data Service. > That’d make it more readily available. WDYT? I think using Patchwork or Mumi is viable, it would probably not be great to use both in the long term. The most useful thing for me would be to pick an approach. Patchwork is closer in terms of features I think, since it has an API for patch series and checks. I know mumi gained the ability to generate mbox files for patch series now though. I think the requirements in terms of Mumi would be to have some way of querying for patch series to test, or at least all/recent patch series. I suppose something could just ask for the 1st or latest series each time there's an email to a issue, that might be the simplest approach. Then there's the bits you describe about showing relevant information about whatever tests take place. I guess Mumi would need an API or some way to find out about that information, and then display it. Maybe that could happen in the form of emails with machine+human readable data that Mumi could interpret. Unfortunately I don't know much about the Mumi internals. Ricardo, are you able to comment on the feasibility and whether this direction would make sense? >> Currently, there's no automated testing of patches, and testing of >> branches is limited to the information that Cuirass provides on failed >> builds. What I'm proposing for the future is: using the Guix Data >> Service together with the Guix Build Coordinator to analyse the effects >> of changes, whether that be from a patch series or a branch. I realise >> that I've already been experimenting with this, what I'm mostly >> referring to here is moving towards this being the documented approach, >> maintained by the project, not just me. > > From an administrative standpoint, I very much agree that this sort of > infrastructure should be financially supported by the project rather > than by an individual, and documented so we can maintain it > collectively. Of course that involves a bit of overhead, and sometimes > we’re not all responsive when it comes to paperwork or sysadmin (perhaps > these are not our preferred activities?), but still, it makes sense to > build that collectively. > > That’s my take. Thanks for the update! That sounds promising. I think trying to change up how branches (staging/core-updates) are tested is a good place to start. The concrete change I'm proposing is to use an instance of the Guix Data Service plus an instance of the Guix Build Coordinator to do the testing and builds, rather than Cuirass on ci.guix.gnu.org which is the current approach. The main advantages of that would be the comparison support from the Guix Data Service, and the build performance and reliability that the Guix Build Coordinator brings. The main disadvantage is probably the lack of an admin like interface similar to that of Cuirass (I think this can be remedied in the medium term though). This would then hopefully be a stepping stone to starting to test patches using the same infrastructure as well. It would be good to hear what people think, particularly the maintainers, then I can either get on trying to make it happen, or not, depending on the feedback. I don't particularly want to push ahead without a strong positive opinion. Thanks, Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 987 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Project direction with testing changes (branches and patches) 2021-08-09 22:09 ` Christopher Baines @ 2021-08-10 6:04 ` Mathieu Othacehe 2021-08-10 19:26 ` Christopher Baines 2021-08-10 7:05 ` Ricardo Wurmus 1 sibling, 1 reply; 9+ messages in thread From: Mathieu Othacehe @ 2021-08-10 6:04 UTC (permalink / raw) To: Christopher Baines; +Cc: guix-devel, guix-maintainers Hello Chris, > I think trying to change up how branches (staging/core-updates) are > tested is a good place to start. The concrete change I'm proposing is to > use an instance of the Guix Data Service plus an instance of the Guix > Build Coordinator to do the testing and builds, rather than Cuirass on > ci.guix.gnu.org which is the current approach. > > The main advantages of that would be the comparison support from the > Guix Data Service, and the build performance and reliability that the > Guix Build Coordinator brings. The main disadvantage is probably the > lack of an admin like interface similar to that of Cuirass (I think this > can be remedied in the medium term though). We indeed desperately need some more automation. For each new patch series, it would be great to have the following information: * Status of the linter. * Status of the depending derivations. * Status of the unit tests (in the tests/ directory). * Status of the system tests (in the gnu/tests/ directory). I would like to stay focused on the existing, well adopted solutions and build upon them. With Cuirass we already have most of the machinery to provide those information. In addition, we have dashboards, RSS and email notification support which could allow us to extend Cuirass functionalities to provide the expected CI features. We could imagine a new API such as /api/changeset/new that would create temporary Cuirass specifications. The output result could be consulted using a new /api/changeset/status API or directly through the Cuirass web interface. Cuirass could also send email and RSS notifications on that changeset. Those APIs could be used by Mumi to trigger the /api/changeset/new API notification on one hand and to display some status using the /api/changeset/status API on the other hand. I think that this whole infrastructure is just a few Guile modules away and if we could involve more fellow hackers in the process, it would be just great. Thanks, Mathieu ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Project direction with testing changes (branches and patches) 2021-08-10 6:04 ` Mathieu Othacehe @ 2021-08-10 19:26 ` Christopher Baines 2021-08-11 10:37 ` Ludovic Courtès 0 siblings, 1 reply; 9+ messages in thread From: Christopher Baines @ 2021-08-10 19:26 UTC (permalink / raw) To: Mathieu Othacehe; +Cc: guix-devel, guix-maintainers [-- Attachment #1: Type: text/plain, Size: 2749 bytes --] Mathieu Othacehe <othacehe@gnu.org> writes: >> I think trying to change up how branches (staging/core-updates) are >> tested is a good place to start. The concrete change I'm proposing is to >> use an instance of the Guix Data Service plus an instance of the Guix >> Build Coordinator to do the testing and builds, rather than Cuirass on >> ci.guix.gnu.org which is the current approach. >> >> The main advantages of that would be the comparison support from the >> Guix Data Service, and the build performance and reliability that the >> Guix Build Coordinator brings. The main disadvantage is probably the >> lack of an admin like interface similar to that of Cuirass (I think this >> can be remedied in the medium term though). > > We indeed desperately need some more automation. For each new patch > series, it would be great to have the following information: > > * Status of the linter. > * Status of the depending derivations. > * Status of the unit tests (in the tests/ directory). > * Status of the system tests (in the gnu/tests/ directory). > > I would like to stay focused on the existing, well adopted solutions and > build upon them. With Cuirass we already have most of the machinery to > provide those information. I was thinking of using Cuirass for building derivations when testing patches, but I gave up on that approach back in 2019 after trying to use it (I discussed trying to use it here [1]). 1: https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00010.html I was specifically thinking about testing patches when I initially designed both the Guix Data Service and Guix Build Coordinator. For me at least, the focus has been on this direction for the last ~3 years. I realise that Cuirass now has some of the functionality that the Guix Data Service was written to provide, like tracking all packages/derivations in each revision. But from my perspective, Cuirass still lacks key things like being able to compare two revisions and tracking lint warnings. There's also things like testing derivations on different hardware, regularly testing fixed output derivations and automatically retrying failed builds that I think the Guix Build Coordinator is better setup to do compared to Cuirass. But this feedback is why I started this thread. I don't see the same option as was found for improving substitutes by setting up a new substitute server using the Guix Data Service and the Guix Build Coordinator. There's a much stronger need to have one approach as a project for testing changes, and if using the Guix Data Service and Guix Build Coordinator isn't looking like a convincing option at this point, that's better to know now, compared to later when more time and effort has been put in. Thanks, Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 987 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Project direction with testing changes (branches and patches) 2021-08-10 19:26 ` Christopher Baines @ 2021-08-11 10:37 ` Ludovic Courtès 2021-08-11 22:27 ` Christopher Baines 0 siblings, 1 reply; 9+ messages in thread From: Ludovic Courtès @ 2021-08-11 10:37 UTC (permalink / raw) To: Christopher Baines; +Cc: guix-devel, Mathieu Othacehe, guix-maintainers Hi Chris, Christopher Baines <mail@cbaines.net> skribis: > I was thinking of using Cuirass for building derivations when testing > patches, but I gave up on that approach back in 2019 after trying to use > it (I discussed trying to use it here [1]). > > 1: https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00010.html > > I was specifically thinking about testing patches when I initially > designed both the Guix Data Service and Guix Build Coordinator. For me > at least, the focus has been on this direction for the last ~3 years. > > I realise that Cuirass now has some of the functionality that the Guix > Data Service was written to provide, like tracking all > packages/derivations in each revision. But from my perspective, Cuirass > still lacks key things like being able to compare two revisions and > tracking lint warnings. Cuirass has always had to track packages/derivations in each revision; it’s been this way from day 1 when it started more or less as a revisited Hydra, which did exactly this. The Guix Data Service provides info not available elsewhere though, and that’s why we need to take advantage of it. > There's also things like testing derivations on different hardware, > regularly testing fixed output derivations and automatically retrying > failed builds that I think the Guix Build Coordinator is better setup to > do compared to Cuirass. > > But this feedback is why I started this thread. I don't see the same > option as was found for improving substitutes by setting up a new > substitute server using the Guix Data Service and the Guix Build > Coordinator. There's a much stronger need to have one approach as a > project for testing changes, and if using the Guix Data Service and Guix > Build Coordinator isn't looking like a convincing option at this point, > that's better to know now, compared to later when more time and effort > has been put in. I can sympathize with the bitter feeling. I do think though that we must work collectively; to me it’d be a problem if misplaced competition were to prevent us from moving forward. Several concrete incremental steps were proposed in this thread and earlier. Instead of trying to provide a definite answer as to whether the grand plan you propose is a convincing option at this point, I’d like us to collect the low-hanging fruits, in an opportunistic way. :-) Several easy hacks have been proposed in this thread and before: custom web/CLI views for the Data Service, Cuirass APIs to spin up specs on the fly, Data Service integration in Mumi/Gitile, Cuirass notifications sent to the Data Service, etc. None of these is impressive in itself, but each of these can be a step making our hacker lives better, IMO. WDYT? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Project direction with testing changes (branches and patches) 2021-08-11 10:37 ` Ludovic Courtès @ 2021-08-11 22:27 ` Christopher Baines 0 siblings, 0 replies; 9+ messages in thread From: Christopher Baines @ 2021-08-11 22:27 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel, guix-maintainers [-- Attachment #1: Type: text/plain, Size: 3785 bytes --] Ludovic Courtès <ludo@gnu.org> writes: > Hi Chris, > > Christopher Baines <mail@cbaines.net> skribis: > >> I was thinking of using Cuirass for building derivations when testing >> patches, but I gave up on that approach back in 2019 after trying to use >> it (I discussed trying to use it here [1]). >> >> 1: https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00010.html >> >> I was specifically thinking about testing patches when I initially >> designed both the Guix Data Service and Guix Build Coordinator. For me >> at least, the focus has been on this direction for the last ~3 years. >> >> I realise that Cuirass now has some of the functionality that the Guix >> Data Service was written to provide, like tracking all >> packages/derivations in each revision. But from my perspective, Cuirass >> still lacks key things like being able to compare two revisions and >> tracking lint warnings. > > Cuirass has always had to track packages/derivations in each revision; > it’s been this way from day 1 when it started more or less as a > revisited Hydra, which did exactly this. I know it tracks some derivations against a revision, but it has only been tracking all of the derivations associated with each revision since this change [1]. 1: https://git.savannah.nongnu.org/cgit/guix/guix-cuirass.git/commit/?id=bba1311478a50c837a8c70a556d308ca32ead816 >> There's also things like testing derivations on different hardware, >> regularly testing fixed output derivations and automatically retrying >> failed builds that I think the Guix Build Coordinator is better setup to >> do compared to Cuirass. >> >> But this feedback is why I started this thread. I don't see the same >> option as was found for improving substitutes by setting up a new >> substitute server using the Guix Data Service and the Guix Build >> Coordinator. There's a much stronger need to have one approach as a >> project for testing changes, and if using the Guix Data Service and Guix >> Build Coordinator isn't looking like a convincing option at this point, >> that's better to know now, compared to later when more time and effort >> has been put in. > > I can sympathize with the bitter feeling. I do think though that we > must work collectively; to me it’d be a problem if misplaced competition > were to prevent us from moving forward. > > Several concrete incremental steps were proposed in this thread and > earlier. Instead of trying to provide a definite answer as to whether > the grand plan you propose is a convincing option at this point, I’d > like us to collect the low-hanging fruits, in an opportunistic way. :-) > > Several easy hacks have been proposed in this thread and before: custom > web/CLI views for the Data Service, Cuirass APIs to spin up specs on the > fly, Data Service integration in Mumi/Gitile, Cuirass notifications sent > to the Data Service, etc. None of these is impressive in itself, but > each of these can be a step making our hacker lives better, IMO. > > WDYT? I don't perceive this as bitterness, just pragmatism. I think I have an answer now as to whether there's consensus on making use of the Guix Data Service and Guix Build Coordinator for testing changes. Knowing there's some objections is useful when considering the risk and managing my own expectations. I still personally think that the general direction this work is going is a good one. There's still some areas of uncertianty, but there's definitely some stuff that can be done to move forward and more discussion that can be had. Thanks for your suggestions on next steps, I still need to get my own thoughts in order. As you alluded to, I do like to have a plan in mind. Thanks, Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 987 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Project direction with testing changes (branches and patches) 2021-08-09 22:09 ` Christopher Baines 2021-08-10 6:04 ` Mathieu Othacehe @ 2021-08-10 7:05 ` Ricardo Wurmus 1 sibling, 0 replies; 9+ messages in thread From: Ricardo Wurmus @ 2021-08-10 7:05 UTC (permalink / raw) To: Christopher Baines; +Cc: guix-devel, guix-maintainers Christopher Baines <mail@cbaines.net> writes: > I think using Patchwork or Mumi is viable, it would probably not > be > great to use both in the long term. The most useful thing for me > would > be to pick an approach. > > Patchwork is closer in terms of features I think, since it has > an API > for patch series and checks. I know mumi gained the ability to > generate > mbox files for patch series now though. I wouldn’t mind getting rid of Mumi. Surely Patchwork has a way to configure the user interface somewhat? > I think the requirements in terms of Mumi would be to have some > way of > querying for patch series to test, or at least all/recent patch > series. I suppose something could just ask for the 1st or latest > series > each time there's an email to a issue, that might be the > simplest > approach. There is an /issue/<id>/patch-set/<num> handler to download patch series. IIRC there is a bug somewhere that makes it not work as intended, but I did use it in the past to get a whole bunch of patches and apply them with ‘git am’. > Then there's the bits you describe about showing relevant > information about whatever tests take place. I guess Mumi would > need an > API or some way to find out about that information, and then > display > it. Maybe that could happen in the form of emails with > machine+human > readable data that Mumi could interpret. I don’t know what this means. What exactly is needed here? > Unfortunately I don't know much about the Mumi > internals. Ricardo, are > you able to comment on the feasibility and whether this > direction would > make sense? I think it’s feasible to add a few more things to Mumi to make the existing features work better. But I should also emphasize that I’m in no way attached to Mumi. If we have something better I’d be happy to retire it. Mumi has served us well; we don’t need to extend its use beyond what is reasonable. -- Ricardo ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Project direction with testing changes (branches and patches) 2021-08-01 11:50 Project direction with testing changes (branches and patches) Christopher Baines 2021-08-04 21:15 ` Ludovic Courtès @ 2021-08-12 8:04 ` Lars-Dominik Braun 1 sibling, 0 replies; 9+ messages in thread From: Lars-Dominik Braun @ 2021-08-12 8:04 UTC (permalink / raw) To: Christopher Baines; +Cc: guix-devel Hi Chris, > So, I think I've recently switched to thinking about the problem as one > of testing changes, rather than just testing patches. Since both patch > series, and branches are used to propose changes, I think this makes > sense. I agree with this analysis and this was always something that bugged me about Patchwork: That it knew about patch series (most of the time), but seemed to operate on individual patches only. > - Then there's the general UI component, ideally a first time > contributor would be able to take advantage of automatic feedback > about a patch they submit. There's multiple other groups of users > though, like patch reviewers, and committers for example. > […] > The UI part is much less certain, I've done some work with Patchwork, > and I do have some ideas in mind, but there's still more thinking and > work to do in this area. This is the main problem right now: UI. As a reviewer I need the following information about a changeset: 1 Is anyone else reviewing it already and what were the comments? (Do I need to take a look at it?) 2 Which packages/components are affected? (Do I have the knowledge to review this changeset?) 3 Are there any obvious issues with it? (Does it pass linting? Does it build? Can it be rebased onto master without conflicts?) 4 Where can I pull the changeset from to do further tests? (Patch-over-email is super-fragile, from encoding/newline issues to merging problems) 5 Who is the contributor? (Does he/she have commit access or do I have to commit on his behalf?) I also want to subscribe to certain changesets (new comments, new versions, …) and filter them to find those, where I can actually help. And debbugs certainly can’t provide any of this. I believe it would be wise not to spend too much time to recreate what GitLab/gitea/GitHub/… do already and just use them to our advantage, filling the holes with bridges/bots to some CI infrastructure (it does not matter whether this is Cuirass, Chris’ build coordinator, the Data Service, … – we just have to be able to get the data in and out somehow). Cheers, Lars ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-08-12 8:04 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-08-01 11:50 Project direction with testing changes (branches and patches) Christopher Baines 2021-08-04 21:15 ` Ludovic Courtès 2021-08-09 22:09 ` Christopher Baines 2021-08-10 6:04 ` Mathieu Othacehe 2021-08-10 19:26 ` Christopher Baines 2021-08-11 10:37 ` Ludovic Courtès 2021-08-11 22:27 ` Christopher Baines 2021-08-10 7:05 ` Ricardo Wurmus 2021-08-12 8:04 ` Lars-Dominik Braun
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).