Bundling more plugins into bzrtools
Toshio Kuratomi
a.badger at gmail.com
Fri Feb 15 00:42:16 GMT 2008
Jeff Licquia wrote:
> Toshio Kuratomi wrote:
>> 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.
>
> I'm confused. If you have twenty upstream plugin authors working on a
> unified source base, and one of them has a security update, you still
> have to respin your package, right?
>
Sorry, I thought I was making that clear in the next sentence. Using a
security update probably wasn't good though.
>> 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.
>
So if you have twenty packages on different release schedules (some
plugins never update, some plugins update with every bzr release, some
go through cycles where upstream has time to develop and time when it
can't develop) then whenever an upstream project updates because of a
bug you, the downstream, are probably going to want to respin your
package because you don't know when any of the other upstream projects
are going to make a new release. If there's one upstream project that
holds all of these plugins then the project can evaluate the severity of
the bug, distance to their next anticipated release, and whether there
is one other bug that is pending a release or twenty.
> This is a little confusing, also. I get that *you* have less work, but
> I don't see the savings in the total amount of work. Someone has to
> herd those ten upstreams into one big thing; it's not going to happen by
> itself.
>
Sortof. If you are a member of an upstream project that is doing a
release in two weeks you know that you either have to get your changes
into mainline by a certain date or be skipped over until the next
release. There is a certain amount of self-regulation going on. If you
are a downstream packager that is bundling twenty upstream projects then
you are stuck consuming what the upstream produces when they produce it.
In the first scenario there is a certain amount of herding going on by
each plugin author because they know that there's a set goal at a
certain time in the future. In the latter there is no one herding the
upstream projects whatsoever.
-Toshio
-------------- 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/e35d0f32/attachment.pgp
More information about the bazaar
mailing list