All developers plz read this!

Mon Aug 25 11:12:58 GMT 2003

OK, my take on this is very straight forward....

1. No new features should be added to Lunar version 1.  Instead just 
bugfixing and annotation of things to change in Lunar version 2.

2. No changes to core behavior, this should be annotated as "quirky 
behaviour" and corrected in version 2.

3. Stability should be achieved with what is present, not changes to how 
it works to make it better.  That is a version change, not a bug fix.

In the past Lunar has rolled out new things as bug fixes when really 
they should be version changes in the Lunar utilities.  I am not saying 
it should be bumped to version 2x or what not because of changes to the 
core tools, but that we have not versioned the core tools at all.  
Instead the core tools have been a free flowing entity, with no version 
at all.  This for sanity reasons makes it extremely hard to track 
issues, and to say what belongs where, and when to change the way 
something behaves.  It also makes it very hard to so any serious testing 
before implmentation.  Right now our versioning is by the hour, not by 
release number, and I am not saying this is wrong, but only that we need 
versioning for the core tools.  Although we have ISO versioning the core 
tools that are used are often not the same as what is on the ISO.  So a 
Lunar 1.3.2 ISO is not the same as the core tools recieved from a "lunar 
update".   Also, when you "lin lunar" or "lin theedge" you get newer 
tools as well... especially with theedge.  There is no history, no 
rollback for users on the core tools.  What if the tools worked better 
for one person on an older version and they want to "rollback" for 
themselves?  With our current incarnation is that possible without going 
into /var/cache/lunar/ and hand rolling back, or doing a "lrm 
--downgrade" and knowing the exact hour they need to roll back to?  
Either way is kinda ugly if you ask me.  I say we _not_ focus on core 
improvements, only bug fixes (for real bugs), and instead come up with a 
design doc of things we want to see in version 2.  Many of the issues I 
have seen posted here lately will all be solved in verison 2 as I see 
it.  I have a semi working kludge written for lunar2 and Hal Fulton and 
I have talked at length on this, we would like to get a semi working 
preview for everyone fairly soon(ish) so you can see what we mean.  It 
is hard to convey across this medium what exactly we want to do and how 
we can do it.  I admit I am not that good at documentation or expressing 
what I want to achieve, but I do have plans for lunar version 2 and they 
address most of these exact issues.  I would like to see the modules 
re-written to not use logic in the DEPENDS files, and to move to lunar 
version 2 alot will have to be re-written in the moonbase.  Our current 
code count is over 5000 lines of actual code that gets sourced whether 
needed or not.  I want that lower, and our use of ENV variables is over 
the top, again, I want that lower.  I want all menuing and gui to be 
"addon" not part of the core.  I want more functionality of the core 
tools, and by that I mean to not force people on taking any option they 
dont want, while at the same time giving people the option to take all 
the options they do want.  In doing this I want to not have to answer 
any question again without using "lin -r" to say I want to reconfigure.  
That is the only time other than the intitial install I want prompts for 
anything.  We pride ourselves on speed, bloat is the antithesis of 
speed, but in some instances it is needed, even wanted.  So that should 
be an option, but not the default.  No matter how you want your system 
that should be remembered and the build go accordingly from then on 
until you say I want to reconfigure.  Again, clean up modules, fix bugs 
in v1, but do not look for v1 to evolve.... it should not evovle beyond 
its current state.  Instead lets sit down and come up with things we 
want to fix/improve/add/remove and charge ahead with version 2. 

Jason Johnston
aka... Xoritor

Chuck Mead wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> <csm> the DEPENDS in many of our modules are doing things that make it
> difficult to impossible to move forward with lunar2
> <csm> we have to stop doing logical code in the DEPENDS
> <csm> so make it gtk2 and assume everyone wants everything... libical 
> etc.
> <csm> our "if" logic needs to come out of those DEPENDS files
> <nhudson> ok np
> <csm> and that means *ALL* DEPENDS need to be changed for this... no
> logic in DEPENDS
> <csm> in short it was a good idea which is unsupportable over the long 
> haul
> <nhudson> ok well I think that is the only module with logic in the
> depends file but I will look over the moonbase and find out if there are
> anymore like it
> <csm> okay
> <csm> anyplace we have it... "max_options" become defaults
> <csm> if you see what I mean
> <csm> if there is a way to do it in BUILD that's fine (maybe) but if you
> think about it that may raise serious issues as well
> <csm> there are many, many builds that may have to be re-written to make
> the jump to lunar2
> <nhudson> well frankliy I am tired of being asked do I want to install
> this or that 400 times in a module
> <nhudson> I would just rather have everything installed for it and be
> done with the module
> <csm> yes... and in fact the *RULE OF LAW* with virtually every other
> AMS in existence is that it must run/install completely automagically
> <csm> RH would have the head of any dev who did that on a silver platter
> <csm> for instance... the nano install was recently reworked to ask
> questions...
> <csm> I say no questions but max options by default
> <nhudson> yeah I agree, I dont care how many deps it has just install
> them and be done with it
> <nhudson> well I will get started on that this afternoon
> <csm> okay... and glad you see my point
>
> - --
> csm
> Lunar Project Lead
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQE/SOTBq3bny/5+GAcRAjYpAJ9Z8O7OIWKBrpU4yKxFE+INuMmj9ACeNGNy
> 0/x+LKCdna2hGhkMFS+8lp4=
> =fZH9
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> lunar-dev mailing list
> lunar-dev at lunar-linux.org
> http://dbguin.lunar-linux.org/mailman/listinfo/lunar-dev
>