Ubuntu+eBox status

Tue Jan 22 13:37:05 UTC 2008

On Thu, Jan 17, 2008 at 04:06:50PM +0100, Javier Uruen Val wrote:
> > Seeing as feature freeze is slightly less than a month away, I'd
> > like to get a status update on your progress for eBox in Ubuntu.
> Well,  we have ended up running behind schedule.  I have already
> packaged most of the eBox modules for Gutsy, you can take a look at
> the announcement here [0].

I'd like to have some way to easily track your progress and also become
aware of any blockers you're encountering. Do you have this kind of
overview somewhere on you Trac instance, or could you perhaps keep us
updated with a status e-mail from time to time?

> From the functional point of view there are just a few things left to
> polish in order to have a full-fledged eBox in Ubuntu or, at least,
> with the same functionality as our Debian based version. I will
> probably fix these issues next week.

Sounds great.

> From the Ubuntu packaging point view there are a few other things to
> work out.  For example, I had to go back to apache 1.3. 

We removed apache 1.3 completely from Ubuntu as of Gutsy.

> The reason was the large amount of memory used by apache2 + modperl +
> eBox in comparison with apache 1.3: at least more than 100M.  And also
> some random weirdnesses we didn't have with the good-old apache. 

This sounds like a bug that should be fixed. Have you filed a bug report
on Launchpad (or elsewhere)?

> There are a couple more of perl modules we have packaged:
> libnet-cups-perl-0.55 and libtree-perl-1.0.

libnet-cups-perl is already in hardy. Could you upload libtree-perl to
REVU [1] so we can get it into universe? That's the usual process adding
new stuff to universe.

> There are a few other details I have changed based on your previous
> packaging work. I'll gather together these things and I'll email you. 

Ok, cool.

> You have to keep in mind that we "relax" the Debian policy in some
> packages in order to have a working version ASAP. Our first goal was
> to have a working Ubuntu version which  can be released by us. 

That's fine, as long as you keep our release schedule[2] in mind.
Feature Freeze is February 14th. New features (and packages) needs to be
in the archive by this date, so that we have a reasonable amount of time
before release to test this and fix as many bugs as we can.

> Now that we have most of it working smoothly we can pay more attention
> to the Ubuntu/Debian policy. And again, we as a project are *very
> willing* to fix whatever is needed to comply with the packaging
> policy.

Sounds great! :)

>>  * ebox-samba needs to follow the Debian policy for managing
>>  configuration files. Among other things, this means that it must
>>  preserve user changes to smb.conf. I'd like to get a status on that.
> I haven't done anything about that yet. It's now when I'll have time
> to start with that. We have to decide what we want to do with this.

> Merging eBox configuration with user configuration without an external
> tool which takes care of it can be very very tricky.

Yes, I realised this at some point, too. :) 

> Another approach is detecting if the file which is going to be
> overwritten has been modified by the user, in that case the user would
> be informed and prompted to confirm changes or cancel. I guess that
> should be the way to go with every single configuration file
> overwritten by eBox from other packages.

The best thing to do is to maintain the user's changes, but failing
that, at least it should be *very* obvious to the user that when he says
"yes, please save my changes" on the web UI, he will be nuking his
changes to files "/etc/foo" and "/etc/bar" or whatever.

> My main concern here is not the implementation but the time frame and
> if we'll be ready for Hardy.

Well, if we're not ready, we're not ready. Any ideas for a backup plan?

> > It would be lovely if we could get your current stuff packaged up
> > and uploaded to universe, so that we can begin testing, so
> > everything can be in good shape before release.
> That would be cool.

Very much so :)

Ideally, your development team should become MOTU's so that you could
maintain this yourselves.

[1]: http://revu.tauware.de/
[2]: http://wiki.ubuntu.com/HardyReleaseSchedule

-- 
Soren Hansen
Ubuntu Server Team
http://www.ubuntu.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20080122/3a601d92/attachment.pgp>