dubuntu-team team mailing list archive

[Charl Wentzel <charl.wentzel@xxxxxxxxxxxxxx>]

Hi Jay

At this point I'm out of my depth.  I'll have to go and do some research
first to get a much deeper understanding of all the tools.  I'm aware of
most, but I don't know enough about them.  You seem to know what your
are talking about and everything you've proposed sounds very reasonable
to me. But, I want to be in a position were I can agree based on my
knowledge not because it sounds right.  

Please give me a little time to do the research.  But hey, don't stop
sending comments and proposals just because I'm doing some reading.

As far as the development environment is concerned.  I've only every
worked with KDevelop, so that's all I know.  But I've been wanting to
broaden my experience and have looked at Ajunta.  It seems to be very
popular among Ubuntu projects, and has everything I normally use.  So
why don't we both try something new... Ajunta + Glade then?

This is where it would be nice to already have our installer :-)  Of
course, this could be our first trail.  Getting our installer to
properly install our own development environment!!!

I've suggested GTK+ as it is used by many applications (it was initially
developed for GIMP).  It is thoroughly integrated into Gnome and as this
is the default desktop for Ubuntu it seems like a good idea.

The user interface concept looks good, but we'll need to add an
"explanation/help box".  As you move through the option it must explain
what it is about.  There might actually be some newbies out the that
does not know what an IDE is!

Of course, we we add some graphics to our installer we can add a
progress wall instead of a progress bar.  Every time you complete a
step, another brick is laid in the wall.  (Way to early for this type of
suggestion, but I couldn't resits).

There are many repos, even google has one.  I'll have to do some
research on this.  Brad also suggested some repos to me.  I've only used
CVS on a local server, but apparently there's a much bigger world out
there.  

There's of course two things we need to back up, preferably
separately.  
a. the source code
b. the Ajunta projects (or whatever we use)
This way anyone could easily use any development environment they choose
without cluttering the source code.  I do the same on CVS.

There's a lot of research to be done here, but hey... isn't this what
it's all about for a project like this?  The more we know the better our
installer would be and the greater the experience of the users!

PS: The "SCAM" name was just a joke.  I really don't want that name like
to our project! :-)

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: Thu, 11 Dec 2008 03:26:41 +0200


i agree with your idea of installer. but anyway we'll have to make a
pure devbuntu distro because not everyone will like to first install a
number of packages during general installation of ubuntu/kubuntu/xubuntu
and then delete/replace them as it's time consuming and our goal is to
save users' time as well. and you will also have to use two cd's instead
of one. for newbies it will be much easier to install an integrated
distro that will carefully guide him/her through the entire installation
process. but it's not something of great importance so we can safely put
it off until we're done with the configuration manager.



i've suggested to replace synaptic because it's the configuration
manager whose job is to extend current configuration. if you want to
manage entire configuration from one place then you either use synaptic
or scm - not the both. if the configuration manager is capable of adding
new packages to existing categories and creating new
mega/metapackages/package categories it will provide a great way for
users to share their configurations in form of patches for existing
megapackages or as brand new ones (in form of XML or JSON files; i stand
for JSON as it will save traffic (and thus time) still remaining human
readable, and will simplify online editing with javascript). if we
implement it carefully there will be a boom of new subdistros and
everything else as everything that you need will be a preinstalled
configuration manager and our website or any other site with a
compatible web-service. our role in this process will be to approve some
of thirdparty patches and create new ones to keep the official selection
up-to-date. but everyone who won't agree with us will have enough
freedom to create an alternative solution. what about synaptic, afaik,
it doesn't use any 'pure' database like mysql, but scm will use a such
so the entire synchronization between the two can be implemented just as
dumping scm database into synaptic's configuration files (maybe to apt
ones as well). i guess it won't be too hard (we could implement it as a
plugin for example; maybe we'll make another plugin that will import
current configs into the database as a separate megapack or such).
if i get it right we have most of synaptic's functionality implemented
in apt libraries so we really shouldn't avoid replacing it. today
synaptic is not the best thing one can imagine as a package manager - it
'thinks' too long because it doesn't use any pure db like mysql, it
doesn't allow bittorent or other download managers to survive while it's
doing its job as it doesn't have anything like a pause button. if we
succeed we will provide users with a more user-friendly tool that will
allow you to manage your configuration from one place (with synaptic you
still need to add repos via another program). finally as we are free to
implement anything in scm we will be able to make it embeddable into
another gtk based apps like ubuntutweak or such making the invention of
a 'pure' control center for ubuntu more feasible. in short, if
everything goes fine we will bring software management process to
another level while staying compatible with the whole ubuntu world.



> 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.

> 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.

installation process will start at megapackage level and go down to the
package level so even pros will have entire freedom of choice. maybe
we'll provide them with a synaptic-like look at the list of available
packages so that they'll just pick up some packages they're aware of
instead of searching for a certain catergory these packages belongs to.
but this can be implemented as a plain search function - nothing
complicated when you use mysql. by the way here's a simple scheme of
possible ui:

______________________________________________________
|                    |                                |
| navigator:         |  list of package categories:   |
|                    |                                |
| list of megapacks  |  [x] compilers                 |
| developer studio   |  [ ] ide's                     |
| >> cli development |  [x] documentation             |
|____________________|________________________________|
|                                                     |
| [save]               [root][previous][next][finish] |
|_____________________________________________________|

the navigator column shows how far from the root you are at the moment.
every item in it is clickable so you can move to any upper level
instantly. in the 'list of package categories' you are shown what
categories belong to 'cli development' metapackage and in which ones
you've installed something. next/previous/finish buttons implement a
step-by-step approach desirable for newbies and annoying for pros. also
we'll add a special area for descriptions of every step that will guide
newbies.
btw. adding a package that's not selected by us yet will be as easy as
adding it's name, version, repo (an apt line) i.e. everything needed to
install a package with apt. and you most probably won't have to type it
in as scm will provide you with an autocompletion feature.
bookmarking feature can be used to save you current position.



i also think that blueprints will help us but we must first clearly
outline some basic concepts they will reflect. by the moment we only
have a concept of installer. well, let's add an approp. blueprint. how
to add them by the way? i'm very new to launchpad.



what about gui development - almost the only thing i didn't try on
windows was mfc. i had a very big experience in gui development
including everything from writing gui apps in MASM and other assembly
flavors to playing with .net classes in c# and vc++. but on linux i only
worked with xlib and never touched gtk. so i'll have to learn it too.
i guess at this point we can make some general decisions about what
common ide to use, what repository to use and where to store it.
any ideas on a public repo are welcome as i won't be helpful here. i
guess an svn somewhere at sourceforge will be enough. what about ide -
i'm currently using netbeans (switched to it from eclipse) but i guess
anjuta is more approp. for us:
http://anjuta.sourceforge.net/features.
http://ubuntuforums.org/showthread.php?t=295515
i'll give it a try on these days. eclipse and netbeans are also capable
of building gtk+ apps but if we decide to use glade we'll have to use it
as a separate tool when anjuta natively supports it.



what about the name, Software Configuration Advanced Management sounds
like we already have working Software Configuration Management. let's
first implement the latter;-). i agree that we need a fork here -
installer and configuration manager should not be linked too tightly (in
fact the installer will only need to invoke the manager after the first
reboot). this will make it possible for other guys to easily port scm to
another platforms.

best regards,
jay

On Wed, 2008-12-10 at 06:53 +0200, Charl Wentzel wrote:
> 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