On 22/01/08 at 11:41 -0500, Michael Stone wrote: > On Tue, Jan 22, 2008 at 04:20:51PM +0100, Lucas Nussbaum wrote: >> OK, let's try to be on the positive side. > > That would be great. > >> I noticed that the status of coreutils since to be a bit problematic. >> Since some people are interested in helping, could you please describe: >> >> - how people could help you improving the situation (where should they >> start?) > > Nowhere, really (unless somone wants to check the status of ancient bugs, > but there's never been anything stopping someone from doing that.) I will > note that it isn't at all unusual for old required packages to have a lot > of ancient bugs.
Sure, some old packages have a lot of bugs, but many old packages, even important/required ones, have a good status wrt bugs. >> - what are your plans for lenny. do you plan to release with coreutils >> 5.97, or 6.X? If 6.X, what's your timeline? Do you know when coreutils >> 6.10 is expected to be released? > > 5.97 should be considered a dead branch. I had a chat with manoj about > getting selinux into etch, and let in a patch to do that. The upside was > that selinux support got into etch, the downside is that it came in the > form of a huge patch that makes it extremely hard to keep in sync with > upstream. The reason I did that was that upstream support for a variation > on the patch was expected soon, so it was expected that the selinux > supporting version of 5.97 wouldn't be around for very long. I experimented > with forward porting that patch to the 6.0 series before etch was released, > but decided that the risk of destabilizing etch was too high and backed off > that approach. (That was, IIRC, during the only partially enforced freeze > on essential packages.) The upstream release supporting selinux took a bit > longer than anyone expected, but should be done soon. Again IIRC, there > have been two branches upstream, one with the selinux support and another > which was the source of the past few 6.x releases. I've packaged a couple > of snapshots to make sure there aren't any major showstoppers, and have > considered sending one of those to unstable. At this point I haven't done > that because I think that the rate of churn has been too high for a > required package. The possibility is still open, but I don't expect the > current situation to continue much longer so I'm not too worried about it. > I think 6.10 should drop in fairly easily and a whole lot of bugs which are > currently marked fixed-upstream will be closed. > >> - regarding bug triaging, should the efforts be targetted at cleaning up >> the status for coreutils 5.97 or 6.X? > > The latter, once 6.10 is released. > >> - regarding team maintainance, which organization would you like? would >> an svn repository in the collab-maint project work for you? > > Look at the number of debian-specific patchs to the 6.10 snapshot; I really > think that a vcs is overkill. One of my major goals has been to get the > number of debian patches down to zero, and I don't see anything that leads > me to believe the package needs to go in a different direction. (In general > I try to push patches upstream quickly, and they're generally integrated > upstream quickly, and the debian package is then updated to reflect the new > upstream version. That process has been hampered by the selinux > integration, but again, I don't expect that to continue much longer.) OK, all of this sounds very good. Regarding the VCS, I'd personally prefer to use one, since it tends use ease coordination, but this can be discussed again later. So it seems that something where you could use some help is going through the old bugs. I noticed that you have quite a lot of old bugs tagged wontfix. Why not close them if they are never going to be fixed? They can be unarchived if it's necessary. I don't think that we need to wait for 6.10 to be released to start bug-triaging. We can Version-close the bugs using the experimental versions. This way, when 6.10 is released, you just have to include the 6.10~XXX entries in the changelog, and the BTS will automatically understand that those bugs are fixed in 6.10. And we can use http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=coreutils;dist=experimental;arch=i386, which understands version tracking. I looked at the packaging, and noticed that you are using dbs. Have you thought about moving to cdbs, which seems to be in more widespread use in Debian? -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

