On 3.8.2014 at 1:33 AM Olav Vitters wrote:
1. New categories: Core, Core Apps, Apps
There is something wrong when pushing:
When I have the line
http://api.gnome.org/doap-extensions#core"; />
in my DOAP file and push, I get the error
remote: ERROR: babl.doap is not valid:
remote:doap:c
Hi,
thank you for your efforts.
I just tried to update some DOAP files (and thought it's a quick job),
but came across some questions:
On 3.8.2014 at 1:33 AM Olav Vitters wrote:
[ Please reply to desktop-devel-list@gnome.org ]
André Klapper suggested we should make more use of the doap file
[ Please reply to desktop-devel-list@gnome.org ]
André Klapper suggested we should make more use of the doap files. As a
result of that together with GUADEC, the following changes have been
made on git.gnome.org:
1. New categories: Core, Core Apps, Apps
Note: Not every module has been put int
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
On Sat, 2014-08-02 at 00:22 +0200, Andre Klapper wrote:
> Please take a quick look at the list below, comment (on the ticket),
> and
> raise your voice if you see an important issue missing.
https://bugzilla.gnome.org/show_bug.cgi?id=728496 is getting really
annoying as well.
signature.asc
Descr
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, 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 aft
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 aft
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 m
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 downstr
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 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
On Thu, 2014-07-31 at 11:21 +0200, Olav Vitters wrote:
> On Wed, Jul 30, 2014 at 05:12:53PM +0200, Olav Vitters wrote:
> > The following git modules have been archived:
[...]
> Anything can be unarchived of course.
In Bugzilla, I've moved all affected products to the "Deprecated"
classification, c
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 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
u
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 communicat
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 rolli
On Sat, Aug 2, 2014 at 12:22 AM, Andre Klapper wrote:
>
>
> == GNOME-CONTROL-CENTER ==
> background: thumbnails are tiny in 3.13.3
> https://bugzilla.gnome.org/show_bug.cgi?id=732375
I'm pretty sure this one was already fixed by Debarshi.
> == GNOME-THEMES-STANDARD ==
> HighContrast: calendar
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 rel
19 matches
Mail list logo
