+++ This bug was initially created as a clone of Bug #603981 +++ 2 changes required to our feed reader options: * Re-add Bloglines - see Bug 609824. * Remove goo RSS Reader - the service will be discontinued on May 31. http://blog.goo.ne.jp/goorssreader/e/be9171be872a15289919c1e3186053b0

Would you please attach a patch here and ask Pike(l10n@mozilla.com) for a review? Thanks.

mar-san: can you take this one?

We should do same as en-US for this change. So we should do: for 1.9.1/1.9.2: remove goo and re-add bloglines for 2.0 or later: remove goo

[ja] re-add Bloglines and remove goo RSS reader.

[ja-JP-mac] re-add Bloglines and remove goo RSS reader. same with [ja].

[ja] just remove goo RSS reader.

[ja-JP-mac] just remove goo RSS reader. same with [ja].

Comment on attachment 530576 [details] [diff] [review] for 1.9.1/1.9.2-ja r=me. With this and the other patches I review in this bug, please land them with a check-in comment referencing this bug, describing the change, and denoting my review. Something like "bug 649888, add bloglines back, remove goo as it's discontinued, r=l10n@mozilla.com", adjust as feasible for the patch.

Comment on attachment 530578 [details] [diff] [review] for 2.0/central ja r=me for landing on central/aurora/beta. Please use the same changeset for aurora and beta, and transplant from central to aurora. That'll make release mechanics much easier.

Comment on attachment 530579 [details] [diff] [review] for 2.0/central ja-JP-mac PS: No need to land on 2.0 anymore, as we don't intend to ship an update from that branch, at least not one with l10n updates.

(In reply to comment #9) > Comment on attachment 530578 [details] [diff] [review] [review] > for 2.0/central ja > > r=me for landing on central/aurora/beta. Please use the same changeset for > aurora and beta, and transplant from central to aurora. That'll make release > mechanics much easier. I have some questions how should we work with repositories. You mean, aurora/beta changesets should be the same, but central/aurora may be different? If so we should do differently for central->aurora (when we import central's update to aurora) and aurora->beta (when we import aurora's update to beta). We should hg transplant from central->aurora like this? // in http://hg.mozilla.org/releases/l10n/mozilla-aurora/ja working dir hg transplant -s http://hg.mozilla.org/l10n-central/ja [revs for aurora, except central only one] What about aurora->beta case? And sorry, we've already commit/push to central/aurora/beta same update separately with different changesets. If they should be the same changeset, what should I do? # though it's not the case now, how should we do when we need update only for beta, not for aurora?

(In reply to comment #10) > Comment on attachment 530579 [details] [diff] [review] [review] > for 2.0/central ja-JP-mac > > PS: No need to land on 2.0 anymore, as we don't intend to ship an update > from that branch, at least not one with l10n updates. Then we'll land on only for 1.9.1/1.9.2 and aurora/beta. As for check-in comment, I miss-included the update of this bug within the recent aurora/beta check-in. I think I should revert changes only for this bug and re-commit with proper comment. But not sure about how should handle changesets for aurora/beta yet (how and which changeset need to be the same). I'll do revert/re-commit with proper comment after that.

At least, 1.9.1, 1.9.2 and central are resolved. 1.9.1: http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/ja/rev/57415b844dd5 http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/ja-JP-mac/rev/c58d6e8a9199 1.9.2: http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/ja/rev/ac954387f8ae http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/ja-JP-mac/rev/e36307e44ed9 central: http://hg.mozilla.org/l10n-central/ja/rev/d1a8ac5749ef http://hg.mozilla.org/l10n-central/ja-JP-mac/rev/35af93290446 For aurora and beta that mentiond at comment 12 are following. aurora: http://hg.mozilla.org/releases/l10n/mozilla-aurora/ja/rev/2696bfa75eb7 http://hg.mozilla.org/releases/l10n/mozilla-aurora/ja-JP-mac/rev/7863648cb35b beta: http://hg.mozilla.org/releases/l10n/mozilla-beta/ja/rev/470e7c593c2e http://hg.mozilla.org/releases/l10n/mozilla-beta/ja-JP-mac/rev/285f15fbfcb1 And, I transplanted them to miramar (These are not needed). miramar: http://hg.mozilla.org/releases/l10n-miramar/ja/rev/4e6be3dd5d38 http://hg.mozilla.org/releases/l10n-miramar/ja-JP-mac/rev/c068da2f2b69

It's unfortunate that we're having the same change with different revisions, it would be easier to follow what landed where if that was one revision as much as possible. Trying to fix that now is just gonna make things worse, though, so let's not do anything on top of what we have. I think this bug can be closed?

Axel, you mean we need not do any more now but we should have the same changeset id for the future releases? If so, how will we have the same changeset again for aurora/beta? I think I should have done this to keep the same changeset for aurora/beta. 1. clone aurora (local-aurora) 2. edit/comit files on local-aurora 3. push from local-aurora to aurora 4. clone beta (local-beta) 5. pull from aurora on local-beta 6. push from local-beta to beta AFAIK pulling from other repository like this is the only way to have the same changeset id. We cannot have the same changeset id if it's parent (and ancestor) changeset is different. If we don't merge aurora/beta now, all the future changesets cannot have the same id aren't they? To have the same changeset for aurora/beta, we can do: 1. clone aurora (local-aurora) 2. pull from beta to local-aurora 3. merge/comit two heads (including same updates) 4. push from local-aurora to aurora 5. push from local-aurora to beta resulting tree will be: https://bitbucket.org/dynamis/aurora-beta/changesets @ changeset: 141:bd7085359c53 |\ tag: tip | | parent: 140:f9c72d7c35d1 | | parent: 137:4aedfe5b0e97 | | | o changeset: 140:f9c72d7c35d1 | | | o changeset: 139:2696bfa75eb7 | | | o changeset: 138:e58e7fa5e762 | | parent: 134:ad4b99c77b59 | | o | changeset: 137:4aedfe5b0e97 | | o | changeset: 136:470e7c593c2e | | o | changeset: 135:cd25f08d7585 |/ If we need have the same changeset id in the future we should do this now? Or is there other way to have same changeset in the future? Or we just need not have the same changeset anymore?

That bitbucket repo looks good, want to go ahead and push that to hg.m.o? Be cautious to not put relbranches all over, though, just push default? Technically, there are three ways to go forward, your merge being one. The other two are 1 and 2 in http://mercurial.selenic.com/wiki/PruningDeadBranches#Closing_branches. We're going to use one of the two in our mass uplifts that we do for aurora to beta and beta to release.

(In reply to comment #16) > That bitbucket repo looks good, want to go ahead and push that to hg.m.o? Pushed and sign-off updated with these same changeset ids: http://hg.mozilla.org/releases/l10n/mozilla-aurora/ja/rev/238d57b85ad5 http://hg.mozilla.org/releases/l10n/mozilla-beta/ja/rev/238d57b85ad5 http://hg.mozilla.org/releases/l10n/mozilla-aurora/ja-JP-mac/rev/d478c1a1bae4 http://hg.mozilla.org/releases/l10n/mozilla-beta/ja-JP-mac/rev/d478c1a1bae4 > Be cautious to not put relbranches all over, though, just push default? ja/ja-JP-mac beta don't have relbranches for fx5 yet and only default can be merged. Even if we have different relbranches, we can use hg transplant to merge only default branch I think. > Technically, there are three ways to go forward, your merge being one. The > other two are 1 and 2 in > http://mercurial.selenic.com/wiki/PruningDeadBranches#Closing_branches. > We're going to use one of the two in our mass uplifts that we do for aurora > to beta and beta to release. I see. We'll just close beta only branch and use new branch from aurora for next beta release in the mass uplifts. I understand how we handle aurora/beta branches now. Thanks Axel and closing this bug.