Re: Paths into Debian

[Lucas Nussbaum <lucas@debian.org>]

Hi,

On 22/09/13 at 12:46 +0200, Daniel Pocock wrote:
> - I've started creating wishlist bugs in my packages, these provide
> useful coding tasks for people, especially students.  They are
> particularly useful for GSoC applicants, because they need to
> demonstrate their coding skills during the selection process.  Even
> maintainers who have no time to interact with GSoC or anything could
> still create such bugs and tag them in some way to provide entry points
> for people to start contributing.

Did you tag them 'gift'?
https://wiki.debian.org/qa.debian.org/GiftTag

Tagging them 'gift' makes them get listed in how-can-i-help.

> - the github fork and "pull request" phenomenon.  It is tremendously
> easy for people to contribute what they want.  There has been some talk
> about getting something like Gerrit into Alioth, that may help us in
> that direction.

Alternatively, maybe we should review the current process for one-shot
patches. Assuming that someone wants to fix a typo in a package and
submit it as a patch, the current simpler process is (TTBOMK):

1. 'debcheckout packagename' (but this fails when the package is not
maintained in a VCS. maybe it should fallback to using 'apt-get
source'?)
2. Build a source package, so that we can run nmudiff later:
   'dpkg-buildpackage -us -uc -S' or 'git-buildpackage -us -uc -S'
   (depending on the Vcs used.)
3. 'cd packagename'
4. make the change (which might involve adding a patch with dpkg-source
   --commit, depending on the source format version used)
5. dch --nmu; enter comment
6. build package (and test, obviously)
7. nmudiff

There are lots of variations depending on whether the package is
maintained in a VCS or not, on the source format version used, etc.

Steps 1 and 2 could clearly be improved:
- debcheckout could automatically build the source package
- debcheckout could use gbp-clone instead of git clone, so that the
  local pristine-tar branch would be set up to track the remote
  pristine-tar branch. (a warning is displayed by git-buildpackage,
  though apparently a correct source tarball is generated, so maybe
  the warning is harmless and should not be displayed?)

Additionally, the fact that one needs to think about the source format
version used in step (4) makes things quite inconvenient (though I don't
see how this could be fixed).

Using nmudiff in step (7) is also a bit cumbersome if someone just wants
to submit a patch.

Lucas