infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
Holger Levsen writes ("infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)"):
> I can totally confirm this. When people ask me how to get foo fixed in Debian
> and I start explaining the above, people role their eyes and point to this:
Yes.
> there have been a few trying to stick around but often they dont
> know where to move on, as there is no "Debian workflow", no "Debian
> manual", there's just a hundred Debian workflows to maintain a
> package and 200 manuals for that.
I would encourage anyone who has effort to work on this end of the
contributor experience to consider what dgit has to offer. dgit
provides a single git workflow for all Debian packages.
Depending on the maintainer's workflow practices, the history may be
poor, but the code is there in your git tree just like a non-Debian
git user would expect, and patches can be cherry-picked straight onto
it off upstream branches.
The dgit user does not need to know anything about the Debian
packaging teams or workflow rules or to read package-specific
documentation from the maintainer; nor do they need to know anything
about Debian source *packages* (as opposed to source *trees*).
To do a test build and install the user does need to know
some runes, and they do need to mess with the changelog:
https://manpages.debian.org/jessie-backports/dgit/dgit-user.7.en.html
(And of course if they want to change packaging they will need to know
or learn about whatever it is they're changing.)
Areas of work that could do with attention from people with relevant
expertise and effort:
* Getting rid of the need to mess with the changelog. That might
involve changes to Debian changelog practice, or better tooling (eg
yet another wrapper around dpkg-buildpackage - maybe a way to set
the version without committing? - etc. etc.)
* Pull request workflow for submitting changes. This should
eventually turn into a bug submission to the Debian BTS.
This sounds to me like it probabl needs to be a web service, but
perhaps some local client utility that looked enough like a web
page would do.
* User/contributor testing to discover other roadblocks that make
contribution tricky.
An area that I am working on myself is:
* A way to do a new upstream version that does not involve the user
having to mess with Debian source packages. Sadly I can't see how
to do this in a reasonable way without interacting with the
maintainers' git workflows; for now, I am working on a way for
maintainer(s) to cooperate using git branches as the interchange
format, with the patch stacks on upstream worked on as a rebasing
git branch.
Ian.
Reply to: