[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] Patches
this is a summary reply to distinct parts of this discussion... I hope
it doesn't get too confusing, but as I'm not a developer I believe you
won't find it necessary to reply to most of my thoughts.
25.10.2008 21:53, Ulrich Leodolter wrote:
> On Sat, 2008-10-25 at 21:11 +0200, Eric Bollengier wrote:
>> Le Saturday 25 October 2008 13:41:15 Ulrich Leodolter, vous avez écrit :
>>> On Sat, 2008-10-25 at 11:32 +0200, Kern Sibbald wrote:
>>>> For some time now, I haven't really been happy with the Bacula patch
>>>> procedure. Basically, when we fix a bug (either from a bug report or
>>>> ourselves), we usually generate a patch, post it to the bug report, if
>>>> any, and upload it to the Bacula patches area of Source Forge.
>>>> Providing you are subscribed to the bugs database and to the
>>>> bacula-patches release notification on Source Forge, you will see these
>>>> patches and can apply them if you deem necessary.
>>>> The problems I have with this is that some people may not know about
>>>> patches (we see this in bug reports where a problem is already resolved
>>>> with a patch), and there is no formal mechanism for developers when
>>>> generating a patch.
>>>> We already have more work than we can handle, so any change needs to be
>>>> simple and not time consuming for developers, but I am wondering if
>>>> anyone has suggestions how to improve this. I can think of a few:
>>>> 1. Change nothing (signing up for bugs and patch notification is already
>>>> not bad).
Well, you started by stating that you want to improve this, so let's
see if we can find a real improvement :-)
>>>> 2. Announce patches to the bacula-devel list
Probably not necessary - I assume readers of this list who want to
closely follow the development also monitor the bugs database and the
>>>> 3. Announce patches to the bacula-devel list and the bacula-users list
No - keep the -users list out of this. There are some people there who
regularly report back the development status on features and bug
fixes, and I think this is sufficient.
>>>> 4. Announce patches to the bacula-announce list as well as the other two
Combine my two thoughts from above, and you know that I don't like
this suggestion :-)
>>>> 5. Put patches in the news (time consuming and I doubt that many read
I agree - that won't help the majority of people who would profit from
>>>> 6. Create an rss feed (I doubt that many users use rss, and this
>>>> also could be time consuming).
With the framework available in the baculasystems.com web site, it
wouldn't be much more time consuming than writing an email, but I
agree that probably many users don't use rss.
So, the announcements mailing list seems to be the place most suitable
for announcing patches.
>>> One thing i am missing are patched packages, rpm and also deb packages
>>> have a mechanism to include patch files an apply during build process.
>>> For most bacula users it would be much easier to apply patches by "rpm
>>> -U ..." or "dpkg install ...".
>> Yes, but you have to build, test and release a package for each disto after
>> each patch, this is a *huge* amount of work, we have something like 10
>> patches between two releases.
>> If someone want to build, test and package 10 more often than before for free,
>> no problem, but i prefere spend my time with new features and bugs hunting.
>>> Operating systems like RedHat, CentOS, SLES, Debian, ... are always at
>>> least one step behind last official version.
>>> An official bacula package repository (yum, apt) would be great.
>> Fedora, debian and ubuntu already provide this kind of repositor, and often,
>> they have a backport branch.
A maintained list of those repositories would be a good thing, I
think. I don't know of any such list.
> Sure u right, a lot of work and resources are needed.
> Just curious, how will Bacula Systems handle this ?
> Includes Enterprise-Class Support patched binary packages for Customers?
This is something that's still under discussion. You might have
noticed that Kern mentioned he's writing a document regarding the
I believe he will cover this topic, too.
What *I* believe is that Bacula Systems will not necessarily provide a
new package for every new patch. There are two reasons for this belief:
First, resources - Bacula Systems doesn't have the resources to build
and, more important, test new packages for all the supported platforms
that often. We might want to, but unless the paying customers, as a
whole, want that service and are ready to pay for it, that's simply
not possible with the fees we're getting paid. Similarly, third party
packagers probably don't want to run a patch/build/test/package/test
cycle for each published patch. The testing is simply too time
Secondly, and that's probably even more important, most users don't
want new packages each month or even week. As long as there are no
bugs fixed that affect the individual user, nobody wants to upgrade...
so, Bacula Systems has, similarly to what every other company
publishing software does, to somehow limit the frequency of package
updates. This always implies that some bugs remain unfixed for a while
longer than technically necessary. In many cases, unfixed but
documented bugs are easier handled than a system-wide update. The
Bacula Systems developers and support crew have to decide when a new
version should be produced. Bacula Systems people are probably aware
that they will sometimes disappoint certain users, but, with limited
resources, that simply can't be avoided.
Personally, even for my own smallish network and the few customer
systems where I manage updates and software versions, I don't like the
moments when I have to decide if I'm going to update or wait with it
if there are no bugs or security issues fixed that affect me. I prefer
the frequency of those days to be as low as possible :-)
> Best Regards
>>> Only Sourcecode an patches are released to sourceforge (maybe win32
>>> binaries too).
>>> Best Regards
>>>> If anyone else has ideas we would like to hear them.
>>>> Best regards,
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> Bacula-devel mailing list
Sandstr. 6, 49080 Osnabrück
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Bacula-devel mailing list
This mailing list archive is a service of Copilotco.