[request-tracker-maintainers] 3.8 sid upload

[Niko Tyni]

On Thu, Jan 15, 2009 at 02:43:54PM +0000, Dominic Hargreaves wrote:
> On Thu, Jan 15, 2009 at 12:19:16AM +0200, Niko Tyni wrote:

> > Upgrades leave orphaned files in /etc/request-tracker3.8; is it
> > worthwhile to go through them and remove them if unmodified or warn the
> > admin otherwise? That's a bit complex for experimental, but the packages
> > have been widely announced...
> 
> I think it would be nice, but not essential (a NEWS.Debian entry would be
> sufficient). It's crud left behind, but not disastrous (unlike the
> sqlite goofup I introduce which I fixed in the last upload :( )

OTOH it's very easy to fix for most people, just putting the old md5sums in
one file and running something like

 md5sum --check --status $file && perl -alne 'print $F[1]' $file | xargs rm 

should do.

> Given that people on rt-users are interested in stablish packages,
> uploading to unstable sooner rather than later would be good, it might
> be worth having another check over the packages to make sure there
> aren't any other time bombs that could be fixed first.

Certainly, but I'd not go over the top worrying about breakage in
sid either. A soonish upload would be fine by me.

The lack of feedback on the RT packages has always been a bit discouraging
for me; it seems that people only use the current version in stable and
testing/unstable doesn't get enough testing before the release. This
may work better for the next release cycle because 3.8 isn't going to
be in lenny.

> > BTW, how about ditching svn and moving to git? I'm OKish with git-svn,
> > but it could be better...
> 
> Hmm, never used git, so I don't have a reason to switch. 

OK, no worries then. Let's stick with SVN, it's not that bad.

> Is there a nice
> explanation of the benefits w.r.t package maintenance anywhere?

I suppose http://vcs-pkg.org/ is the place to start.

For me the main benefit is the offline experimentation; I only push the
changes when I'm reasonably confident they don't break anything. 

Also, the svn 'mergeWithUpstream' mode is somewhat a PITA, and doing the
merge inside the git repository alleviates the pain.

I'll see about creating a git repository for my own use at the Alioth
personal webspace and gate the SVN side there.
-- 
Niko