6:26 a.m.
Hi Gang!
Well, the first release is out the door. It's gonna take a few more
of those before that becomes 2nd nature, so please bear with me. I'm
sure I'm going to make some mistakes. :-)
The hardest thing I found with doing the release was writing the
CHANGES-Beta file. From now on I am going to try to keep it up to
date as the patches go in. If anyone wants to include a CHANGES-Beta
entry with their submitted patches, that would be fantastic. But
please, don't feel obligated to do that.
Other Points and Thoughts:
=========================
Build Reports:
-------------
I'm going to try to keep a database of the submitted build reports to
see what kinds of invaluable information we can learn. Is there
anyone who could set up a PostgreSQL database to do this for me?
I'd like to encourage you all to send in a build report _every_ time
you build XEmacs. The more data I can gather the better the quality
of the information that can be gathered from that data.
Patches:
-------
I'll do my best to review as much as I can but if you read "Steve's
TODO list" on -design you'll understand that I'm going to be pretty
busy.
Bug Reports:
-----------
I want to keep on top of these. My goal here is to make sure that no
bug reports get forgotten and that they are all dealt with.
Release Frequency:
-----------------
I've seen and heard promises of weekly or fortnightly releases from
previous XBRM's. I'm not sure that I want to make such a promise.
Besides, if I don't promise the world you won't be disappointed. :-)
What I will say is that there will probably be more releases than
we've had recently.
Also, I want to co-ordinate with the "Big Players" so I can put out
releases just prior and just after major changes. Our current "Big
Players" would be: Ben Wing, Mike Sperber, Andy Piper, and Jerry
James.
If you guys could give me a quick heads up prior to big changes I'll
do my best to get a release out before the change. And shortly
afterwards so people can test it.
Snapshot Releases:
-----------------
Do we want them? I could probably set up a script to run from cron on
my account on Tux to do a cvs up, then build a tarball each night. I
won't do this unless people think it'd be a good idea.
Feedback:
--------
I want it! The good, the bad, and the ugly. If you think I'm doing a
terrible job, tell me. I'm an Aussie and I guarantee that you can't
offend me, so don't hold back. Of course, I'd like to hear good
things too. :-)
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
9:54 a.m.
Steve Youngs <youngs(a)xemacs.org> writes:
Bug Reports:
-----------
I want to keep on top of these. My goal here is to make sure that no
bug reports get forgotten and that they are all dealt with.
I would strongly vote for some kind of public bug-database. Perhaps
Bugzilla is a bit too big but something like this. I'd think of this:
Bug-ID | Date | Status | Importance | concerned versions | Platforms | Description
where Bug-ID is a unique identifier
Date the date when the bug was submitted
Status one of new, confirmed, not reproduceable, fix postponed (because
something different has to be done first}, in work or fixed.
Importance perhaps something like cosmetic, normal, critical
Concerned versions the branches which are affected and the version /
date when the bug was introduced
Platforms the platforms where the bug is active
Description a short description about the symptoms of the bug and a link
to the full bug report and the steps how to reproduce it.
I'm no coder, but if somebody volunteers in setting this up, I hereby
volunteer to help keeping it up-to-date.
MFG Frank
--
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.
3:40 p.m.
|--==> "FS" == Frank Schmitt <ich(a)frank-schmitt.net> writes:
FS> Steve Youngs <youngs(a)xemacs.org> writes:
>Bug Reports:
>-----------
>I want to keep on top of these. My goal here is to make sure that no
>bug reports get forgotten and that they are all dealt with.
FS> I would strongly vote for some kind of public bug-database. Perhaps
FS> Bugzilla is a bit too big but something like this. I'd think of this:
FS> Bug-ID | Date | Status | Importance | concerned versions |
FS> Platforms | Description
FS> where Bug-ID is a unique identifier
FS> Date the date when the bug was submitted
FS> Status one of new, confirmed, not reproduceable, fix postponed (because
FS> something different has to be done first}, in work or fixed.
FS> Importance perhaps something like cosmetic, normal, critical
FS> Concerned versions the branches which are affected and the version /
FS> date when the bug was introduced
FS> Platforms the platforms where the bug is active
FS> Description a short description about the symptoms of the bug and a link
FS> to the full bug report and the steps how to reproduce it.
FS> I'm no coder, but if somebody volunteers in setting this up, I hereby
FS> volunteer to help keeping it up-to-date.
A proper bug tracking system is something that XEmacs definitely
needs. Maybe we should look into something like Bugzilla, I know
people have suggested it before (Robin?). Personally, I'd prefer
something with an XEmacs front-end, but if someone can come up with
some lisp to make XEmacs talk to Bugzilla, that'd be cool.
Thanks very much for the suggestion, Frank. I'll definitely keep you
in mind for the job of "bug-tracker".
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
12:24 a.m.
On Mon, 2002-07-29 at 17:40, Steve Youngs wrote:
FS> I would strongly vote for some kind of public bug-database.
Perhaps
FS> Bugzilla is a bit too big but something like this. I'd think of this:
A proper bug tracking system is something that XEmacs definitely
needs. Maybe we should look into something like Bugzilla, I know
people have suggested it before (Robin?). Personally, I'd prefer
something with an XEmacs front-end, but if someone can come up with
some lisp to make XEmacs talk to Bugzilla, that'd be cool.
Just a reminder, don't count out Scarab, <http://scarab.tigris.org/>
when evaluating/considering a bug tracking system for XEmacs. At least
it's easier to customize than Bugzilla, probably easier to interface
too.
--
\/ille Skyttä
ville.skytta at xemacs.org
1:52 p.m.
>>>> "Steve" == Steve Youngs
<youngs(a)xemacs.org> writes:
Steve> Personally, I'd prefer something with an XEmacs front-end, but if
Steve> someone can come up with some lisp to make XEmacs talk to Bugzilla,
Steve> that'd be cool.
Gnats? By the looks of it, it has both a web and emacs interface.
Malcolm
--
Malcolm Purvis <malcolmpurvis(a)optushome.com.au>
The hidden, terrible cost of nuclear warfare is Really Bad Public Art.
- Angus McIntyre, alt.peeves, 13/3/02.
6:25 p.m.
Malcolm Purvis <malcolmpurvis(a)optushome.com.au> writes:
>>>>> "Steve" == Steve Youngs
<youngs(a)xemacs.org> writes:
Steve> Personally, I'd prefer something with an XEmacs front-end, but if
Steve> someone can come up with some lisp to make XEmacs talk to Bugzilla,
Steve> that'd be cool.
Gnats? By the looks of it, it has both a web and emacs interface.
How do the emacs interface send mail? It would not be nice to have
the bug reporting utility break if there is a bug in, say, the
mail-lib package.
In general, something that works standalone from emacs but with an
emacs interface too sounds good to me.
9:02 p.m.
Malcolm Purvis <malcolmpurvis(a)optushome.com.au> writes:
Steve Youngs <youngs(a)xemacs.org> writes:
> Personally, I'd prefer something with an XEmacs front-end, but if
> someone can come up with some lisp to make XEmacs talk to Bugzilla,
> that'd be cool.
Gnats? By the looks of it, it has both a web and emacs interface.
just had a look about the homepage (www.gnu.org/software/gnats) and I
think it looks very promising.
--
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.
6:41 a.m.
>>>> "Frank" == Frank Schmitt
<ich(a)Frank-Schmitt.net> writes:
> Gnats? By the looks of it, it has both a web and emacs
> interface.
Frank> just had a look about the homepage
Frank> (www.gnu.org/software/gnats) and I think it looks very
Frank> promising.
I've been working on this, off and on, for a while. Here's my feeling
about the ones I know about. First, two general principles:
1. An email interface is a must; we have a huge backlog of good
reports in the ML archives that could be converted to the BTS
database over time. Preferably programmable so we can
automatically categorize by keywords in the message.
2. Should adapt to current workflow. In particular, I don't see Ben
Wing spending tons of time looking at bug tracker reports; he
currently doesn't even read the mailing lists on a timely basis.
Gnats
Jitterbug
Debian BTS
Mostly email-based, some web interface. Closest to current XEmacs
workflow. Require care and feeding from _both_ a "full-time" bug
tracker and the core people, or they will get out of control.
Bugzilla
Unless the docs get better, it's too hard to manage unless you're
willing to convert the whole workflow to revolve around one of the
existing versions of Bugzilla. Last I looked, no email interface,
which means major changes for most core people. Reputedly quite
hard to customize, documents stink.
Roundup
Neat idea but not ready for primetime on a large project IMO
(although last I looked the Python people were considering it).
SourceForge tracker
I hated working with it as a user; AFAIK no email interface.
A couple others were mentioned in this thread, I'll take a look at
them.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
3:15 p.m.
>>>> "stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
stephen> Jitterbug
Jareth Hein and I implemented this eons ago (1997/8ish?); it adapted
extremely poorly to XEmacs development workflow, so I'd vote against
it.
best,
-tony
--
A.J. Rossini Rsrch. Asst. Prof. of Biostatistics
U. of Washington Biostatistics rossini(a)u.washington.edu
FHCRC/SCHARP/HIV Vaccine Trials Net rossini(a)scharp.org
-------------- http://software.biostat.washington.edu/ ----------------
FHCRC: M: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email
UW: Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX
(my tuesday/wednesday/friday locations are completely unpredictable.)
2:14 a.m.
>>>> "rossini" == rossini
<rossini(a)blindglobe.net> writes:
>>>> "stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
stephen> Jitterbug
rossini> Jareth Hein and I implemented this eons ago (1997/8ish?);
Ah, you were in that too? Thanks!
rossini> it adapted extremely poorly to XEmacs development
rossini> workflow, so I'd vote against it.
I know. I was aware of that when I said I thought these were closest
to XEmacs workflow. :-( I'm afraid we're going to have to build our
own, really. All the projects that are successfully using BTSes that
I know of either (1) have money to enforce the seriousness of the
effort, or (2) are spin-offs from such an environment, or (3) are
basically one-man shows at the top.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
3:53 a.m.
>>>> "stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>>> "rossini" == rossini <rossini(a)blindglobe.net>
writes:
>>>> "stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
rossini> it adapted extremely poorly to XEmacs development
rossini> workflow, so I'd vote against it.
stephen> I know. I was aware of that when I said I thought these
stephen> were closest to XEmacs workflow. :-( I'm afraid we're
stephen> going to have to build our own, really. All the projects
stephen> that are successfully using BTSes that I know of either
stephen> (1) have money to enforce the seriousness of the effort,
stephen> or (2) are spin-offs from such an environment, or (3) are
stephen> basically one-man shows at the top.
Unfortunately, I'll also have to strike against Roundup. I just tried
unsuccessfully to get it working (with Zope). Docs aren't the
greatest.
I _DID_ get the Zope ZWiki Tracker working. It's extremely primitive,
but isn't a bad thing. I could try to set an example up in about
10-14 days (I'm out for the next 7). Mailin/Mailout + WWW interface.
It's not too bad. It's pretty simplistic, though (would need to be
customized to assign bugs, but for this, that isn't too bad of a
thing).
best,
-tony
--
A.J. Rossini Rsrch. Asst. Prof. of Biostatistics
U. of Washington Biostatistics rossini(a)u.washington.edu
FHCRC/SCHARP/HIV Vaccine Trials Net rossini(a)scharp.org
-------------- http://software.biostat.washington.edu/ ----------------
FHCRC: M: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email
UW: Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX
(my tuesday/wednesday/friday locations are completely unpredictable.)
1:36 a.m.
|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org> writes:
SJT> I've been working on this, off and on, for a while. Here's my feeling
SJT> about the ones I know about. First, two general principles:
SJT> 1. An email interface is a must; we have a huge backlog of good
SJT> reports in the ML archives that could be converted to the BTS
SJT> database over time. Preferably programmable so we can
SJT> automatically categorize by keywords in the message.
SJT> 2. Should adapt to current workflow. In particular, I don't see Ben
SJT> Wing spending tons of time looking at bug tracker reports; he
SJT> currently doesn't even read the mailing lists on a timely basis.
Both principles I agree with totally. Some other things I'd like to
see, in no specific order:
3. Ability to "assign" a bug report to one or more
developers.
4. Automatic reminder notices sent to "assignees", with
frequency of reminder dependent on severity of bug.
Perhaps:
critical - daily
moderate - weekly
low - monthly
5. Ability to keep a "log" for bugs that take time to fix.
What I mean here is, you work on fixing a bug, but only get
it partially fixed. You "log" what you've done so others
don't come along and try to redo all your hard work.
6. A way for users (bug submitters) to get feedback on the
progress of their bug report (another reason for 5).
7. A way for users to browse the database to search for any
similar bugs etc.
8. Automatic feedback to the submitter once the bug has been
resolved.
Dear <submitter>
Thanks once again for submitting your bug report
titled: <subject>. We really appreciate your blah
blah blah.
We are pleased to inform you that your bug has now
been resolved. For details please visit <URL>.
Thank you so much for helping us make XEmacs a better
XEmacs.
The XEmacs Bug Busters.
I have no idea if any of that is possible but it's all WIBNI...
SJT> Gnats
SJT> Jitterbug
SJT> Debian BTS
SJT> Mostly email-based, some web interface. Closest to current XEmacs
SJT> workflow. Require care and feeding from _both_ a "full-time" bug
SJT> tracker and the core people, or they will get out of control.
I would have thought that any BTS would require a full-time bug
tracker.
SJT> SourceForge tracker
SJT> I hated working with it as a user; AFAIK no email interface.
Correct, no email interface. And I hated it too, as a user and as an
admin.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
5:44 a.m.
>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
SY> Some other things I'd like to see, in no specific order:
All your desiderata have been implemented in one or more of the major
BTS implementations.
One we both missed, but which may not be trivial:
9. XEmacs integration. That means patcher, build-report, build.
SY> I would have thought that any BTS would require a full-time
SY> bug tracker.
Well, some of them actually manage the whole workflow. So it's really
a tool for El Supremo, a part of the management technology, rather
than something that some individual takes care of. You can get away
without a BTS officer if you make sure that all bugs get assigned,
somehow.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
4:45 p.m.
At 03:26 PM 7/29/2002 +1000, Steve Youngs wrote:
Do we want them? I could probably set up a script to run from cron
on
my account on Tux to do a cvs up, then build a tarball each night. I
won't do this unless people think it'd be a good idea.
I think its a good idea, if only to give people without CVS access to more
recent versions of the code.
andy
9:58 p.m.
|--==> "AP" == Andy Piper <andyp(a)bea.com> writes:
AP> At 03:26 PM 7/29/2002 +1000, Steve Youngs wrote:
[ Nightly Snapshots ]
AP> I think its a good idea, if only to give people without CVS access to
AP> more recent versions of the code.
OK, unless anyone has any strong objections, I'll set this up.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
8141
days inactive
8152
days old
14 comments
8 participants
participants (8)
-
A.J. Rossini -
Andy Piper -
Frank Schmitt -
Malcolm Purvis -
Simon Josefsson -
Stephen J. Turnbull -
Steve Youngs -
Ville Skyttä