[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
- Subject: Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
- From: todd rme <firstname.lastname@example.org>
- Date: Sat, 9 Oct 2010 00:28:38 -0400
- To: email@example.com
On Fri, Oct 8, 2010 at 10:50 PM, Marc Paré <firstname.lastname@example.org> wrote:
>>> Would you then have any idea if this would cause a lot of devoted dev t
>>> part-time, full-time attention. Would LibO then have to have a dedicate
>>> in charge of this?
>> I doubt it would require a full-time developer, since changes would
>> only need to be made when a new version of openoffice or, maybe, when
>> a new version of a distribution is released, so probably 4 or 5 times
>> a year. I don't know about deb files, but spec files for rpms would
>> only require the version number be changed and, if there are changes
>> to the file names in output, some changes to the list of files. We
>> are probably talking a few hundred lines of code for the entire spec
>> file, and only between 1 and maybe a few dozen would have to be
>> changed for a openoffice update, while only at most 5 or so would
>> likely need to be changed for a new distribution release (ideally none
>> would have to be changed in that case).
>> However, it may still be too much work given the benefit.
>> Distributions will normally handle the packaging themselves anyway, so
>> I am not exactly clear on what benefit there would be in duplicating
>> this effort. Really the main benefit I can see is not to users
>> directly, it is making sure the software builds on common Linux
>> distributions without distributions having to make their own
>> modifications. So it may be worthwhile from a debugging perspective
>> alone, and if the packages are going to be built then publishing them
>> would be no added effort.
> Perhaps a benefit would be a coordinated unveiling of the product on a gi
> date. Rather than having to rely on other distros to update their packagi
> DocumentFoundation would then be the distributor of the different package
> Updates and critical bug fixes could then be distributed quicker.
But it is important to keep in mind the distributions' own release
policies. Many distributions do not allow non-security-related
updates over the course of a single release cycle. This allows them
to thoroughly test a given combination of software. Having the
distribution release one set of packages and having the foundation
release another set may be confusing to users and will may prove to be
a major annoyance to distributions which work hard to provide a
coherent set of packages.
I am not saying that such packages should not be released, my point is
merely that we need to be mindful of the needs and limitations of the
distribution maintainers, and not make life any more difficult for
them than is absolutely necessary. Just pushing out packages and
telling users to download them is not a good strategy, in fact it is a
really good way to turn distributions against you. More thought, and
a lot of discussion with those maintaining the distributions, will be
needed in order to guarantee a mutually beneficial approach. It may
not be possible to completely please every party, but unilaterally
bypassing the distributions entirely is not a good idea in my opinion.
To unsubscribe, e-mail to email@example.com
All messages you send to this list will be publicly archived and cannot be deleted.
List archives are available at http://www.documentfoundation.org/lists/discuss/
|Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)||Marc Paré <firstname.lastname@example.org>|
- Prev by Date: Re: [tdf-discuss] List available at GMANE
- Next by Date: Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
- Previous by thread: Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
- Next by thread: Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)