Date: Wed, 2 May 2001 21:51:56
From: zyrnix
To: SAStk-public
Subject: [Sastk-public] SAStk future plan revision 1
Here's my tentative plan for the upcoming releases.
1. Our number one priority is to get the new file layout into a stable
condition.
2. Unit tests if the other developers are up for it (see 0.1.5.0 below).
3. Write a dialog frontend to all the user prompts.
Everyone should work on the first planned item. We need to get this out
of the way before anything else can go forward. I'd like to then work on the
tests along with any other willing developers.
The nature of our program is subject to change with every Slackware Linux
release. So we have to have a way to check to see if it affected anything
in our program. And what better way to do that than automated tests?
I think we need a more formal testing environment. Many free software
projects do not have a real way of doing automated testing. It's pretty
much read through the code and see if you see anything wrong plus doing
installs on test machines. And maybe beta testers if you're lucky.
We should still do this, but compliment it with automated testing during our
continuous integration of code. Writing test cases is not as fun as
developing the main code, but it sure leads to less hassles down the road.
It is especially important to run tests before anything is committed to
the CVS tree so we know instantly if the commit was going to break the
other code as a result. Since it's automated, it should take less than a
minute to run all the tests.
I think we should restructure the way we do version numbers. Our releases
would be 0.1.2.0 then 0.1.3.0. If we have fast security fixes or
pre-releases, they would be 0.1.2.1 and 0.1.2.2 and so on to hopefully reduce
confusion on what is a full release vs. unplanned/incremental one.
I'm thinking of the following release schedule:
0.1.3.0 - New file layout with a stable base.
This should be the same as 0.1.2.1 functionality but with the new
file layout.
Also, GPG sign all future releases along with MD5 and SHA1
checksums.
0.1.4.0 - Write unit tests for the scripts since they are now separated
into files. There is a skeleton of an automated testing system
for shell scripts under the GPL that we could base on at
xprogramming.com. It needs work before we can use it.
Also check out www.extremeprogramming.org while you're at it :)
We can use this for testing to make sure that our base system
is not compromised with new additions.
I don't know how you other developers feel about it, but I think it
is a good idea and I'm willing to help implement it. We could have
a shell/perl script called on CVS commits to automatically see if
the unit tests pass. If not, email the developer with the results
and don't commit the changes until the issues are resolved.
This can also tell us immediately if the slakpacks from Slackware
Linux affect any of our changes. It would also tell us immediately
what is failing in our scripts for new releases of Slackware Linux.
Users can also see if their local changes affect the base system in
a negative way.
0.1.5.0 - Add a dialog frontend for all questions and descriptions.
0.1.6.0 - Add in new features and go through any user submissions that are
to be added in with proper credit of course.
What do other users and developers want? Should we take on doing
kernel patches such as openwall? Auto-configure tripwire?
Testing doesn't stop with the old code either. If we want automated tests,
we have to add new ones for all newly committed code too. And for future
releases, we design tests for that future functionality so we can have a
concrete way to tell when we're done (100% tests pass).
We don't have to work serially on these projects. All developers should help
with 0.1.3.0, but they can choose if they want to help with 0.1.4.0 or 0.1.5.0
release after that.
Anyone think the above schedule is a bad idea? If so, why? I'm open to
suggestions.
-zyrnix