Re: Creating new modules (was Re: Git vs SVN (was: Can we improve things?))

[Jeff Waugh]

> Bringing it back to the present, there's stuff on svn.mugshot.org that
> really belongs on gnome.org, but it seems it didn't end up there. I don't
> think this was a conscious thing, but I think it probably was due to just
> enough of a barrier to create a new gnome module.

This happens with more than just revision control infrastructure. More and
more projects are hosting everything (web, svn, lists) elsewhere, because of
the social and technical issues related to staying upstream -- it's not just
infrastructure (though your example is probably the strongest atm).

Anyway, this warrants a lot of thought.

- Jeff

-- 
linux.conf.au 2008: Melbourne, Australiahttp://lca2008.linux.org.au/
 
 "Again you are making up inventing as you go. Be specific aba gaba
 datata." - Oscar Plameras
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Jeff Waugh]

> $ bzr init-repo --trees some-project
> $ cd some-project
> $ bzr checkout http://url/to/some-project
> $ bzr branch mainline working
> $ cd working
> $ ./configure
> $ make
> 
> ...compared to the same steps using svn...
> 
> $ svn co http://url/to/some-project/trunk some-project
> $ cd some-project
> $ ./configure
> $ make

You appear to be comparing completely different things. If you want to do a
checkout with bzr:

$ bzr co http://url/to/some-project/trunk some-project
$ cd some-project
$ ./configure
$ make

If you want to have a branch with bzr:

$ bzr branch http://url/to/some-project/trunk some-project
$ cd some-project
$ ./configure
$ make

Same.

- Jeff

-- 
GNOME.conf.au 2008: Melbourne, Australia http://live.gnome.org/Melbourne2008
 
o/~ we all live in a yellow subroutine o/~ - auspex
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Can we improve things?

[Jeff Waugh]

> On Fri, 2007-09-07 at 21:56 +1000, Jeff Waugh wrote:
> 
> > I know Planet GNOME maintenance has been patchy -- I've been thinking
> > about ways to alleviate that while keeping strong editorship in place.
> > The Board has prompted me about this too, so I have plenty of incentive
> > to resolve it without any of the poop flinging we've seen in this
> > thread.
> 
> Does this need to be any more complicated than having a "planet-gnome"
> module on SVN, and a README that says "to add someone to the feed, put him
> in people.xml"?  Then anyone who has a SVN account can add someone else to
> Planet.

planet-web already exists, but making it a free-for-all isn't a useful
solution.

- Jeff

-- 
linux.conf.au 2008: Melbourne, Australiahttp://lca2008.linux.org.au/
 
   "Boys will be boys, hackers will be hackers, geeks will be geeks, and
 cyberpunks will always just be ravers with Macintoshes." - Monkey
Master, Crackmonkey
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Curtis Hovey]

On Mon, 2007-09-10 at 16:41 -0700, Sanford Armstrong wrote:
> On 9/8/07, Jeff Waugh <[EMAIL PROTECTED]> wrote:
> > 
> >
> > > I simply meant that less people are familiar with D-SCM tools and that
> > > they are somewhat harder for a newbie to learn than C-SCM tools.
> >
> > This is an unfortunate cultural relic created by arch/tla, and hilariously
> > promulgated by git. Sure, fewer people are familiar with them, but the good
> > ones are not harder to learn.
> 
> I'm not really talking about the UI of the D-SCM tool, but about some
> fundamentals of the distributed model.  Getting code and pushing code
> seems to always require an additonal step.  Users have to learn about
> branching and merging up front, whereas in SVN this would come later
> in their education.  If I were a newbie developer I would find this
> confusing.  As I've stated, I don't have much experience with D-SCM,
> but these are the instructions to get started hacking on one project
> using bzr...
> 
> $ bzr init-repo --trees some-project
> $ cd some-project
> $ bzr checkout http://url/to/some-project
> $ bzr branch mainline working
> $ cd working
> $ ./configure
> $ make

Maybe there is. I'm not certain I would want to check something out.
That is the same workflow problem this thread is discussing.


Just skip the checkout, branch, make lots of changes and commits
(uncommits, shelves, unshelves, and merges) until you are sure you have
something that someone else is interested in. after pushing the changes
to a public place. Ask the third party for review, and that party could
do the merge and commit. If your very privileged, you can do the merge
into mainline and commit yourself.

> ...compared to the same steps using svn...
> 
> $ svn co http://url/to/some-project/trunk some-project
> $ cd some-project
> $ ./configure
> $ make
> 
> There's just a higher cognitive investment for a newbie getting
> started with D-SCM.  As bzr/git/etc become more common in the FLOSS
> communities, this won't be as much of an issue, though.  And the
> advantages of the distributed model have been well covered here.  :-)


The initial investment for both is still conceptional, and it takes the
same amount of time. The only people who have a higher investment are
people learning multiple workflows. Everyone working with versioning
systems needs to understand repositories, where the code is, how to get
it, how to record/report their changes, and how to publish.

D-SCM benefits people who are not the maintainers, or are offline
frequently. The project maintainers remain in authority to oversee
oversee and accept changes. The advantage is that developers who are not
in authority can exchange and collaborate on a project without special
(and possibly dangerous) power. When their work is good enough for
mainline, it can be accepted by the maintainers. D-SCM provides a
workflow for non-privileged users to achieve more in the time they have
to contribute.

-- 

__C U R T I S  C.  H O V E Y___
Guilty of stealing everything I am.


signature.asc
Description: This is a digitally signed message part
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Lucas Rocha]

Hi,

I hate to do this but... again... please move this discussion to a
more appropriate mailing list like d-d-l or gnome-infrastructure.

Thanks,

--lucasr


2007/9/11, Sanford Armstrong <[EMAIL PROTECTED]>:
> On 9/8/07, Jeff Waugh <[EMAIL PROTECTED]> wrote:
> > 
> >
> > > I simply meant that less people are familiar with D-SCM tools and that
> > > they are somewhat harder for a newbie to learn than C-SCM tools.
> >
> > This is an unfortunate cultural relic created by arch/tla, and hilariously
> > promulgated by git. Sure, fewer people are familiar with them, but the good
> > ones are not harder to learn.
>
> I'm not really talking about the UI of the D-SCM tool, but about some
> fundamentals of the distributed model.  Getting code and pushing code
> seems to always require an additonal step.  Users have to learn about
> branching and merging up front, whereas in SVN this would come later
> in their education.  If I were a newbie developer I would find this
> confusing.  As I've stated, I don't have much experience with D-SCM,
> but these are the instructions to get started hacking on one project
> using bzr...
>
> $ bzr init-repo --trees some-project
> $ cd some-project
> $ bzr checkout http://url/to/some-project
> $ bzr branch mainline working
> $ cd working
> $ ./configure
> $ make
>
> ...compared to the same steps using svn...
>
> $ svn co http://url/to/some-project/trunk some-project
> $ cd some-project
> $ ./configure
> $ make
>
> There's just a higher cognitive investment for a newbie getting
> started with D-SCM.  As bzr/git/etc become more common in the FLOSS
> communities, this won't be as much of an issue, though.  And the
> advantages of the distributed model have been well covered here.  :-)
>
> Sandy
> ___
> foundation-list mailing list
> foundation-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/foundation-list
>
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Sanford Armstrong]

On 9/8/07, Jeff Waugh <[EMAIL PROTECTED]> wrote:
> 
>
> > I simply meant that less people are familiar with D-SCM tools and that
> > they are somewhat harder for a newbie to learn than C-SCM tools.
>
> This is an unfortunate cultural relic created by arch/tla, and hilariously
> promulgated by git. Sure, fewer people are familiar with them, but the good
> ones are not harder to learn.

I'm not really talking about the UI of the D-SCM tool, but about some
fundamentals of the distributed model.  Getting code and pushing code
seems to always require an additonal step.  Users have to learn about
branching and merging up front, whereas in SVN this would come later
in their education.  If I were a newbie developer I would find this
confusing.  As I've stated, I don't have much experience with D-SCM,
but these are the instructions to get started hacking on one project
using bzr...

$ bzr init-repo --trees some-project
$ cd some-project
$ bzr checkout http://url/to/some-project
$ bzr branch mainline working
$ cd working
$ ./configure
$ make

...compared to the same steps using svn...

$ svn co http://url/to/some-project/trunk some-project
$ cd some-project
$ ./configure
$ make

There's just a higher cognitive investment for a newbie getting
started with D-SCM.  As bzr/git/etc become more common in the FLOSS
communities, this won't be as much of an issue, though.  And the
advantages of the distributed model have been well covered here.  :-)

Sandy
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Creating new modules (was Re: Git vs SVN (was: Can we improve things?))

[Federico Mena Quintero]

On Mon, 2007-09-10 at 16:42 -0400, Havoc Pennington wrote:

> Anyway. I'm not sure the old cvs-commits-list type approach really
> scales to GNOME's current size, but I think something *was* lost.

Yes, something definitely was lost.  It was quite pleasant to see commit
messages go by; people cared enough that you'd see jokes and funny stuff
deliberately written for the commit messages.

Then it became a firehose as the project grew larger.  I do miss reading
commit logs and wouldn't mind doing it for a few sub-projects, but
definitely not for all of GNOME.

  Federico

___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Foundation Board Meeting Minutes :: 23rd Auguest 2007

[Glynn Foster]

Present: Lucas, Anne, Glynn, Quim, Rosanna, Jeff
Regrets: Behdad, Vincent

1) Zana's planning to be out of action with a baby due at the end of
   November. She commented that she has 2 weeks off per year as is
   the minimum requirement working for a single employee organization.
   Quim commented that the board should meet to discuss other
   timelines around Zana's maternity leave and communicate accordingly.

   ACTION: All to discuss maternity leave dates on board-private.

2) Boston Summit

   In the process of confirming the venue. There is a minor development
   where 2 groups are saying different things about the venue - one
   saying that it's free, and the other (conferencing services) saying
   it is not free. There's no current summit planning team on the ground,
   but Jeff expects that to happen once the core summit details are worked
   out.

3) Treasurer

   Vincent commented that he could do the treasurer position if no one
   else was keen. Board voted to approve Vincent as the ongoing treasurer
   after Dave's departure.

4) Election Term

   Jeff commented that his current thinking was to change the bylaws to
   state that there is a maximum 2 year term to be defined by the board
   by the time of elections, so that it can adapt to any changes in the
   future, but also have a limitation that is reasonable. Jeff suggested
   that a change to the bylaws should be written, and then taken to the
   membership. We aren't sure whether we have the infrastructure for
   such a vote, and would be good to check with the membership committee.

   Quim commented that it seemed reasonable to make this smaller change
   rather than a wide reaching revision of the bylaws. Glynn commented
   that the membership should feel free to suggest changes (just like
   any other board member). Lucas agreed that it should be a set of
   atomic changes rather than a larger one. All agreed we should get this
   out sooner than later to the membership.

   ACTION: Jeff to contact James Vasile about changing the election term
   in the bylaws.

   ACTION: Lucas to check with Baris about the current election mechanism
   and see what is possible to do.

   ACTION: Jeff to send new proposal to foundation-list once it is written.

5) GUADEC Debrief

   Paul joined the call temporarily to give a quick debrief of GUADEC this
   year. He commented that there was a good selection of high quality talks
   and that credit was due to the members and paper committee. Other big
   hits were stickers, USB keys, the venue and social events. He said that
   most things that went wrong were those he expected to go wrong, and that
   nothing major was unexpected. Most of the heartache was caused by only
   getting into the venue the day the conference started. Paul commented that
   he was in the process of getting the finances finished, and if there was
   money available, he thoguht it was worth printing more stickers. He said
   that travel assistance hadn't yet been paid out, and was still waiting
   for a few sponsors to push their invoices through the system - once that
   was done, he would re-imburse everyone. The videos are having a few
   technical difficulties, so it may take time to post process.

6) Planet GNOME

   Jeff wants time to think about it more, and will respond on list.

   ACTION: Jeff to respond to Planet GNOME maintenance thread on board-list.

7) Marketing Team Board Blessing

   Jeff commented that we shouldn't be creating official committess of
   the Foundation unless we're absolutely sure of it - they are quite
   heavyweight and have certain responsibilities according to the bylaws.
   We should be blessing leaders and teams instead rather than anything
   moreformal. Anne commented that it would be nice to develop these
   teams futher to a stage where they could eventually be made an official
   committee if necessary. Jeff replied that he didn't think very many
   had a need to official, and wasn't stopping them getting work done. Glynn
   commented that official committees wasn't exactly in the spirit of the
   GNOME Foundation, and we should try to keep things as least bureaucratic
   as possible. Jeff commented that many of the teams grown up around GNOME
   took on positions of responsibility because the rest of the community
   bought into them by their own merit.

   Quim clarified that his intention was just to get a marketing team
   formalized just as much as other official teams in the project, like
   i.e. Sysadmin or the Release team, not to get the status of official
   committee of the Foundation. This topic will continue in the
   marketing-list.

8) Summer of Code

   Lucas commented there was 27 projects that reached the end of the program,
   and some had really nice results. He mentioned that the mentors were a
   lot closer to the students during the development, and this helped a lot.
   He expected to have some regular contributors to the proejct out of
   

Re: Can we improve things?

[Olav Vitters]

On Mon, Sep 10, 2007 at 05:23:28PM -0500, Federico Mena Quintero wrote:
> On Mon, 2007-09-10 at 16:21 -0400, Claudio Saavedra wrote:
> 
> > That's the way things are handled ATM. With the exception that only Jeff
> > is supposed to commit to the appropriate file (there's a README or
> > HACKING somewhere there).
> 
> Well, we can certainly stea^H^H^H^Hfree Jeff from the drudgery of having
> to do that :)
> 
> What's the module on SVN?

planet-web, just adding things can break planet; IIRC it doesn't handle
500 errors nicely (well.. it'll mail jdub every time it updates..
meaning 15min)
-- 
Regards,
Olav
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Can we improve things?

[Federico Mena Quintero]

On Mon, 2007-09-10 at 16:21 -0400, Claudio Saavedra wrote:

> That's the way things are handled ATM. With the exception that only Jeff
> is supposed to commit to the appropriate file (there's a README or
> HACKING somewhere there).

Well, we can certainly stea^H^H^H^Hfree Jeff from the drudgery of having
to do that :)

What's the module on SVN?

  Federico

___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Creating new modules (was Re: Git vs SVN (was: Can we improve things?))

[Claudio Saavedra]

On Mon, 2007-09-10 at 17:01 -0400, Havoc Pennington wrote:
> 
> Then the daily summary could be in the planet gnome feed, perhaps.
> 
> I don't know, I'm sure there are better solutions, and it's academic
> unless someone turns up who decides to try and code something. Just
> throwing out ideas. 

CIA.vc already provides some access to this information in a standard
way.

For instance, 

http://cia.vc/stats/project/gnome/.rss for all the commits going in
http://cia.vc/stats/project/gnome/eog/.rss for all the commits in EOG
http://cia.vc/stats/author/csaavedra/.rss for all my commits, 

etc.

Claudio

-- 
Claudio Saavedra  <[EMAIL PROTECTED]>

Día del Software Libre, Curicó  http://curico.diadelsoftwarelibre.cl

___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Olav Vitters]

On Mon, Sep 10, 2007 at 03:05:18PM -0500, Federico Mena Quintero wrote:
> On Sat, 2007-09-08 at 10:17 +0200, Olav Vitters wrote:
> 
> Hi, Olav,
> 
> > You are ignoring the central place. You need somewhere all GNOME devs
> > are able to commit. This is what is so wrong about
> > www.gnome.org/~foo/git/.
> 
> The interesting question is, "why are people doing ~foo/git/blah in the
> first place?"

Oh, only reading this email after the one from HP.

> Because it is no longer possible to create new SVN modules easily, as it
> was when we used CVS.  By "easily" I mean that it you want to create a
> module, you don't need to ask anyone to do it for you.

So ehr, we should have svn.gnome.org/svn/testingground ?
(or whatever?)

> Think of a gnome.org developer who has just written a new and exciting
> program, and wants to make it available.  You are in that beautiful
> moment when the program works well enough that you want to show it
> around, and you are pumped up!  The only thing that goes through your
> mind is publish, publish, publish!
> 
> So you start writing an exciting blog post full of nice screenshots and
> plans, and you write "you can get MyProg at svn.gnome.org/svn/..."
> 
> Oh, shit.  Giant brick wall.  You cannot create the module by yourself.
> You google for "gnome creating new svn modules" and you get pointed to
> http://developer.gnome.org/tools/svn.html - which leads you to
> http://developer.gnome.org/doc/tutorials/import.html if you want to
> import your code, but THAT WON'T WORK because it still talks about "cvs
> import".

Feel free to fix it and point to NewSVNRepos.

> Okay... so you know that the developer's site is pretty bad and
> outdated, so you go to check the wiki.  Go to live.gnome.org and type
> "svn" in the search box.  Great, the first search hit is
> http://live.gnome.org/NewSVNRepos - which tells you "mail an admin with
> this list of requirements".  Download page?  Project homepage?  Come on,
> this is my first "it barely works" release - I don't have all that set
> up yet!

Ehr? Doesn't it tell you that *if you have a GNOME SVN account*, we only
care about *your GNOME SVN account and your requested module name*?

if it doesn't, just mention this (it is a wiki:). Above is a generic New
SVN repos page, meant for people who want to host their existing SVN
repos on GNOME.

> So you are stuck.  Ask an admin to create a new module?  That will take
> days.  Your energy and happiness go to hell.
> 
> It is very sad that even if you already have an SVN account, you cannot
> create a module by yourself.
> 
> Back when we used CVS, anyone with an account could do "cvs import",
> just as described in the developer's site.  People botched it up and
> imported generated files, etc., but that could be easily fixed.

Only because it was one repos (IIRC).
Suggestions are welcome btw. This without handing people (root) shell
accounts on socket.

> People are using ~foo/git/bar because *it works* without having to ask
> someone else to import your code for you.

If you have shell for another reason. IIRC (no clue really) you could
just as well setup SVN repos on there.. although I don't know for sure
if that Apache stuff is optional or not.
-- 
Regards,
Olav
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Creating new modules (was Re: Git vs SVN (was: Can we improve things?))

[Havoc Pennington]

Hi,

On 9/10/07, Olav Vitters <[EMAIL PROTECTED]> wrote:
> svn-commits-list exists and you can limit the email receive to one or
> more projects (or all).

Right, but like I said I'm not sure it scales anymore; there's too
much stuff in svn to want to get an email per commit. If you limit to
only your projects, then you miss out on learning things by accident,
which is the real value. For example, if you are a library maintainer,
it's very helpful to happen to see commits where people are trying to
use the library. And everyone benefits from noticing new experimental
projects as they appear.

Maybe a daily summary like:
   gnome-panel - whoever (3), someone-else (2)
   ...

where it's all linkified going to the appropriate svn/git web (could
also have mouseover tooltips showing details so you could quickly
scan)

Then the daily summary could be in the planet gnome feed, perhaps.

I don't know, I'm sure there are better solutions, and it's academic
unless someone turns up who decides to try and code something. Just
throwing out ideas.

Havoc
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Creating new modules (was Re: Git vs SVN (was: Can we improve things?))

[Olav Vitters]

On Mon, Sep 10, 2007 at 04:42:03PM -0400, Havoc Pennington wrote:
> Hi,
> 
> On 9/10/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote:
> > Because it is no longer possible to create new SVN modules easily, as it
> > was when we used CVS.  By "easily" I mean that it you want to create a
> > module, you don't need to ask anyone to do it for you.
> >
> 
> When this first came up on d-d-l I was sort of "not sure this is a big
> deal" but then recently I was thinking about it again and decided it
> did matter.
> 
> Back in the day the cvs-commits-list was part of the community. One of
> the things that frequently happened is that people followed up to
> commit messages to discuss, or noticed a commit and discussed it on
> IRC.

svn-commits-list exists and you can limit the email receive to one or
more projects (or all).

> Anyway, the centralization and common CVS repo was really a big part
> of how the community worked. It let people get credit, it let people
> informally notice where they could help each other, it let everyone
> have a baseline knowledge of what was being worked on.

I think this worked because /cvs/gnome was one big repos right? Now we
create a repos per module. This needs someone with a shell (root) to set
it up. Don't like handing out shell on that machine, but perhaps some
webinterface when possible (after mango).

-- 
Regards,
Olav
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Creating new modules (was Re: Git vs SVN (was: Can we improve things?))

[Havoc Pennington]

Hi,

On 9/10/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote:
> Because it is no longer possible to create new SVN modules easily, as it
> was when we used CVS.  By "easily" I mean that it you want to create a
> module, you don't need to ask anyone to do it for you.
>

When this first came up on d-d-l I was sort of "not sure this is a big
deal" but then recently I was thinking about it again and decided it
did matter.

Back in the day the cvs-commits-list was part of the community. One of
the things that frequently happened is that people followed up to
commit messages to discuss, or noticed a commit and discussed it on
IRC.

The really important community effect is that you could kind of just
watch everyone working, and if it happened to relate to you or
happened to look interesting, you could pile on. Since commit access
was not per-module but for the whole GNOME project, you probably
already had commit access.

Another social effect is that you knew who was doing work, and if you
did a lot of work you got credit for it without having to
self-promote, since people saw your commits flying by.

Anyway, the centralization and common CVS repo was really a big part
of how the community worked. It let people get credit, it let people
informally notice where they could help each other, it let everyone
have a baseline knowledge of what was being worked on.

Importantly, this happened *even for brand new or experimental
projects*. Those were worth having in the central repo because of the
social and community value of knowing what people were up to and being
able to help them or assign them your respect or whatever accordingly.

Bringing it back to the present, there's stuff on svn.mugshot.org that
really belongs on gnome.org, but it seems it didn't end up there. I
don't think this was a conscious thing, but I think it probably was
due to just enough of a barrier to create a new gnome module. And then
once you start a module in one place, it's a Major Project to move it
(probably not truly a major project, but enough to result in
procrastination).

Anyway. I'm not sure the old cvs-commits-list type approach really
scales to GNOME's current size, but I think something *was* lost.

To give a productive suggestion, I wonder if a nice "code commits
planet" would be a win for GNOME, perhaps somehow mixed in to or in a
sidebar of the current planet. It could track all the repos related to
GNOME and try to display in readable summary form 1) which modules had
commits today and 2) who did the commits. To show who's doing stuff
and what stuff they are doing, at least in terms of which module they
are working on.

Havoc
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Can we improve things?

[Claudio Saavedra]

On Mon, 2007-09-10 at 14:43 -0500, Federico Mena Quintero wrote:
> 
> Does this need to be any more complicated than having a "planet-gnome"
> module on SVN, and a README that says "to add someone to the feed, put
> him in people.xml"?  Then anyone who has a SVN account can add someone
> else to Planet. 

That's the way things are handled ATM. With the exception that only Jeff
is supposed to commit to the appropriate file (there's a README or
HACKING somewhere there).

Claudio

-- 
Claudio Saavedra  <[EMAIL PROTECTED]>

Día del Software Libre, Curicó  http://curico.diadelsoftwarelibre.cl

___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Federico Mena Quintero]

On Sat, 2007-09-08 at 10:17 +0200, Olav Vitters wrote:

Hi, Olav,

> You are ignoring the central place. You need somewhere all GNOME devs
> are able to commit. This is what is so wrong about
> www.gnome.org/~foo/git/.

The interesting question is, "why are people doing ~foo/git/blah in the
first place?"

Because it is no longer possible to create new SVN modules easily, as it
was when we used CVS.  By "easily" I mean that it you want to create a
module, you don't need to ask anyone to do it for you.

Think of a gnome.org developer who has just written a new and exciting
program, and wants to make it available.  You are in that beautiful
moment when the program works well enough that you want to show it
around, and you are pumped up!  The only thing that goes through your
mind is publish, publish, publish!

So you start writing an exciting blog post full of nice screenshots and
plans, and you write "you can get MyProg at svn.gnome.org/svn/..."

Oh, shit.  Giant brick wall.  You cannot create the module by yourself.
You google for "gnome creating new svn modules" and you get pointed to
http://developer.gnome.org/tools/svn.html - which leads you to
http://developer.gnome.org/doc/tutorials/import.html if you want to
import your code, but THAT WON'T WORK because it still talks about "cvs
import".

Okay... so you know that the developer's site is pretty bad and
outdated, so you go to check the wiki.  Go to live.gnome.org and type
"svn" in the search box.  Great, the first search hit is
http://live.gnome.org/NewSVNRepos - which tells you "mail an admin with
this list of requirements".  Download page?  Project homepage?  Come on,
this is my first "it barely works" release - I don't have all that set
up yet!

So you are stuck.  Ask an admin to create a new module?  That will take
days.  Your energy and happiness go to hell.

It is very sad that even if you already have an SVN account, you cannot
create a module by yourself.

Back when we used CVS, anyone with an account could do "cvs import",
just as described in the developer's site.  People botched it up and
imported generated files, etc., but that could be easily fixed.

People are using ~foo/git/bar because *it works* without having to ask
someone else to import your code for you.

  Federico

___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Can we improve things?

[Federico Mena Quintero]

On Fri, 2007-09-07 at 21:56 +1000, Jeff Waugh wrote:

> I know Planet GNOME maintenance has been patchy -- I've been thinking about
> ways to alleviate that while keeping strong editorship in place. The Board
> has prompted me about this too, so I have plenty of incentive to resolve it
> without any of the poop flinging we've seen in this thread.

Does this need to be any more complicated than having a "planet-gnome"
module on SVN, and a README that says "to add someone to the feed, put
him in people.xml"?  Then anyone who has a SVN account can add someone
else to Planet.

  Federico

___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

About Planet GNOME

[Quim Gil]

Hello everybody,

The board received a request from Valek Filippov about the
administration of http://planet.gnome.org . We accepted it for
discussion and this is the conclusion we have got:

- Planet GNOME is an official GNOME subsite and for that reason it is
good to have more than one person administering it.

- The content of Planet GNOME is good and it reflects the good editorial
work that Jeff has been doing accepting feeds. The board is happy with
any improvement on the current situation keeping Jeff's editorial
leadership.

- The more mundane administration of the Planet is less critical from
an editorial point of view and is in fact the cause of most criticism.
The board thinks that these administrative tasks will be better
handled by a team, and probably also through better channels than
private emails.

- Although some board members had several ideas to improve the current
management of Planet GNOME in more transparent and decentralized ways.
board-list is not the place to discuss or agree on those. We recommend
Jeff and anybody interested in this topic to discuss and get to
conclusions openly in gnome-web-list.

Thanks,

-- 
Quim Gil /// http://desdeamericaconamor.org
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Behdad Esfahbod]

On Mon, 2007-09-10 at 00:29 +0200, Christian Rose wrote:
> On 9/9/07, Behdad Esfahbod <[EMAIL PROTECTED]> wrote:
> > On Sun, 2007-09-09 at 18:49 +0200, Christian Rose wrote:
> > > Nothing is ever solved by letting others be
> > > responsible for solving problems that may have been introduced by you.
> > > Or vice versa. That's a basic fact in SCM.
> >
> > But more often than not the build is left broken by a translator.
> 
> But translation commits are also account for a significant share of
> the total number of commits, so any "statistics" are bound to be
> skewed some way if you don't account for the selection.

Fair enough.  What surprises me though is that many translators never
build the software and probably don't test their translation before
committing.  At least that's my impression from watching how broken a
state some leave the module in.

> Still, I supposed this situation had improved since there were
> mandatory precommit checks introduced. Isn't that the case? If not,
> this can probably be improved in a lot of ways.

po/ is hardly a problem these days.  Most common case of broken build in
my experience has been translators moving user docs to gnome-doc-utils
and not correctly updating Makefile.am and configure.ac.  That may just
be a problem in the wiki page about the migration.

> Christian

This really belongs to gnome-i18n.

-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759



___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Lucas Rocha]

Hi all,

Could you please move this discussion to d-d-l and/or
gnome-infrastructure? This mailing list is definitely not the place to
discuss SCM in GNOME.

Thanks,

--lucasr

2007/9/10, Olav Vitters <[EMAIL PROTECTED]>:
> On Mon, Sep 10, 2007 at 08:29:35AM +0300, Kalle Vahlman wrote:
> > 2007/9/8, Olav Vitters <[EMAIL PROTECTED]>:
> > > On Sat, Sep 08, 2007 at 04:47:31PM +0300, Kalle Vahlman wrote:
> > > > And this all is naturally from the developer/maintainer POV, as
> > > > translators and documentors do not benefit from this as much. But as
> > > > the general opinion seems to be, they shouldn't be forced to use SCM:s
> > > > directly anyway.
> > >
> > > That is a theoretical discussion. Ideally GNOME has a D-SCM now and all
> > > translators use a websystem that automatically translators. It doesn't 
> > > exist.
> >
> > Of course it is theoretical since there's no hope (nor sense) in
> > switching over to anything before there are tools. As is pointed out,
> > it would make things worse for non-developres.
>
> D-SCM systems exist. Such a translator tool does not. Especially as
> someone has to write that tool, I do not like discussions that involve a
> tool 'someone will write' (well, unless one of the damned-lies people
> shows a clear proposal; including authentication bits).
>
> > But that doesn't mean the discussion needs to be punted indefinetly,
> > and statements like "I don't want to learn a new SCM" are really not
> > contributing to a discussion of the benefits a new tool would give to
> > developers. At least I thought we were discussing exactly that.
>
> I disagree. It translates to easy of use. Why should I have to care how
> a SCM works? A tool should either warn me strongly before doing
> something wrong, or prevent it outright. It should have a --help that is
> understandable. The man pages should have the most common usages, etc.
>
> I'm all for some D-SCM tool that provides benefits to people who
> understand (D-)SCM in&out, but I need to use it as well. Perhaps git now
> is good enough, no idea. But just discussing benefits of some tool
> without discussing ease of use is ignoring part of the users.
>
> > > Although there is now some progress towards D-SCM, I don't see
> > > such a websystem happening. Also am not sure if a websystem is the most
> > > appropriate way.
> >
> > I'd much rather see something like SCM support for gtranslate which
> > would give a comfortable tool to translate and send changes to the
> > server.
>
>
>
> --
> Regards,
> Olav
> ___
> foundation-list mailing list
> foundation-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/foundation-list
>
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list