1.0.5 Release - Lessons learned

Under development: PCMCIA, wireless, etc.
Message
Author
User avatar
rarsa
Posts: 3053
Joined: Sun 29 May 2005, 20:30
Location: Kitchener, Ontario, Canada
Contact:

1.0.5 Release - Lessons learned

#1 Post by rarsa »

I think it's just about time to start doing a post-implementation review of the 1.0.5 release.

I am happilly using it and I hope I'm not out of place suggesting a retrospective view.

Here are my retrospective views (based on many years of professional software development):

Puppy has grown from a one man show to now having multiple contributors. As with any other project, once this transition happens, the need for a process an for the management of that process becomes evident.

This process is not to force obsturctive red tape, but to facilitate communication and improve quailty, stability and continuity for the development process. It is particularly important for an open source distributed development, where the development should be resilient to the change of individual contributors.

What went right:
- Having a single final desicion maker (Barry) speeds up desicions and avoids long useless discussions.
- The puppy community (starting with Barry) is very open to new contributors and very responsive to issues and concerns from puppy users.
- There is a lot of enthusiasm from the puppy community members to improve puppy. Nothing beats a cohesive team.

What could have been better:
- There were important differences between 1.0.5rc and 1.0.5. Once an 'rc' release is out of the door, it should only be modified to fix bugs. Contributors should be confident that if they test on the 'rc' it will work on the final release. After all, that's the purpose of an "rc" release.
- No last minute untested modifications should be done for the final release. That goes for all the components that go into the CD Image.
- If the final release requires core changes (e.g. change in the folder structure, libraries, etc) It should be communicated more broadly to other developers.
- The final release should also have a buffer time for testing between the final image and the public release.
- DotPups should not make hardcoded assumptions on the existence of dependencies, files, folder structure, etc. They should rely instead on environment variables, 'which', configuration files, etc.
- Documentation should be updated by the time the release goes out.

Here are some particular examples of what I mean:

I've had to repackage the following dotpups after 1.0.5 was out the door:

vncserver:
Up until the last minute I didn't know if the final version would include fvwm95. The existing script creates an xstartup that launches fvwm95. Maybe I shoul have used a configuration file or environment variable to identify the current wm when I create the xstartup script.

JWM themes
The location for the themes folder changed from 1.0.5rc to r.0.5final. Did I miss the communication informing this?

Opera 5.0
The qt library was not included in the final image. Did I miss the communication informing this?

Please add your comments to the release. I'd like to hear what you think

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#2 Post by BarryK »

- There were important differences between 1.0.5rc and 1.0.5. Once an 'rc' release is out of the door, it should only be modified to fix bugs. Contributors should be confident that if they test on the 'rc' it will work on the final release. After all, that's the purpose of an "rc" release.
Yep, I agree with you completely.
It was sloppy project management on my part.
Just got too tempted by all the new goodies.
Up until the last minute I didn't know if the final version would include fvwm95.
I'm surprised at that. 1.0.5rc only had JWM.

Regarding relocation of jwm themes, and missing Qt, you are
quite right, they weren't communicated publicly beforehand.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#3 Post by BarryK »

Incidentally guys, the PupGet package manager can be run
from the commandline, like this:

Code: Select all

# pupget +qt-3.3.4
to install the qt-3.3.4 package.

However, normally Puppy has to reboot after installing Qt,
to set environment variables. /etc/profile has this:

Code: Select all

if [ -e /usr/lib/qt ];then #do not use -d as qt may be link?
 QTDIR=/usr/lib/qt
 export QTDIR
 PATH=$QTDIR/bin:$PATH
 LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH
fi
So, you own install script can test for qt, like above, then
could call pupget to install it, but you would then have to
tell the person to reboot -- or the script can do it.

This is all assuming that Qt will be left out. It could well be
left out of someone else's puppy creation, so even if we
decided that it must be in the official 1.0.6 release, so the
above code is a good idea, that is, something based on:

Code: Select all

if [ ! -e /usr/lib/qt ];then
 pupget \+qt-3.3.4
fi

Guest

#4 Post by Guest »

Puppy has grown from a one man show to now having multiple contributors. As with any other project, once this transition happens, the need for a process an for the management of that process becomes evident.
We do need to make some transitions.

Guest

#5 Post by Guest »

I, BarryK, made that last post.

yes, I agree, we need to get a bit more formal.

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#6 Post by Lobster »

8) . . . enter the Puppy Foundation . . . starting Friday Sep 2005 (time could be whenever - yet to work out internet time) we will be holding the PUPPY PARTY to celebrate 1.0.5 release and to formally elect a kennel of Trustees . . .

So far as he is most keen Raffy is proposed as Chair - though I will propose Barry if he wants to be chair . . .
Treasurers proposed (already has an account for Puppy) is Barry or Ian (part time drunkard)

Full details here
http://www.goosee.com/puppy/wikka/FoundationPuppy

I think on the discussion agenda is how we manage software development. Most of it is Barry - but Dotpups and all sort of modifications and stuff going on.
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

User avatar
JohnMurga
Site Admin
Posts: 555
Joined: Wed 04 May 2005, 04:26
Location: Far to the east
Contact:

#7 Post by JohnMurga »

Hey,

I think it would be nice if PERL was included by default ... The cut-down version is pretty small (a few hundred k), and it would mean that things like NdisWrapper and CUPS would work better out of the box.

It is a chicken and egg thing really, you can't really expect a user to connect to the internet to download something they'll need to set up their internet connection.

Or maybe it's just me who thinks this doesn't make sense ...

But it is nice to see a nice solid and slim version of puppy again :-)

Cheers
JohnM

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#8 Post by GuestToo »

BarryK wrote:normally Puppy has to reboot after installing Qt,
to set environment variables
there are ways that might work without rebooting

if the ENV variable is set, eg. ENV=/root/.ashrc then shell commands in .ashrc will be executed everytime sh runs

if bash is run as sh (through a symlink) it behaves like ash, and will use the ENV variable if it's there

if bash is run as bash, it will execute commands in /root/.bashrc

bash has a slightly complicated and powerful system of rc and profile files that can be set up ... i think most people put most rc stuff all in one file and source that file from the other files ... it's simpler and all that's necessary for a standalone machine
Last edited by GuestToo on Fri 30 Sep 2005, 08:24, edited 1 time in total.

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#9 Post by Pizzasgood »

I think it would be nice if PERL was included by default ... The cut-down version is pretty small (a few hundred k), and it would mean that things like NdisWrapper and CUPS would work better out of the box.

It is a chicken and egg thing really, you can't really expect a user to connect to the internet to download something they'll need to set up their internet connection.
I second that. I have the dev addon, so I automatically get perl, and it is incredably nice to be able to pop in rt2500.inf, run ndiswrapper, throw in my config files, and BAM be on the internet. I actually plan to set up my own personal network dotpup that will put in my config files, compile my drivers, and everything with a single click. How it used to be, I had to either get the drivers from bladehunter or compile them on my own in vector.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#10 Post by BarryK »

So far as he is most keen Raffy is proposed as Chair - though I will propose Barry if he wants to be chair . . .
Treasurers proposed (already has an account for Puppy) is Barry or Ian (part time drunkard)
I'll make a statement about that on Friday.

User avatar
rarsa
Posts: 3053
Joined: Sun 29 May 2005, 20:30
Location: Kitchener, Ontario, Canada
Contact:

#11 Post by rarsa »

I think it would be nice if PERL was included by default
It is included in the usr_devx.sfs file.

I have mixed feelings about including it on the base Puppy. Of course I would like it: It would have saved me to rewrite the vncserver script in shell script.

On the other hand, I prefer that the CD includes only what is necessary to run the applications that come with puppy, If someone needs something else, it should be an add-on (pu-get/dotpup). Having everything for everyone is what ultimatelly bloats the OSs.

Keep the little Puppy focused.

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#12 Post by Lobster »

I agree with rarsa - if Perl why not python. If Python why not java, if Java why not [insert Ruby, Gambas, Forth or other pet language] . . .

Puppy has assembler, C, C++, script, Tcl, PuppyBasic, XUL, Ajax. A great deal has and can be achieved with that. Many languages can be compiled or come with run times. When some dotpups appear from these other languages, then the case for them becomes more serious . . .
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

User avatar
JohnMurga
Site Admin
Posts: 555
Joined: Wed 04 May 2005, 04:26
Location: Far to the east
Contact:

#13 Post by JohnMurga »

Lobster wrote:I agree with rarsa - if Perl why not python. If Python why not java, if Java why not [insert Ruby, Gambas, Forth or other pet language] . . .
Because many of the base/common UNIX utilities are written in PERL (not Java, Ruby, Gambas, Forth or other pet language) ...

I hate PERL myself (when I've had to work with it). But my point about having to download something from the net to get the net to work stands ...
rarsa wrote:On the other hand, I prefer that the CD includes only what is necessary to run the applications that come with puppy, If someone needs something else, it should be an add-on (pu-get/dotpup). Having everything for everyone is what ultimatelly bloats the OSs.
Well ... That is the thing ... Puppy DOES include ndiswrapper, and one of the first things I did with my freshly burned 1.0.5 was put it into one of my old lappys to try and set up it's wireless only to get a nice little message telling me it wasn't functional and I needed to download the PERL package or the usr_devx.sfs.

If that had me upset and put me off the idea imagine what it would do to your average user ...

Cheers
JohnM

User avatar
rarsa
Posts: 3053
Joined: Sun 29 May 2005, 20:30
Location: Kitchener, Ontario, Canada
Contact:

#14 Post by rarsa »

Could we open another thread for this discussion and try to bring the topic back to the retrospective analysis on the pupy 1.0.5 release in this thread?

User avatar
JohnMurga
Site Admin
Posts: 555
Joined: Wed 04 May 2005, 04:26
Location: Far to the east
Contact:

#15 Post by JohnMurga »

rarsa wrote:Could we open another thread for this discussion and try to bring the topic back to the retrospective analysis on the pupy 1.0.5 release in this thread?
Feel free ... At the end of the day if no one else see's what I am trying to say I'll just have to make sure it is fixed in the 50Mb version I'm hoping to re-master (right when I upgrade the board and do all the other stuff) :? .

However, as this is the only thing that dissapointed me about 1.0.5 it really is part of the retrospective analysis on the pupy 1.0.5 release (as much as everyone might disagree with me on the specific point).

I'll go back to my cave and shut up now ...

Cheers
JohnM

User avatar
rarsa
Posts: 3053
Joined: Sun 29 May 2005, 20:30
Location: Kitchener, Ontario, Canada
Contact:

#16 Post by rarsa »

Sorry if what I said came out the wrong way. I clearly understood that the comment about perl was part of the retrospective.

My point was that it is a topic that requires it's own thread. As a retrospective point was well taken (I even commented on that).

My "let's move it to another thread" was not trying to shut-up people. It came out without thinking on other interpretations it may have. That's what I normally do in live meetings at the office, if the topic starts deviating to another important topic, it is noted as a topic to handle 'off line' or in another meeting. Just to keep the focus.

PeterSieg
Posts: 363
Joined: Wed 04 May 2005, 16:06
Location: Germany, 37603
Contact:

I agree, rarsa!

#17 Post by PeterSieg »

Hi.
- There were important differences between 1.0.5rc and 1.0.5. Once an 'rc' release is out of the door, it should only be modified to fix bugs. Contributors should be confident that if they test on the 'rc' it will work on the final release. After all, that's the purpose of an "rc" release.
- No last minute untested modifications should be done for the final release. That goes for all the components that go into the CD Image.
Just wanted to let my feelings out about this... Rarsa, I coudn't find better
words for my exactly the same thoughts about that! Thanks!

I have to say, I was some kind of disappointed, when I read, about the many changes between 1.0.5rc and the final version. As you said (and Barry agreed upon), between a releace candidate and the final version should be mostly only bug fixes. Another thing was that Xcdroast was out and the new graveman it...
I don't know both of them so I am not able to say much about that...
I also disagreed with the statement, that 1.0.5rc is for developers only?!
No, all people who are willing to spend time for testing should be highly welcome!


My suggestion to have a beta/rc version, was to get a very stable
release... I still believe we have archieved a lot here!

So next time, if Barry agrees:

* release an alpha release for first impression/testing/discussion/etc.
* decide on the inside and outlook of next release...
* when Barry thinks he's finished, release a rc/beta for testing/bug fixes
* here we need beta testers for each function like printing, internet,
hdd install, skype, etc. etc. to assure proper testing!
* after app- 2 weeks testing/bug fixes, prepare the final release.
* no changes between rc/final release except for fixing things.
(or only very uncritical additions)

* after final release, go on for next version...
* probably release a patch(pup) for lastest stable release...

I know, that we are not (yet) Suse/Red Hat :)
So we must find a good way between how we do things now and how
we could do things in the future to meet the goals:
* Keep the fun with making newer and better puppys!
* Make the users happier and the community growing with better and
stable releases of Puppys

PS
Have fun :)

Guest

#18 Post by Guest »

Actually after seeing that rc was out for a week or two (that right ?), I really disappointed with the bug list for the final release :cry: . So I guess I'll just stick with a modified 1.0.4 as it does everything I require and I know it's stable.
Was 1.0.5rc acutally 1.0.5 and 1.0.5 actually 1.0.6 ?

Looking forward to a more successful release next time around.

User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#19 Post by MU »

Lobster wrote:I agree with rarsa - if Perl why not python. .
In fact, there is a difference.
Python is quite new, Perl is extremely old and used by many programs.
I think even building the kernel required Perl until last year.

So Perl is a kind of "integrational part" of linux.

However as most Puppy-tools did not require it yet, there was no need for it.
But if several new things like these Wrappers that was talked about need it, it might be worth a thought to add it to the base-system.

Greets, Mark

User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#20 Post by MU »

I think the Problem with this release of Puppy was:

There was somuch feedback on the RC, that we might have been waiting some more days with the final release.
I actually don't see that too many new features were added.
But the features that required bugfixes were not tested long enough in the bugfixed version.

Also some of the bugs were not reported for the RC, but for the Final.

So I think it is an acceptable workaround to have a kind of "servicepack" as G2 just announced to fix last problems.

Also as lobster described, this release has a new "quality", as it includes several things contributed by external programmers.

Such a concept always tends to be a bit more buggy than a "monolithic" version made by just one person (which has less features then off course).

Conclusion:
Next time, take some more time for testing.
In the final release, inform people, they should look out for a "service pack" after one week that fixes bugs unseen before.

Greets, Mark
Last edited by MU on Fri 30 Sep 2005, 09:22, edited 1 time in total.

Post Reply