On Saturday 26 September 2009 10:38:07 Blake Dunlap wrote:
> > Hello,
> >
> > Recently several email design threads have pointed out an important
> > deficiency
> > in the Bacula project that I would like to discuss. We (I) I have already
> > designed (mostly in my head) a good number of future projects --
> > including how to support portable clients better, deleting volume on
> > purge, clients initiating backups, ... Often these are put down in
> > sketchy notes and shared
> > with the programmer who wants to do the work (mostly Eric). Generally
> > the solutions designed are far more general and complete and already
> > encompass much of what is being discussed via email. The problem is that
> > this process
> > is not well defined and is not implemented in a way that a number of
> > users can participate or even see what those proposed designs are.
> >
> > It seems to me that we need a more public way to share Bacula design
> > proposal.
> > Launchpad has a nice way of doing that (I forgot exactly what they call
> > it),
> > but I have recently moved off of Launchpad because as a project manager,
> > I was unable to properly structure the project (it seems that only the
> > Launchpad programmers can do that), in addition, I found launchpad very
> > difficult to navigate.
> >
> > What we need is either a place where I can publish approved designs
> > (probably
> > the web site) or possibly a special design wiki. At the moment, it is
> > not clear to me that a wiki would work well -- the biggest problem is
> > that many
> > users don't fully appreciate the Bacula philosophy and how Bacula works,
> > which means that it is easy to go off on a tangent. This is not a
> > criticism
> > of anyone, but is meant to point out that designing new features for
> > Bacula
> > is very non-trivial and requires a *lot* of work and thought before any
> > implementation begins.
> >
> > I suppose that the first step is for me to write up (or gather up what is
> > already written) a few of the designs for ideas that are being discussed
> > on
> > the email lists so that you can see the direction I currently favor ...
>
> Speaking as a minor hacker / user of the project, that would help greatly.
Yes. :-)
>
> Speaking personally as a systems architect / developer, it practically
> makes me twitch trying to make any modifications without any design
> knowledge as far as the current project managers and developers, as it is
> counterproductive and quite often results in effort that will never make it
> to mainline, and while generally the work in question is useful to the
> original party, the effort of trying to maintain a secondary patch set is a
> project in itself, and rarely worth the effort long term except for special
> cases of either strong philosophy differences or considerable differences
> in target use. Anyone who has ever tried to work with/for OSS/semi-OSS
> projects that they do not control probably has experienced this at some
> point (I'm looking at you asterisk).
We have mostly worked around these problems by strongly encouraging potential
developers to read the Developers Guide posted on www.bacula.org. It pretty
much covers all the points necessary to ensure that code submissions are
accepted. The problem is that not everyone reads this document.
>
> Currently without dedicating considerable time to just understanding what
> is trying to take place / extracting the information from other quite busy
> developers who quite rightly feel it is unlikely to have any return on time
> investment, or do not wish to rehash said discussions, it is extremely
> difficult to get a good overall picture for anything not already documented
> (and likely mostly completed for a long time) or be able to give any
> genuinely useful input besides very minor modifications and simple bug
> tracing / fixes as most discussion is not held publicly.
As you point out, sometimes it can be a big waste of time discussing with a
potential developer the details of a project because 9 times out of 10
despite their good intentions, programmers just don't have the time to do
everything they would like to do.
Once we see that a developer is serious, we (I) do spend a lot of time
(generally off list) helping developers with design, questions, coding,
understanding Bacula, ...
The problem is that the above is more one to one, which is very rewarding for
me, but it is not very scalable, and Bacula is growing, so we need to figure
out ways to gently scale it better.
>
> Unless there are specific questions posted, or there are specific feature
> requests to be made, I know I personally try to sideline as much as
> possible, as I do not have the understanding necessary at this point, to do
> much other than for the most part, waste others time.
One user suggested to me that a blog may be a good way to encourage more
participation without costing too much extra load on the developers, so I
have just enabled Wordpress for Bacula and posted a test ...
You can see what is there at:
https://sourceforge.net/apps/wordpress/bacula/
I think you have to login to get to that page. The idea is that we develop
more detailed project specifications (starting generally from the Feature
Request) and post them there where Bacula users can put their comments. At
some point development will begin. Thus potential developers can look at
project design notes. I am not really sure how it will work, but it is
worth experimenting with the idea -- unless someone has a better idea.
>
> I think Bacula is a wonderful if not very well known project, and vastly
> superior to any other product I have seen save for high end commercial
> backup offerings. It scales quite well, and is adept at covering the needs
> of quite small setups, to very large ones, with some minor caveats. I know
> it has saved my company and some of our customers (though they don't know
> it) considerable time, money, and headache compared to the previous
> products we have used (for instance I hate Arcserve with a passion still
> that burns in my veins to this day), however there are just the same, a few
> weak points that we have had to work around as well that it would be very
> nice to see those issues handled natively and "just work".
Thanks for all your comments. I hope that the project will become better
known, because the more users there are the better Bacula will become.
If you have some good ideas of how to fix the Bacula weak points and they are
not already covered in the "projects" file, please let us know about them.
>
> > Does anyone have any comments or ideas on this?
>
> You asked =)
Thanks :-)
Kern
>
> > Best regards,
> >
> > Kern
>
> Blake Dunlap
>
> ---------------------------------------------------------------------------
>--- Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Bacula-devel mailing list
> Bacula-devel AT lists.sourceforge DOT net
> https://lists.sourceforge.net/lists/listinfo/bacula-devel
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
