Daniel: Welcome everyone, this is the "Bits from the DPL"
with our Debian Project Leader, Stefano Zacchiroli
so, really, give a round of applause, I don't think he need much of an introduction
Stefano: Thanks
[applause]
So, I'm sure you're here because this will be the last time
I'll bother you with this "Bits from the DPL" speech,
at least at a DebConf, so thanks for being here.
In this talk, I'm gonna go through two main parts:
the first one is some sorts of... a set of mantras
that have become the way I define Debian today.
I've presented them to various people before
I see there is enough people in the room
that won't be bothered because it's the first time they hear them,
so I hope you will allow me to go through them.
And then, after this kind of defining mantras of Debian,
I will present some of the challenges that I think we have in Debian
and that we need to take care of
to guarantee that we have a long and healthy life ahead.
But before that I'm trying to make the point that we did make history.
So, this is how Debian started in 1993,
the first quote.
1993 is almost twenty years ago.
Back then there were very few GNU/Linux distributions around,
and they were... they had troubles,
and the quality was not stellar
and people started to think about
"how can we make GNU/Linux competitive with commercial operating system?"
and Ian Murdock came up with this great idea of Debian
and this is where all this started.
But then we made history at least in two ways:
one way is a sort of community and social way:
in a more recent interview of a couple of years ago,
Ian made the point that Debian has been the first intentional community project;
there were distributions back then,
there were Free Software projects back then,
but Debian was kind of designed with community in mind
and with the idea that if you want something to scale to the size of Debian today
we need to have a community behind it.
So, I think we really made the history
showing up how a project as big as Debian
can be made only in a community driven way.
But then, we also made history in very technical ways:
twenty years has passed since 1993
and if we look today at Debian
we have something like almost forty thousands binary packages,
in Debian proper;
we have made twelve releases
and - who knows? - maybe we'll make the thirteenth before the end of this year;
we have a project of almost one thousand members;
and almost two hundreds Debian Maintainers
that are interested in maintaining some parts of Debian;
and various thousands of contributors doing a lot of other stuff
useful for the project.
We have the largest number of ports
among - let's say - "major" binary distributions out there.
We have non-Linux ports:
we have released a version of Debian that works with a kernel other than Linux.
We haven't yet release a version of Debian that works with a kernel like Hurd
but for people who like Hurd and want to try it
Debian still remains the best choice to do that.
Well done! This is us, making this!
Bravo! All of you! We made this!
But then, one thing is making history
in some ways, technically or socially
and a completely different thing is remaining relevant.
So, in these past three years as DPL
I faced the problem that people were starting to question
- that was like a couple of years ago -
"Do we still need Debian?"
"Ok, you made history, you made a lot of stuff
you made derivatives, you made a lot of stuff but ...
... Do we still need Debian today?"
I've asked myself how to answer the question
and a way to answer the question is asking us ourselves
what's different from what we do and what the other distributions do.
There are something like three hundreds, four hundreds active Free Software distributions around:
what is that makes Debian special?
And I've started to thinking at some answers to that question
and I've come to five specific traits that make - I think - the Debian Project unique.
I think it's useful to keep them in mind
and to remind why we are contributing to Debian and not to some other similar project.
The first reason,
and sort of my first mantra that makes Debian special,
is freedom.
This seems obvious but there's freedom in many ways.
The first reason why Debian is special in terms of freedom
is that we essentially have agreed with our public and with Free Software public in general
to keep Debian always free.
We've been promoting the culture of Free Software, not only giving Free Software to people,
we've been promoting the culture of Free Software since 1993,
and we have a product which is free the bottom up
there is an incredibly high amount of dog food in what we do.
So it is free in the software we give to people
and it's free in the way we make it.
Every single bit of the Debian infrastructure is free
and nobody would accept if we start making Debian using like
non free stuff in our infrastructure.
This is kind of peculiar per se.
And we have also a notion of freeness
in the process we use.
People who have been around in Debian for quite a while
have heard the motto of "There Is Not Cabal!"
as some sort of joke, several times.
And we use it in saying that, in thinking that there is some cabal around
but the point is that if we make this joke
it means that we really cannot stand the idea that there is someone
driving Debian behind the curtain,
driving Debian not in the open.
So we are free not only in our infrastructure,
not only in the software we make,
but also in the way we do things.
We try to be as transparent as we could be.
And what is interesting for me
is that there's some sort of community awareness
of this kind of attachment we have for freedom.
Our community trusts us to not betray software freedom principles
and they think that this is being a very high contribution to Free Software in general
so we've set some sort of very high bar
to decide when something is free or not.
When people need to decide if some software is free or if some license
should be considered Free Software or not
they go basically to three entities:
they go to the Free Software Foundation,
they go to the OSI,
they go to Debian
and they see if that license is considered free
by those people. And we are one of them.
So first point, which I think is determining what we do in Debian, is freedom. Software freedom.
Second point is a kind of perfectionism
which sometimes strikes back on us
sometimes makes that...
it gets in the way of some of our choices
but we do have a sort of culture of technical excellence.
We have the Policy, which is where we have codified our quality needs for packages;
we have a huge amount of testing: we have Lintian, we have Piuparts;
we have automatic testing to see that packages matches our Policy;
we have maintainers who are software experts.
We try to discourage people to maintain software in Debian if they only know about packaging
we try to encourage people to maintain software they use
and software of which they are experts
and this is huge in terms of users support.
So when a user comes to us
comes to the respective maintainer of some software in Debian,
usually he find someone that knows about that specific piece of software.
This, for us, is quality.
We have packages that are all up to the same quality requirements
and there are no packages... there is no distinction in the Debian archive that says
"we try to have this quality requirements for one part of the archive
and a different one for another part of the archive".
And also when we say "we release when it's ready"
it's our way to say that
we know we cannot commit yet to a specific date
because we fear finding issues, quality issues, just before that release date
and we fear compromising our release quality for that specific date.
So when we say "we release when it's ready"
is also a matter of quality.
Third point, and something important for what I'm going to tell you next,
is independence.
If you look around at the ecosystem of distributions out there
you won't find many distributions where
you cannot pinpoint a company that is backing the distribution.
Among the big distribution, we are one of the very few
that is completely run on a volunteer basis
that have no corporate or some sort of hierarchical structure
where the decisions come from top down.
We have no single company babysitting us
and we essentially live up to donations,
in terms of time, so volunteers contributing time to Debian
and donations in terms of money.
This is very remarkable
in the ecosystem of today, especially in Free Software distributions.
And once more we have a phenomenon of community awareness:
our community seems to trust that, due to this independence of us,
decisions in Debian won't be taken due to some profit reasons
or other kind of reasons than our own core values.
So, independence is another very important value, for me, that motivates me to contribute to Debian.
And then, we have decision making.
Decision making is something that is very well codified in our Constitution.
The basic rule, which I started to call a while ago do-ocracy
- actually I picked it up from someone but I don't remember from whom I did pick it up,
but it seems to be sticking around -
essentially it says that if someone is responsible to do some kind of work in Debian,
as long as is doing that work, well, they decide how to do it.
Nobody can go there and say: "you need to do that work in that way",
unless
they are ready to commit and do the work themselves.
And this is the default rule.
All decisions in Debian, by default, are taken this way
and then we have also democracy:
we have come to some kind of potential correction on how we take decisions.
So we are allowed to take decisions all together,
in a democratic way, voting on stuff.
We are wise enough to that only, and in general, for political reasons
and for philosophical reasons
we try not to do that for technical reasons
but we can do that even for technical reasons.
So we try to use this
as some sort of way to make the default way of taking decisions works.
And what this means?
This means that is very easy to have an impact on Debian
if you know how to do something in Debian, and nobody is doing that,
you can pick it up
and if you start doing it, you will decide how to do that.
So, this is why is very is to have an impact on Debian thanks to the way we take decisions
but it also means that the reputation in the project follows work
if you have a good reputation in the project is usually because you've done a lot of work
and a lot of very high quality work.
And finally, once more, it means that there are not imposed decisions
it's not like the people who own the infrastructure
or who employ people
can decide how decisions are made
decisions are made this way.
And last point,
we've ended up being as some sort of root
of a huge ecosystem of derivatives.
I believe you all know what derivatives is about:
you take an existent distribution,
you start compiling packages,
you add your own packages, you change stuff
and you obtain a completely new distribution.
This is something that started to happen in the last
- started to happen massively -
in the last - let's say - ten years
and that really changed the way in which distribution products are made.
Derivatives can focus on customization
and benefit from all of the work that is done by their mother distribution
and Debian ended up being at root at something like
140 active distributions
according to distrowatch.
That means that the work we do in Debian
is not only relevant for our own - let's say - "direct" users,
is useful for the users of all this sort of distributions
which include the most popular distributions out there.
People out there, even if they do not know, rely a lot on the work which is done in Debian
and I think that this is great.
All in all, my point here is that Debian has a very important role to play
in the Free Software ecosystem in general
and if we fail at doing what we are supposed to do
not only the direct users of Debian will fail.
I think Free Software in general will suffer from a failure in Debian on delivering what we are about.
So the question is:
are we up to what we are supposed to do in Free Software in general?
And I've seen some challenges that I would like to discuss with you.
The first challenge is staying healthy
and staying healthy
for a Free Software project, for a volunteer Free Software project, essentially means
being able to recruit people
to find new volunteers that year after year join the project
and if you have heard me talking at DebConf on the past two years
or in general to the Debian developers public
we have always discussed the lack of manpower
as a major problem in the project:
we cannot do stuff because we have a lack of manpower.
In fact I've looked up the data
and our recruitment, if we can call it this way, is going very well.
Over the past two years
we have had thirty new DDs
more every single year
this is net in the sense that this is an actual increase on the number of DD
I have already discounted the number of DDs that dropped off the project
because of some sort of natural turnover.
Thirty DDs per year is quite a lot.
And if we look at maintainers, Debian Maintainers,
we have something like fifty new Debian Maintainers per year
this is gross because I didn't find the actual net data
but it still give an idea that we do, we are able to recruit people
both to work on Debian in general
- whatever the task -
and to work on specific packages in the archive.
I think we should really stop using the lack of manpower as an excuse
we are a volunteer project: we will always lack manpower to do something
but our ability to recruit new people is doing well
is doing very well.
What we really need to do is to actually better use the manpower that we do have
and, in particular, I'm worried about
the barriers for contribution that exist within the Debian Project.
One thing we discuss often is
we don't need people to maintain yet another package in the Debian archive
what we need is people working on some of the core teams
the infrastructure teams or maintaining the very important packages in the archive.
But the key to make that work
is to make it easier for people to contribute to those teams.
We have a lot of services in Debian which are very difficult to contribute to
we have services which are online
which have no mentions of where is the code behind those services
of where to report bugs for those services.
These are all small attentions we could use
to make it easier to contribute within the Debian Project
and if someone starts working on some leaf package in the archive
and if he find easier to contribute to some more important stuff
they will do that.
In fact that's how I think most of us that got involved in the Debian Project
ended up doing more and more important stuff
starting from the easy part and climbing up at bit
doing the more complex stuff.
So, if you are working on something within the Debian Project
in addition to think at the work you're doing
please think at "how can I make it easier
for others to contribute to this?"
"have I documented how to contribute to this?"
"have I put a link of where is the source code of this thing I maintain in Debian?"
"have I mentioned who should they contact for a project?"
all this kind of questions.
This is what will help in better using the manpower we have in Debian.
And another one, and someone will probably kill me for this,
is diversity in various senses.
I think we've realized
that to do an operating system like Debian
we need a lot of skills:
packaging is not enough,
packaging is one piece in the puzzle
but we need a lot of other stuff.
We need translations,
we need people doing artwork,
we need system administrators,
we need porters,
and all this kind of skills are quite different,
we need software developers,
and good packagers are not necessarily good software developers and vice versa.
We need a whole lot of different skills
and we do should not think that packagers are good at doing all of it
it is not the case: the skills needed are very different.
This is one reason why I think diversity is good
for a project like Debian
but I think it's good also for the discussion culture in Debian:
if you know that in a discussion place
you will find people that have very different backgrounds from yours,
very different point of view than yours,
then you need to be more cautious about how you write things
you need to make less assumptions when you write things
so having a more diverse project
actually helps also in having a better discussion culture.
This is the second reason why I think diversity is good for Debian.
We've done a lot in the past few years
we've sort of fixed the membership process
making it clear that we do welcome people with a wide range of skills joining Debian
and we have also, more recently, fixed the nm.debian.org website
to make it clear... to avoid implicit assumptions
that there are only packagers that we welcome.
This is great, we've done that.
But as Christian mentioned in the previous talk, stealing my argument
we are not doing very well
at attracting people who do stuff other than packaging:
in two years we've attracted only five people
in this so called "non-uploading" DD category,
only five people decided to join Debian as a project members
and said
"you know, I don't really care about packaging
I want to do something else in the Debian Project
and I commit to do that on a longer basis
but I do understand the values of the Debian Project and I'm ready to uphold them".
Only five is a bit ... it's quite a few
sorry, it's not too much.
We really need to understand how to invite
people with different backgrounds than packaging
to join the Debian Project.
I think that diversity statement we sent out
is a step in the right direction, but we need to do more:
I don't know what exactly, but we really need to do more to attract those kind of people.
Some other challenges are related to the release process.
I'm still amazed that people on the net
still complain that Debian has unpredictable release cycles:
the other day I replied on Linux Weekly News to someone who was complaining
that Sarge has been very much delayed as release.
Yes, that's true:
Sarge has been a delayed release,
like three years or something
but it is something which happened seven years ago.
Even in the time frame of Debian, that's a lot,
that's one third of our time in existence.
Since then we have learned:
the release cycle of Etch
took 22 months,
same for the release cycle of Lenny.
The release cycle of Squeeze took 24 months.
All of these look pretty much predictable to me.
I think we are doing well on that front
and starting with Wheezy,
for the first time in our history,
we've done time based freezes.
You probably know that I'm a huge fan of that
not all of us agree with that
but I think that is a huge step forward
because it helps developers in planning ahead changes.
Yes, there are people that will upload the last minute no matter what,
I understand that,
but for all the people who want to plan ahead
that's a huge help.
And it also helps our upstreams:
there are upstreams out there
who very much care about the version of their packages that will end up
in a stable Debian release.
There are people out there that if they know we freeze on a specific date
they will commit to give long term support for that software.
So knowing a freeze date in advance is a huge help for them.
I think we should keep this in mind,
keep in mind what was not working with the previous model,
like people getting upset of abort freeze
without knowing in advance when they were going happen.
And I think we should try to not forget this
aim in the future at reliably freezing every x months.
24? Maybe.
More than that?
Fewer than that? I don't know.
But I think we should try to keep this in mind and maintain that in the future.
And in case you didn't notice:
Wheezy is frozen!
And we did this with a time based freeze.
I think it worked well
but there is still a lot of work to do
and in particular
we have frozen with something like
135 more RC-bugs with respect to the previous stable release.
There is a lot of work to do for all of us.
In this work which is ahead of us
I think we should really aim to have a short freeze period
that's something we should aim to.
It will happen or it will not happen it depends on us,
but I think it should be a goal.
It should be a goal because it will show us that
time based freeze is a sustainable model
even if it means freezing with a bit more bugs than before
it will reduce the period of time
in which we are bit frustrated
in which we cannot do far reaching changes.
The shorter we can keep this period
it will be better for people who really want to make some more profund changes.
Asheesh do you have a question?
Sorry?
Asheesh: How short is good?
Stefano: So the question is how short is good.
Well, I don't know
I think it should be a goal
I don't think we can say...
Well, I mean, staying within the limits of the past trend
like six months
I think that's would be good.
Better would be shorter than that.
But this is not really a question for me, this is more for the release team
but I think we should have in mind
that we should do all we can
to keep that as short as possible.
And also there are distributions out there
that rely on testing
we do have in mind a single product, which is Debian stable
which is a great product
but, like it or not,
people out there are using Debian testing as a product
they're using it on their desktop machines,
on their development machines
because it's kind of
the thing that invented rolling distributions out there.
And it's a great suite.
Keeping it short
keeping the release - ehm, sorry - the freeze period short,
will also help other people that rely on something like Debian testing.
How do we do that?
I don't think it's really normal to have that many release critical bugs
at the freeze point
it means that there are maintainers... it means two things
that there are very hard bugs to fix, which is normal,
but it also means that there are some maintainers
that they kind of neglected their work
that they didn't manage to complete to clean up
their packages of release critical bugs before the freeze.
But it happens
we are here, it has happened in the past, it will happen again in the future.
So the only way I think we have to release at this point
is to, once again, keep in mind that releasing
is not something that the release team does alone
they cannot release Wheezy alone.
I've been bothering you with this idea since ever
since way before I became the DPL
but I think the only solution we have for this
is doing NMUs,
accepting NMUs,
welcoming NMUs,
loving NMUs
every single day, please, have a look
at the list of release critical bugs reports.
I look at this graph, essentially, every morning
and also after coffee, to see how we are going
really, please do the same!
Then, please, every day
look up if there is a release critical bug you can fix
even, and especially, if it is not in your package.
There are people, like Gregor - who is somewhere here in the room -
that every single day - thanks Gregor -
every single day try to do that
and publish the initiative to make other do the same
he is not the only one, a lot of other people are doing that
but also publishing it is very good.
And, really, NMUs that fix RC-bugs
are free for all
do them properly, try to make it clear that you're trying to help
the maintainer of the involved package
but please: that's the only way
we're going to release Wheezy
really.
And if you want another way of looking at this,
it's for the software engineering fan,
is collective code ownership.
So, collective code ownership is a notion that
well, this term comes from extreme programming
and essentially says that all programmers
have access to all of the code of a project
so that no single person can be a bottle neck
on a specific part of the project.
This is considered good in agile development,
this is considered a best practice to follow
in open source project management,
but in some way it is not always considered good in Debian.
Which is kind of weird.
In the past we didn't have the notion of maintainer
then, Bdale will correct me if I'm wrong, in 1995
has been introduced.
Is it right? Something like that? Ok thanks.
And with that we sort of added some barriers.
There are useful stuff behind the notion of maintainer
like pride in what you do, being recognized for the work you do
which is great.
But we should also keep in mind that there are barriers
with the notion of maintainer
that make it harder
for others to contribute to your package.
So the best approximation we have
to collective code ownership in Debian
is essentially being more liberal with NMUs
and team maintenance,
but we don't have teams which are as large as the Debian Project.
So liberal NMUs is really our best approximation
for collective code ownership in Debian.
And then, moving to the past two,
which probably will be a bit more controversial.
Low company involvement, I think is becoming a problem in Debian.
If you look at other similar project to Debian
with the same kind of history and with the same size,
you'll see that Debian has less paid work opportunity around
and you'll see that we have few companies which are contributing directly.
Think at the Linux kernel:
everyone who can show that can get code in the Linux kernel
will find a job in five minutes.
We do have companies that will be happy to hire Debian Developers
but not as much as you have around a project like the Linux kernel.
So, for me, volunteering is great
I wouldn't work on Debian on paid time, I would not do that.
I work on Free Software for volunteering reasons
it matches my view of society where
each of us has a work
and some extra time, after work,
in which he does something to contribute to society
so this is not really for me.
But I think it could be a problem for Debian in general.
Why?
We do compete
with companies and their full staff - sorry - and their full time employees.
So, our competitors are commercial distributions
with huge means in terms of employees who are working on the distro.
That's fine, we don't do Free Software only to make money
but we need to watch out for our morale.
So, when we start thinking stuff like
"Debian is not innovating anymore"
"It is other distributions innovating"
well, we need to keep in mind that
the ratio of forces in the field may not be very well balanced.
This is the first problem that I think having low company contributing to Debian.
Second reason is that
there are useful tasks out there
that volunteers won't bother doing.
I've been asked many many times:
"why don't you go to hardware vendors and convince them
to pre-install Debian on their machines?"
Well, try to find a volunteer that is happy to spend his time
in, you know, lobbying hardware producers to install Debian on it.
That's an example.
Other examples are all sort of certification lobbying:
something that very often public administrations ask me
is why Debian is not certified for
random very high quality corporate database system.
Why Debian is not certified for that unnamed system?
Well, because you need lobbying to do that,
you need people going to the
software vendors and convince them to say "Yes, you can run this on Debian".
Otherwise, there are people out there that won't run Debian.
And all sort of other stuff,
like creating a sort of networks that makes
specific adopters convinced them they will be fine adopting Debian.
And the last reason why I think we need a bit more of companies involved in Debian
is a sort of disturbing thought.
What if only one company or a few companies, for what it's worth
end up hiring the whole lot of DDs?
The independence I've been babbling around before will be gone.
This is not paranoia.
This is a kind of problem that has been discussed,
for instance, in the Linux kernel community for a long time.
They know that they have some sort of independence because they have
many different companies
with interest in the Linux kernel
which sort of balance each other.
So if we don't have more companies interested in Debian
we'll risk ending up in that situation.
Some sort of very early work in progress
which I've tried to kick start
is a sort of user group, debian-companies,
of companies who have some strategic interest in Debian
and want to try to work on fixing this problem.
They may be other solutions,
I don't know, I wanted to present this as problem
as I think that in the long run we'll need to think about it.
And the last thing is the DPL.
Which happens to be me at the moment.
What does the DPL do for you?
According to my family possibly too much
but that's a separate problem.
He does fancy stuff:
he goes to conferences, he's all around the world, he's invited to talk about Debian
and he has a wikipedia page and all this kind of fancy stuff.
But he also has to do
all sort of needed but pretty boring, for the average geek, stuff.
He has to take care of money:
approving reimbursements,
buying hardware,
DebConf, donations
trying to avoid bankruptcy,
which is a nice thing to do.
And he needs to take care of lawyers.
I've never been working with lawyers
as much as in the last three years.
He takes care of what we do with patents:
can we have it in the archive or not,
what we do with trademarks,
what we do with copyright, for instance,
can we relicense the Debian logo
without undermining some other asset we have?
And legal responsibility:
and what if a Debian Developer get a lawsuit?
All this sort of stuff,
which is useful,
because if we now have a bit more
- how to say? - enhanced multimedia experience in Debian
is also because we take the time
to discuss this stuff down with lawyers that are experts in Free Software.
And he does mediations,
and he does reports.
How many reports from me have you got in the past three years?
Yeah, too many!
This is all sort of boring stuff
which I think is useful for the project.
But then, as it is today, the DPL is a problem.
I am a problem, but it's not me, it's the role of DPL who has a problem in Debian.
It just does not scale.
We basically rely on some sort of luck
that we will find
candidates that will have enough time to do all of this
and it's quite a bit of time.
I don't know if it's wise to only rely on luck
to finding those people
over the years forever.
Second problem: transparency is very hard.
I've tried to... I've worked quite a bit on that:
I think I spend like half of my time
as DPL
in trying to tell you what is going on
and only the other half on working on stuff.
I've been happy to do that, but is very hard.
And as long as I'm talking to myself
or replying to inquiries that come to the Leader's mailbox
there are some sort of intrinsic limits:
if you are in a team with more people
you need to discuss things
and if you force yourself to discuss things publicly
you don't have these intrinsic limits.
And the third problem is that there is very little institutional memory.
We keep on, essentially, rediscover the job
at each DPL change.
Yes, I can write a DPL Howto
with the help of all past DPLs.
We can do that, but things change
and essentially the key of the problem is that
being the DPL is unlike any other task in the project:
it's difficult to know who will be a good DPL before
because he or she has never done that before
and there is essentially only trial and error.
There is very little institutional memory of how to do things.
How can we fix this?
I've been thinking a lot about this,
is one of the reason why I decided to run again for a third term,
essentially I think the problem is that
the role of the DPL is a relic of the "benevolent dictator" era in the Free Software.
It made a sense in the past,
today projects of the size of Debian are not run in this way
not even for only the management part.
We do not do the technical part with a benevolent dictator, which is very good,
but we do that for all the kind of management part.
I think the only solution possible here
is have some sort of board of directors
as other projects have
which essentially helps the DPL.
The role of the DPL should not disappear.
I think we should try to keep this as informal as possible
but if we have a group of people that we can call the Debian Board of Directors
that can have some sort of turnover
to guarantee that there is some institutional memory
so they should not be tied to the normal DPL period,
otherwise you'd have the problem of institutional memory again,
with periodic meetings for transparency
and if we do have this
you can have the people on this kind of board
that help out and show if themselves they will be able to do
good DPLs or not.
I think this is the only way
to make the role of the DPL scalable
without changing the nature of what the institution is.
And as an interim solution
I'm trying to collect a group of DPL helpers
you've seen the call for help, thanks to all the people who replied.
So what I'm trying to do is to
try to see if this kind of things could work.
And yet, the DPL will remain.
So, given I'm here basically because someone
a few years ago started joking about me becoming DPL,
well, this is a good occasion for all of you
to start think at the next one
and maybe start joking with him
whether he or she will be happy to candidate the next year.
So, thanks a lot
it's a pleasure to be here
and if you have questions or thoughts I'm available.
Thanks
[applause]