On Thursday 26 April 2007 05:25, David Boyes wrote:
> > This refers to the fact I will not be happy to have to spend any more
> of
> > my
> > time on this bug, and when I am not happy about events, I usually take
> > some
> > steps to avoid their re-occurrence in the future.
> > I expect the bug to be fixed and quickly, but this is a volunteer
> project
> > so
> > it is up to you guys to decide.
>
> While I can understand frustration when something seems to be slipping
> through the cracks, I'm not sure that continuing to criticize Robert and
> Landon in public is accomplishing anything useful. An off-list
> discussion between the three of you may be more fruitful.
>
Perhaps you are right, and I understand that a number of people may be
surprised or even shocked to hear a certain level of criticism because
generally most all criticism has done off list.
In this case, there is a much bigger issue here, and the subject merits
discussion. I've specifically copied the Bacula users list on this email so
that everyone can see my point of view
The main issue here is that my time is limited. It does not scale with the
size of the project.
As a consequence, I have decided that I will not personally "support" all
platforms, as I have done in the past. Note, this is a personal decision,
and criticisms of this decision such as "your reasons are not valid" don't
hold water with me when it concerns how I use my own time.
For a platform to be officially "supported" by Bacula, I feel there are a
minimum of three things that are required. This is nothing new, it may not
have been explicitly stated, but it has always been part of the Bacula
project philosophy:
1. The regression scripts are run regularly and on demand.
2. The platform is fully documented in the manual.
3. There are one or more persons that will respond to platform specific bugs
in a timely basis.
I will put the above someplace in the manual or perhaps the Developer's Guide
so that it is clear. Please note, that there are many other Client packages
that are "known to work". They may be partially documented in the manual,
but no regression scripts are run on them, and bug fixes come from submitted
patches. Such packages are not "officially" supported as Linux, Solaris,
FreeBSD, and the Win32 client have been.
I will continue to do the above tasks as I have done in the past for Linux (in
particular the platform I am running, and to a lesser extent for the Win32
Client, though that really should be 100% handled by a Windows person).
The point was/is that I will no longer provide the above services for Solaris,
FreeBSD, and Win32, which means that unless something changed, they would be
no longer supported. The status of those are as of today:
Solaris, FreeBSD:
Item 1: regression testers "signed" up.
Item 2: already documented in the manual
Item 3: problematic, but I will work with the regression testers until
appropriate developers are found. In any case, these
platforms have very few problems since their underlying
API is the same as Linux in most cases.
They will very likely remain supported, but there is still a lack of
developers for them.
Windows (note we are talking about the new server code rather than
the client):
Item 1: Unknown
Item 2: Documented in a README but not in the manual.
Item 3. Unknown. I do not offer to work on the servers, and
this platform needs a good deal of developer attention
because the underlying API is significantly different from
Unix/Linux.
============
What you may not understand because I haven't been able to clearly formulate
it until now is that this decision, and more particularly certain of the
reactions to it have profoundly changed the nature of the Bacula project. Up
to today, the project has worked a bit as follows:
1. Kern is project manager, but does not want to be a "gate keeper".
2. Developers are quickly accepted into the project and in a very short
period (typically a week or so) have full SVN write permission.
3. There are growing numbers of contributions (very good).
a. Some contributions come in the form of relatively small patches, which
Kern reviews, integrates, documents, tests, and maintains.
b. The other source of contributions, which is also growing (very good)
has been direct commits from developers. Typically, I look at these
submissions in a summary fashion. For most of the code submitted
in this way, I have not reviewed it in detail, and have not integrated
it (the developer did so). However, I generally document it in the
manual, write the regression test if any, test it, and then maintain it.
c. A minority of the developers (there are thank God some), take full
responsibility for writing the code, posting as patches so that I can
review it as time permits, integrating it at an appropriate time,
responding to my requests for tweaking it (name changes, ...),
document it in the code, document it in the manual (even though
their mother tongue is not English), test it, develop and commit
regression scripts, and answer in a timely fashion all bug reports --
even occassionally accepting additional bugs :-)
4. Now what I have realized is
Item 3.a will continue and is a normal event for any open source project.
Item 3.b is unsustainable because it does not scale (my time is limited),
it is not very professional because the code is not really fully
supported, and in the long term will slow down development of the
project (IMO). This mode of development is going to disappear.
Item 3.c is a sustainable way of going forward with Bacula, and the
direction that the project will be taking. It is not in itself a complete
solution to the lack of developers, but it is a *big* step forward. For
example, in the past, we have had some very dedicated programmers
who did major projects as described in item 3.c, however, those
programmers due to outside obligations (job responsibilities change of
job, school duties, ...) could not continue to maintain the code. In
those cases, the code suffers from lack of maintenance, sometimes I
patch it, sometimes not. In the end, the code gets dropped from the
project (there are two such contributions that are heading in that
direction).
So, this current "frustration" as you call it has accelerated the process of
transitioning from a development environment as described in 3.b to one
described in 3.c.
In the future, you will see me acting more as a gate keeper rather than simply
accepting all submissions, and developers will have slightly less freedom for
direct commits (changes in items 1 and 2). Tightening the development
requirements and acting as a gate keeper doesn't particularly please me, but
I see no other way of going forward.
I've started the process by documenting it above (it will go into the
development manual), in addition, I have removed all the developers from the
project who have not already signed the FLA (Fiduciary License Agreement).
None of them had write access to the SVN, and so there seems to be little
reason to keep them listed. If any of those developers would like write
access or to be re-listed, I'll be very happy to discuss it and add you back,
please contact me off-list.
=====
I have previously mentioned this, but perhaps it merits being said again.
Concerning my personal use of time in Bacula, much of it will continue as
before, though new code will now be handled in a different manner with much
more responsibility placed on the developers rather than on me. The other
major aspect is that I will be focusing my efforts on helping Bacula
penetrate the "commercial" sector, and I plan to do that by working with 3rd
party Bacula professional service companies to provide quality support Level
2 support to commercial clients. My contribution will be to help these
service companies get recognition, standardize their methology, provide
certification of their services, help them obtaining contracts, and providing
level 3 support to them should they need it. The primary goal of this is to
ensure wide spread qualified "independent" professional support for Bacula so
that enterprises will have a real alternative to the commercial backup
vendors. I won't explain all the details here, but this will also
significantly improve the margins of these 3rd party support organizations
that are often financially squeezed between their clients and the commercial
backup vendors.
The benefit of the above will be more contributed code to Bacula, wider use of
Bacula, Bacula being used hence tested in much more demanding environments.
I think it is a win-win-win (Bacula project-support companies-users)
situation except perhaps for the commercial backup vendors.
Best regards,
Kern
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
