[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] Patches


Hi,

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:
>>>> Hello,
>>>>
>>>> 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 
-announce list.

>>>> 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
>>>>     lists.

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
>>>> news).

I agree - that won't help the majority of people who would profit from 
those announcements.

>>>> 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.

>>> Hello,
>>>
>>> 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 
certification process.

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 
consuming...

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
> Ulrich
> 
>>> Only Sourcecode an patches are released to sourceforge (maybe win32
>>> binaries too).
>>>
>> Bye
>>
>>> Best Regards
>>> Ulrich
>>>
>>>> If anyone else has ideas we would like to hear them.
>>>>
>>>> Best regards,
>>>>
>>>> Kern
>>>>
> 
> 
> -------------------------------------------------------------------------
> 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
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Bacula-devel mailing list
> Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/bacula-devel

-- 
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
www.its-lehmann.de

-------------------------------------------------------------------------
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
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-devel mailing list
Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilotco.