[xen-tools-dev] Filesystems and your project goals

[Axel Beckert]

Hi,

On Sat, Jul 24, 2010 at 09:53:32AM +0200, Stéphane Jourdois wrote:
> 2) Moving make_fs_* options to conf is not as trivial as it could be, as  
> we still have to name each filesystem. Adding a filesystem implies to  
> modify the script and the conf, I would love a solution where only the  
> conf has to be modified.

Yeah, sounds like a good idea.

> 3) I can't find a generic enough tool to create any filesystem. Do you  
> think using parted would be a good idea (one more dependency...) ?

Hmmm, is parted also able to create proper fstab entries, i.e. with
the right default parameters or so?

> 4) I'm not sure this is necessary/wanted for a 4.2 release. xen-tools is  
> primarily for production use (please correct me if needed),

No, you're right.

> where you don't use fancy filesystems anyway.

I wouldn't say that although it is definetely not the default case.

> btrfs should be added though.

Yes.

> Now some timeline questions :
>
> 1) Is your goal to release 4.2 any time soon ?

Soon. Preferably before the Freeze for Debian Squeeze which maybe in
August.

At least I'd like to publish another beta or release candidate next
week (i.e. before the Freeze).

> 2) Should we stick to first TODO items ?

Preferably. The faster we have a 4.2 we can focus on a 4.3 or 5.0 with
bigger changes.

> 3) Would you mind moving this filesystem item in 4.3 release goals ?

Not really anymore.

> 4) I really think that Steve's aborted move to Xen::Tools was a  
> necessary step in the project as it would provide a lot benefits :

Sure. I must admit, that I didn't notice that Steve just started them
but didn't manage to finish them.

But OTOH one of my plans was to massively reduce all that code
duplication which also made headaches here for us already.

>  - Permit a lot of code refactoring,

Yep. One of the main points of a bigger major release. We probably
won't manage that before the freeze for squeeze.

>  - Permit use of xen-tools in other frontends (as in a cute web page),

Interesting idea. Steve used it partially that way.

>  - Simplify code modification (4333 lines for xen-create-image...),

Yeah, belongs to refactoring and reduction of code duplication.

>  - Only implies non-visible changes, so no changes in the frontend, no  
> compat issues,

That's an interesting thought. But I don't believe we will manage to
release e.g. 4.3 with tons of refactoring but without any visible
improvement.

>  - Last but not least, that is the current /perl way of doing things/,  
> and adding those modules to perl CPAN would provide a great visibility  
> for your project.

Yet another interesting idea I haven't thought about it. But yeah,
that's an quite obvious step. First I should check if my CPAN account
still exists.

>  - _really_ improve testing (as in 'make test'), as we can then test  
> each perl function provided by the modules, and test functionalities,  
> not only code styling issues,

Yeah, that would be important for refactoring.

> Now, I am willing to implement this step, but only of course if you
> want me to do it.

I at least liked a lot what I've seen in code from you. Especially the
caring comments if you weren't sure if the commit would be ok.

> I estimate the work needed for about a couple of weeks. I imagine
> you'd want to release 4.2 before and then do this move for a 5.0+
> release.

Indeed. If we want to start earlier, we should make a seperate branch
for that.

> /me going to do some research about locales configuration in each  
> supported distribution, now :-)

Oh, neat. :-)

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe at deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe at noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)