New server stacks suggestions

Registered by Chuck Short

This session will discuss potential new server stacks that are not covered elsewhere during UDS. Please feel free to suggest anything (add to the whiteboard below) and come prepared to discuss it (including necessary unpackaged dependencies) during the session.

Blueprint information

Status:
Started
Approver:
Jos Boumans
Priority:
Low
Drafter:
Chuck Short
Direction:
Needs approval
Assignee:
Chuck Short
Definition:
Approved
Series goal:
Accepted for maverick
Implementation:
Started
Milestone target:
milestone icon maverick-alpha-2
Started by
Chuck Short

Related branches

Sprints

Whiteboard

Status:
samba-vscan is no longer necessary since samba ships scannedonly vfs module
zafara has already been packaged for the partner repository.
sogo/sope is not in a state package wise where it should be included in the archive. I have emailed the developers with suggestions.

Work items:
Port samba-vscan to 3.5.2: DONE
Create samba sub-package for samba-vscan: DONE
Review requirements for sogo with upstream: DONE
Upload sogo to universe if appropriate: DONE
Review requirements for zarafa with upstream: DONE

ttx review / 20100526:
 * I'd consider Zenoss, Liferay to be outside the scope: they need to be engaged by packaging partnership deals before they can make it to universe or partner
 * Spice should be part of a separate blueprint, fully driven by RevolutionLinux guys
 * Did we have confirmation on how desirable samba-vscan was, given that we'd have to maintain it specifically in Ubuntu ?
 * I don't see Zarafa in the spec anymore, should it be considered as sogo ?
 * Suggested assignees: zulcss / ?
 * Estimated complexity: 3-5 ?
 * Suggested priority: 3/Low
 * Suggested Subcycle: Iteration 1 or 2 (Alpha2 or Alpha3)

jib review 20100526:
 * Seconded the above
 * I'd like to see an estimate of work specifically on samba-vscan; if it's low hanging fruit it's a
   very interesting target
   * IMHO the cost is mostly a maintenance cost, the patch is well understood and can be applied with minimal effort, but creates a delta with debian and upstream that you have to maintain over the long run -- ttx
    + we already have a large delta and whats one more patch, doing a google search this is a wanted feature for most users.
 * Looking at the UDS outcome, most others are separate specs or partner engagements and
   should probably be out of scope for this spec.
   * I'd keep the vscan thing and simple WI to potentially review/upload zarafa/sogo, for a total complexity of 2-3 -- ttx

(?)

Work Items