On 2/17/07, Quentin Mathé <[EMAIL PROTECTED]> wrote:
Le 16 févr. 07 à 19:38, Yen-Ju Chen a écrit :
> So I think most people agree the -trunk and -stable approach for now.
> Then we can go through all the stuffs we have.
> I divide everything in four categories for now:
> 1. Bundles and Languages.
> 2. Frameworks.
> 3. Services/Private
> 4. Services/User
>
> The Build, Documentation and Themes probably go -stable automatically.
Build isn't part of the repository, it's just generated dynamically
by etoile.make to handle dependencies between modules.
I see. But for anyone who plan to grab the -stable and compile
the whole Etoile, it needs to exist.
So I think it still need to be in -stable.
> And since Developers is only for developers,
> I think it never goes into -stable.
Not sure of that. Any other opinions?
I am more thinking that -stable is for users and -trunk is for developers.
Another way to say it is that -stable is for beta release
and -trunk is for alpha and prototype.
So developers should be able to find /Developers under -trunk.
If everyone agrees this point of view,
all bug reports should target -stable, not -trunk.
And whoever want to try Etoile, we can ask them to use -stable, not -trunk.
> Let's focus on bundles and languages for now
> since there are less than other categories.
>
> ** Bundles/Camaelon: go stable
Depends on which targets we decide to associate with 'stable'?
- basic feature set complete
- code quality (readability, conformity to guidelines, polished code,
polished code organization)
- no UI visual glitches
- no UI behavior bugs
- etc.
?
We can raise the criterion along with the maturity of Etoile.
Camaelon currently work fine, no major bugs,
ready to be tested by others, especially regular users.
Of course it can be better, but to me, it is qualified as beta release.
In Camaelon, for example they are some issues: visual glitches,
behavior bugs, conformity to code guidelines, polished code (and
perhaps code organization needs also few minor improvements)…
I think everybody will agree that Camaelon will be part of any
releases starting from now, then… Should we keep it away from
'stable' but include it in 'release' ?
I think it needed to be -stable before -release.
Release is just a tag on -stable more or less.
Or we move it to 'stable' and we decide any modules that 'basically
works well' is ready for 'stable' inclusion.
I would say so.
> ** Bundles/EtoileBehavior: go stable ?
Surely.
> ** Bundles/EtoileWildMenus: go stable
Issues somewhat similar to Camaelon.
> ** Bundles/SQLiteClient: NOT go stable, probably deprecated.
We can put it somewhere else. /etoile/other/SQLiteClient along /
etoile/trunk/
Because gnustep-make start to support different file system layout,
there is no reason to have a SQLiteClient on our own.
And it is not used by anyone.
We can easily import it again from gnustep if there is a need.
So I prefer to deprecate it.
> ** Bundle/WildMenus: NOT go stable, probably deprecated ?
Done.
> ** Languages/Io: go stable ?
Not immediately, but real soon. I'm currently working on an update of
Io_unstable, latest Io ObjcBridge once merged with my own
modifications will be quite stable in term of syntax, core features
and run-time stability. However I need to submit my patches for
integration into official Io repository. After that I think we can
switch to use Io project directly (I mean getting rid of our own
build system based on gnustep-make to build Io) as you suggest it in
the past since Io build system looks really flexible now that
everything is compilated in term of dynlibs.
I would say currently we just come up a list to be in -stable.
Developers can decide when to move it in -stable.
Io currently work for at least two applications.
I would say it is worth to be in -stable.
All your further improvement can stay in -trunk until you are satisfied.
Yen-Ju
Quentin.
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
