[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] Patches
"Kern Sibbald" <kern@xxxxxxxxxxx> kirjoitti viestissä
> On Saturday 25 October 2008 21:53:00 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).
>> > > > 2. Announce patches to the bacula-devel list
>> > > > 3. Announce patches to the bacula-devel list and the bacula-users
>> > > > list 4. Announce patches to the bacula-announce list as well as the
>> > > > other two lists.
>> > > > 5. Put patches in the news (time consuming and I doubt that many
>> > > > read
>> > > > news). 6. Create an rss feed (I doubt that many users use rss, and
>> > > > this also could be time consuming).
>> > >
>> > > 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.
> I was out yesterday, so will answer here in your second email.
> Yes, I think having full packages available is the best way to get
> We already sometimes do that. However, as Eric pointed out, it is a lot
> work. The packaging is done by the community. I release a new source tar
> file and (with the exception of Win32), the community creates new packages
> they want. They always do so for new releases, and for what I designate
> critical fixes, but possibly not for all the more minor patches.
I guess there are a number of users who are not familiar with the packaging
process, partially that includes me, although I'm rather used to build many
binaries from source rpms.
One reasonable way to reduce the burden to the packagers might be, if they
mostly concentrated (now I'm talking only about rpm packages, I don't know
eg. debian) in building the source packages that could be expected to
succesfully build into binaries. I understand that there is a lot of work
after building the source package that somehow seriously can be expected to
work, since the various final binaries preferably should also be installed
in the target systems and tested there -at least to the point they start
nicely. But when it's about "small" minor patches, it might be reasonable
that an experienced packager views the patch and the spec file, and if it
were expected that all this could result in a working binary package,
building the binaries could be left to the end users -at least when it comes
to the very minor patches.
Currently, at least I am a little bit scared about the idea of building and
installing into a "production environment" an application that was shipped
as a source tarball, since it may conflict with the existing system, and I
have some bad experiencies from the past how to uninstall some tarball
installations (not speaking of Bacula now), though a bad rpm binary may be
hard to uninstall as well.
So, could a reasonable middle-way be releasing more source rpms, and include
in the release notes an example how to build the binary rpm? Or, if a
supposed-to-be-perfect spec file that can handle the patches is already
included in the tarball, just include an example command sequence how to
build a binary rpm all the way from the source tarball? This would reduce
some raw shovel-level work from the packagers. Then, if the binary could not
be built eg. due to some bug in the spec file, it would be up to the
official packager again if he/she has resources to fix it at that point, or
decides to wait until the next release.
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.