Bundling more plugins into bzrtools

[Toshio Kuratomi]

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[1]_ 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?

.. _[1]: 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...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080214/6df85f7d/attachment.pgp