dubuntu-team team mailing list archive

[Charl Wentzel <charl.wentzel@xxxxxxxxxxxxxx>]

Hi Jay

Thanks!  I think we're getting to the real nitty gritty now... that's
great.  And of course the more thorough we are at this stage, the less
problems we have later on.

1. The installer
We don't have a lot of time to get the first version out if we want to
stick to the Ubuntu schedule, which is in line with my thinking as well.
The whole Ubuntu world is synchronised, we shouldn't be the odd ones
out.

To reduce the work and make things even simpler I suggested the
installer with no general Ubuntu installation, i.e. you install
Ubuntu/Kubuntu/Xubuntu/etc from the normal installation CD's, Then you
run our installer to install your development environments.  This is the
same approach taken by Edubuntu, which simplifies things a hell of a
lot.  

It also means there are a lot of things we won't have to worry about and
the users can get the benefit of all the effort and features put in by
these respective Ubuntu versions.  I believe it will create a much
bigger audience for us as most people want to use and experience the
"natural" releases of Ubuntu and only wish to customise it to their
needs.

Of course, where then left with testing our installer on the pre-release
versions of these sub-distros, which would be a lot less work.

This also take care of your comment regarding not having a filing system
to "save" your selection in, as you will be working from a fully
operational Ubuntu system by the time you start this installer.

There will then be only one program (one installer) that will take care
of everything:
- whether you run it immediately after installation, 2 years later on an
old installation
- whether you want to make a clean minimalistic install or update your
already highly customised installation
Installation and upgrade would be the same process.  And only one
installer means less work for us.

Ulitmately, we could release a full sub-distro for development, for
those who want it, but I don't think it would be as successful.

Again to simplify things, I don't wish to replace things like Synaptic.
It's a good thing, it works well and is well integrated into Ubuntu.
Anyway it is very handy in selection packages that are not included in
our "selection".  It also takes care of the upgrading of individual
packages which I think is outside our scope.

The function of our installer for now should be to simplify selection of
packages.

2. I agree with your vision of the package selector and we'll probably
have plenty more discussions on this matter.  I think to simplify this
work, we need to create a blueprint on launchpad or use the existing
blueprint by Brad Whittington (would you mind Brad?).

I do wish to keep the more detailed selection feature as this allows the
pros (whom most of the time are very "picky") to customise the selection
more.  This is an optional step which will only be suggested for Pros.
And only at this stage do you get to save your selection.

I think, we're missing each other on the "configuration management".  I
don't which to "create" packages or meta-packages inside the installer,
i.e. specify new things for inclusion.  What I meant was saving your
detailed selection.  You will only be able to select that which is
available for selection.

Does this make more sense?  The actual "creation" of the available
selection is what the development team is there for, that's us.  An
trust me, this will require a lot of late nights as it is!!!!

3. On the process of selection... I think the "process management"
concept is probably better that my "questions" concept.  If you ask
someone a bunch of questions and then provide the answers, you've simply
fed them with a spoon and they are no wiser.  If we use a logically
managed process with a description of each step, the newbie will learn
how and why everything is done.  He would learn something as he goes
along.  This will be much faster and more organised that the University
of Google.

4. I agree on the database, but I think this will evolve as we go along.
It is almost futile to try and determine what we will need at this
stage.  But we have to try none the less.  Again, maybe the Lauchpad
Blueprint facility will be a great place to manage this process... after
all that's why Ubuntu set it up.

5. I must admit, I agree on the C++.  I was kind of looking forward to
learning a new language, but it would have delayed the process.  I'm
very experience in C++, but I'm an Embedded systems/command line
developer.  I've only done GUI's in windows, not in Linux.  So there
will be something new to learn... yeah!!

6. I was also thinking that the name of the installer should not be
linked to Devbuntu as it has a much wider scope.  In fact there may
actually be scope for two separate projects, 
a. the installer, and 
b. the package selection for Devbuntu that will use the installer.

What about something like Software Configuration Advanced Management --
"SCAM"  :-D 

Regards
Charl

-----Original Message-----
From: jay <jay.27182818@xxxxxxxxx>
To: charl.wentzel@xxxxxxxxxxxxxx
Cc: Dubuntu - Ubuntu for Developers <dubuntu-team@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Dubuntu-team] package selector for devbuntu
Date: Tue, 09 Dec 2008 23:08:45 +0200


hi charl

here's my vision of the question. it's based on your proposal so i'll
just mention what's different and what you didn't explain. i'm also a
bit busy today so here's a very short explanation of my ideas.

1). what will it all look like?
first of all we have a very nice installer in ubuntu 8.10 (it's gui
based and quite simple). so i suggest to split installation in two main
steps. first you make a very basic installation of ubuntu (just a few
core packages, desktop and some utilities like gedit) with a slightly
modified default ubuntu 8.10 installer. this will provide you with a
clean up-to-date installation that you will be able to use in any way
you want not necessarily transforming it into a development environment
(maybe you will only want to play with core system utilities to gain
some knowledge in this field). then you boot into ubuntu and manually
(or automatically) run package selector.

2). Package selector. I suggest another name for this tool - software
configuration manager (scm for short). it will replace both synaptic and
software sources manager and will provide a higher level of abstraction.
it will manage current software configuration on localhost (and maybe on
remote machines as well). software configuration consists of
megapackages, metapackages, package catergories and sofware packages.

megapackage (what you call subdistro) is a set of metapackages combined
together to provide an environment suitable for a number of tightly
related activities. examples of megapackages:

- core (a set of core packages; see 1).).
- development studio
- multimedia center (listen to music, watch video etc.)
- multimedia studio (the same but with approp. editing tools)
- gaming center
- home server (web server, mail server, database server etc.)
- office workstation

each metapackage describes a certain activity (when a megapackage
describes a set of related activities). examples of metapackages inside
'development studio' megapackage:

- cli development
- gui development
- web development
- software packaging
- documenting (editors for man pages, etc. maybe even ooo.writer)

every metapackage will contain a number of package categories. here's an
example for 'cli develpment' metapackage:

- compilers
- ide's
- debuggers
- documentation
- ... maybe something else.

every metapackage, package category and package must have a good
description so that a newbie developer will not have any questions
regarding which c++ compiler to install, what ide to use with it, etc.
for example when selecting kdevelop a user will know from the comment
that it can be used with gcc. and when selecting say g++ he/she will
know that it's a c++ precompiler that's used with gcc. maybe we'll have
a special meta field that will describe which compiler which language
supports. and the order in which categories appear is important as well
- first you are likely to select a compiler and only then an ide.
management process can be implemented as a step-by-step procedure,
that's similar to your idea of questions.

so scm will provide a comfortable way for both newbies and pros to
easily manage their software configuration. i've got some idea of what
gui i will provide but i have no time to describe it here.

with scm users will be able to install, update, create and share
software mega/metapackages, package categories and packages(not sure
about creation but it'd be great to have such a feature). our web site
will provide both a web interface for humans and a webservice for scm
and other utilities.

i should mention another important thing: you suggest to have a
configuration management feature inside the installer but i think we
should keep things as simple as possible. if we add such functionality
to the installer we will make it very complex and complicate development
and debugging. giving user an ability to edit configuration both while
installing the system and after it will give an extra choice that he/she
obviously doesn't need. newbies will feel themselves much more
comfortable when configuring the system after it's successfully
installed than while installing it as making even some very basic
installation is a great stress for a newbie. also imagine this
situation: a user has made his choice about what to install but then he
decided to put it off and just make a clean installation. when this
happens during installation there's no possibility to store the choice
somewhere as there may be no filesystem on the hard drive because the
installer first asks where and what to install and only then creates a
filesystem and make other changes to the system. also if something goes
wrong it's much easier to fix errors related to system core
functionality when you first make a clean install and have an ability to
test installation at this point. also if we develop scm as a normal app
intended to run in some graphical environment it will be much easier to
test it and maybe even port it to another platform.

3). database. the database will have several tables:

- packages. it will contain a description for every package, e.g. name,
version, description, rating, repository. having these metadata scm will
be able to install packages from multiple repos without requiring user
to do add them manually via software sources manager.

- package categories
- metapackages
- megapackages.

4). i suggest using c++ instead of python. first of all almost every
linux developer knows it or at least is able to understand sources. if
we use c++ we'll be able to receive contributions from a much bigger
community of developers and we'll make our work understandable for the
rest of world. you know that most of software we may use throughout our
development process is written in c/c++ so we won't need any special
bindings to use it and if we decide to adopt some third-party code
there's a great chance that we'll have fewer problems with it.

5). release schedule. should we follow debian/ubuntu one or just provide
regular snapshots (some of them will correspond to ubuntu releases)? i
think the latter variant is more suitable 'cas you won't have to
download several hundreds of megabytes of updates when you try to
install devbuntu in the middle of the period between current and next
releases.

best regards,
jay


On Tue, 2008-12-09 at 07:32 +0200, Charl Wentzel wrote:
> Hi guys
> 
> I wanted to create a full descriptive document of the installer, but
> find myself a little short of time.  So here's a short version.
> 
> The concept of the installer is already well laid out in the wiki, so
> please read that first.  In this mail I'll focus on the conceptual
> inner workings of the installer:
> 
> Background:
> 
> First of all note that the aim is not to create a separate
> distribution like Kubuntu or Xubuntu, but rather an add-on
> installation, more in the line with Edubuntu.  Developers quickly
> understand and customise their Linux to suite themselves, so I don't
> wish to upset their already customised environment, but we do want to
> enhance it.  The installer is therefor less of a Ubuntu-installer and
> more of a "very advanced" package selector.
> 
> Another important point is that we do not want to reinvent the wheel
> and redo that which has already been done.  We would like to use as
> much of the existing framework and utilities that already exist.  This
> is the reason for it being a package installer.  Once you've installed
> it something like Adept takes over and constantly upgrades the package
> for you (or with your permission, whichever way you've configured it).
> 
> So we're left with two problem:
> - Simplifying and enhancing package selection and installation
>     This is where the installer comes in, which is described below
> - Knowing what to install
>     This is where the webstie comes in.  We don't know everything but
> there a community out there that would like to share... I hope.
> 
> Operation:
> 
> The package selector must have a bunch of questions it will ask you.
> The first level of these questions should be result based, i.e. "what
> do you want to do?".  This should have questions like:
> - Which programming language(s) do you prefer (C++, Pacal, Java,
> Python, perl, etc)
> - What type of applications do you want to develop (command line,
> kernel, Gnome, KDE, etc)
> 
> The next layer will show you a high level selection of tools (without
> too much details, based on the answers.  This could be something like:
> - IDE: KDevelop, Ajunta, etc
> - Compilers: Gnu gcc
> - Libraries: libstdc, etc
> - Tools: ValGrind, Cachegrind, etc
> - Documentation: ....
> - etc
> 
> Under each heading there will be list of options.  From here you can
> then select the specifics of what you want (or everything if you
> like). 
> 
> Inner workings:
> 
> To make the selection I suggest we use an "really big" XML file.
> Actually, I would prefer an embedded database due to the amount of
> information we will have and the speed at which we need to process
> it.  
> 
> Firstly, In this definition will be all the questions that needs to be
> asked with all the possible answers for each question.
> 
> Secondly, we will have a list of all the "package sets" you need.  For
> each set we will have the answers to the questions that is required to
> add this package set to the first level selection.  If we have a
> database, this selection can be done with a few queries.
> 
> This will be compiled from the data on the website, refer to the
> "columns" I've suggestions.  The website will contain all the
> suggestions with comments.  We can mark these suggestions as approved
> and export it directly to the installer when we release it.
> 
> Development:
> 
> It's been suggested that we use Python with GTK for the front-end.  In
> the back-end we can use apt and MySQL (both of these have interface
> libraries for Python and will drastically reduce the work).
> 
> Apt will do the interfacing to the repo libraries.  MySQL can easily
> be embedded into an applications so you don't actually have to install
> MySQL server or clients to use the database.
> 
> If we do the website with MySQL as well, it saves having directories
> with files.
> 
> Vision:
> 
> There are two more things worth mentioning here:
> 
> - Customised selections
> We could allow you to "save" your final selection to a file, which you
> can share (hopefully on our website). These files could then be loaded
> as short-cuts so you don't have to answer all the questions or refine
> the selection again. This would allow for the following:
> a. Setting up several of your machines in exactly the same way... VERY
> QUICKLY
> b. Allow Ubuntu projects to define there development environments and
> get newbies going... VERY QUICKLY
> c. Share your "revelation" of what a development environment should
> look like with your friends.  The same way we share our videos on
> YouTube and our thoughts on blogs
> 
> These short-cuts can be saved as XML instead.
> 
> - Other projects
> A good package installer like this would actually open up a whole new
> world of possibilities for guys wanting to create add-on distributions
> like Devbuntu and Edubuntu.  They could use this installer to create
> there own "sub-distros" for other things, e.g. graphics design, making
> music, making movies, etc.  Think of the possibilities.  What we are
> doing here, or rather the way we plan to do it, is not limited just to
> development enviroments.
> 
> So what do you think?
> 
> Charl
> 
> 
> 
> -----Original Message-----
> From: jay <jay.27182818@xxxxxxxxx>
> To: Charl Wentzel <charl.wentzel@xxxxxxxxxxxxxx>
> Subject: package selector for devbuntu
> Date: Sun, 07 Dec 2008 18:51:25 +0200
> 
> hi charl. i'd like to ask you a couple of questions about your idea of
> package selector - what will it actually be? what will be the format for
> files it will produce? i can suggest this scheme but i'm unsure is it
> similar to what's on your mind or not:
> 
> 1). on some host we will have a directory with files which names
> correspond to development categories (gui, commandline, web etc.). each
> of these files will contain a list of packages that will be installed
> when user makes appropriate choice during installation process or
> post-installation tweaking.
> 
> 2). we'll have a pool for proposals on the same host - a separate
> directory with patches for appropriate files in the main directory or
> new files for new dev. categories.
> 
> 3). we'll have a web interface (a simple form or so) to approve
> proposals and some other administrative tasks. the host will also
> provide a web-service that can be used to create commandline utilities
> or gui frontends.
> 
> i didn't send this message to the list 'caz i just want to figure out
> what you mean when saying 'package selector' before sending any
> proposals to the list.
> 
> best regards,
> jay
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dubuntu-team
> Post to     : dubuntu-team@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dubuntu-team
> More help   : https://help.launchpad.net/ListHelp