Confirmed users
329
edits
Multiple Project Repositories: Difference between revisions
Jump to navigation
Jump to search
Multiple Project Repositories (view source)
Revision as of 01:32, 21 December 2010
, 21 December 2010no edit summary
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
There have been various grumblings for a while that we ought to be using more project repositories, following the model of the TraceMonkey branch. The recent "Post-FF4 Branch organization" megathread and the faster release cycle discussion have brought the idea into the light. This page is for exploration of the idea in a more persistent format (it's gotten hard to keep track of everything covered in the thread.) | |||
Note that multiple project repos are not necessarily connected to a faster release cycle, but they could be part of the overall release cycle change plan. | |||
== Main Advantages/Disadvantages == | == Main Advantages/Disadvantages == | ||
* When bustage is committed, fewer people are affected | |||
* More experimental changes can be made and the problems shaken out because of the smaller sandbox | |||
* Easing of the patch bottleneck when the tree gets busy (you just need to space pushes with respect to others in the same tree, not with everyone who might commit anything anywhere) | |||
* Commit policy can be more closely matched to the needs of a restricted area (eg churn from small changes is less harmful and so more acceptable => more conducive to refactoring) (Note that I would ''not'' expect review policies to differ between repos) | |||
* More merges are required, and more "clumps" of changes move around the system | |||
* Less clarity on where individual changes should go, especially for less active (new, occasional) contributors | |||
* More overhead for release engineering, QA | |||
* Better correspondence between repos and IRC channels | |||
== Issues == | == Issues == | ||
A number of issues came up during the mailing list thread. The ones I can recall are captured here and (one) response given. Please add more, and add/improve the responses. You can try to initiate discussions here, or (probably better) post to the mailing list for discussion and document the result here. | |||
=== Contributors will need to maintain too many repositories === | === Contributors will need to maintain too many repositories === | ||
| Line 51: | Line 64: | ||
Theoretically, the splitup ought to be a good thing, since we'd have some extra bits of evidence about where random oranges come from. If an orange is truly intermittent, but only shows up on one project tree until it merges into m-c, that's useful information. | Theoretically, the splitup ought to be a good thing, since we'd have some extra bits of evidence about where random oranges come from. If an orange is truly intermittent, but only shows up on one project tree until it merges into m-c, that's useful information. | ||
(An an aside, I should point out it's really not philor's personal responsibility to star everyone's oranges. He's providing an incredibly valuable service for us all. Is it because he has a generous heart, or | (An an aside, I should point out it's really not philor's personal responsibility to star everyone's oranges. He's providing an incredibly valuable service for us all. Is it because he has a generous heart, or because he's batshit insane? Or both?) | ||
=== Too hard to watch changes === | === Too hard to watch changes === | ||
| Line 57: | Line 70: | ||
Summary: Right now you can watch the mozilla-central pushlog. With project repos, you'd need to either watch them all, or get giant clumps of changes when they hit mozilla-central. | Summary: Right now you can watch the mozilla-central pushlog. With project repos, you'd need to either watch them all, or get giant clumps of changes when they hit mozilla-central. | ||
Create a unified pushlog view. Done. You even get added functionality by being able to filter by repo. | Create a unified pushlog view. Done. You even get added functionality by being able to filter by repo. Seems overall good? | ||
=== Contributor Confusion === | === Contributor Confusion === | ||
Summary: A prospective contributor won't know where to make changes | Summary: A prospective contributor won't know where to make changes | ||
This is a real problem I don't have a quick answer to. I think there's probably a flip side, though -- if the contributor ''does'' find the repo or IRC channel corresponding to the area being modified, they'll be able to work in a smaller, less overwhelming environment. The rules and procedures for contributing are pretty complex, and right now you have to either not care, or spend a lot of time in advance figuring out exactly what you're supposed to do. If you know you're only going to affect the dozen or so people active in a particular area, it's a lot less intimidating to get involved. But I still haven't addressed the original issue. | |||