[request-tracker-maintainers] Re: First rt3.4 upload?

[Niko Tyni]

On Fri, Jun 16, 2006 at 09:21:42AM +0200, Toni Mueller wrote:
> 
> > There's version 3.4.5-1 in the Alioth SVN repository, including
> 
> I'm still wrestling with Alioth, having no experience with it, and
> found that the project page only has a CVS link which shows 3 year old
> code. The CVS tab should probably be replaced with an SVN (or general
> SCM) tab...

I disabled the CVS tab for now. I don't know if it's possible to have
SVN there.

See http://wiki.debian.org/AliothSVN for information on the SVN
repository.

> Maybe I find time this weekend to look into it, but I can't promise
> immediate upload.

That would be great.

> > I'm missing something, like eg. rt-mailgate?
> 
> Likely, as otherwise, you end up with files unreadable by the web
> server when they should be, which is bound to give "inconsistent"
> results...

Hm. It might be rt-crontool; that's not run by www-data and wants
to use RT::Logger (through RT::Interface::CLI).

I don't see the need for the setgid bit in the mason cache directories,
though.

> > (Toni: I'm CCing you as you don't seem to be on the list.)
> 
> Umm... can you please put me on the list, then? Can I do it myself?

Sure you can. Just check the Lists tab on Alioth when you're logged in.
I guess it's best if you subscribe yourself. The direct URL is

http://lists.alioth.debian.org/mailman/listinfo/pkg-request-tracker-maintainers

I don't know how to make the list public, though. The mailman information
on the list says it's run by dopey, and its administration needs a List
Administrator Password, which I don't have. Oh well.

> I think there are two points of interest:
> 
>  * rt 3.4.5 should be uploaded ASAP to prevent the package from falling
>    out of the archive. Also, if nothing else changes, this package
>    would then be the fall-back for etch.
> 
>  * We're still some 5 months away from etch, as far as I can see, and
>    if it's possible to make rt 3.6.x go in (and if 3.6.x gets enough
>    positive/little enough negative responses), then we should try to do
>    it, no?

Yes, this makes sense.
 
> I'm still a bit wary about Perl dependencies - despite a statement in
> the upstream source that 3.4.5 requires only Perl 5.6 or so, I have
> other statements saying that it requires at least Perl 5.8.7 (or 5.8.8)
> due to a restriction on one of the DBIx modules.

The perl dependency is currently hard-coded as >= 5.8.3. If that's not
correct, it should of course be fixed. I'll look into this a bit later.

Cheers,
-- 
Niko