Re: Announce release of non-official module

[Olav Vitters]

On Sun, Aug 03, 2014 at 04:41:26PM +0200, Juan R. Garcia Blanco wrote:
> So my question is: could I send an announcement to gnome-announce-list
> without submitting a tarball, just tagging the repo?

If you announce a release, distributions will want to download a tarball
from somewhere. So you'd need to put that somewhere. For
gnome-announce-list: doesn't require that the software is on
download.gnome.org.

-- 
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

[Maciej Piechotka]

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

[David Woodhouse]

> 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

[Dan Winship]

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

Announce release of non-official module

[Juan R. Garcia Blanco]

Hi all,

I inherited libchamplainmm some time ago now. libchamplainmm, as you
suppose, are the C++ bindings for libchamplain. I've been working on it
to make it up to date with upstream libchamplain.

I think libchamplainmm is now quite complete. I'd like to make a
development/unstable release; i.e. create a tag and announce it. I don't
even want to push a tarball to gnome's ftp. But I would like to send an
'official' announcement to gnome-announce-list mainly to advertise the
project; probably not many people knows that C++ bindings exist.

So my question is: could I send an announcement to gnome-announce-list
without submitting a tarball, just tagging the repo?

Thank you very much.

Best regards,
Juan.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Screenshot automation BoF at GUADEC

[Alexandre Franke]

On Fri, Aug 1, 2014 at 10:10 PM, scl  wrote:
> Hi,

Hi,

> I develop, document and translate in GIMP and like to know more
> about this topic. Can you already tell me about results of your
> BoF session at GUADEC, please?

We took notes, they are at:

https://wiki.gnome.org/GUADEC/2014/BOFs/ScreenshotAutomation

-- 
Alexandre Franke
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: git.gnome.org changes and new doap file requirements

[scl]

On  3.8.2014 at 10:45 AM Carlos Soriano Sánchez wrote:

Hi,
Thanks a lot for this, now we can point newcommers to git.gnome.org
 to take a look on apps in some specific
programming language.
I spotted an error though, trying to order the column Owner breaks the
style and it doesn't order, so we can see programs in the same
programming language consecutively (not sure what to do with apps with
multiple languages though)


Indeed.
I wanted to be precise and listed 'Shell Command Language' and 'M4'.
Now that I see how the Owner row breaks the layout, I'm hesitating
whether we want to list them, because presumably every GNOME project
uses the Autotools which include them.

Kind regards

Sven

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: git.gnome.org changes and new doap file requirements

[Carlos Soriano Sánchez]

Hi,
Thanks a lot for this, now we can point newcommers to git.gnome.org to take
a look on apps in some specific programming language.
I spotted an error though, trying to order the column Owner breaks the
style and it doesn't order, so we can see programs in the same programming
language consecutively (not sure what to do with apps with multiple
languages though)

Cheers,
Carlos Soriano


2014-08-03 10:32 GMT+02:00 Olav Vitters :

> On Sun, Aug 03, 2014 at 08:05:21AM +0200, scl wrote:
> > What am I doing wrong? Needs the git hook to be fixed?
>
> Right, instead of testing that it gives an error, I should also have
> tested that it works as intended. I fixed about 3 bugs now, please try
> again. :-P
>
> --
> Regards,
> Olav
> ___
> 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: git.gnome.org changes and new doap file requirements

[scl]

On  3.8.2014 at 10:32 AM Olav Vitters wrote:

On Sun, Aug 03, 2014 at 08:05:21AM +0200, scl wrote:

What am I doing wrong? Needs the git hook to be fixed?


Right, instead of testing that it gives an error, I should also have
tested that it works as intended. I fixed about 3 bugs now, please try
again. :-P


Ok, this works fine now.
Thank you for fixing!

Sven


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: git.gnome.org changes and new doap file requirements

[Olav Vitters]

On Sun, Aug 03, 2014 at 08:05:21AM +0200, scl wrote:
> What am I doing wrong? Needs the git hook to be fixed?

Right, instead of testing that it gives an error, I should also have
tested that it works as intended. I fixed about 3 bugs now, please try
again. :-P

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: git.gnome.org changes and new doap file requirements

[David King]

Hi Olav

On 2014-08-03 01:33, Olav Vitters  wrote:

Aside from above I also slightly changed the wiki.gnome.org header
(e.g. shows RecentChanges+Schedule again). The Schedule is IMO quite
important.


Excellent, I had been missing that since the redesign! (Of course, 
thanks for all the DOAP changes too.)


--
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