Bundling more plugins into bzrtools
a.badger at gmail.com
Thu Feb 14 19:11:13 GMT 2008
Jeff Licquia wrote:
> Toshio Kuratomi wrote:
>> This consolidation is also helpful to the upstream projects. For
>> instance, if bzr-dbus, bzr-bisect, and bzr-stats tried to solve
>> problem #1 individually they would each have to implement build
>> scripts to make their checkout into a ready to consume tarball, each
>> have to write instructions for installing, and each have to create
>> releases when the time came. If combined, one set of build scripts
>> and one release manager could do the job for all of them.
> If the upstream plugin maintainers can't merge, for whatever reason,
> can't the package maintainer(s) do the merge for them?
> I (the author of bisect) wouldn't have a problem if Fedora had a
> "bzr-plugins-popular" that lumped dbus, bisect, stats, etc. into a big
> package, complete with "original" tarball. With a little work, you
> could even auto-maintain the tarball, with update scripts that do pulls
> from each upstream, update the package changelog and version, etc.
We have a de facto standard in Fedora_ of one tarball one package.
There are multiple reasons for this but the number one reason is
coordinating release schedules. If you have twenty upstream projects
and one updates with a security fix, you have to respin your package.
Note that this differs from one upstream project with multiple parts in
that one upstream project on bzr's release schedule might release once
or twice a month because people agree to work towards a common release
date. If you are spinning one package which is made up of ten upstreams
and just three of those do a single update in that same time frame you
are doing more work.
This kind of thing is exacerbated by working with snapshots of
upstream's tree rather than being able to depend on upstream making
releases because you don't know if a series of commits shows that
upstream has finished a feature, is still testing, or have run out of
time and plan to finish up next weekend. So you end up spinning new
packages more often.
Of course, one way that the multiple plugin authors could minimize this
churn is by agreeing that they are going to only make their releases at
a certain time of the month but is that something the authors want to
do? And if so, what's the remaining reasons for not merging?
.. _: Packages whose lineage dates back to Red Hat Linux are in the
process of being split up if they don't follow this.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080214/6df85f7d/attachment.pgp
More information about the bazaar