Hi, Quoting Wookey (2024-04-07 22:42:34) > On 2024-04-07 16:04 +0200, Andreas Tille wrote: > > Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst: > > > [Feel free to quote any part of this email which I wrote outside of this > > > mailinglist] > > OK, moving the discussion to debian-devel where it should belong. > Good plan. finally! Thank you!! <3 My personal take on the general discussion: can we first agree on a non-mandatory packaging workflow before we talk about reducing strong package ownership? Or at least add a way for a package to declare the used workflow? I'm not feeling comfortable doing more than opening merge requests or sending patches via the BTS to any package (even if the package is in the low threshold nmu list) without this knowledge. > > > The fact that a package is listed as maintained by a person rather than a > > > team does not mean the person is the only person who is responsible for > > > that package. Debian as a whole is. And the release team is, in the > > > context of deciding what happens with a package that has outstanding RC > > > bugs. And the QA team is, when they run full-archive test rebuilds for > > > new things. And our users are, when they file bugs. > > So I agree with everything Wouter said in this mail. I'm keen on > changing the _culture_ to make it easier to just fix things. > > But Andreas seems to have taken this idea of 'we should make it easier > to help people maintain packages', and conflated it with 'everyone has > to use salsa' and 'everything should be team maintained'. > > I think that's a mistake, and I'm not a fan. Because so far as I can > tell 'use salsa' actually means 'maintain your packages in git'. So > far as I can see it is not possible to use our existing 'uscan, patch, > sbuild, dupload' type workflows with Salsa. And that's why I'm not > using it, and don't want to be made to use it. > > But I am _not_ against people helping me fix my stuff - I'm on the > 'just NMU my packages - I won't bite' list. > > As I said elsewhere: > For me Salsa is just one more thing to deal with. It is useful if you > need to share a package _before_ it is uploaded, but mostly it's just > a load of extra stuff I didn't want or need (git, web-interfaces, > certificates). And when I _do_ have to deal with it it takes a lot of > extra time and effort I would prefer to have spent elsewhere. > > I have a workflow I am quite happy with (uscan, meld, quilt, sbuild, > dupload). I've tried various fancy new things (salsa, git, dgit) but > mostly I've found they got in the way (and delayed uploads/wasted > time) rather than made my life easier, so I keep going back to the old > way because it just works. > > I don't mind what other people do, but I worry that conversations like > this seem to take the new thing as so self-evidently better that > no-one can reasonably complain about them being made a > requirement. Well, we don't all think it's better, and I wouldn't > enjoy seeing 'packages must be in Salsa' made a requirement, for > example. > > Dgit almost solves this problem but is backwards from my POV. It lets > the git people pretend that they still use quilt and tarballs so the > interface remains compatible (excellent). But it doesn't let the > tarball people expose an interface to keep the git people happy (SFAIK - you > can't do a dgit upload unless you have a git repo) which is a pity - I'd be > fine doing doing 'dgit upload' instead of 'dupload' for compatibility > purposes. Personally, I cannot imagine myself maintaining my packages without them being in a VCS like git. I want to be able to "git log" a file to see which changes touched it. I want to be able to "git blame" a file to see which change modified a certain line. I want to "git revert" changes or "git rebase" local feature branches. Even without any contributors, I don't mind the overhead of using git for packaging as it helps *me* in the end. Then there is salsa... I have mixed feelings about it. On the one hand, it's this big beast with tons of javascript and apparently we are not even dog-fooding gitlab as packaged in Debian to overseves. I'd like our infrastructure to be based on the things we offer in our distro. And it's just so much javascript... I cannot open a build log in the browser without it just vanishing before my eyes with an error message in red at the top. My computer is slow (ARM Cortex A53) and this does not play well with it. I wish there was a way to interact with it from my terminal instead of having to click on buttons in a very slow web interface. On the other hand, salsa has enabled me to have confidence in what I upload as I haven't had before. I really like that I can "git push" my changes and then another computer can tell me whether autopkgtest, piuparts, reprotest and friends are happy. I could set all this up locally but due to the limitations of my machine I like that I can just trigger another computer to do this work for me while I use that time to work on other stuff. I like that salsa gives me a lot of confidence in my package actually not being half broken before I "dput" it into the archive. I also like to receive contributions through salsa which (in contrast to contributions via the BTS) will show me via a green icon that the change does not break something. In contrast to email communication on the BTS, merge requests and issues on salsa allow me to easily amend or change existing messages, automatically hide resolved conversations not only on my end but also for other people viewing a merge request, have in-line comments on a code diff which I know not only my own special e-mail client will display that way but will look the same for other people in their browser. I can click links to cross-referenced issues, receive automatic improvements from jelmer's janitor or manage several experiments that I have in multiple branches not just locally for me but publicly for everybody to see and comment upon and then others see those comments organized for each of these merge requests. Using just the BTS does not allow this level of collaboration. It doesn't integrate this tightly into the code itself and does not display the information that clearly. In summary, I understand people for whom having their packaging in git is "self-evidently better". I really struggle to see the benefits of the "uscan, meld, quilt, sbuild, dupload" workflow you describe over one that involves a local git repository. It just helps me so much to have things in git. I don't want to tell you that your approach is wrong. It clearly is working fine for you. But I have just too often thought "drats, I wish I now could look up what changed when in which file" that having everything in git is a no-brainer for me and maybe I was able to motivate you a bit to give git another try. It really revolutionized how I work with files on my computer, including Debian packaging. As for salsa: I understand the ups and downs I think. I like to use it but I've also cursed at it enough times to understand the dislike. But I think the benefits outweigh the costs for me, so I ended up using it. I'm not feeling entirely comfortable with making its use mandatory. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature