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
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
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
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
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
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
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
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
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
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
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
On 01/08/2014, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote:
On Thu, Jul 31, 2014 at 5:24 PM, Sébastien Wilmet swil...@gnome.org 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
, 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
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
On 2014-08-01 23:40, Sébastien Wilmet swil...@gnome.org 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
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
On Sat, Aug 2, 2014 at 2:24 PM, Sébastien Wilmet swil...@gnome.org 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
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,
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
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
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
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
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
On Sat, Aug 2, 2014 at 4:09 PM, Sébastien Wilmet swil...@gnome.org 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 Thu, Jul 31, 2014 at 5:24 PM, Sébastien Wilmet swil...@gnome.org 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
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
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
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
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
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
30 matches
Mail list logo
