dubuntu-team team mailing list archive

[jay <jay.27182818@xxxxxxxxx>]

hi charl

i think we both need some time to make enough research and get used to
new tools. i agree on using anjuta and glade. what about cvs, i think
it's too old for today. maybe svn? i don't insist but many projects have
already moved from cvs to subversion or are on this way (freebsd is an
example though they still maintain their cvs repo).

as i see there won't be much progress in development for some time but
at this point we can do this:
- create blueprints
- design gui with gimp or inkscape to figure out what i may look like
- define some basic scheme for scm structure: what layers it will
contain etc. though we both don't have enough understanding of how many
things work we do can split the whole project into several components
e.g.
ui,
apt,
network,
database,
plugins
and at least define directory layout. of course we will probably change
many things while we make our progress but by the moment when we decide
to get down to real coding we'll already have a strong vision at the
whole structure of the project.
- create some docs, a glossary for instance. as we are developing a
brand new model for software management we need to introduce some new
terms but on this way we must be accurate and coordinate our efforts. i
think we can create a special page named 'glossary' or something like
this in our wiki.

best regards,
jay

On Thu, 2008-12-11 at 07:14 +0200, Charl Wentzel wrote:
> 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
> 
>