Le 01/09/2019 à 19:15, Bernd Zeimetz a écrit : > > > On 9/1/19 6:41 PM, Alexis Murzeau wrote: >> I find both arguments quite valid: >> - The BTS is more future proof, stuff on it will probably last longer >> than whatever is on Salsa currently. > > Why? There is no real reason to remove MRs or bug reports in salsa after > some time.
Because BTS is running and keeping history from 1996 at least, and Salsa is far younger than that. It may last for many years more, but given its code complexity (compared to the BTS), it might be replaced by something else later the same way Alioth base on FusionForge got replaced with Salsa with gitlab. ATM, its just a matter of probabilities, but still. In 20 years, maybe the way we work will change again and maybe gitlab will be outdated. But I clearly agree that as of now, gitlab seems to be perfectly good. It's just than stuff appear and disappear rather fast when looking at it on the range of several decades. Gitlab was born just 8 years ago. Gitlab can be forked if needed, but I'm not sure maintaining a fork of Gitlab for Debian own use would be feasible. Maybe we should just accept to leave some bug history behind and move on. Linux got jitterbug, bitkeeper and bugzilla. But on the patch side, it's still just mails but with tools like https://patchwork.kernel.org/. I think many project got the reflection of whether to move to newer tools to handle bugs and/or merge requests. As I see, this is the case, but the response to this largely depends on the context. > > That raises one question: is salsa being indexed by crawlers, at least > bug reports/MRs? Yes it seems ok, I've just searched for "debian salsa merge_requests" and it returned me results with merge requests of various projects. When searching with keywords in the MR, I get merge requests results. But I'm not sure these results are kept if the underlying page disappear. > > >> [....] >> I'm myself ok with the BTS but I have to send sometimes more than one >> mail to control@b.d.o before having the right action on the bug done >> (mistyped command, wrong syntax, bad bug status when merging bugs, ...). >> So it is not as easy to use as a graphical interface. >> Maybe I should just use command line tools instead of plain mails :) > > Exactly. It is unnecessary hard for our uses to use the interface. > > From my own experience: since I have my bigger packages (like > open-vm-tools, gpsd...) on github/salsa, I've started to get *a lot* > more pull requests than I got patches in the bts on all of my packages. > Also it is much more easy to review pull/merge requests - I even do it > on the mobile phone sometimes - and merge them if possible. > > I think github and the like got popular because of these tracking features and collaboration tools like forks and pull/merge requests. And also automatic stuff like automatic CI run on every MR, test coverage diff and the like. Not all are applicable to Debian but still. I think this makes contributing easier for many users that don't use mails that much beside administrative/legal stuff. I think that: - easier way to submit bugs (without patch) can cause just more work to maintainers (which might not be really that better in the end if a maintainer is already somewhat busy) - easier way to submit patches can help users help more often maintainers even if a package has not the help flag set. It's just up to the maintainer to accept or not the patch (really, the merge request in gitlab) But as I see by re-reading other mails, is that there are some people that are better with the current way to handle patch (via mail and BTS) and others that prefer merge requests. I'm not sure it's possible for one to convince someone else about that. Letting maintainer allow the merge request feature seems a good way to me to actually "test" if that feature is really good. As a technical tool, maybe a gitlab webhook can help to make people of different though about patch workflow (mail vs MR) work together with less friction. As I said, not sure if this is possible or even that good, it might be just a "spam" tool. But it seems not possible to use a global gitlab instance webhook ATM. -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
signature.asc
Description: OpenPGP digital signature
