[Java-gnome-developer] (no subject)
Brought to you by:
afcowie
Menu
▾
▴
[Java-gnome-developer] (no subject)
|
From: Mark H. <mh...@ca...> - 2003-12-10 13:41:48
|
Hello, Sorry for such a long email -- it is important for the java-gnome project, however, so I think it's worth it. Please send any comments or questions you have. For those of you who don't know yet, some of the gtkmm developers have proposed and in fact created and 'official' set of gnome bindings. This means that the bindings are listed on the gnome bindings web pages as official bindings [1]. Developers (and distributors and end users) will therefore be far more interested in these bindings than bindings listed in a contrib page. Being in the gnome bindings release set will show quality and commitment. It may also lead the way for applications developed with gnome bindings (as opposed to the standard c gnome) to be included in the official gnome desktop release. [1] http://www.gnome.org/start/2.5/bindings/ Java-Gnome developers have agreed in private that we should definitely do all we can to join this group. Of course, there are quite a few changes and guarantees we need to make -- we need to follow the rules [2]. [2] http://developer.gnome.org/dotplan/bindings/rules.html Summary of rules ---------------- (my proposals are in the section after this) API support NB: this is my interpretation of what we should be doing - there doesn't seem to be any official version - If we say we support a gtk/gnome module, we should support all of the latest version of it (e.g. for gtk+ we cannot leave out treeview widgets). However, small variations are acceptable, especially for cases which are exceedingly difficult to support in java, such as not including the entire drag and drop functionality - *we* choose which modules we support. We announce these in the modules list [3]. - If we want to develop bindings for a new module, we can do this without following the schedule - making our own releases when we like, but they will not be listed in the modules list [3]. [3] http://www.gnome.org/start/2.5/bindings/modules.html Release schedule We must strictly follow the release schedule [4]. Note that this includes first tarballs by 22 December, further tarballs roughly at 2 week intervals, API freeze and beta1 tarballs by Feb. 16th, and the final release by Mar. 22nd. [4] http://www.gnome.org/start/2.5/bindings/ Multiple tarballs (many developers from many projects disagree about this). We should have separate tarballs for each module we support. This is a good idea - we can assign modules to developers and more easily ensure that each module has an active developer. This will be of even more importance as the project grows to support more of gnome. Also, it is required by the bindings release set rules and will look good from that perspective. We will still create a large tarball containing everything, which is what most people will actually use. Version Numbers major.minor.sub minor = odd -- development version minor = even -- stable release There has not been a recommendation to follow upstream version numbers at this stage. Changes to be made to Java-Gnome -------------------------------- Now for the important part. This is what I think we need to be doing now: API support ----------- We should (initially) publicly announce support for glib, gtk, gnome, libglade. We then need to urgently see how much of the upstream api we actually support. The current sources are based on 2.0 releases -- there are probably many changes which are required. *please* can ppl volunteer to take a module each and go through this -- either file bug reports for any API sections which we don't support, or produce a document listing them all (if there are many). We need to produce a schedule for this and make sure it is all done properly, ideally within the next 2 weeks. This task is probably vital to our joining the gnome bindings release. CVS Hacking ----------- If there are no objections, I will do this over the next few days. Reorganise cvs: java-gnome/web - website java-gnome/java-gnome - main code tree. Includes makefiles which will build everything. { java-gnome/java-gnome/gtk java-gnome/java-gnome/pango java-gnome/java-gnome/atk java-gnome/java-gnome/glib java-gnome/java-gnome/glade java-gnome/java-gnome/gnome java-gnome/java-gnome/gtkhtml java-gnome/java-gnome/vte java-gnome/java-gnome/gconf } - These are the main source code areas. Each will contain separate Makefile.in's (the makefiles will be generated using data from jg/jg/build/), /src/java/org/gnu/... and /src/jni/ trees. These will all generate separate jar files and shared libraries { java-gnome/java-gnome/doc-core java-gnome/java-gnome/doc-glade java-gnome/java-gnome/doc-gnome } - packages containing documentation and example applications. java-gnome/java-gnome/build - scripts to automate creation of makefiles, tarballs, etc. Applications currently in cvs should be moved to separate projects -- they are too large to be classed as example applications. Having them in separate projects would also be of great benefit to them. Could somebody please volunteer to be the maintainer for each of these and create a new sourceforge project? In order to make these changes, I will download the cvs repo source and hack that manually. This will leave a few days where no commits can be mode and then everybody will have to check everything out again. It's a nuisance - but sadly necessary. I will start as soon as other j-g developers send an email saying they agree - please do this soon. Released Tarballs ----------------- (note - these will all be created by a single script, so it won't be a difficult as it sounds) tarball_name (cvs modules included) libglib-java (glib) libgtk-java (gtk, pango, atk) libgnome-java (gnome) libglade-java (glade) [ libgtkhtml-java (gtkhtml) ] [ libgconf-java (gconf) ] [ libvte-java (vte) ] [ libgnomepanel-java (gnomepanel) ] Items in brackets will be created and put on the website, but will not go in our gnome bindings module list until we are sure we can support them. They are in development. [ java-gnome (all) ] - this is as a convenience. It will probably be used by everyone, especially developers and distributors (who will then create multiple binary packages). Releases will be made: a) (for each module) When we want to. e.g. I would release a libglib module now, including changes to CustomEvents which I made recently. b) (for all public modules) When we need to create tarballs to send to the gnome bindings release group. Focus Shift ----------- At present, the focus of java-gnome has been on improving api and adding support for more gnome libraries. This has to change. We will have to work in three modes: * upgrades - upgrading existing bindings to the latest upstream API. Note that this only includes released stable modules * maintenance - fixing bugs in released modules (e.g. gnome 2.6 release series when we are busy working on 2.7). This will produce tarballs to go into gnome 2.6.x releases. Will mostly be done in parallel with upgrade work (This is not an issue at the moment since we don't have any stable releases - it will be in the future though) * development - Developing bindings for new modules (gconf, gtkhtml, panel-applet, gnome-vfs...). This will be done separately. Releases will be made, but will not be sent to gnome and will not follow the bindings release schedule (until they are complete and we put them forward for inclusion in our stable modules list) The important factor about this is priorities - maintenance then upgrades, then development - we must do things in this order. CVS Branches ------------ In order to implement this, we will have to be more clever with cvs. HEAD branch - development. This is where we will be most of the time gnome2.6 branch - created once 2.6 is nearly ready for release. j-g0.8 branch - created immediately after the cvs hacking and cleaning up from that. This will be for bug fix releases made between now and 2.6 release. (versions may change - see below) NB: having the separate modules in cvs for each upstream module will make this far easier - we will be able to branch modules at different times depending on their development. Release Schedule ---------------- We will release when gnome release schedule asks us to and also when we feel like it. IMHO, releases have been far too infrequent so far for java-gnome. The build scripts for building tarballs should make this easier. Separate modules can be released separately. We will differentiate stable and developmental releases. API changes in stable releases will only happen when they do in gnome -- every 6 months. Parallel install ---------------- We need to make sure that this is all done correctly. The java sources need modifying to load libraries including the major.minor version numbers; the shared libs need to be created with these numbers. People will want to have multiple versions of java-gnome installed - stable for their existing installed apps and developmental for their bug fixing/development/etc.. Version Numbers --------------- java-gnome 0.9.0 should be the next set of tarballs (Dec. 22nd, for gnome 2.5.1). These are our development releases. java-gnome 1.0.0 will be released alongside gnome2.6 I don't think we should follow gnome version numbers - I'm not saying why - this email is far too long already. Move away from sourceforge? --------------------------- CVS is unreliable. File releases are a lot of work - uploading tarballs to an ftp server is much easier Bug tracking is very limited I would like to apply for accounts on gnome.org for java-gnome project. In addition to solving the above problems, it would be yet another sign that java-gnome is a part of the gnome community and ppl should be using it for their applications Upstream contacts ----------------- We need to stay in touch with upstream developments more closely than we are doing at present. If any java-gnome developer is not already subscribed to lan...@li..., please do so now. Also, please keep a check on the gnome bindings release pages and more generally gnome pages. We need help! ------------- I know that many people read java-gnome developer without taking part in java-gnome development. If you can spare any time at all it would be much appreciated. I will try to help out as much as I can with new developers, I'm sure other developers will do too. The main priority at the moment is checking how much of the gnome api we implement - somebody will send another email in a few days with links to the upstream API reference, changes between 2.0 and 2.5 and our own api reference - please volunteer to look through a small section of this. Actions Summary --------------- (I'm really sorry this email got so long...) api - somebody needs to send links to all upstream apis and changes between them (any volunteers?). We all then need to check how much we currently support. We need to keep a record of what checks we have done. cvs hacking - Let me know if it's ok & I'll get to it. tarballs - we'll release more of these after the cvs hackery focus - work more on existing bindings while there are pending bug reports, then look to new libraries release schedule 22 December - tarballs. Make or break time for our inclusion in the official bindings list. 16 Feb - API Freeze 22 March - bindings for 2.6 released parallel install - need minor code modifications version numbering - let me know if you disagree my proposal above sourceforge - anyone second my proposal upstream - join the ml, look at webpages. Find out about development. Find out what API has changed from 2.0 to 2.5 Please send comments, questions and suggestions ASAP -- to be included in the gnome release set we need to move very quickly. -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... | mh...@ca... |
