[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

alioth patch tracker and task manager enabled



Hello,


Guillem and I have enabled the patch tracker for Alioth's pkg-hurd
project. This means that we now have a centralized place to collect
porting patches for other packages. Likewise, we have enabled the task
manager, which will hopefully cut down on duplicated work as people can
see whether somebody is already working on a package.

The patch tracker and the task manager are located at
https://alioth.debian.org/tracker/?group_id=30218&atid=410472
https://alioth.debian.org/pm/task.php?group_project_id=33&group_id=30218

It is highly recommended that you get an Alioth account. Debian
Developers have such an account automatically, others can easily create
one which will be prepended by 'guest-'.

In order to make it easy to browse through patches and keep track of
them, please follow some simple guidelines when submitting them:

1. The Summary should contain the name of the package. If there is a
   Debian bug associated with the patch already, the bug number should
   be prepended. If the patch is for something else than a build fix, a
   short description of it should be added as well.

Examples:

#218624: krb4
zephyr
#285857: dpkg-shlibdeps /usr -> . support

   If you submit an already registered patch to the Debain BTS, the
   summary should be updated with the bug number, once available.

2. Patches have a 'Category' and a 'Group'. 

   'Category' is the type of build failure:

   - 'build-env' are for general build environment problems like faulty
     configure.in files or totally missing gnu support for
     non-autotoolized projects.

   - 'debian' is for debian specific problems, like wrong Build-Depends
     or required special-casing of things in debian/rules.

   - 'posix' is for code problems like PATH_MAX or MAXHOSTNAMELEN.

   - 'linuxism' is for code assuming the only system running on top of
     glibc is GNU/Linux, or code using Linux syscalls or other
     Linux-specific stuff without checking.

   - 'several' if more than one of the above is covered in the patch. It
     might be more appropriate to split up your patch in this case.

   - 'other' if none of the above fit.

   'Group' is for the status of the patch (we couldn't choose the field
   name, sorry). Possible values are:

   - 'unreviewed' - Use this if you submit a patch for the first time
     which has not been looked at.

   - 'needs-work' - The patch is either not functional yet or not
     perfect and needs revising.

   - 'unsubmitted' - The patch has been positively reviewed but not
     submitted to the BTS or upstream yet.

   - 'submitted' - The patch has been submitted.

   - 'fixed-debian'/'fixed-upstream'/'fixed' - The patch has been
     included in the debian package or in an upstream release, or in
     both, respectively.

   Further categories and groups can be added as needed, your comments
   are solicited. 

   If you submit a new patch, you should try to classify it as good as
   possible and set it to 'unreviewed' if nothing else happened earlier,
   like in case you salvaged the patch from the BTS.

3. As Detailed Description, you should add a pseudo-header in a
   debian/control style format, including at least the following
   information:

   - 'Author:' The person who initially wrote the patch.

   - 'Source:' The Debian source package name. You can find that out by
     running 'apt-cache showsrc <package> | grep Package'.

   - 'Strip-Level:' which strip level has to be passed to the patch
     utilty in order to successfully apply the patch (e.g. '-p0' or
     '-p2'). If your patch is targetted to be put under debian/patches,
     put the proposed filename here, like 
     'debian/patches/hurd_build_fix.diff'

   - 'Status:' Mostly the group from above, but you can be a bit more
     verbose here. E.g., add the bug number in paranthesis for
     'submitted', or shortly specify what works still needs to be done
     for 'needs-work'. Also, you can put more than one here, like
     'submitted, needs-work'. 

Examples:
Status: Applied in #102991, dropped subsequently
Status: submitted(#281870), needs-work 
Status: submitted(#218624), needs-work (NCARGS)

   -  'Categories:' The same as the Categories field, but you should 
      specify all applicable categories here in case your patch is in
      'several', or clarify if you put it into 'other'.

   You can add further comments in free-form after this pseudo-header.

Exampless for Detailed Descriptions:

Author: Guillem Jover <guillem@debian.org>
Source: krb4
Status: submitted(#218624), needs-work (NCARGS)
Categories: posix, linuxism
Strip-Level: debian/patches/036_hurd

Author: Munteanu Alexandru <io_alex_2002@yahoo.fr>
Source: zephyr
Status: unreviewed
Categories: posix
Strip-level: -p2

Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Source: dpkg
Categories: runtime
Status: submitted(#285857), needs-testing
Strip-Level: -p0 

4. Add your patch with a meaningful description (its filename suffices).

5. Profit!


I hope this was not too confusing, just look at the patches which are
already there to see how it should be done.


Some other notes for working with patches:

6. If the state of a patch changes, please copy the whole pseudo-header
   in a new comment, modifying the changed bit (and possibly adding an
   explanation). See the krb4 patch for an example.

7. If you have a task manager item for that particular package you
   should build a task relation between the task and the patch by
   following that link.

8. If you review somebody else's patch, just add a comment laying out
   what should be changed, or set the patch from 'reviewed' to
   'unsubmitted' or whatever is appropriate along with your positive
   comment.


The patch tracker is meant as a tool, so longer discussions about
particular patches are probably easier to have on a proper mailing list.

Also, debian-hurd will get notifications about new or changed patches,
so people can take a look at them and review them. We can change that to
another list if it turns out to be too annoying or somebody objects.


At the end, I'd like to thank everybody who made this patch tracker
necessary in the first place :)  It's great to see people interested in
porting packages to GNU/Hurd. Keep up the good work!


happy hacking,

Michael

-- 
Michael Banck
Debian Developer
mbanck@debian.org
http://www.advogato.org/person/mbanck/diary.html



Reply to: