As for PR workflow, it will be hopefully. There's a discussion[1] to replace the Alioth[2] with Pagure[3], which has a similar workflow with Github. Maybe the Pagure is not the final decision, but it will be a modern platform that's easy for contributors.

[1] https://lwn.net/SubscriberLink/724986/90728a14d7a85770/

[2] https://alioth.debian.org/

[3] https://pagure.io/

The problem with a git repo for each package is that not every maintainer uses git..

I realise that integration could be better, but most of these things do already exist:

CI: https://ci.debian.net/

Tool for reporting bugs: reportbug (CLI) / reportbug-ng (GUI). This is also the way to submit patches.

Inspect debian source packages: apt-get source

> ...not every maintainer uses git.

I can't think of a valid reason for people to avoid learning git. Is there one?

"Avoid learning" and "not using (for this particular job)" are different things.

Is there a valid reason to move to git from any other VCS a person happy with, regarding time and resources one have to spend on it instead of productive work?

It could be beneficial for a Linux distribution sticking to only one tool to be able to build a common Workflow around it. For example Debian only uses one bug tracking system which might not be what everyone likes most but imagine what a nightmare it would be if everyone would set up their own solution for their package.

I can't contrast git with all the different VCS tools that are available, but different tools have different capabilities with respect to working offline and reconciling branches.

At any rate, it was an honest question. I'm not familiar with any salient reasons to not use git. If the only reason is that some developers still haven't learned git yet, I guess that's an answer. Not a very satisfying one to me, but it's worth knowing that's the reason.

There are those of us who have learned git and still prefer Mercurial. It's really annoying that git is supposed to be what we use across all programs, distributions, operating systems and hardware. Just about ASCII or TCP/IP are the only things that are about as universal, and git shouldn't be nowhere nearly as foundational as them. There should be room for more than one way to do source control.

Sadly, mercurial-buildpackage in Debian is a dead-end. :-(

> Have a git repo for each package

Bad idea, because you don't want to lock all of Debian into one technology. Suppose Debian had similarly had one cvs repo for each package 20 years ago. Progress happens when people have the opportunity to independently build and test out different solutions without first having to convince the world that theirs is the best.

> with a simple issue tracker

Dunno what you mean by "simple", but there is an issue tracker for all the packages that's as simple to use as it gets, you don't even need to create an account!?

> Also move away from message boards and IRC to more user friendly tools.

I haven't seen message boards used by Debian!? As for IRC, what would you consider a more user friendly tool?

> Currently, it's too hard to report bugs

So, running reportbug on your machine is too hard?!

> inspect debian source packages

So, running apt-get source on your machine is too hard?!

> propose fixes

See bugtracker above?

> many open source projects has old infrastructure

What is wrong with old infrastructure?

It doesn't have to be a git repo :)

But a github-like setup, project package, issues, branches, PRs.

> So, running apt-get source on your machine is too hard?!

Where is the web ui? I honestly feel like these commands are magic because I don't know what they clone from. (and I have to be on debian)

> As for IRC, what would you consider a more user friendly tool?

slack or similar...

> So, running reportbug on your machine is too hard?!

This assumes on a debian machine. Sometimes I find a bug searching on google, it'll be something like this:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304373

How do you subscribe, comment, propose a PR, where do you find the source.

I have used some of the debian tools like apt-get source, but it takes a long time to learn these things, and I forget them. A github-like system is much more intuitive.

----

Note: I'm not criticizing the debian project, many open source projects have old infrastructure, that's hard to use. And I fully understand how that infrastructure came to be, and why migrating away is super hard.

My point is: github-like development flow have dramatically better usability and, hence, lowered the bar for participation. I wish more of the big open source projects would embrace the importance of these advancements in usability.

> But a github-like setup, project package, issues, branches, PRs.

Well, how is that supposed to work and not run into essentially the same problem? You can use any version control system, but only after you have integrated it into the Debian meta version control system?!

> Where is the web ui?

Why would you want a web UI, especially if it's supposed to be user friendly? I have a very nice and powerful development environment ... why would I ever want to have a "Debian Web UI" for inspecting a package's source code instead of just using the tools that I know well how to use?

> I honestly feel like these commands are magic because I don't know what they clone from.

Well, there is documentation that explains what they do?! Like ... man apt-get? And it's not really all that complicated either.

> (and I have to be on debian)

Well, you can just download the source packages from the website if you want, but in the common case that you just want to inspect or modify the code of the package that you have installed, what's easier than have apt download and unpack it for you?

Also, of course, that's all only relevant to the Debian packaging, not the upstream source.

> slack or similar...

What do you mean by similar? Proprietary software with a monopolistic supplier that you cannot participate in unless you enter into a contract with that third-party supplier under their terms, and that forces you to use their user interface instead of integrating it with your existing communication infrastructure? How is that more user friendly than "start any free-software IRC client of your choosing if you haven't one running yet, and join the channel (or use some web IRC client if you want)"?!

> This assumes on a debian machine.

Well, it is meant for reporting bugs in a Debian install, so ... yeah?

Also, again, you don't need to use that, but it's the easy way in the common case that you are indeed on a Debian system when you want to report a Debian bug.

> How do you subscribe

You click the "subscribe" link in the line "Reply or subscribe to this bug." at the top.

> comment

You click the "Reply" link in the line "Reply or subscribe to this bug." at the top.

> propose a PR

Same as above, just put the URL of the repo to pull from in the email.

Though in practice just putting the patch into the email is the usual approach, given the nature of packaging bugs (the fix usually is relatively simple).

> where do you find the source.

You click on the "docker" (or whatever the package name is) link in the "Package: docker [...]" line at the top, that gets you to the bug tracker overview page of that package (essentially the list of all bugs related to that package), there you click on the "docker package page" link in the "You might like to refer to the docker package page, [...]" line at the top, which gets you to the list of available related packages and their versions, where you click on the relevant package and version, which gets you to the info page about exactly that package in exactly that version, which, among many other things, contains links to the source package in the right column.

That might seem like a lot of clicks to get from A to B, but if you realize that bugs are not specific to single package versions, but Debian as a distro of course is built on specific versions that are published as packages, it actually makes sense.

> I have used some of the debian tools like apt-get source, but it takes a long time to learn these things, and I forget them.

Well, yeah, it certainly is something you have to learn if you want to use it, just as github is something you have to learn if you want to use it!?

I just don't see how anything like github would be a replacement for Debian package management tools. I mean, the purpose of apt and dpkg and the like is not to be general-purpose software development tools, they exist just for the purpose of packaging and building software for Debian. If you want to package and build software for a distro, you'll naturally have to learn how to use the packaging tools of that distro, and if you are just interested in the upstream source of some software that just also happens to be packaged for Debian, then why bother with any of the Debian stuff?!

> A github-like system is much more intuitive.

Are you sure you don't just mean "I am more familiar with github"?

I find github just annoying in that it's constantly trying to get me to use their user interface instead of just giving me easy access to the raw data and letting me use my own tools (and I am not interested in using github for anything, I just am confronted with it when other people choose to host their software on it).

> many open source projects have old infrastructure,

I still don't see what's wrong with old infrastructure?!

> that's hard to use.

Well, hard to use infrastructure is bad, whether old or new, isn't it? Github, for example, is relatively new, and just terrible. I can't even report a bug in projects hosted there, I'd first have to create an account with them just to post a simple bug report, it's just such a terribly complicated workflow (not to forget I'd probably have to accept their TOS?).

I still don't really see any similar problems with how Debian operates from what you have written!?

> And I fully understand how that infrastructure came to be, and why migrating away is super hard.

Well, I still don't see why one possibly would want to migrate away in the first place!? I mean, not that there is nothing that could be improved, but I don't really see anything that "switching to" would somehow make things better.

> My point is: github-like development flow have dramatically better usability and, hence, lowered the bar for participation.

Did it? I guess it depends on what you mean by "github-like"? My experience with github specifically is completely the opposite.

I have contributed to quite a few projects, with usually very low barriers to get involved. Usually, you just send an email with the patch (or a pull request for more complex changes) to the mailing list or maintainer, and that's it (or maybe a few more mails back and forth to discuss some improvements or whatever, but no up-front cost before you can get started, no need to create accounts, no need to learn additional user interfaces, ...).

On the other hand, I had a few bug fixes for projects that were hosted solely on github where I couldn't find any way to submit them without first making an account with github and learning their proprietary user interface, so I just ended up dropping them on the floor.

How is the latter an improvement?! Or is it?

> I wish more of the big open source projects would embrace the importance of these advancements in usability.

But ... what are those advancements in usability? Really, I still don't see any. I mean, not that usability couldn't be improved here and there, but what you write so far mostly reads to me like "if you know github and don't know non-github, then github is easier to you than non-github" ... which might be true, but would generally be equally true for anything else, and in particular doesn't really have anything to do with usability!?

You need some linebreaks in your post.

This issue could be helped with some tactical updates to the Debian Wiki. I'm in two minds about IRC - I'd hate to see it disappear and go to something like Slack, but I understand it's a bit daunting.

#debian-mentors on OFTC can help with contributions to Debian.

Yes. See that KDE makes this easy with bug reporting built in to applications and desktop tools.

Debian has reportbug and reportbug-ng.

I know that when I google an error code and somehow find a bug from debian it's always often obscure mailing list archive.

If I google a docker error code, I often end up on a github issue.

It is not Debian's fault that Google prioritizes ad ridden mailing list mirror links over the neat & clean bugs.debian.org pages.

There's already a git repo for every package.

    % apt-get install dgit
    % dgit clone foo-package