On Sun, 2004-07-11 at 17:48, Cosimo Alfarano wrote:
> All discussions are supposed to be taken on d-custom@l.d.o list, I think
> Ben has redirected some email from tracker/tasks system to the list for
> the same reason.
I have not yet done this. Each Tracker and each Project has a field for
entering an email address for this purpose. I will use debian-custom
here for each project and tracker I create.
> >From my point of view at least three macro areas of developing may be
> found:
>
> - Packaging: Package something inside a CDD (cdd-dev, debconf, cfengine
> & Co)
This is fairly straightforward. Where a group of cooperating packages
is involved, I think a single project will suffice. So, for instance,
even though my junior-* packages currently each have separate sources,
if I were to create a project for them, they would all go under a common
project, called, e.g. "Junior Metapackages".
> - Maintaining: Maintaining packages in a CDD (PTS/BTS & Co. services to
> track packages)
Initially packaging and maintaining are really two phases of the same
kind of project: packaging. In support of maintenance of my "Junior
Metapackages" project, I would combine PTS/BTS, subversion, and some
subset of possible Trackers to carry out this work. Looking at the
available trackers, there are:
Bugs (covered already by BTS)
Support Requests
Patches (covered already by BTS)
Feature Requests (covered already by wishlist bugs in BTS)
Support Requests are the only of these four that is not covered bythe BTS. Where these might apply to "Junior Metapackages" is the following hypothetical request:
> - Managing: Manage the whole CDD (release and Co. issues, including
> liveCDs)
>
> We should analyze them (adding, splitting or whatever you think useful :),
> with the final target of identifing a good set of subprojects to start
> working on
>
> A Task is associated to a subproject and usually have a starting and
> ending date (or better is supposed to be completed in a finite time
> period).
>
> Usually there are several ways to see a problem, for instance
> should Documentation be a subproject with a task for each thing to
> document, or a simple task inside of each subproject?
>
> I think it's a subproject, since it hasn't to be completed, and has task
> like "Documentaion of release X" or "Y Conference report".
>
> So I propose at least
> - Documentation Project
>
> We wait for your comments :)
>
> cheers,
> c.
> --
> Cosimo Alfarano, kalfa at {bononia.it,debian.org,cs.unibo.it}
> 0DBD 8FCC 4F6B 8D41 8F43 63A1 E43B 153C CB46 7E27
> foaf://www.bononia.it/~kalfa/foaf.rdf
>
Attachment:
signature.asc
Description: This is a digitally signed message part