Hi,
Mozilla's Manifest principle #8 states:
8.Transparent community-based processes promote participation,
accountability and trust.
Decision making, afaik, is a process.
So...
Taras Glek wrote:
*User Repos*
TLDR: I would like to make user repos read-only by April 30th. We should
archive them by May 31st.
Time spent operating user repositories could be spent reducing our
end-to-end continuous integration cycles. These do not seem like
mission-critical repos, seems like developers would be better off
hosting these on bitbucket or github. Using a 3rd-party host has obvious
benefits for collaboration & self-service that our existing system will
never meet.
I'd like to question the above. "I would like to make user repos ..."
Was this decision arrived by yourself, or through a transparent
process with your releng team? And if it was transparent,
where was it discussed? Would I be privy to these discussions?
Or is this decision similar to the DT issue?
So, in the name of transparency, how exactly did you come about in
deciding this?
Reading your message, I understood the possible issues(read: Why?):
1) Resource: Time
2) Resource: Disk space
3) Resource: maintenance
Is the machine/vm/whatever that holds the user repos and/or
non-user repos anyway tied to the CI systems? i.e Does the
CI system also contain the user/non-user repos?
Also, are you sure that these are not 'mission-critical'
repos (user-repos and non-user repos)? The word 'seems'
imply you're not sure.
Don't get me wrong. You have every right to make these
decisions. I know (with 100% certainty) that
this decision affects a few community projects.
I'm not saying it isn't technically 'feasible' to move repos away
from Mozilla's systems. It is technically do-able. Feasibility
is project-dependent. What I'm not 100% certain is whether it is the
'right' thing to do.
Once you have migrated your repository, please comment in
https://bugzilla.mozilla.org/show_bug.cgi?id=988628so we can free some
disk space.
This covers #2 in the list. Disk space. From your post to gps, I
quote:
"The fact that repos keep growing means that we'll have to do this
migration again soon. We are at 260gb/300gb."
I can see why this might lead you to make your decision; but is
this the only alternative? I mean 300GB? How much is 1TB in
the US? AIUI, having user and non-user repos don't take that
much processing power and the minimum HD size you can get
now-a-days is 500GB. Why not migrate it to a 1TB drive?
How long would that last? How long did 300GB last?
*Non-User Repos*
There are too many non-user repos. I'm not convinced we should host
ash, oak, other project branches internally. I think we should focus on
mission-critical repos only. There should be less than a dozen of those.
I would like to stop hosting non-mission-critical repositories by end of
Q2.
How exactly did you come to the conclusion that 'there should be less
than a dozen of those'? I'm really curious. Did you go through each
non-user repos (as you did with the user repos) and decided which ones
fitted to your criteria as 'mission-critical'?
Which are the 'dozen'(or less) repos are you talking about?
This is a soft target. I don't have a concrete plan here. I'd like to
start experimenting with moving project branches elsewhere and see where
that takes us.
Pardon me, but is this the right approach? We're talking about a lot
of project branches here. 'Start experimenting' isn't something that
would go well with already established processes/systems. Moving them
isn't a technical issue.(We've established that it's technically
do-able.) It's a systematic issue. Moving a project, say A, to a
different system (3rd party or otherwise), require some changes to the
underlying systems/processes that require that repo to be where it is.
So those need to be changed. Then the processes/systems are
checked for errors. If it doesn't work, move the project branch
elsewhere. Another set of changes. Do-able? Sure. I'm not
saying it isn't do-able. Is it necessarily the right thing
to do?
*What my hg repo needs X/Y that 3rd-party services do not provide?*
If you have a good reason to use a feature not supported by
github/bitbucket, we should continue hosting your repo at Mozilla.
*Why Not Move Everything to Github/Bitbucket/etc?*
Mozilla prefers to keep repositories public by-default. This does not
fit Github's business model which is built around private repos.
Github's free service does not provide any availability guarantee.
There is also a problem of github not supporting hg.
I'm not completely sure why we can't move everything to bitbucket. Some
of it is to do with anecdotal evidence of robustness problems. Some of
it is lack of hooks (sans post-receive POSTs).Additionally, as with
Github there is no availability guarantee.
Umm. Haven't you already given reasons why moving everything to
bitbucket isn't a good idea? (No availability guaranteed would
be a killer, and private repos only is another.) I'm quite confused
with what you wrote.
Hosting arbitrary Moz-related hg repositories does not make strategic
sense. We should do the absolute minimum(eg http://bke.ro/?p=380)
required to keep Firefox shipping smoothly and focus our efforts on
making Firefox better.
That link, afaiui, states the movement of repos from NFS to local
disk. I'm not sure how that relates to hosting arbitrary
repos. Do you mean that the lesser the # of 'arbitrary' repos,
the better Firefox is cloned/maintained?
What about community projects? What about developer projects?
Those projects exist because they have/had a use. Sure, if they are no
longer used, then by all means remove them. But wouldn't asking
developers about this be appropriate? Your message is a "I would like
this be done by so and so" and not a "Hey guys/gals. I've got
an idea. What's your opinion if we did this?..."
And 1 month? Is there something particularly urgent that
requires (if this is even the right word to use) the paring
down of project branches/user-repos?
Also, what is this 'strategic sense'? Possibly an explanation
required. Yes, I do understand strategies evolve and change.
In the past, these project repos were created. (paraphrase)
"But now it's not strategically sensible in keeping them.
(I'm hoping I'm not warping your words. I really would appreciate
clarifications.) Is this right? Why does it not make strategic sense
now? What has changed? (Grant you, things certainly have gotten more
complicated, wrt Firefox.)
ps. Footprint stats:
So?
Footprint stats only says how large the repo is. It doesn't
say what it is used for (mission critical or otherwise).
So 'size' isn't a good indicator of 'mission-criticality'
unless it's related to how much space is taken away
from mission-critical functions. If you've already
stated the relationship between the paring of repos
and Firefox's release efficiency/effectiveness,
I do apologize. I just haven't quite grasped
your rationale yet.
*Space Usage by Non-user repos ~100GB*
Seriously? 100GB? So a total of 230GB. Will paring down
this will make Firefox release run smoothly? If so, how?
Firefox depends on mozilla-central, mozilla-integration,
mozilla-aurora, mozilla-beta, and the l10n trees. How,
will (i.e.) the removal of projects/holly help Firefox?
How will the removal of projects/ash help Firefox?
Please take no offense to my questioning. It's
not the issue of questioning your authority. It's
just that I'm trying to understand the rationale
for such a change.
I realize it isn't something to be taken lightly,
and definitely not something to be done in
so short a time, unless of course the understanding
of the whole process and the plethora of changes
required can be understood within a few weeks
and done within another few weeks. I don't know.
Kinda stretching it, especially with the work
load releng has.
I've asked some questions that might help you
(or not) to understand the depth and 'far-reaching
consequences' of such changes. Am I making a
mountain out of a mole hill? I don't know. My
perspective is still close to the ground level.
Your perspective is higher up, so there's possibly
something you see that I don't.
At the end of the day, it is still your decision.
Cheers,
Edmund
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
