Re: New orgs, new repos!

[Henrik Skupin]

Dustin J. Mitchell wrote on 04/18/2014 12:04 AM:

Hi Dustin,

> The "qa" PuppetAgain organization is coming up to speed in the next
> few days, so it's time to get a little more serious about isolating
> organizations from one another.

I have to already thank you for your help in the past couple days to
bring me up-to-speed with Puppet. As deeper I dive into this tool, as
earlier I can't have all of this running. Lets see what we can
accomplish the next week.

To update all others on the list, for now we want to get the initial
setup, and system and application updates working for our Mac and Linux
machines. If possible we also want to follow-up with those for Windows
during this quarter. Full system deployments will happen later.

> More surprising: there won't be any "canonical" repository. We'll
> all merge *from* the other repos as frequently as our change
> management allows. That allows each organization to decide when to
> take a particular update or change, and to resolve any conflicts. I
> plan to check for updates at least weekly, and try to merge whenever
> I learn about a substantial change in another tree.

So how can we ensure that changes have been proven to work? I don't want
to merge code which could break us. Personally I would observe a
repositories maintained by Puppet admins, which ensure that all merged
code is working properly. Also merging from each others repositories can
become kinda confusing depending on how many different orgs we will have
in the future.

> There will still be changes that need to be coordinated across
> organizations, particularly when package repository changes take
> place. We'll use this mailing list to coordinate such changes, and
> try to minimize those situations.

Wouldn't it be better to handle real implementations via Bugzilla? I
think that would be helpful to also get proper review. We have a Puppet
component so everyone of us could watch it, and would get all of the
updates.

The mailing list would be perfect for discussions and feature proposals.

Cheers,

--
Henrik Skupin
Software Engineer in Test
Mozilla Corporation

[Dustin J. Mitchell]

----- Original Message -----
> > More surprising: there won't be any "canonical" repository. We'll
> > all merge *from* the other repos as frequently as our change
> > management allows. That allows each organization to decide when to
> > take a particular update or change, and to resolve any conflicts. I
> > plan to check for updates at least weekly, and try to merge whenever
> > I learn about a substantial change in another tree.
>
> So how can we ensure that changes have been proven to work? I don't want
> to merge code which could break us. Personally I would observe a
> repositories maintained by Puppet admins, which ensure that all merged
> code is working properly. Also merging from each others repositories can
> become kinda confusing depending on how many different orgs we will have
> in the future.

Anything committed anywhere should be "working properly", but because the context is so different from org to org, it's difficult to make any guarantees about that without actually testing on every type of machine in every org. Rather than put this burden on each committer or on "Puppet admins" (I'm not sure who those are!), the burden falls to each org to look at incoming changes and make that determination at an appropriate time (e.g., not in the middle of a release process).

We'll see how this unfolds over time. If we end up with too much divergence, too many repos, or confusion over multidirectional merges, we can revisit.

> > There will still be changes that need to be coordinated across
> > organizations, particularly when package repository changes take
> > place. We'll use this mailing list to coordinate such changes, and
> > try to minimize those situations.
>
> Wouldn't it be better to handle real implementations via Bugzilla? I
> think that would be helpful to also get proper review. We have a Puppet
> component so everyone of us could watch it, and would get all of the
> updates.

The implementations will be in Bugzilla. What will be called out here are actions that need coordination, so that they're not lost in Bugzilla. For example, when we upgrade a package in an Ubuntu repo, generally the old version of the package is removed, so any Puppet manifests specifying that old version will fail. An email to the list helps everyone be aware of the timing of such a change to avoid breaking their org. In practice these situations have been rare, but we may find more potential issues now that there are more orgs.

If the warnings turn out to be redundant to Bugzilla communication, I'll be happy not to send them, but I'd like to err on the side of reliability for now!

> The mailing list would be perfect for discussions and feature proposals.

Indeed, that too!

Dustin

[Henrik Skupin]

Makes all sense. Lets see how it works. I'm looking forward!