Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
<helmut.wollmersdorfer at gmx.at> writes: > The problem is, that there is demand from users to have the latest > development versions available with debian-packaging. I'll take the hit on that one. I certainly haven't been doing a good job of getting the latest drbd packaged into Debian. I was under the impression that 0.6.x was for Sarge, and that 0.7.x or beyond would be for sarge + 1 (aka etch). However, at the very least, 0.7.x packages should be sitting in experimental. > Having the debian directory in the upstream version is a little > inconvenience for the developers, and a very less inconvenience for > the maintainer (I assume), but it is a large convenience for many > users. > > Personnally I am not a great friend of differences between developer > and distribution versions, if there is no _serious_ reason. Things could be worked out with upstream to make coordination of the debian directory easier. Here are some steps that could be taken. 1) Don't put code changes in the debian/changelog. The debian changelog should only be for changes to the debian packaging, or closing bugs that have been filed in the Debian BTS. For code updates, the ChangeLog file at the base directory of the source tarball is the appropriate place for that information. It does not need to be duplicated in the debian package changelog. 2) Don't tag a package as being for unstable unless it is actually destined for unstable. Also, lets come up with an alternate versioning scheme that will interact well with Debian versioning. For example, in the current drbd-0.7.4 tarball, in the changelog there is: drbd (0.7.4-1) unstable; urgency=low Instead, I propose: drbd (0.7.4-0) experimental; urgency=low Now, lets say drbd-0.7.4-1 makes it into debian, but due to lag or whatever there is a desire to make changes to the debian directory. For that case I would recommend: drbd (0.7.4-1upstream1) experimental; urgency=low If another upstream version came out before it was packaged in debian, you could do: drbd (0.7.4-1upstream2) experimental; urgency=low etc. Now, lets say a new version of the package goes into Debian. It would get: drbd (0.7.4-2) unstable; urgency=low And then upstream could increment that via: drbd (0.7.4-2upstream1) experimental; urgency=low Hopefully this makes sense. I'm definately open to other suggestions on how to make this process better. > At least I see the necessity to have a co-maintainer for DRBD to avoid > too large time lags. I agree, and fortunately Phillip Hug is stepping up to help out. >> I would assume some people are still more comfortable using 0.6.x >> over 0.7.x, so we would want to keep both versions available. > > Maybe some users of Kernel 2.2.x or Woody want to have 0.6.x still > available. But 0.7.x is more important and the release of 0.8.x is > maybe coming within months (and not years). > For me personally, I'm sticking with 0.6.x using a 2.4.x kernel on my production systems until I get time to adequately evaluate and test 0.7.x. Having no 0.6.x version available in Debian would suck for me. Obviously, there is a way to have both packages exist at the same time in Debian. However, I think getting a 0.7.x version of drbd into sarge would be somewhat difficult. Phillip, can you shed some light on if getting a 0.7.x drbd package into sarge would even be possible?