[M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse?
Olaf Wagner
wagner at elegosoft.com
Tue Sep 22 13:21:46 CEST 2009
Hi Randy, Tony, Jay and all others,
thanks for your updates. Things already look better in Hudson and
Tinderbox; there may still be some script failures which need manual
intervention.
As this mail is relevant for all M3 committers, I've CC'ed it to
m3devel, too.
I understand that a major bug (race condition in pthreads) has been
fixed, but there are still some problems in Windows' threads and
Solaris' formsedit which are currently investigated. I'll try to add
some information of your summaries to the Trac roadmap soon.
I think the main problem currently for release engineering is
in procedure: we all need to agree to use the same tools and rules
for proper collaboration. I know that I may have introduced a bit
much in this respect for the small M3 community, but the m3devel list
really proved inadequate at least for me to accomplish the tasks
related to release engineering for 5.8. So I suggest we use all the
available tools (Tinderbox, Hudson, Trac) at least for this release
(and may improve the tools and procedures later). Very likely I haven't
provided enough information regarding the tool use and intended
procedure though, so I'll try to sum up some important points for
everybody (again?):
o Release engineering is performed on the cm3_branch_release_5_8.
This should decouple (stabilizing) bug fixes from potentially
destabilizing other commits. CVS is still used for version control;
the steps needed to perform merges to the release branch are
'cvs update -j rev' (two point merge) or 'cvs update -j rev -j rev'
(three point merge, general case). All merges in CVS are performed
in a local workspace and need to be committed explicitly (after
local testing, at least proper compilation).
o The continuous integration in Hudson I tried to set up during the
recent months is currently tracking the release branch and should
be used as an indicator for the release quality.
o After every commit to the release branch the developer involved
should observe the results in the Hudson CI. The lastok-build
and release-build jobs on all platforms should succeed (color blue);
some tests may be expected to fail (color yellow). None of the
main jobs should be read at any time (network communication problems
may lead to failures though, usually indicated by `failed to join
the process' in the console log). In case of any regression (build
failures, more test failures), the problem should either be fixed
or the changes reverted (until something better is available).
o Anybody logged-in to Hudson can also start jobs manually with the
build button. This should be used with case though. In general,
jobs should be triggered by CVS checkins.
o Trac is used to manage the procedural aspects of the release
engineering process, i.e. define milestones and create, change
and close tickets for issues related to bugs and other tasks.
It also contains a WiKi for project documentation and is
integrated with CVS and Hudson. It should be easy to use, but
the current setup still has some problems (manual administration
needed). Everybody who participates in source changes should also
have access to trac and update related tickets at the same time.
Indeed, for release engineering there should be no commit at all
without an associated ticket.
o The release engineer's role I'm trying to perform for the current
release does mainly include janitorial services like merging fixes,
writing scripts for package builds and tests, performing builds
and installation and other tests. This is more than enough work for
one person; others are expected to analyze failures and collaborate
by providing the changes and information needed via the established
tools and procedures. I think the current setup, though still a
bit fragile, should be a quite good base for building and documenting
a usable CM3 release. I'm not able to perform the required tasks
just based on the commit and m3devel mails (I'm often even unable
to read them all, and doubt others will do better there). So please
use all the installed tools as best as you can.
As concrete steps to continue with the 5.8 release I suggest these:
(1) Review of all open tickets and appropriate updates and comments.
See
https://projects.elego.de/cm3/query?status=resolved&status=reopened&status=assigned&status=analyzed&status=new&status=accepted&group=status&milestone=CM3+Release+5.8+RC3
and
https://projects.elego.de/cm3/query?status=resolved&status=reopened&status=assigned&status=analyzed&status=new&status=accepted&group=status&milestone=CM3+release+5.8
(links from the roadmap page of trac)
(2) Create missing tickets for problems not yet described. Add complete
information (error messages, stack traces etc.). Jay's list suggest
a couple of new tickets I think.
(3) Abandon the RC3 pacakges and retarget everything to RC4 in two or
three weeks.
(4) Retarget the final release to the end of October (at least).
Does this sound reasonable?
All help and cooperations is greatly appreciated as usual. Especially
anybody to help creating and updating tickets for everything reported
on m3devel and m3commit would be welcome.
Olaf
Quoting Tony Hosking <hosking at cs.purdue.edu>:
> I am confident that pthread-based threading is now better than it has
> ever been (there was a nasty race that has been thoroughly fixed, and
> the logic is now much simpler to understand). It runs all the X11
> apps (juno, mentor, formsedit) without problems. In sum, I think
> pthread threading is ready for prime-time. I have never made more
> than trivial changes to the WIN32 threads implementation. I don't
> know the current state of things there, but hope that our Windows
> enthusiasts can test things thoroughly.
>
> On 21 Sep 2009, at 10:46, Randy Coleburn wrote:
>
>> Olaf:
>>
>> I ran a build last night on both XP and Vista. I have not noticed
>> any new problems on these platforms. I note that Jay has added
>> more commits since last night, so I haven't tried these yet. (I
>> am pulling from the head branch for these builds.)
>>
>> Also, I note that Jay says he is going to rewrite some of the Date
>> stuff into C--again I would like to ask why, but I don't want to
>> be seen as causing problems. Perhaps he should say why he feels
>> it necessary to recode in C versus fixing whatever problem exists
>> in Modula-3. I would be willing to work on any Modula-3 coding
>> problem if given the chance.
>>
>> I am concerned about all the message traffic of late about
>> suspected problems with the threading. I use threads a lot and if
>> they aren't working correctly this is going to be a real problem.
>> I ran a quick test using one of my multithreaded programs, but
>> didn't see any problem. Unfortunately, this program requires
>> connection to some specialized hardware that I don't have access
>> to in order to give it a real workout.
>>
>> Regards,
>> Randy
>>
>>>>> Olaf Wagner <wagner at elegosoft.com> 9/21/2009 10:25 AM >>>
>> Hi all,
>>
>> I'm back again from my trip to France. Though there seems to have been
>> lots of activity during my absence, the current status is worse
>> than when I left:
>>
>> o tinderbox status is comletely red
>> o Hudson builds fail due to syntax errors
>> o no tickets have been closed or even changed
>>
>> Does anybody care to fix? It would be nice if we could at least backup
>> to the status of when I left...
>>
>> A summary about the activities/changes would be welcome. I'll need
>> some days to read all the mails.
>>
>> So long,
>>
>> Olaf
--
Olaf Wagner -- elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
More information about the M3devel
mailing list