Translation commits pushed when rolling a tarball
Hi, At some rare occasions, especially after the string freeze, translation commits are pushed when rolling a tarball for making a new release. Since the commit for the release should be pushed only when 'make distcheck' has succeeded, there can be a push conflict and the maintainer have to repeat the process (sometimes several times). I think it would be nice to send mails on gnome-i18n and gnome-doc-list to explain that commits should not be pushed during the release days. If a translation or documentation commit is important, the maintainers can anyway be contacted on IRC to know if the commit can be pushed. I think there is no equivalent of 'svn lock' for git, so sending a mail is a solution. Bonus point is to add a warning on l10n.gnome.org, but it is more work. What do you think? Is it too rare to care about this problem? Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Thu, Jul 31, 2014 at 5:24 PM, Sébastien Wilmet wrote: > Hi, Hi, > At some rare occasions, especially after the string freeze, translation > commits are pushed when rolling a tarball for making a new release. > Since the commit for the release should be pushed only when 'make > distcheck' has succeeded, there can be a push conflict and the > maintainer have to repeat the process (sometimes several times). > > I think it would be nice to send mails on gnome-i18n and gnome-doc-list > to explain that commits should not be pushed during the release days. If > a translation or documentation commit is important, the maintainers can > anyway be contacted on IRC to know if the commit can be pushed. > > I think there is no equivalent of 'svn lock' for git, so sending a mail > is a solution. > > Bonus point is to add a warning on l10n.gnome.org, but it is more work. > > What do you think? +1. > Is it too rare to care about this problem? I don't think so but being a maintainer for years, you'll learn to do `git push origin master` first always. :) -- Regards, Zeeshan Ali (Khattak) Befriend GNOME: http://www.gnome.org/friends/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Thu, Jul 31, 2014 at 05:24:55PM +0200, Sébastien Wilmet wrote: > I think there is no equivalent of 'svn lock' for git, so sending a mail > is a solution. I think we could add something as equivalent to svn lock. It takes a bit of time to setup though, and damned lies (l10n.gnome.org) would have to be able to handle errors from git.gnome.org. If enough devs speak up I could maybe make something to lock a repository against pushes. Maybe with a timeout, maybe not. With SVN anyone could force a lock to be removed. Not sure of what is best. I assume a lock should at most be held for 2 hours. I'd appreciate a bit of insight from some tarball creators aka maintainers :-P -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On 08/01/2014 05:22 PM, Olav Vitters wrote: > I'd appreciate a bit of insight from some tarball creators aka > maintainers :-P I personally don't mind at all if someone pushes translation fixes while I'm rolling a tarball. It's not really much of a problem for me to run 'make distcheck' once more to pick up additional translation goodness. -- Kalev ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Fri, 2014-08-01 at 18:40 +0200, Kalev Lember wrote: > It's not really much of a problem for me to run > 'make distcheck' once more to pick up additional translation goodness. For stable releases taking the latest translations is important, but for unstable releases it's not a big deal if the translation is for the next beta. Making releases is not the funniest part of a maintainer work, even if push conflicts are rare (at least for me), the fact that I know it can happen doesn't put me in a comfortable position when rolling a tarball (it's more on the psychological side). Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Fri, 2014-08-01 at 11:31 +0200, Zeeshan Ali (Khattak) wrote: > I don't think so but being a maintainer for years, you'll learn to do > `git push origin master` first always. :) 'make distcheck' sometimes fails, for example a file which is not distributed in tarballs. Maybe GNOME Continuous could run 'make distcheck' on (almost) every commit? To detect such errors earlier than the release day. Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On 01/08/2014, Zeeshan Ali (Khattak) wrote: > On Thu, Jul 31, 2014 at 5:24 PM, Sébastien Wilmet wrote: >> Hi, > > Hi, > >> At some rare occasions, especially after the string freeze, translation >> commits are pushed when rolling a tarball for making a new release. >> Since the commit for the release should be pushed only when 'make >> distcheck' has succeeded, there can be a push conflict and the >> maintainer have to repeat the process (sometimes several times). >> >> I think it would be nice to send mails on gnome-i18n and gnome-doc-list >> to explain that commits should not be pushed during the release days. If >> a translation or documentation commit is important, the maintainers can >> anyway be contacted on IRC to know if the commit can be pushed. >> >> I think there is no equivalent of 'svn lock' for git, so sending a mail >> is a solution. >> >> Bonus point is to add a warning on l10n.gnome.org, but it is more work. >> >> What do you think? > > +1. > >> Is it too rare to care about this problem? > > I don't think so but being a maintainer for years, you'll learn to do > `git push origin master` first always. :) As someone who makes releases, I always prefer to have the latest translation in the release, but I understand that running a distcheck on some of the larger projects can take a long time. From a documentation point of view, it doesn't make sense to block pushes for a whole day, especially as some maintainers release very late. Have you considered dropping an email to gnome-doc-l...@gnome.org and gnome-i...@gnome.org lists before running the distcheck? I found communicating with translators to be very effective and the docs team would prefer communication over a ban. > -- > Regards, > > Zeeshan Ali (Khattak) > > Befriend GNOME: http://www.gnome.org/friends/ > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, Aug 2, 2014 at 9:37 AM, Ekaterina Gerasimova wrote: > On 01/08/2014, Zeeshan Ali (Khattak) wrote: >> On Thu, Jul 31, 2014 at 5:24 PM, Sébastien Wilmet wrote: >>> Hi, >> >> Hi, >> >>> At some rare occasions, especially after the string freeze, translation >>> commits are pushed when rolling a tarball for making a new release. >>> Since the commit for the release should be pushed only when 'make >>> distcheck' has succeeded, there can be a push conflict and the >>> maintainer have to repeat the process (sometimes several times). >>> >>> I think it would be nice to send mails on gnome-i18n and gnome-doc-list >>> to explain that commits should not be pushed during the release days. If >>> a translation or documentation commit is important, the maintainers can >>> anyway be contacted on IRC to know if the commit can be pushed. >>> >>> I think there is no equivalent of 'svn lock' for git, so sending a mail >>> is a solution. >>> >>> Bonus point is to add a warning on l10n.gnome.org, but it is more work. >>> >>> What do you think? >> >> +1. >> >>> Is it too rare to care about this problem? >> >> I don't think so but being a maintainer for years, you'll learn to do >> `git push origin master` first always. :) > > As someone who makes releases, I always prefer to have the latest > translation in the release, but I understand that running a distcheck > on some of the larger projects can take a long time. > > From a documentation point of view, it doesn't make sense to block > pushes for a whole day, especially as some maintainers release very > late. Have you considered dropping an email to > gnome-doc-l...@gnome.org and gnome-i...@gnome.org lists before running > the distcheck? I found communicating with translators to be very > effective and the docs team would prefer communication over a ban. You mean send them email to not push translations? Are they all on those lists and read their inbox each time before pushing changes? If so, sure but then again the main issue (at least for me) is forgetting (to run `git push master` rather than `git push master RELEASE`) so I don't know what adding an additional manual step to remember would achieve. -- Regards, Zeeshan Ali (Khattak) Befriend GNOME: http://www.gnome.org/friends/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, 2014-08-02 at 09:37 +0200, Ekaterina Gerasimova wrote: > Have you considered dropping an email to > gnome-doc-l...@gnome.org and gnome-i...@gnome.org lists before running > the distcheck? I found communicating with translators to be very > effective and the docs team would prefer communication over a ban. With an equivalent of 'svn lock', there can be a friendly message explaining that a developer is creating a release, and that the commit can be pushed later (e.g. the following day). It is anyway temporary. I wouldn't use the word "ban", I prefer the word "temporary lock", it is less negative. Docs and translations commits are more than welcome, you do a great job! It is just that the push conflicts can be a little annoying. But if each maintainer sends a mail to announce the distcheck to the translation and doc teams, you'll receive hundreds mails, it doesn't scale. Another mail should also be sent when the distcheck is finished. Sending such mails is not convenient for the maintainer, and it assumes that those mails are read as soon as they are sent. Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On 2014-08-01 23:40, Sébastien Wilmet wrote: On Fri, 2014-08-01 at 18:40 +0200, Kalev Lember wrote: It's not really much of a problem for me to run 'make distcheck' once more to pick up additional translation goodness. For stable releases taking the latest translations is important, but for unstable releases it's not a big deal if the translation is for the next beta. Making releases is not the funniest part of a maintainer work, even if push conflicts are rare (at least for me), the fact that I know it can happen doesn't put me in a comfortable position when rolling a tarball (it's more on the psychological side). It is not a problem for me, neither a psychological or an actual one (I cannot remember a time when a translation commit has been pushed while I ran distcheck, but conceivably it could have happened), so I would rather keep the behaviour simple, as it is now. -- http://amigadave.com/ signature.asc Description: Digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Fri, 2014-08-01 at 17:22 +0200, Olav Vitters wrote: > I think we could add something as equivalent to svn lock. It takes a bit > of time to setup though, and damned lies (l10n.gnome.org) would have to > be able to handle errors from git.gnome.org. > > If enough devs speak up I could maybe make something to lock a > repository against pushes. Maybe with a timeout, maybe not. With SVN > anyone could force a lock to be removed. Not sure of what is best. I > assume a lock should at most be held for 2 hours. Would be a nice-to-have thing. I personally have a script for creating the tarball in one command (after creating the commit). It does a git clean, make, make distcheck etc. So the lock/push/unlock can easily be added to such a script, without adding more manual steps. > I'd appreciate a bit of insight from some tarball creators aka > maintainers :-P In gedit it has already happened to have to distcheck 3 times due to 2 translation commits pushed. So this is something that *can* happen. Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, Aug 2, 2014 at 2:24 PM, Sébastien Wilmet wrote: > On Sat, 2014-08-02 at 09:37 +0200, Ekaterina Gerasimova wrote: >> Have you considered dropping an email to >> gnome-doc-l...@gnome.org and gnome-i...@gnome.org lists before running >> the distcheck? I found communicating with translators to be very >> effective and the docs team would prefer communication over a ban. > > With an equivalent of 'svn lock', there can be a friendly message > explaining that a developer is creating a release, and that the commit > can be pushed later (e.g. the following day). It is anyway temporary. I > wouldn't use the word "ban", I prefer the word "temporary lock", it is > less negative. Docs and translations commits are more than welcome, you > do a great job! It is just that the push conflicts can be a little > annoying. Well you could just create a branch do your release there so that you don't have to care about what happens on master (branches are free in git) and merge it back to master afterwards. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, 2014-08-02 at 15:21 +0200, drago01 wrote: > Well you could just create a branch do your release there so that you > don't have to care about what happens on master (branches are free in > git) and merge it back to master afterwards. In GNOME we generally prefer to have a linear git history, but creating a branch is indeed another solution. Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Fri, Aug 1, 2014, at 07:18 PM, Sébastien Wilmet wrote: > Maybe GNOME Continuous could run 'make distcheck' on (almost) every > commit? To detect such errors earlier than the release day. No. I think tarballs are a waste of CPU power and human time generated solely because many popular downstream build systems predate widespread use of revision control and haven't made the leap to understanding git. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, 2014-08-02 at 14:14 +0200, Zeeshan Ali (Khattak) wrote: > You mean send them email to not push translations? Are they all on > those lists and read their inbox each time before pushing changes? If > so, sure but then again the main issue (at least for me) is forgetting > (to run `git push master` rather than `git push master RELEASE`) so I > don't know what adding an additional manual step to remember would > achieve. I like 'git push --follow-tags' If you have to 'git pull --rebase' due to a translation commit after running distcheck and tagging the commit, you can still do this: it's a bit questionable since the tag and release won't be on any branch, so I normally rerun distcheck, but it works. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, 2014-08-02 at 15:55 +0200, Sébastien Wilmet wrote: > On Sat, 2014-08-02 at 15:21 +0200, drago01 wrote: > > Well you could just create a branch do your release there so that you > > don't have to care about what happens on master (branches are free in > > git) and merge it back to master afterwards. > > In GNOME we generally prefer to have a linear git history, but creating > a branch is indeed another solution. (replying to myself after a bit more thoughts) I think it's the best compromise. I've never thought about this solution because I always do a rebase on top of master. Thanks for the tip! Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, 2014-08-02 at 15:55 +0200, Sébastien Wilmet wrote: > On Sat, 2014-08-02 at 15:21 +0200, drago01 wrote: > > Well you could just create a branch do your release there so that you > > don't have to care about what happens on master (branches are free in > > git) and merge it back to master afterwards. You shouldn't need to create a branch for this. What we're talking about here is an utterly normal and everyday part of the git workflow — not specific to releases and translations. Any time you've done some work locally and it's time to push it upstream, you may find that someone else has pushed something before you. The correct thing to do when that happens is to pull, resulting in a merge commit in your tree, and then push that upstream. There's nothing to see here; this whole thread doesn't exist. There is no problem. > In GNOME we generally prefer to have a linear git history, but creating > a branch is indeed another solution. Right. You have correctly identified the root cause of the problem. We shouldn't be advising people as a matter of course *not* to use the version control system correctly in the manner in which it was designed. This mentality of rebasing for no better reason than because we like straight lines isn't just an issue in the specific case discussed here. It also causes the loss of accurate history in other cases, which can cause problems. It's relatively rare, but it does happen that two concurrent patches can conflict with each other. I could do some work in my local tree which is entirely correct and functional, but by the time I've finished testing and I go to push it upstream, someone else has pushed something which subtly breaks my work. If I rebase, it is just human nature that I'm not going to retest every intermediate commit of the rebased version as carefully as I retested the original, and it's quite possible that I'll end up pushing a commit which in some circumstances *never* worked. If I use git correctly and push the *merge*, however, then my original work is preserved. Someone later trying to work out what happened has actually got a correct version of history to refer back to, and the problem can be correctly tracked down to the *merge* of the concurrent changes. Whereas if I rebase and rewrite history to make it look like I just committed something that *never* worked, sorting that out later is *much* harder. We really ought to abandon this idea that we "prefer to have a linear git history". It might be simpler that way, but it's wrong, and in the cases that *matter* it actually makes things harder. And the cases that don't matter... don't matter. Unless you have some kind of OCD about straight lines. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, 2014-08-02 at 15:38 +0100, David Woodhouse wrote: > The correct thing to do when that happens is to pull, resulting in a > merge commit in your tree, and then push that upstream. Merge conflicts are probably less likely to happen in GNOME thanks to the longer development cycle. In contrast with a merge window of two weeks in Linux. So a normal merge should probably be done only when a merge conflict happens. In the other cases a rebase is better in my opinion (if we trust Git). But you're absolutely right, we're doing it wrong™. As a side note, a merge window has an advantage: it normally prevents half-finished features to be sneaked in at the last minute, with the hope that all the bugs will be identified and fixed during the feature freeze. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, Aug 2, 2014 at 4:09 PM, Sébastien Wilmet wrote: > On Sat, 2014-08-02 at 15:55 +0200, Sébastien Wilmet wrote: >> On Sat, 2014-08-02 at 15:21 +0200, drago01 wrote: >> > Well you could just create a branch do your release there so that you >> > don't have to care about what happens on master (branches are free in >> > git) and merge it back to master afterwards. >> >> In GNOME we generally prefer to have a linear git history, but creating >> a branch is indeed another solution. > > (replying to myself after a bit more thoughts) > > I think it's the best compromise. I've never thought about this solution > because I always do a rebase on top of master. Thanks for the tip! Actually thats what I usually do but trouble with this approach is that I often then forget that I'm on the branch and assume everything went fine after doing a successfull `git push origin master && git push origin TAG`. Later I realize that master has changed and my tag is not in its history. :( -- Regards, Zeeshan Ali (Khattak) Befriend GNOME: http://www.gnome.org/friends/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On 08/02/2014 10:38 AM, David Woodhouse wrote: > If I use git correctly and push the *merge*, however, then my original > work is preserved. Someone later trying to work out what happened has > actually got a correct version of history to refer back to, and the > problem can be correctly tracked down to the *merge* of the concurrent > changes. Except that this correct version of history looks like this: - Implement X - Implement Y - Implement Z - Make a whole bunch of changes all at once, some of which are related to X, some to Y, some to Z, and some to more than one of them, and without any indication of which changes relate to which commit so no one in the future will ever be able to figure it out ha ha ha. Which sucks. So I'll stick with rebasing, thanks. -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
> On 08/02/2014 10:38 AM, David Woodhouse wrote: >> If I use git correctly and push the *merge*, however, then my original >> work is preserved. Someone later trying to work out what happened has >> actually got a correct version of history to refer back to, and the >> problem can be correctly tracked down to the *merge* of the concurrent >> changes. > > Except that this correct version of history looks like this: > > - Implement X > > - Implement Y > > - Implement Z > > - Make a whole bunch of changes all at once, some of which are > related to X, some to Y, some to Z, and some to more than one of > them, and without any indication of which changes relate to which > commit so no one in the future will ever be able to figure it out > ha ha ha. > > Which sucks. So I'll stick with rebasing, thanks. That is so far from the normal experience of using git as intended, that I don't quite recognise it. It sounds like you've had a bad experience of someone doing something truly bizarre and ill-advised, and it's put you off doing things *correctly* for ever more. Much like the libxml2 insanity with quantum symbol versioning seems to have put people off using *that* properly. Or indeed at all. But I wasn't necessarily expecting the "don't use git properly" policy to be changed - it's just that nobody seemed to be acknowledging the elephant in the room in this thread, which was that the whole problem being discussed is an artificial one purely caused by that policy. So I felt it appropriate to make sure it was mentioned. -- dwmw2 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sun, 2014-08-03 at 19:38 +, David Woodhouse wrote: > > > > On 08/02/2014 10:38 AM, David Woodhouse wrote: > > > If I use git correctly and push the *merge*, however, then my > > > original > > > work is preserved. Someone later trying to work out what > > > happened has > > > actually got a correct version of history to refer back to, and > > > the > > > problem can be correctly tracked down to the *merge* of the > > > concurrent > > > changes.> > > > > Except that this correct version of history looks like this: > > > > >- Implement X > > > > >- Implement Y > > > > >- Implement Z > > > > >- Make a whole bunch of changes all at once, some of which are > > related to X, some to Y, some to Z, and some to more than one > > of > > them, and without any indication of which changes relate to > > which > > commit so no one in the future will ever be able to figure it > > out > > ha ha ha. > > > > > Which sucks. So I'll stick with rebasing, thanks.> > That is so far from the normal experience of using git as intended, > that I > don't quite recognise it. It sounds like you've had a bad experience > of > someone doing something truly bizarre and ill-advised, and it's put > you > off doing things *correctly* for ever more. > > Much like the libxml2 insanity with quantum symbol versioning seems > to > have put people off using *that* properly. Or indeed at all. > > But I wasn't necessarily expecting the "don't use git properly" > policy to > be changed - it's just that nobody seemed to be acknowledging the > elephant > in the room in this thread, which was that the whole problem being > discussed is an artificial one purely caused by that policy. So I > felt it > appropriate to make sure it was mentioned. > > I don't think the 'using git as intended' is a clear-cut thing. I guess it's reasonable to assume git was intended for Linux kernel development workflow where the linux-next is managed by Linus, who pulls the commits from lieutenants who pull the data from branches. Even in such situations IIRC the people are adviced to just rebase on feature branches to avoid the myriad of merge commits. Maintaining of Linux kernel is a bit more complicated then Gnome modules - I'd imagine that we would have corresponding situation when we would have a whole Gnome in single git repository and gtk+ development would happen in separate branch while i18n could have a separate branch. When the release of new Gnome would come a release team would pull the changes in and make a release. This is not a way which makes sense for Gnome though it makes sense for Linux as we can and are more modular. My guess would be to do it in 'Linux' way and avoid multiply merge commits would be to push the i18n to separate branch and make the maintainer, though I would imagine to be much more complicated for our purposes. -- After some digging about usage of git in Linx: LWN article http://lwn.net/Articles/328436/ - "Linus does not tell developers not to use it [rebasing]; in fact, he encourages it sometimes.", "On the other hand, private history can be rebased at will - and it probably should be.". Original Linus post http://lwn.net/Articles/328438/ - "So you can go wild on the "git rebase" thing on it", "Keep your own history readable" Best regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sun, 2014-08-03 at 23:18 +0200, Maciej Piechotka wrote: > My guess would be to do it in 'Linux' way and avoid multiply merge > commits would be to push the i18n to separate branch and make the > maintainer, though I would imagine to be much more complicated for our > purposes. Linux is probably not the best comparison because Linux has a single person who is able to push to the master upstream tree. There is *no* way to get your code into that except for Linus to pull it. So you have to have a labelled tree or branch somewhere that he can reference by its URI. But there are plenty of other things which *do* have multiple committers all actively pushing to the same tree. There's no need for separate branches other than "the tip of my working tree". It really is just "oh, someone else pushed something while I was working. I'll pull that, handle any merge that's required if it isn't entirely automatic, retest as necessary and push again". > -- > > After some digging about usage of git in Linx: > LWN article http://lwn.net/Articles/328436/ - "Linus does not tell > developers not to use it [rebasing]; in fact, he encourages it > sometimes.", "On the other hand, private history can be rebased at > will - and it probably should be.". > Original Linus post http://lwn.net/Articles/328438/ - "So you can go > wild on the "git rebase" thing on it", "Keep your own history readable" Note that I'm not saying rebasing should be *banned* either. It's a useful tool and I do it all the time. But we shouldn't *force* people to rebase, especially not with commit hooks which block merge commits. If we didn't do that then the whole problem being discussed in this thread wouldn't exist. You could still have a policy of "rebase whenever you can because..." er, well I don't actually know why, but whatever. As long as you allow normal git usage in the cases such as $SUBJECT where enforced-rebase is causing a real problem. So just dropping the commit-hook, and keeping the same policy but just applying it a little more flexibly, should be ideal. Or perhaps if people really insist, you could even keep the commit-hook but make a special case in it to permit merge commits where one side of the tree only touches the po/ directory. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, 2014-08-02 at 16:09 +0200, Sébastien Wilmet wrote: > On Sat, 2014-08-02 at 15:55 +0200, Sébastien Wilmet wrote: > > On Sat, 2014-08-02 at 15:21 +0200, drago01 wrote: > > > Well you could just create a branch do your release there so that you > > > don't have to care about what happens on master (branches are free in > > > git) and merge it back to master afterwards. > > > > In GNOME we generally prefer to have a linear git history, but creating > > a branch is indeed another solution. > > (replying to myself after a bit more thoughts) > > I think it's the best compromise. I've never thought about this solution > because I always do a rebase on top of master. Thanks for the tip! Not seeing releases on the master commit list is going to confuse more than a few drive-by developers, bug squaders, and translators. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Thu, 2014-07-31 at 17:24 +0200, Sébastien Wilmet wrote: > Hi, > > At some rare occasions, especially after the string freeze, translation > commits are pushed when rolling a tarball for making a new release. > Since the commit for the release should be pushed only when 'make > distcheck' has succeeded, there can be a push conflict and the > maintainer have to repeat the process (sometimes several times). > > I think it would be nice to send mails on gnome-i18n and gnome-doc-list > to explain that commits should not be pushed during the release days. If > a translation or documentation commit is important, the maintainers can > anyway be contacted on IRC to know if the commit can be pushed. > > I think there is no equivalent of 'svn lock' for git, so sending a mail > is a solution. > > Bonus point is to add a warning on l10n.gnome.org, but it is more work. > > What do you think? Is it too rare to care about this problem? It's happened quite a few times for my modules, whether it was due to translations being pushed between the tarball release, and me trying to push, or me simply forgetting to update the tree before doing the release. My workflow looks something like: - bump versions, update NEWS and commit this - run make distcheck, and if it doesn't pass, create one or more new commits to fix the problem, then running "git rebase -i" to put those before my version bump commit - distcheck passes, try to push - If the push succeeds, it doesn't matter if other commits come afterwards, as you can tag, branch, etc. based on that commit, not always the latest one as SVN used to handle - If the push doesn't succeed, run "git pull -r", run "make distcheck" and push. If you're particularly cocky, you can run "make dist" and push, but a broken .po file could get in your way ;) Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Mon, 2014-08-04 at 12:49 +0200, Bastien Nocera wrote: > Not seeing releases on the master commit list is going to confuse more > than a few drive-by developers, bug squaders, and translators. It depends on what tools to use to view the commit list. With a merge commit, the release commit and tag are also part of the master branch, it is just not a straight line. Compared to implementing an equivalent of 'svn lock' for git, a merge commit is a far more easier solution. The fact that 'git lock' doesn't exist is maybe because the branch system is powerful enough. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Mon, 2014-08-04 at 14:25 +0200, Sébastien Wilmet wrote: > On Mon, 2014-08-04 at 12:49 +0200, Bastien Nocera wrote: > > Not seeing releases on the master commit list is going to confuse more > > than a few drive-by developers, bug squaders, and translators. > > It depends on what tools to use to view the commit list. Btw, which tools do you have in mind that don't display diverging commits? Such tool should be fixed or avoided, because it gives a false view on which commits are present on a branch. git log correctly displays all commits, for example. The well-known git lola alias too, even if you remove the --all parameter. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On 08/03/2014 03:38 PM, David Woodhouse wrote: >> - Make a whole bunch of changes all at once, some of which are >> related to X, some to Y, some to Z, and some to more than one of >> them, and without any indication of which changes relate to which >> commit so no one in the future will ever be able to figure it out >> ha ha ha. >> >> Which sucks. So I'll stick with rebasing, thanks. > > That is so far from the normal experience of using git as intended, that I > don't quite recognise it. How else is a merge commit going to look? If you have more than one commit on your branch, and more than one conflict with master, and you only get one commit to fix it all up, then how can you avoid having that one commit include fixes that are unrelated to one another? (Sure, if you don't have any conflicts, then the merge commit will be empty and confusion-free, but in that case you could have rebased without conflicts too, so the argument about accidentally creating bugs while rebasing doesn't apply.) -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Mon, 2014-08-04 at 09:38 -0400, Dan Winship wrote: > On 08/03/2014 03:38 PM, David Woodhouse wrote: > >> - Make a whole bunch of changes all at once, some of which are > >> related to X, some to Y, some to Z, and some to more than one of > >> them, and without any indication of which changes relate to which > >> commit so no one in the future will ever be able to figure it out > >> ha ha ha. > >> > >> Which sucks. So I'll stick with rebasing, thanks. > > > > That is so far from the normal experience of using git as intended, that I > > don't quite recognise it. > > How else is a merge commit going to look? If you have more than one > commit on your branch, and more than one conflict with master, and you > only get one commit to fix it all up, then how can you avoid having that > one commit include fixes that are unrelated to one another? > > (Sure, if you don't have any conflicts, then the merge commit will be > empty and confusion-free, but in that case you could have rebased > without conflicts too, so the argument about accidentally creating bugs > while rebasing doesn't apply.) There are multiple options here. First of all, you *can* rebase if you want to. I don't think anybody objects to that; only to the *forced* rebasing. But let's say you don't want to rebase, because you really do want to preserve the original context and the validity of the original testing — perhaps other people had tested it for you in esoteric environments. If upstream has done X, Y and Z since you started your work and *all* of them interact non-trivially with what you've done, then rather than pulling today's upstream in one go, you could first pull it as of commit X, resolve conflicts and retest, then pull Y, repeat, and finally do the same for Z. Of course, if X, Y and Z are all inter-related then that might actually be a bit more work than doing it in one go — so you might *not* want to do that. But it's *one* of the options. I'm not trying to take away your options, of which rebasing is sometimes a perfectly valid one. I'm pointing out that this thread only exists because one of the useful options (i.e. *not* rebasing) *has* been taken away. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Mon, 2014-08-04 at 15:31 +0100, David Woodhouse wrote: > I'm not trying to take away your options, of which rebasing is sometimes > a perfectly valid one. I'm pointing out that this thread only exists > because one of the useful options (i.e. *not* rebasing) *has* been taken > away. Yes, thank you for your explanations, as Git is really flexible, it's great to have insight from other free software projects working differently. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
