Argh. In Evolution, the "Edit" menu is perilously close to the "Send" button on the toolbar, so an unifinished copy of this message was accidentally sent to the list first. Please ignore that one and respond to this one instead. 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: "Hi. I'm setting up Debian Jr. for our family. Should I be in the junior group, or is that just for my kids?" The other trackers might come in handy, too, though, for bugs, featur requests, and patches for unreleased code (or unreleased branches). Currently, however, I don't see any need for them for Debian Jr. > - Managing: Manage the whole CDD (release and Co. issues, including > liveCDs) Sounds good. > 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 I agree, except actually there would be several documentation projects. These are each likely to have little, if anything, to do with each other. Thus, there would be the CDD Documentation Project, the Junior Documentation Project, the Med Documentation Project, and so forth. Ben
Attachment:
signature.asc
Description: This is a digitally signed message part