Bash scripts in black and white

Bash scripts in black and white

[Angelo Graziosi]

With the current trunk (rev. 100258), visiting or editing bash scripts 
(*.sh) results in black and white (B&W), i.e. it misses the color 
syntax. There is also an error message. To reproduce:

$ emacs -Q &

C-x C-f test.sh

In the minibuffer Emacs writes:

"File mode specification error: (void-function prog-mode)"

and typing syntax elements (like '#' etc.) results in B&W. The buffer 
'test.sh' is visited in the 'Fundamental' mode.

This happens both on Cygwin and on GNU/Linux Kubuntu 10.04, GTK builds, 
clean bootstraps.

The last bootstrap that works with *.sh files is that done with rev. 100219.

Ciao,
Angelo.

Re: Bash scripts in black and white

[Thierry Volpiatto]

Angelo Graziosi <angelo.graziosi@alice.it> writes:

> With the current trunk (rev. 100258), visiting or editing bash scripts
> (*.sh) results in black and white (B&W), i.e. it misses the color
> syntax. There is also an error message. To reproduce:
>
> $ emacs -Q &
>
> C-x C-f test.sh
>
> In the minibuffer Emacs writes:
>
> "File mode specification error: (void-function prog-mode)"

I can confirm that, what is prog-mode?

> and typing syntax elements (like '#' etc.) results in B&W. The buffer
> test.sh' is visited in the 'Fundamental' mode.
>
> This happens both on Cygwin and on GNU/Linux Kubuntu 10.04, GTK
> builds, clean bootstraps.
>
> The last bootstrap that works with *.sh files is that done with rev. 100219.
>
> Ciao,
> Angelo.
>
>

-- 
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/

Re: Bash scripts in black and white

[Stefan Monnier]

> With the current trunk (rev. 100258), visiting or editing bash scripts
> (*.sh) results in black and white (B&W), i.e. it misses the color
> syntax. There is also an error message. To reproduce:

Thanks, should be fixed now,


        Stefan

Re: Bash scripts in black and white

[Thierry Volpiatto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> With the current trunk (rev. 100258), visiting or editing bash scripts
>> (*.sh) results in black and white (B&W), i.e. it misses the color
>> syntax. There is also an error message. To reproduce:
>
> Thanks, should be fixed now,

It seem it is not, before error was with prog-mode but now:
 
File mode specification error: (wrong-type-argument char-table-p nil)

,----
| Debugger entered--Lisp error: (wrong-type-argument char-table-p nil)
|   char-table-parent(nil)
|   sh-mode()
|   set-auto-mode-0(sh-mode nil)
|   set-auto-mode()
|   normal-mode(t)
|   after-find-file(nil t)
|   find-file-noselect-1(#<buffer toto.sh> "~/bin/toto.sh" nil nil "~/bin/toto.sh" (5062663 2055))
|   find-file-noselect("/home/thierry/bin/toto.sh" nil nil nil)
|   find-file("/home/thierry/bin/toto.sh")
|   dired-find-file()
|   call-interactively(dired-find-file nil nil)
`----

That is with this:

,----
|    commit edbdb1a992c31be4a04cf194218788bac885f4c6
|    Commit: Stefan Monnier <monnier@iro.umontreal.ca>
|    CommitDate: Fri May 14 12:41:01 2010 -0400
| 
|       * simple.el (prog-mode): New (abstract) major mode.
|       * emacs-lisp/lisp-mode.el (emacs-lisp-mode, lisp-mode): Use it.
|       * progmodes/sh-script.el (sh-mode): Remove redundant var assignment.
`----
  

-- 
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/

Re: Bash scripts in black and white

[Angelo Graziosi]

Il 14/05/2010 21.29, Stefan Monnier ha scritto:
>> With the current trunk (rev. 100258), visiting or editing bash scripts
>> (*.sh) results in black and white (B&W), i.e. it misses the color
>> syntax. There is also an error message. To reproduce:
>
> Thanks, should be fixed now,

No, it is still broken!!

Thierry Volpiatto wrote:

> It seem it is not, before error was with prog-mode but now:
>
> File mode specification error: (wrong-type-argument char-table-p nil)

Indeed...

Ciao ciao,
Angelo.

PS. Sometime one gets the idea that Emacs's developers do not test 
deeply (for example, with at least a clean bootstrap) their changes... 
This would explain why the bugs tracker is at #6193 :-)

Re: Bash scripts in black and white

[Lennart Borgman]

On Fri, May 14, 2010 at 11:23 PM, Angelo Graziosi
<angelo.graziosi@alice.it> wrote:
>
> PS. Sometime one gets the idea that Emacs's developers do not test deeply
> (for example, with at least a clean bootstrap) their changes... This would
> explain why the bugs tracker is at #6193 :-)

If someone has time to add unit tests to Emacs this would be a bit better... ;-)

ert.el with my small additions could handle tests for things like this.

Re: Bash scripts in black and white

[joakim]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Fri, May 14, 2010 at 11:23 PM, Angelo Graziosi
> <angelo.graziosi@alice.it> wrote:
>>
>> PS. Sometime one gets the idea that Emacs's developers do not test deeply
>> (for example, with at least a clean bootstrap) their changes... This would
>> explain why the bugs tracker is at #6193 :-)
>
> If someone has time to add unit tests to Emacs this would be a bit better... ;-)
>
> ert.el with my small additions could handle tests for things like this.

Who contacts the author?

-- 
Joakim Verona

Re: Bash scripts in black and white

[Eli Zaretskii]

> Date: Fri, 14 May 2010 23:23:40 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Cc: Emacs <emacs-devel@gnu.org>
> 
> PS. Sometime one gets the idea that Emacs's developers do not test 
> deeply (for example, with at least a clean bootstrap) their changes... 
> This would explain why the bugs tracker is at #6193 :-)

I won't recommend drawing any conclusions from just the number of the
last filed bug.  Especially since the Emacs bug database is shared
with other projects (e.g., Coreutils).  As another data point, the GNU
Make's bug number approaches 30,000...

More to the point: Emacs maintainers do test as deeply as practically
possible for each one of them.  A bootstrap is a lengthy procedure for
someone who has maybe an hour a day to work on Emacs.  We are grateful
to all those who do have resources to bootstrap and test on other
systems, and report results here.

Re: Bash scripts in black and white

[Angelo Graziosi]

Il 15/05/2010 8.33, Eli Zaretskii ha scritto:
>> Date: Fri, 14 May 2010 23:23:40 +0200
>> From: Angelo Graziosi<angelo.graziosi@alice.it>
>> Cc: Emacs<emacs-devel@gnu.org>
>>
>> PS. Sometime one gets the idea that Emacs's developers do not test
>> deeply (for example, with at least a clean bootstrap) their changes...
>> This would explain why the bugs tracker is at #6193 :-)

Sorry for this... but I could not resist... :-)

It is only my opinion and, perhaps, it comes out fro the idea of 
Programming one has in mind.

>
> I won't recommend drawing any conclusions from just the number of the
> last filed bug.  Especially since the Emacs bug database is shared
> with other projects (e.g., Coreutils).  As another data point, the GNU
> Make's bug number approaches 30,000...
>
> More to the point: Emacs maintainers do test as deeply as practically
> possible for each one of them.  A bootstrap is a lengthy procedure for
> someone who has maybe an hour a day to work on Emacs.  We are grateful
> to all those who do have resources to bootstrap and test on other
> systems, and report results here.

Often the bugs come from lack of bootstrap, and bootstrap (+PDF manual, 
+tar.xz of the binary distribution) takes about 25 minutes on Cygwin, 
which is only an emulator...

In any case, thanks for the work of developers.

Ciao,
Angelo.

Re: Bash scripts in black and white

[Juanma Barranquero]

On Sat, May 15, 2010 at 10:15, Angelo Graziosi <angelo.graziosi@alice.it> wrote:

> Often the bugs come from lack of bootstrap, and bootstrap (+PDF manual,
> +tar.xz of the binary distribution) takes about 25 minutes on Cygwin, which
> is only an emulator...

Bootstrap failures are few and far between, so half an hour* to test
every change is a waste of resources**. In any case,  bootstrap
failures are usually detected and fixed in a few hours.

*: Not everyone has powerful, up-to-date computers.

**: I *do* bootstrap almost daily; but I don't think it should be
forced on everyone. If we wanted such an always-buildable,
always-runable repository, we would be better served by a continuous
integration setup. I don't think we want, though.

    Juanma

Re: Bash scripts in black and white

[Angelo Graziosi]

Il 15/05/2010 11.12, Juanma Barranquero ha scritto:
> On Sat, May 15, 2010 at 10:15, Angelo Graziosi<angelo.graziosi@alice.it>  wrote:
>
>> Often the bugs come from lack of bootstrap, and bootstrap (+PDF manual,
>> +tar.xz of the binary distribution) takes about 25 minutes on Cygwin, which
>> is only an emulator...
>
> Bootstrap failures are few and far between, so half an hour* to test
> every change is a waste of resources**. In any case,  bootstrap
> failures are usually detected and fixed in a few hours.

I did not refer to bootstrap failure! and not to bootstrap at every 
changes. At least once per week or when there are many many changes: 
catching a bug soon is better than after some time :-)

>
> *: Not everyone has powerful, up-to-date computers.

My PC was born on September 2007! with the same XP!

> **: I *do* bootstrap almost daily; but I don't think it should be
> forced on everyone. If we wanted such an always-buildable,
> always-runable repository, we would be better served by a continuous
> integration setup. I don't think we want, though.

See above.

Ciao,
Angelo.

Re: Bash scripts in black and white

[Juanma Barranquero]

On Sat, May 15, 2010 at 11:20, Angelo Graziosi <angelo.graziosi@alice.it> wrote:

> I did not refer to bootstrap failure!

No, you did talk about "testing with a clean bootstrap". Still,
failures that manifest themselves after a bootstrap and not a normal
compilation are equally infrequent.

> At least once per week or when there are many many changes: catching a bug
> soon is better than after some time :-)

I don't think there are many bugs that would've been catched by
testing after bootstrap and are not detected a week after they're
committed to the repository...

> My PC was born on September 2007! with the same XP!

My previous one (which I recently retired) was born on 2006.
Bootstrapping was about half an hour. But I wouldn't be surprised to
hear that people are building and bootstraping Emacs on slower
computers (netbooks, for example).

    Juanma

Re: Bash scripts in black and white

[Leo]

On 2010-05-15 07:33 +0100, Eli Zaretskii wrote:
>> PS. Sometime one gets the idea that Emacs's developers do not test 
>> deeply (for example, with at least a clean bootstrap) their changes... 
>> This would explain why the bugs tracker is at #6193 :-)
>
> I won't recommend drawing any conclusions from just the number of the
> last filed bug.  Especially since the Emacs bug database is shared
> with other projects (e.g., Coreutils).  As another data point, the GNU
> Make's bug number approaches 30,000...
>
> More to the point: Emacs maintainers do test as deeply as practically
> possible for each one of them.  A bootstrap is a lengthy procedure for
> someone who has maybe an hour a day to work on Emacs.  We are grateful
> to all those who do have resources to bootstrap and test on other
> systems, and report results here.

I think users have much higher expectation of software quality these
days since there are far more good applications both commercial and
free. And frankly emacs is playing catch-up. The good quality part is
from decades of bug reports and fixes. Most recent additions are not due
to lack of exposure and due to lack of people care enough to report and
lack of people care enough to fix. What I know as truth is emacs may
hang more often than any applications on your system including the
webbrowser, which handles contents far more complex and it is making
emacs 'irrelevant' as time goes by. Let me cite one example here
http://code.google.com/p/latex-lab/.

I also think it would be very helpful for emacs to have a daily build
report on one of the main platforms. This will help developers use their
time more effectively. To the outside, any breakage will last not more
than one day. Such routine can be automated. I have seen it done by
individual user and I have no doubt it can be done in the GNU project.

Leo

Re: Bash scripts in black and white

[Thierry Volpiatto]

Angelo Graziosi <angelo.graziosi@alice.it> writes:

> Il 14/05/2010 21.29, Stefan Monnier ha scritto:
>>> With the current trunk (rev. 100258), visiting or editing bash scripts
>>> (*.sh) results in black and white (B&W), i.e. it misses the color
>>> syntax. There is also an error message. To reproduce:
>>
>> Thanks, should be fixed now,
>
> No, it is still broken!!

> Thierry Volpiatto wrote:
>
>> It seem it is not, before error was with prog-mode but now:
>>
>> File mode specification error: (wrong-type-argument char-table-p nil)

Now yes, seem it is fixed, thanks.

> Indeed...
>
> Ciao ciao,
> Angelo.
>
> PS. Sometime one gets the idea that Emacs's developers do not test
> deeply (for example, with at least a clean bootstrap) their
> changes... This would explain why the bugs tracker is at #6193 :-)
>
>

-- 
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/

Re: Bash scripts in black and white

[Angelo Graziosi]

Il 15/05/2010 11.34, Juanma Barranquero ha scritto:

> My previous one (which I recently retired) was born on 2006.
> Bootstrapping was about half an hour. But I wouldn't be surprised to
> hear that people are building and bootstraping Emacs on slower
> computers (netbooks, for example).

2002 32 bit! (AMD)
1990 16 bit! 286

3 PC in 20 years!

Ciao,
Angelo.

Re: Bash scripts in black and white

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Cc: Angelo Graziosi <angelo.graziosi@alice.it>,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Sat, 15 May 2010 10:51:18 +0100
> 
> I think users have much higher expectation of software quality these
> days since there are far more good applications both commercial and
> free. And frankly emacs is playing catch-up. The good quality part is
> from decades of bug reports and fixes. Most recent additions are not due
> to lack of exposure and due to lack of people care enough to report and
> lack of people care enough to fix.

It's quite obvious Emacs could use more volunteers than it has now.

> What I know as truth is emacs may hang more often than any
> applications on your system including the webbrowser, which handles
> contents far more complex and it is making emacs 'irrelevant' as
> time goes by.

That's not my experience, but YMMV, of course.

> I also think it would be very helpful for emacs to have a daily build
> report on one of the main platforms.

This also needs volunteers.  I hope they will come.

Re: Bash scripts in black and white

[martin rudalics]

 >> I also think it would be very helpful for emacs to have a daily build
 >> report on one of the main platforms.
 >
 > This also needs volunteers.  I hope they will come.

Romain Francoise did that for quite some time at:

http://build.orebokech.com/

Unfortunately, his only ardent admirer was me, so he eventually stopped
volunteering.

martin

Re: Bash scripts in black and white

[Leo]

On 2010-05-15 13:49 +0100, martin rudalics wrote:
>>> I also think it would be very helpful for emacs to have a daily build
>>> report on one of the main platforms.
>>
>> This also needs volunteers.  I hope they will come.
>
> Romain Francoise did that for quite some time at:
>
> http://build.orebokech.com/
>
> Unfortunately, his only ardent admirer was me, so he eventually stopped
> volunteering.
>
> martin

That's a step closer. I have added Romain to the cc's.

We need two things:

1. A reliable machine to run the nightly build. Suggestions?
2. A script to automate the task and send report to an accessible place.

Leo

Re: Bash scripts in black and white

[Stefan Monnier]

>> PS. Sometime one gets the idea that Emacs's developers do not test deeply
>> (for example, with at least a clean bootstrap) their changes... This would
>> explain why the bugs tracker is at #6193 :-)

A clean bootstrap is obviously out of the question for me.
OTOH, I'd be happy if someone setup a build robot that constantly tries
to build Emacs, then run some tests, and if they all succeeds updates
a branch.  This way we can point people to *that* branch where the
obvious bugs have been filtered.  It wouldn't reduce the number of
bug-reports, but it would make reports such as this sh-script one be
machine-generated rather than human-generated, leading maybe to
less frustration.

> If someone has time to add unit tests to Emacs this would be a bit
> better... ;-)
> ert.el with my small additions could handle tests for things like this.

Yes, as I said, I'd be delighted to integrate something like that in
emacs/test.


        Stefan

Re: Bash scripts in black and white

[Romain Francoise]

Leo <sdl.web@gmail.com> writes:

>> Romain Francoise did that for quite some time at:
>>
>> http://build.orebokech.com/
>>
>> Unfortunately, his only ardent admirer was me, so he eventually stopped
>> volunteering.

Yeah, I had to upgrade the machine it was running on and the setup
wasn't trivial to redo (buildbot was patched and running in a
container) so I looked at the access logs and basically, nobody but
me was using it. So I just dropped the service.

> 1. A reliable machine to run the nightly build. Suggestions?

Reliable and not too critical since anybody who has write access to
the repository gets to run code on it automatically and the project
on Savannah has 129 members, some of which may be abandoned accounts
with weak credentials...

> 2. A script to automate the task and send report to an accessible
>    place.

I recommend buildbot.

I'm adding Ted to Cc since he expressed interest in setting up a
buildbot for Emacs the last time this subject came up.

Re: Bash scripts in black and white

[Ken Raeburn]

On May 15, 2010, at 13:12, Romain Francoise wrote:
>> 1. A reliable machine to run the nightly build. Suggestions?
> 
> Reliable and not too critical since anybody who has write access to
> the repository gets to run code on it automatically and the project
> on Savannah has 129 members, some of which may be abandoned accounts
> with weak credentials...

Virtual machines with externally-imposed firewall rules can help with that.  You could even use a non-networked VM solely for building, and handle the network interaction (getting sources, reporting results) on the host.  If full virtualization isn't available, there are also FreeBSD jails, Solaris containers, etc.  A simple chroot isn't enough if you're downloading and running potentially hostile code, and don't want your machine to become a spambot.

>> 2. A script to automate the task and send report to an accessible
>>   place.
> 
> I recommend buildbot.
> 
> I'm adding Ted to Cc since he expressed interest in setting up a
> buildbot for Emacs the last time this subject came up.

I'd been meaning to look into buildbot, though mostly related to stuff I was doing at a job I'm not at any more... if it's easy enough to set up (including firewalling), I might be able to contribute a buildslave virtual machine at some point.

Ken

Re: Bash scripts in black and white

[Stephen Eilert]

On Fri, May 14, 2010 at 6:23 PM, Angelo Graziosi
<angelo.graziosi@alice.it> wrote:

> PS. Sometime one gets the idea that Emacs's developers do not test deeply
> (for example, with at least a clean bootstrap) their changes... This would
> explain why the bugs tracker is at #6193 :-)
>
>

It seems to be caused by a lack of resources, both silicon and
carbon-based. Resources you are providing yourself, by reporting the
breakage.

That's the nature of this style of development. Adapt.


--Stephen

Sent from my Emacs

Re: Bash scripts in black and white

[Ted Zlatanov]

On Sat, 15 May 2010 19:12:26 +0200 Romain Francoise <romain@orebokech.com> wrote: 

RF> I'm adding Ted to Cc since he expressed interest in setting up a
RF> buildbot for Emacs the last time this subject came up.

I'm adding this to my TODO list and will have one up soon-ish.  I don't
think I can do the VCS integration that Stefan suggested without some
help, though.  I don't know what he meant by "update a branch" when a
build is successful.

Ted

Re: Bash scripts in black and white

[Stefan Monnier]

RF> I'm adding Ted to Cc since he expressed interest in setting up a
RF> buildbot for Emacs the last time this subject came up.

> I'm adding this to my TODO list and will have one up soon-ish.  I don't
> think I can do the VCS integration that Stefan suggested without some
> help, though.  I don't know what he meant by "update a branch" when a
> build is successful.

After "bzr update; compile&test", if the "test" (which might just be to
check that it compiles successfully) succeeds, do "bzr push <someplace>"
where the <someplace> could be sftp://bzr.sv.gnu.org/srv/bzr/emacs/tested

So we could tell people to use <someplace> to checkout the latest
successfully tested version of the code.


        Stefan

Re: Bash scripts in black and white

[Thierry Volpiatto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> RF> I'm adding Ted to Cc since he expressed interest in setting up a
> RF> buildbot for Emacs the last time this subject came up.
>
>> I'm adding this to my TODO list and will have one up soon-ish.  I don't
>> think I can do the VCS integration that Stefan suggested without some
>> help, though.  I don't know what he meant by "update a branch" when a
>> build is successful.
>
> After "bzr update; compile&test", if the "test" (which might just be to
> check that it compiles successfully) succeeds, do "bzr push <someplace>"
> where the <someplace> could be sftp://bzr.sv.gnu.org/srv/bzr/emacs/tested
>
> So we could tell people to use <someplace> to checkout the latest
> successfully tested version of the code.

It seem sometime things are fixed in 23 before being fixed in 24 and
vice versa, am i right?, if so i wonder in which branch you develop
emacs.
Can you clarify?

-- 
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/

Re: Bash scripts in black and white

[Stefan Monnier]

> It seem sometime things are fixed in 23 before being fixed in 24 and
> vice versa, am i right?, if so i wonder in which branch you develop
> emacs.

I develop Emacs in the emacs-23 branch, then trunk, and my own personal
branch (by order of riskiness of the change).

But I really have no idea what this has to do with a buildbot.


        Stefan

Re: Bash scripts in black and white

[Thierry Volpiatto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> It seem sometime things are fixed in 23 before being fixed in 24 and
>> vice versa, am i right?, if so i wonder in which branch you develop
>> emacs.
>
> I develop Emacs in the emacs-23 branch, then trunk, and my own personal
> branch (by order of riskiness of the change).

Thanks.
> But I really have no idea what this has to do with a buildbot.

Nothing, just to know.

-- 
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/

Re: Bash scripts in black and white

[Christian Ohler]

Stefan Monnier, 2010-05-15:

>> If someone has time to add unit tests to Emacs this would be a bit
>> better... ;-)
>> ert.el with my small additions could handle tests for things like this.

I have already integrated your additions into ERT.


> Yes, as I said, I'd be delighted to integrate something like that in
> emacs/test.

I am working on cleaning up ERT for inclusion; you can follow my 
progress at http://github.com/ohler/ert/commits/master .  I haven't yet 
received a response from assign at gnu dot org, so I'm taking my time 
and adding some missing features.  Once I update the manual, you can 
begin reviewing the code.

Christian.

buildbot setup (was: Bash scripts in black and white)

[Ted Zlatanov]

On Fri, 25 Jun 2010 00:11:11 +0200 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

RF> I'm adding Ted to Cc since he expressed interest in setting up a
RF> buildbot for Emacs the last time this subject came up.

>> I'm adding this to my TODO list and will have one up soon-ish.  I don't
>> think I can do the VCS integration that Stefan suggested without some
>> help, though.  I don't know what he meant by "update a branch" when a
>> build is successful.

SM> After "bzr update; compile&test", if the "test" (which might just be to
SM> check that it compiles successfully) succeeds, do "bzr push <someplace>"
SM> where the <someplace> could be sftp://bzr.sv.gnu.org/srv/bzr/emacs/tested

SM> So we could tell people to use <someplace> to checkout the latest
SM> successfully tested version of the code.

I'm not crazy about using a branch to announce a build success.  Are
developers then supposed to track two branches?  Or are users going to
track the tested branch but developers the trunk?  What happens if
there's a tracking failure, do I need to manually fix it ASAP?  How do
we test multiple platforms and coordinate a push when they are all
successful?  Or do we keep a separate "tested" branch for each platform
and library combination, which makes it even more fun and amplifies each
of the issues listed so far?

I think it's better and less confusing to simply announce failures
through another channel, perhaps as bugs.  Then silence will be the
default, which is good for everyone, and builds will not have any
effect on the repository.

Ted

Re: buildbot setup (was: Bash scripts in black and white)

[Lennart Borgman]

2010/6/30 Ted Zlatanov <tzz@lifelogs.com>:
> On Fri, 25 Jun 2010 00:11:11 +0200 Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> SM> So we could tell people to use <someplace> to checkout the latest
> SM> successfully tested version of the code.
>
> I'm not crazy about using a branch to announce a build success.  Are

Can't it be just a command to checkout the successfully successfully
tested revision?

> I think it's better and less confusing to simply announce failures
> through another channel, perhaps as bugs.  Then silence will be the
> default, which is good for everyone, and builds will not have any
> effect on the repository.

Can't it be combined?

Re: buildbot setup

[Ted Zlatanov]

On Wed, 30 Jun 2010 20:39:23 +0200 Lennart Borgman <lennart.borgman@gmail.com> wrote: 

LB> 2010/6/30 Ted Zlatanov <tzz@lifelogs.com>:
>> On Fri, 25 Jun 2010 00:11:11 +0200 Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> 
SM> So we could tell people to use <someplace> to checkout the latest
SM> successfully tested version of the code.
>> 
>> I'm not crazy about using a branch to announce a build success.  Are

LB> Can't it be just a command to checkout the successfully successfully
LB> tested revision?

We could use a tag.  But as I mentioned there's a lot of complexity to a
"success" especially if we care about more than one platform and set of
libraries.

>> I think it's better and less confusing to simply announce failures
>> through another channel, perhaps as bugs.  Then silence will be the
>> default, which is good for everyone, and builds will not have any
>> effect on the repository.

LB> Can't it be combined?

Sorry, can you explain?  I can't figure out what you mean.

Ted

Re: buildbot setup

[Lennart Borgman]

2010/6/30 Ted Zlatanov <tzz@lifelogs.com>:
> On Wed, 30 Jun 2010 20:39:23 +0200 Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
> LB> 2010/6/30 Ted Zlatanov <tzz@lifelogs.com>:
>>> On Fri, 25 Jun 2010 00:11:11 +0200 Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>>
> SM> So we could tell people to use <someplace> to checkout the latest
> SM> successfully tested version of the code.
>>>
>>> I'm not crazy about using a branch to announce a build success.  Are
>
> LB> Can't it be just a command to checkout the successfully successfully
> LB> tested revision?
>
> We could use a tag.  But as I mentioned there's a lot of complexity to a
> "success" especially if we care about more than one platform and set of
> libraries.


Would it be possible to write a web page with something like this below?

  To get last successful builds:

    GNU/Linux:  bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk -r nnnnn1
    w32: bzr ... -r nnnn2
    ... etc


>>> I think it's better and less confusing to simply announce failures
>>> through another channel, perhaps as bugs.  Then silence will be the
>>> default, which is good for everyone, and builds will not have any
>>> effect on the repository.
>
> LB> Can't it be combined?
>
> Sorry, can you explain?  I can't figure out what you mean.


Just write a web page as above and make announcements the way you suggested.

Re: buildbot setup

[Stefan Monnier]

> I'm not crazy about using a branch to announce a build success.

That's OK.  You can also use a tag, of course.

> Are developers then supposed to track two branches?

The "tested" branch is just an older version of the "trunk", so there
really aren't two branches, in terms of development.  The "tested"
branch is just a read-only mirror that's only updated when some built
test succeeded.

> Or are users going to track the tested branch but developers the
> trunk?

That'd be the idea, yes.

> What happens if there's a tracking failure, do I need to manually fix
> it ASAP?

No.

> How do we test multiple platforms and coordinate a push when
> they are all successful?

The "tested" branch should correspond to "no known problem during
build&test", so if there's a problem on one platform it should probably be
considered as a global failure.  But I don't think such problems matter
much at this stage.

> Or do we keep a separate "tested" branch for each platform and library
> combination,

Only if you're a masochist.

> I think it's better and less confusing to simply announce failures
> through another channel, perhaps as bugs.  Then silence will be the
> default, which is good for everyone, and builds will not have any
> effect on the repository.

Many people who track Emacs's trunk don't read the mailing-list (or not
regularly enough) and they get annoyed when the build fails.


        Stefan

Re: buildbot setup

[Stephen J. Turnbull]

Stefan Monnier writes:

 > > Or are users going to track the tested branch but developers the
 > > trunk?
 > 
 > That'd be the idea, yes.

XEmacs tried this.  We abandoned it.  It was too much trouble for
maintainers for the amount of trouble it saved users.  It wasn't
anywhere near 100% effective, either, as the users who couldn't build
the trunk frequently had the same unusual trouble with the (allegedly)
tested branch.

We don't currently have any users with requirements like Alan
Mackenzie's, but if we did I'd simply keep track of potentially
destabilizing commits, and tag the last version before one of those.
That might not work so well with Emacs, though.  XEmacs has a very few
large committers whose stuff comes in batches, while others don't tend
to commit patches to areas that might break the build.  I gather Emacs
has several committers working in areas with some risk of breaking the
build, so it might not be so easy to choose an apparently stable
version.

If you could automatically tag based on green buildbots, that might be
a worthwhile alternative, though.

Re: buildbot setup

[Ted Zlatanov]

On Wed, 30 Jun 2010 23:34:45 +0200 Lennart Borgman <lennart.borgman@gmail.com> wrote: 

LB> 2010/6/30 Ted Zlatanov <tzz@lifelogs.com>:
>> We could use a tag.  But as I mentioned there's a lot of complexity to a
>> "success" especially if we care about more than one platform and set of
>> libraries.

LB> Would it be possible to write a web page with something like this below?
LB>   To get last successful builds:
LB>     GNU/Linux:  bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk -r nnnnn1
LB>     w32: bzr ... -r nnnn2
LB>     ... etc

Buildbot can do that, I think.  I don't think it's *useful*.  Do you
expect users to go to this web page, read it, copy the revision, then do
a checkout?  They are just going to check out the trunk and complain if
it doesn't work.

On Thu, 01 Jul 2010 03:43:06 +0200 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> I'm not crazy about using a branch to announce a build success.

SM> That's OK.  You can also use a tag, of course.

I'm not crazy about using a DVCS (specifically the Emacs Bazaar repo) to
announce build results.  My point is that it clutters the DVCS with
extraneous information; if we publish builds with tags then why not
publish a "best-performing-this-year" tag based on profiling results?

>> How do we test multiple platforms and coordinate a push when
>> they are all successful?

SM> The "tested" branch should correspond to "no known problem during
SM> build&test", so if there's a problem on one platform it should probably be
SM> considered as a global failure.  But I don't think such problems matter
SM> much at this stage.

I do.  It may work for one platform but soon enough we'll have 20 jammed
into this system and then it will just be confusing for users and
developers alike.  See the CPAN testers reports
(http://cpantesters.org/distro/E/Every.html for example).

>> I think it's better and less confusing to simply announce failures
>> through another channel, perhaps as bugs.  Then silence will be the
>> default, which is good for everyone, and builds will not have any
>> effect on the repository.

SM> Many people who track Emacs's trunk don't read the mailing-list (or not
SM> regularly enough) and they get annoyed when the build fails.

OK, I think I see the misunderstanding.  You want something for the
users.  I want something for the developers that can actually fix the
problem and read the mailing list.  My target for reporting a broken
build is everyone who comitted since the last successful build and
perhaps it makes sense to simply CC them on the report.  If users
benefit by tracking these announcements, great, but I don't think they
should be targeted by an automatic build system.

Ted

Re: buildbot setup

[Lennart Borgman]

2010/7/1 Ted Zlatanov <tzz@lifelogs.com>:
> On Wed, 30 Jun 2010 23:34:45 +0200 Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
> LB> 2010/6/30 Ted Zlatanov <tzz@lifelogs.com>:
>>> We could use a tag.  But as I mentioned there's a lot of complexity to a
>>> "success" especially if we care about more than one platform and set of
>>> libraries.
>
> LB> Would it be possible to write a web page with something like this below?
> LB>   To get last successful builds:
> LB>     GNU/Linux:  bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk -r nnnnn1
> LB>     w32: bzr ... -r nnnn2
> LB>     ... etc
>
> Buildbot can do that, I think.  I don't think it's *useful*.  Do you
> expect users to go to this web page, read it, copy the revision, then do
> a checkout?  They are just going to check out the trunk and complain if
> it doesn't work.


They can act in different ways. One way is to do a temporary checkout
as you wrote above. Another way is to check this page if something
does not work in the checkout they have. Etc.

Re: buildbot setup

[Stefan Monnier]

> We don't currently have any users with requirements like Alan
> Mackenzie's, but if we did I'd simply keep track of potentially
> destabilizing commits, and tag the last version before one of those.
> That might not work so well with Emacs, though.  XEmacs has a very few
> large committers whose stuff comes in batches, while others don't tend
> to commit patches to areas that might break the build.  I gather Emacs
> has several committers working in areas with some risk of breaking the
> build, so it might not be so easy to choose an apparently stable
> version.

There's indeed some difficulty figuring out when a bootstrap is needed,
as well as how to make sure "make bootstrap" works reliably.

I think the need for bootstrap increases if you update less often
(i.e. if you update everyday, you may never need to bootstrap, whereas
if you update every month you may have to bootstrap every time).

So maybe the buildbot could do a "checkout last bootstrap-tag",
then update and try "make"; if that succeeds, move the tag; else try
again with "make bootstrap" if that succeeds, then add some flag
somewhere indicating that this revision needs a bootstrap and move both
the tested-tag and the bootstrap-tag.

> If you could automatically tag based on green buildbots, that might be
> a worthwhile alternative, though.

I don't know what are green buildbots.


        Stefan

Re: buildbot setup

[joakim]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> We don't currently have any users with requirements like Alan
>> Mackenzie's, but if we did I'd simply keep track of potentially
>> destabilizing commits, and tag the last version before one of those.
>> That might not work so well with Emacs, though.  XEmacs has a very few
>> large committers whose stuff comes in batches, while others don't tend
>> to commit patches to areas that might break the build.  I gather Emacs
>> has several committers working in areas with some risk of breaking the
>> build, so it might not be so easy to choose an apparently stable
>> version.
>
> There's indeed some difficulty figuring out when a bootstrap is needed,
> as well as how to make sure "make bootstrap" works reliably.
>
> I think the need for bootstrap increases if you update less often
> (i.e. if you update everyday, you may never need to bootstrap, whereas
> if you update every month you may have to bootstrap every time).
>
> So maybe the buildbot could do a "checkout last bootstrap-tag",
> then update and try "make"; if that succeeds, move the tag; else try
> again with "make bootstrap" if that succeeds, then add some flag
> somewhere indicating that this revision needs a bootstrap and move both
> the tested-tag and the bootstrap-tag.
>
>> If you could automatically tag based on green buildbots, that might be
>> a worthwhile alternative, though.
>
> I don't know what are green buildbots.
>
>
>         Stefan

Just FYI I have been running a Hudson instance to build Emacs on a
Fedora 12 machine. It was very easy to setup because Hudson has a bzr
plugin. It polls the repos and decides if a rebuild is needed, and shows
diffs between builds and so on.

My interest is more in seeing if different branches build from a clean
checkout properly on different plattforms, not so much if a bootstrap is
needed. 

Currently the setup is too insecure to let out on the internet, I need
to chroot the build environment at least.

-- 
Joakim Verona