Bundling more plugins into bzrtools

[Toshio Kuratomi]

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