toolization

[DidouPh aka Pierre-Henri RAMBOZ]

hi all

Thanks to David, who helped me a lot.
we have a websvn

Its a "proof of concept" a showcase
http://www.ipclinuxos.com/websvn/

it is hosted on my server but can be used to view/browse svn on the
ipclinuxos repository aswell as google code repository!
it could also list more (local distrib ?)

since we yet have a google code account and a private svn, since we
have a group tool, why don't we SIMPLY

1 create a blog to document our progress
2 link it to the wiki (rather than implementating one) or use a part
of the blog as a cms
3 use websvn to share code from either one or the other server
4 keep using google group for communication
5 stick to google code for developing and releasing pclinuxos centric
tools wich are not translation or to develop documentation translation
(less files)

[David Smid]

DidouPh aka Pierre-Henri RAMBOZ napsal(a):

I would rather not span the sources over several hosts.
Let's use the Google repository as our testing sendbox.

David

[Alessio Adamo]

We could let each future team leaders use that space to submit their updates (they would have administration rights), instead of sending them by email. It would be more organized. Once the submitted updates are added to our superserver by our superadministrator(s), they can be deleted from google code. Our superserver would be organized by package (as it is now), while google code would be organized firstly by team and then by package. At least initially we wouldn't have 70 different teams, so there will be enough room.

As for points 1 and 2, did someone of you have a look at google sites? Can it fit our needs?

2008/10/16 David Smid <da...@smidovi.eu>

[Alessio Adamo]

Oops, I forgot to say:

Congratulations! Websvn looks very cool! Well done guys!

2008/10/16 Alessio Adamo <alessi...@gmail.com>

[Ramboz Pierre-Henri]

i would rather use a server that fits our need in space and google code is not yet able to complie with that ... i still got no answer from them and nothing is hosted there ... when i mention multiple host, its for multiple and sub project ... there isn't only one localization team and they are some local teams that might enjoy having a separate space beforme mergin ...

the previous post is more about potential within these tools rather than real achhievement !

if google code is our sandbox ... it sounds like its pretty ... out of question to use it since we had expereinced space shortage and i only got one person requesting svn access in write mode ... in 3 month !

about the svn organisation ...

its definately a good way to get lost in translation to have two different organisation ... in other word, the power of svn is that you may have it organised as it will be on the computer ... lets keep it simple ... there is no reason to have several organisation...

when i mention other project, i mean project "with a different" work than the one we have planed to perform. a splited organisation on the po translation is against the ease of rpm distribution since it needs double work !
anothe argument against double organisation is that it would overload the work on the administrative part.

letting too many people submit source without coordination is a good way to loose track of modification ... we all know that i can't check files from swedish translators unless it is on a "technical basis". Submission by mail allow two things :
1 : everyone is aware of what is going on and has been achieved
2 : everyone is able to check file consistancy before addition to the svn ...

and on the other hand .. everyone has only one thing to do... so less risk that someone forgets to mention an update ! less trust is requested, the system is more open this way ...

in that very domain i think we should stick to the gang policy ... wich means having a limitated amount (2/3) person in the core, able to upload things on the svn !  and uncatched mystake on a svn can end in dramatic issues.

now oposed to the gang's policy, the use of mail / group, allows people to monitor the group's activity and progress, understand the way things work in the team and to learn from our mystakes. we are humans after all, not just names related to files commented with some obscure tags such as "fixed msid#325 with $2". We need to echange, discuss and comment our actions.

about google site ...

google site is more like a myspace than a wordpress ... its too limitated for documentation (bloated and complex) and too complex to edit for information stream.

bloggers is better ... but if we go blog, lets do something adapted and a customized wordpress with optimized content would be much more handy to use and adminuister.

2008/10/16 David Smid <da...@smidovi.eu>

[David Smid]

Ramboz Pierre-Henri napsal(a):

> letting too many people submit source without coordination is a good way
> to loose track of modification ... we all know that i can't check files
> from swedish translators unless it is on a "technical basis". Submission
> by mail allow two things :
> 1 : everyone is aware of what is going on and has been achieved
> 2 : everyone is able to check file consistancy before addition to the
> svn ...

I think the "commit by mail" policy is too clumsy and dependent on project
leader being able to process the requests.

I would rather use SVN accounts for that. Let's assign one account to each
language team leader (they can even be named after locales - fr, cs, de, it, ..).
Delegating some responsibility to language team leaders wouldn't make any harm.
Remember - it's SVN and it's pretty easy to review who has committed what
changes and to rollback them if needed.

Anyone who is not able to learn three simple commands (svn update, svn add, svn
commit) cannot be a language team leader.

David

[Zoltan Hoppar]

I agree with that. But I have an question (maybe an good idea): If somebody uploads files, but there are some error(s) in file(s), then is it possible to mark it with to do's, like in launchpad - that needs review, ok, transferable, for rpm ready and sutch, and send out an mail to turn attention to it? Also, how is it possible to track the file problems (like syntax errors, aso.)?

Zoltan

2008/10/16 David Smid <da...@smidovi.eu>

[Ramboz Pierre-Henri]

back on the tools ... since we're not on the part you're talking about yet... can we please proceed step by step ... what do you "really think" of the current system?

"Its real kool and looking nice" isn't an helpfull answer. for the very simple reason that ... hum satan is kool and nice looking ... it doesn't mean its appropriate :p

my very concern is to set up something functional and useable ... and not to spend my life dealing with a pair of server administration and resynch ...

zoltan pointed out the reason why svn isn't suitable for our needs alone ... its dependent on "efficience" and since we're all speaking different languages ... we have no option to synchronise work properly ...

sure we could split in separate teams ... sure we could have 20 committers, one per language ... but it's yet a hell to doublecheck every file when they transit trough one person from another ... but letting too many people commit to the svn is yet a good way to get an awfull mess and translation as hairy as mandy used to be... i mean ...working this way would mean a complete step backward in the methodology we designed, it would also mean going back in time, adding boundaries and reducing control over data ... so everything would be unsafe (in quality)

don't be missunderstood... i uderstant that we make refference to working task being stored under a per language three ... like they are on the current berlios cvs ... I think we had long talks about that and that the argument stating that it was a nonsence and a waste of time to put things back in place right before the release. I wasn't agreeing on that point and have been convinced by your arguments guys so please ... pick a decision and stick to it a least enough for it to be experimented !

so if i consider your proposal as a definitive statement ... it means we would have to extract file for every single package/subpackage and rename them from whatever.po to package.po and move them to a /svn/locale/po/package.po place. Then each local team would have to translate po and update they svn and send files back to the "main team of gurus" who will check the files (written in a language they don't understand) which should have been checked/tested  by the locale team who would have submitted them. and then uploaded to the "super svn server" in the original order ... then downloaded again to be compiled and packaged as rpm ...

isn't it a waste of time ?

the file needs to be moved about 3 times more than necessary ... there can be confusion/inversion/errors/ ... many thing can happen out of a simple useless transfer ... why can't people just
1 : download files one by one from the main svn
2 : work on them and send them back when fully translated by mail so teammate can be aware of the progress without having to be informed by the commiter or by checking the svn
3 : the commiter uploads
4 the packager resynch and package

file is transformed only once and we need to write it to svn only once and download it only once per state !

on the other hand, if the system i just wrote down about here isn't simple enough, why havn't we kept the previous one ?
just because it was cvs ?

i don't think so ... at least the email way prevent the desperate silence we all suffered from in the last few month ... if you want to go back there and just publish your file on the svn ... ok for me ... i really don't care ... i'm no longuer the leader you know ... i just am here to help !

my 2 cents .*

DidouPh

1 /

2008/10/16 Zoltan Hoppar <hop...@gmail.com>

[Ramboz Pierre-Henri]

I just got a mail from google team to tell us we had our space being increased up to 500mb !
so now we have a large google svn with "pub" and "private" access aswell as websvn

the storage issue is solved for svn.

lets consider my server is out of the equation now. (unless one finds it usefull for something)

1 : how do we organise the google code server ?
2 : do we need more than the svn and group tools ?
3 : do we need a better documentation engine ?
4 : is a wiki the appropriate tool for us ?
5 : do we want to be able to have full control over our sources and docs ?

and how are we supposed to achieve such things ...

less parameters ... more questions, but its getting clearer. don't you think

DidouPh !


2008/10/16 Ramboz Pierre-Henri <did...@gmail.com>

[Ramboz Pierre-Henri]

to add to the discussion, i would like to drag your attention to tools like this one :
http://wordpress.org/extend/plugins/drain-hole/

2008/10/16 Ramboz Pierre-Henri <did...@gmail.com>

[David Smid]

First of all, let me say I still believe the package centric repo organization
is the one we need. But Alessio's tarball does not comply with this scheme
(packages/<package_name>/po/<gettext_domain>/<locale>.po), it lacks the
<gettext_domain> directory.
Second, I don't see a reason why would giving write access to several people
enforce the "locale/po/package.po" scheme. Sure, there is a possibility someone
evil would overwrite things he should not touch, but isn't it about time to
trust people a little bit ? Even in case of such disaster, it's easy to find out
who did that (thanks to SVN accounts) and it's easy to fix the mess and revert
the changes.
Everyone should be responsible for his commits.
If SVN is too complex for translator (I don't think it is), let's use launchpad
but not the "commit by mail" method - it's silly and error-prone.

To reduce the danger of bad commits, we could establish some sort of "contribs"
repository. Translator would first commit his changes there, and after review
from admin, changes would be merged into the main SVN repo.

Ad SVN host tender:
Google code has two advantages:
1) You don't have to administer it or to solve technical problems
2) There is an anonymous SVN access

ipclinuxos.com has only this advantage, but I think it's a killer feature
1) You can automatically let run a validation script after each commit - this
script (maybe just "cd packages; make po") could check if anything wasn't
corrupted and send an email to admin and submitter in that case.

Lack of anonymous SVN account can be overcome by another killer feature:
WebSVN's tarball packing ability. Every luser can download up-to-date tarball
with just one click on "tarball" link of trunk directory.

David

[Ramboz Pierre-Henri]

no one is talking about evil people here and my very problem is with double repository organisation...
the annonymous login can be handled by rsa key like it is now on ipclinuxos ...
any technical problem can be handled on ipclinuxos server by the host crew (wich is much more responsive than google's one as we experienced it.

so really ... if we lack this feature on google, why don't we go on ipclinuxos ... since both are websvn compatible ... we have the tarball option and a complementary set of tools comming with it! There is also the wordpress pluggin option that could ballence the "mail option" and advocate in favour of "multiple" commiters since it will publish news about the repo activity and can also inform on the project and hold the documentation of our project in a safer way.

of cours i know issues can be tracked. but for me, a safe system is one where problems don't apear, not one where you can solve them.

that's why despite the fact you got the svn system to work as expected on ipclinuxos ... i personally had to undestand the mechanism behind it to get it to run properly. That's also why i really don't feel like relaying on anyone but us like we have to with the gang.

About "trust" it isn't a matter of trust. but a matter of efficiency !

last point, about organisation : i had missed the difference you just pointed out in the tarball structure wich i thought to be similar to the targeted one ... but you're right, its not appropriate. by the way, as far as i can see, there is no point in having two repo and we could finally have found the tools we are looking for to work properly.

lets not forget that we not only need access to the source.

DidouPh

2008/10/17 David Smid <da...@smidovi.eu>

[Alessio Adamo]

Just to clarify what I meant. I wrote organize by language/package, not how it was before, but just someting like:

italian o it/userdrake/po/it.po

the italian team leader should meddle only with the italian domain, but the substructure would be exactly the same as in the main server. How can you send by e-mail 10 files named it.po? You need to send 10 e-mails and maybe you get confused where you put what.

Instead with kdesvn you just take care of the italian tree, you have the tree in your hard-drive, the it.po files are in their own folders, you can't make any mistake.

Eventually there's no need to have language domains, we can mirror the structure of the main server and put only the xx.po files for which we have a team.

This just if we want a buffer between the contributors and the main server. As I wrote, whenever the main server maintainers have updated it with the updated po files in google, they would clear the respective directory in google.

I can spend more words if it's not clear yet. I haven't read all you're replies yet. I'm going to do it. In case, I'll add something.

2008/10/17 Ramboz Pierre-Henri <did...@gmail.com>

[Alessio Adamo]

I've discovered we got more space on google...

To summarise the positions:

didouph proposes that only him and David should have access to ipclinuxos svn and that files should be submitted by e-mail to have a buffer between contributors and ipclinuxos

David proposes that all team leaders should be able to access ipclinuxos svn and directly commit what they want.

I was in the middle. When I still didn't know that google could increase our space, I suggested this way to use our small google space. Instead of sending emails, which I personally hate (I totally agree with David), let's make use of google space. All team leaders would access it and would have their own language domain, with a replica of the ipclinuxos folder structure. The italian team can't work as a team with emails. I remember when I was submitting something which didn't go into the CVS for weeks (in some cases never) which made completely lose track of which version I had sent. I thought that our google space could be our work in progress space. Everybody else in the team could see the progress on a daily basis or even hourly. Can you imagine sending 1 email every day? Like that ipcilinuxos maintainers would get crazy! And then you need to explain this it.po file goes to drakconf/, this other to printerdrake/.
Using google as a buffer, every team leader can commit the files they are concerned with, whenever they want. This simplifies the team work management.
It also makes it easier for ipclinuxos maintainers. Sorting out emails I don't think is more efficient. Once the files in ipclinuxos have been updated with the files in google, these would be cleared out. That's the sign: if you don't find a file in google, that means that in ipclinuxos you have the most updated version.
Moreover, if team leaders are able to commit to google whenever they want, you can have a better idea of the degree of activity of their team just by having a look at the change tracking. There's even the option to be informed by email of any change.

As I said, I thought of this when I didn't kwnow that google would increase our space, but I think it's the best option between two needs: the need of safety expressed in didouph position;
the need of shared responsibility and efficient team working expressed by David.

If you (=everybody else) see my proposal pointless, than my vote goes to David's one. emails are just the opposite of what we need.

2008/10/17 Alessio Adamo <alessi...@gmail.com>

[Alessio Adamo]

Last message.

I think the tree has to be organized by package name. In addition, the po files must be in the same folder they would be inside the tarball. It makes easier their implementation into mainstream packages by the devs.

2008/10/17 Alessio Adamo <alessi...@gmail.com>

[David Smid]

Alessio Adamo napsal(a):

> Last message.
>
> I think the tree has to be organized by package name. In addition, the
> po files must be in the same folder they would be inside the tarball. It
> makes easier their implementation into mainstream packages by the devs.

That would break our ability to easily build our l10n RPMs.
All the tools and Makefiles would become useless.

David

[Ramboz Pierre-Henri]

i will reply to the serie of message posted one by one so please take the time to read them all so you will notice every suble nuence including google code increase.

2008/10/17 Alessio Adamo <alessi...@gmail.com>

Just to clarify what I meant. I wrote organize by language/package, not how it was before, but just someting like:

italian o it/userdrake/po/it.po

this has been well understood

the italian team leader should meddle only with the italian domain, but the substructure would be exactly the same as in the main server. How can you send by e-mail 10 files named it.po? You need to send 10 e-mails and maybe you get confused where you put what.

you just hit the problem i mentioned ... why sending the file when you can send the structure !
its not a matter of repository but of file submission policy ... keeping the organisation of files in folders and submitting the package translated by mail embedded in an archive or commiting to the main svn straight ahead is a better solution than straight to svn commitment ... once again. this has been discussed, explained and decided before ... no open source project has more than 3/4 commiters to the svn ... for the reason explainde before ... its not because its simple to fix a problem in svn that we must no be carefull ... if we have many commiters... lets just not have svn ... its simply too complex if we have many people to post ... i'm worried about consistancy of the repo and communication between team and would like you all to keep on topic ... i just don't want to spend my life exchanging information with a computer ... despite the fact that we work with that, we are all human ...

Instead with kdesvn you just take care of the italian tree, you have the tree in your hard-drive, the it.po files are in their own folders, you can't make any mistake.

 

lets just not go this way ...we all knoiw we are able to do mystakes ! and what is the différence if you have all languages in your three or just get your languages po from websvn and send them back either with svn write access or by mail ...

Eventually there's no need to have language domains, we can mirror the structure of the main server and put only the xx.po files for which we have a team.

 

 so eventually we only need to keep the data structure of the package and keep on david's proposal and get back to basics

This just if we want a buffer between the contributors and the main server. As I wrote, whenever the main server maintainers have updated it with the updated po files in google, they would clear the respective directory in google.

the buffer doesn't need to be on svn, since websvn can distibute tarballs ! there is no clearance required ... so less hassle !

I can spend more words if it's not clear yet. I haven't read all you're replies yet. I'm going to do it. In case, I'll add something.

i thin,k you made it pretty clear but i think we don't speak about the same things ...

i'm asking why 2 servers ?
every single point you just drawn gives means of using a second svn but not reason to have two !

do we need two ... isn't one enough?

can't we keep it simple and think that we are not as skilled as david, you (and eventually i ) are !

[David Smid]

Ramboz Pierre-Henri napsal(a):

> no open source project has more than 3/4 commiters to the svn ...

That's nonsense. What about KDE, Linux kernel and many others ?

> the buffer doesn't need to be on svn, since websvn can distibute
> tarballs ! there is no clearance required ... so less hassle !

But SVN is so comfortable and easy to work with ! It just can beat that.
Plus you will have complete history about who changed what.

> i'm asking why 2 servers ?
> every single point you just drawn gives means of using a second svn but
> not reason to have two !

The only reason I can think of is to have different users on the main SVN (only
few people) and different users on the buffer SVN (every language team leader).

David

[Alessio Adamo]

2008/10/17 David Smid <da...@smidovi.eu>

Ramboz Pierre-Henri napsal(a):

> i'm asking why 2 servers ?

> every single point you just drawn gives means of using a second svn but
> not reason to have two !

The only reason I can think of is to have different users on the main SVN (only
few people) and different users on the buffer SVN (every language team leader).

David

I hadn't used a proper language, maybe. I meant specifically two SVNs (ipclinuxos and google code, which, by the way, happen to be onto different servers).

[Ramboz Pierre-Henri]

2008/10/17 Alessio Adamo <alessi...@gmail.com>

I've discovered we got more space on google...

To summarise the positions:

didouph proposes that only him and David should have access to ipclinuxos svn and that files should be submitted by e-mail to have a buffer between contributors and ipclinuxos

not david and i but anyone willing to carry on this task

David proposes that all team leaders should be able to access ipclinuxos svn and directly commit what they want.

I was in the middle. When I still didn't know that google could increase our space, I suggested this way to use our small google space. Instead of sending emails, which I personally hate (I totally agree with David), let's make use of google space. All team leaders would access it and would have their own language domain, with a replica of the ipclinuxos folder structure.

please ... do you want a mirror of ipclinuxos structure or a domain organised structure ?
its not clear !

The italian team can't work as a team with emails. I remember when I was submitting something which didn't go into the CVS for weeks (in some cases never) which made completely lose track of which version I had sent. I thought that our google space could be our work in progress space. Everybody else in the team could see the progress on a daily basis or even hourly. Can you imagine sending 1 email every day? Like that ipcilinuxos maintainers would get crazy! And then you need to explain this it.po file goes to drakconf/, this other to printerdrake/.

you need a ftp for that and you need to exchange with your team and communication is the key!
sending a file either byè e.mail or by svn isn't a good solution to get people informed about what you did or modiffied ... its "consistancy" and "methodology" exchange information with your team and you'll never get lost ... work on you side, silently and you won't get what is going on and get lost in translation between files and revisions.

Using google as a buffer, every team leader can commit the files they are concerned with, whenever they want. This simplifies the team work management.
It also makes it easier for ipclinuxos maintainers. Sorting out emails I don't think is more efficient. Once the files in ipclinuxos have been updated with the files in google, these would be cleared out. That's the sign: if you don't find a file in google, that means that in ipclinuxos you have the most updated version.

one repo is enough and reffering to a computer to check if you are working on the latest version of a file is simply not a good method. a good workflow would recommand that you inform the team of the change you've made, then submit those changes for validation and then commit those changes for testing then for release ...

since we do the release as rpm... we do the developement releases aka testing from the svn ... if you get the file from svn, its valid for you are suposed to have worked on it within your team !

Moreover, if team leaders are able to commit to google whenever they want, you can have a better idea of the degree of activity of their team just by having a look at the change tracking. There's even the option to be informed by email of any change.

i personally have several files that i never released to the svn or cvs as a reaction to texstar's policy and to prevent the release of an international dvd containing such files if we don't get at least a little respect from the gang and the minimal information we deserve to do a good job. Can the svn activity monitor tell you that ? sure it can't! that's why such communication is important.

As I said, I thought of this when I didn't kwnow that google would increase our space, but I think it's the best option between two needs: the need of safety expressed in didouph position;
the need of shared responsibility and efficient team working expressed by David.

If you (=everybody else) see my proposal pointless, than my vote goes to David's one. emails are just the opposite of what we need.

i do think e.mail is just a complementary thing and a way to prevent (since at the very moment commitment to the svn might be performed by 90% of team member so it will be a privilege to be restricte in access to svn) lack of communication wich made people think we were dead ! even i think that 90% of team members are not even aware about what is going on ... the e.mail way of working has proven being efficient for small team management and a 500meg svn repo for teams is onlmy a short term solution ...

i really do think that all team must be unified in one very project and not to scatter all around or we won't get far ... i mean once the svn is set up and the teams are working who knows what they are up to ... who knows if they work on 1 or 5 files, who knows if the files are going to be committed back before next update ? many questions that the double svn would definately prevent to find an answer to since those will definately isolate each team in its own realm ...

DidouPh

[Ramboz Pierre-Henri]

much simpler and clearer but you exposed my view ...

the old cvs was easyer to browse for each team but a pain in the neck for packagers !

[Ramboz Pierre-Henri]

by servers i ment svn servers !

2008/10/17 Alessio Adamo <alessi...@gmail.com>

[Alessio Adamo]

2008/10/17 David Smid <da...@smidovi.eu>

 I know. We'll better discuss this with the devs. Gettinther wasn't so enthusiastic about your language pack idea. I have myself some concerns (as you know). And if to implement it we are just forced to build our own testing repo, I think it's much better to simply rebuild the rpms with updated po files.

[Alessio Adamo]

This message refers to what?

2008/10/17 Ramboz Pierre-Henri <did...@gmail.com>

[Ramboz Pierre-Henri]

2008/10/17 David Smid <da...@smidovi.eu>

Ramboz Pierre-Henri napsal(a):

> no open source project has more than 3/4 commiters to the svn ...

That's nonsense. What about KDE, Linux kernel and many others ?

please ... its a matter of size too ... and trust is related to achievement in that very domain ... lets also not go this way ... i know i can be rude but i think that statements could be accepted for what they are ands we should compare what can be compared ... we are nothing in size and activity compared to the projects you mentioned !

a good example of multi svn is windows and the multiple delay between commitment end up in "human" errors

> the buffer doesn't need to be on svn, since websvn can distibute
> tarballs ! there is no clearance required ... so less hassle !

But SVN is so comfortable and easy to work with ! It just can beat that.
Plus you will have complete history about who changed what.

why two ?

> i'm asking why 2 servers ?
> every single point you just drawn gives means of using a second svn but
> not reason to have two !

The only reason I can think of is to have different users on the main SVN (only
few people) and different users on the buffer SVN (every language team leader).

David

the point is not can we think of one ... but do we need one ?

[Ramboz Pierre-Henri]

2008/10/17 Alessio Adamo <alessi...@gmail.com>

2008/10/17 David Smid <da...@smidovi.eu>

Alessio Adamo napsal(a):

> Last message.
>
> I think the tree has to be organized by package name. In addition, the
> po files must be in the same folder they would be inside the tarball. It
> makes easier their implementation into mainstream packages by the devs.

That would break our ability to easily build our l10n RPMs.
All the tools and Makefiles would become useless.

David

 I know. We'll better discuss this with the devs. Gettinther wasn't so enthusiastic about your language pack idea. I have myself some concerns (as you know).

so how are we going to release ?

are you talking about the monolitic solution or multiple rpm solution ?
 

And if to implement it we are just forced to build our own testing repo, I think it's much better to simply rebuild the rpms with updated po files.

i do agree ... but do we have the time to do the work twice ... package will be released once without i18n support and then with it ?

aren't we wasting time and drifting off the tool discussion ?

 

[Ramboz Pierre-Henri]

2008/10/17 Alessio Adamo <alessi...@gmail.com>

sorry ... to this :

[Alessio Adamo]

2008/10/17 Ramboz Pierre-Henri <did...@gmail.com>

please ... do you want a mirror of ipclinuxos structure or a domain organised structure ?

its not clear !

imagine to do

mkdir google_code/it
cd ipclinuxos/
cp -a * google_code/it

with the only difference that you copy just the it.po files.
 

you need a ftp for that and you need to exchange with your team and communication is the key!

sending a file either byè e.mail or by svn isn't a good solution to get people informed about what you did or modiffied ... its "consistancy" and "methodology" exchange information with your team and you'll never get lost ... work on you side, silently and you won't get what is going on and get lost in translation between files and revisions.

We have 500 MB for nothing, why should we set up an ftp server which even doesn't keep track of changes. Let's find some use for them!
For sure we need communication and emails are good for that, not for exchanging files. The problem of our team is not lack of communication, is lack of perspectives.
Sending stuff by email, in addition, can quickly eat up our mailing list space, which is still 100 MB. We also have an attachment limit of 10 MB. We would just create a new issue where there wasn't.

one repo is enough and reffering to a computer to check if you are working on the latest version of a file is simply not a good method. a good workflow would recommand that you inform the team of the change you've made, then submit those changes for validation and then commit those changes for testing then for release ...

I'm missing this point. SVN tells you everything. And you can comment any change.

[Alessio Adamo]

2008/10/17 Ramboz Pierre-Henri <did...@gmail.com>

aren't we wasting time and drifting off the tool discussion ?

You're right.

Since I've a deadline on Wed, I'll be probably off for some days. So, guys, don't think I'm rude if I don't reply.

;-)

[David Smid]

Alessio Adamo napsal(a):
> 2008/10/17 David Smid <da...@smidovi.eu>

> That would break our ability to easily build our l10n RPMs.
> All the tools and Makefiles would become useless.
>
> David
>
>
> I know. We'll better discuss this with the devs. Gettinther wasn't so
> enthusiastic about your language pack idea. I have myself some concerns
> (as you know). And if to implement it we are just forced to build our
> own testing repo, I think it's much better to simply rebuild the rpms
> with updated po files.

I think you've noticed we tried to discuss it with them but the
discussion was postponed.
We (me and DidouPH) decided that we must be prepared for any outcome of
that discussion and therefore we will establish an experimental l10n RPM
repository on ipclinuxos.com. Just to be prepared. It should be our
proof-of-concept.

David

[Alessio Adamo]

That's a good move and with your tools it should be a piece of cake. Just beware of the exceptions (for instance bootsplash.mo goes somewhere in /etc if I recall correctly). Those might need some makeup of the scripts.

I'm looking forward to testing our repo.

2008/10/17 David Smid <da...@smidovi.eu>

[Ramboz Pierre-Henri]

2008/10/17 Alessio Adamo <alessi...@gmail.com>

2008/10/17 Ramboz Pierre-Henri <did...@gmail.com>

please ... do you want a mirror of ipclinuxos structure or a domain organised structure ?

its not clear !

imagine to do

mkdir google_code/it
cd ipclinuxos/
cp -a * google_code/it

with the only difference that you copy just the it.po files.

why the hell two svns are needed ?

 

you need a ftp for that and you need to exchange with your team and communication is the key!

sending a file either byè e.mail or by svn isn't a good solution to get people informed about what you did or modiffied ... its "consistancy" and "methodology" exchange information with your team and you'll never get lost ... work on you side, silently and you won't get what is going on and get lost in translation between files and revisions.

We have 500 MB for nothing, why should we set up an ftp server which even doesn't keep track of changes. Let's find some use for them!
For sure we need communication and emails are good for that, not for exchanging files. The problem of our team is not lack of communication, is lack of perspectives.

consider my svn is out of the equation...
also remember that the guy who asked for 5 time increase in size on Google code is ... me !
why would we have two organisation?
 

Sending stuff by email, in addition, can quickly eat up our mailing list space, which is still 100 MB. We also have an attachment limit of 10 MB. We would just create a new issue where there wasn't.

please ... just don't create issues where theire is none ... if you need storage space i can also set up one on my server !

one repo is enough and reffering to a computer to check if you are working on the latest version of a file is simply not a good method. a good workflow would recommand that you inform the team of the change you've made, then submit those changes for validation and then commit those changes for testing then for release ...

I'm missing this point. SVN tells you everything. And you can comment any change.

of course it tels you everything but you need to ask it ... it won't come and tell you


TO all

guys ... this is getting plain stupid ...

my server is no loguer open for use by i18n team ...
its not a punishment, just a way to make things clear !

i just need to know how are we going to work !
i'm not here to argue on what should be put or not and written in what color.
i guess we are all adults and all have methods that fits our need and likeness ...

i personally didn't liked the berlios way and neither do i like the previous one ... i'm always open for discussion but if we all stand still on our positions we wxill go nowhere ... so from now on ... consider suibmitting proposal rather than argument ... i spent enough time explaining you what is possible and what is not. what is reasaonable and what is not

doing commit to two servers is pointless and with no real reason since
1 / all the files to build the release might be on both server
2 / the second server will only host the release files/identical to the srpm ...

so its a waste of time and space... admins are useless and just don't check anything and even if they check they check things that are yet checked and that they only can validate on a "technical" basis and not on a "useability" and "consistant" basis ...

i won't take part in a project where people don't listen to one another ... we yet reached about 32 message and nothing good came out of it

so now
we have google code and the list ... topic closed ... i'm sorry but i won't administer a mess

forget about indépendent svn server
forget about ipclinuxos on dedicated space
forget about the rpm repo on this server
forget about ftp access to this repo
forget about a home hosted wiki or blog on the same domain

we have the tools we had a week ago with 500 more megs ... lets keep all acting with no coordination !

do you want to try launchpad ?
i can give you my login to access it !

[Alessio Adamo]

The bloody second svn is needed to avoid the use of the bloody emails to submit files and at the same time to preserve a privileged access to the first one. I was trying to mediate between your position and David's position. If this is too complicated, as I said, I'm with David.

You must accept that somebody might not see things in your very same way. Discussion is pointless if you act like "do as I want, or nothing". This is a childish behaviour. I will accept whatever it will be decided, I'm not going to say: "do as I want or I won't help anymore" or stuff like that.

When I mentioned that I prefer a public server, it was exactly to avoid things like this. One day one person wakes up and decides: I'm fed up with you and you can f... off my server. This is something I don't understand but happens all the time. In this very case it took less than 24 h. It must go to Guinness of records.

Don't ask for opinions if you're not able to accept them.

So let's use google and that's it. Anyway it seems that your server was already out of the equation. So I don't know what we were talking about for so many messages, and I don't know why we should forget about it if it was already out of the equation.

PS. No bad feelings on my side, just disappointment.

2008/10/17 Ramboz Pierre-Henri <did...@gmail.com>

[Ramboz Pierre-Henri]

i've sent an uncensored and personal version of this post to alessio

please all read the initial post ... in this discussion

Then consider apointing someone to get the keys ... i'm out if we start adressing one another this way !
the keys mean :

google code / list admin
berlios admin
launchpad project admin

let me just remember you that i am the one who proposed the move to google code and groups
since many complain have been filled about spam and lack of flexibility from those ... i kept on trying to set up a third party proposal as a proof of concept... just an example ... a test ...

as i said it before if you want two svn i don't care, i just want a good reason for that ... a GOOD one, no t just one that fits one needs or mine ... just something WE david, alessio, i ... and of course the other !
not just one or two of us ...

it would be easy to set up tools as i wish andf let you cope with it as you wish
it would be so easy to let the project crumble into ashes by doing nothing
it would be quite easy too to give everyone what he requires ...

the lates few days gave birth to anarchy in this project, maybe thanks to my way of dropping things like bombs and see what happens ... but usually people at least notice where the bomb comes from and where they fall

at the very moment ... i recommand you all, unless you want to see this project collapse, to fall back on your sit and relax.

we have achieved nothing yet and look at the lack of organisation we show !

we have no plan of action ( clear )
we have no coordination ( no leader )
we have no discussion ( fight )
we have nothing fuctional ... why would my personal services go beyond the "testing point"

if santa team had been acting the way we did, they wouldn't be using my repo at the very moment... they formulated a request and i answered to it ... end of topic ... total mail exchanged : 5

33 mails to end in swear and personnal agression ... for a svn server test ... and noone asked how it was accessible ... WHAT a test ! thats team work ...

so maybe my words are hard but is the topic of this group and post about the domination of one over the other or the tools setup for a good teamwork in translation of a distribution

i yet mentioned several times that the answers were offtopic ... but accepted to answer them.

the "tech guy" here is David. he's the most advanced in developement and packaging ... so his opinion on server organisation prevail over anyone else but isn't the "Only".

my personal point of view, only few of you knows it ... and its not close to what you've read here ... if i was to do think my way, we wouldn't be discussing but releasing the fruit of our work

every single of us have personal opinions and wishes ... we can't get everyone happy ... at the very moment noone is and that's why i proposed my server ... noone is still so i remove it and myself too because my very opinion is that i am the problem ...

DidouPh

[Ramboz Pierre-Henri]

ok alessio and david have been apointed both as leader of the i18n projects on google code and google groups
since david is yet known as admin on berlios ... all i have to say is ... just ask if you need some translation or some packaging coding! i'll be happy to work on translation of pclinuxos.

DidouPh

[Zoltan Hoppar]

Well, I would like to say, I (we) just want to commit, but without leading / information - hard to do it. I translate quite some projects, also in launchpad - but never met such problems. I have accepted DidouPh leading, he was with the teams from start. I know, there are lot of work, and hard translation times are in it, but we want to have localized i18n pclos, right? For that, DidouPh has made wiki, berlios, and much of things that worked mostly - but worked. For all the hard work, and for the long time that spended with us as a i18n leader - we would like to thank you all the efforts Ph. But also thanks for david and for the others for helping us.
Shutting down this project - is sad thing. But... Anyway - please, anybody - if you know the way to get back on track, with all of the teams, and controll, and files - say the clear method, we will be there. Just dont let sink an great project...

So.... But, I think for the beginning were enough Berlios. But as more and more teams are came in picture - then it were much harder, and harder to look at it trough. I think we have grown out, and if we need more supported languages, then we need more control, help and easy accessibility.
There are not much trackers are outside were you have for your own lang so much support as in launchpad.
By the way, I say, I think we need SVN though, an google code with 500 megs, and launchpad as a frontend. Why and how?
Think about it, just theoretical on this vision:

- Launchpad offers great translation tools, and great help, tracking, aso. Good for the teams, and who willing just translate. PO-s if its are correct, can be anytime rpm'ed - and pulled to SVN for testing. We have time....
- Google code (*or google docs), is good for documentation, texts, backups, translating - spec files, docs, html pages, and much more. And all if its translated, or made could be pulled down as rpm, or tgz for testing to SVN.
- SVN, where i think only one enough it could store all of the alredy translated and zipped stuff, and tested before the ripper gang touching it / and we or our main leader releasing it.

Lets say - follow one PO road - translators are working in groups on the uploaded po/ts on the pclinuxos i18n project. If one PO is ready, the it could be tried out directly if you askin launchpad for get in mo - for example. Everybody can work with it, and its followable wich team where, and whats doing. If one group finishing, it could be pulled for get rpmed by santa into the SVN. If its tested by the team, the we mark releseable for the ripper gang - they pulling over, and we becoming happy people later....
 On googe code - we need that for preparing other things, and store here backups, translation tools, docs, extracted spec files - converted ones to po's - what is translatable on launchpad.

One more thing. I know, this is too big for one leader. But DidouPh has been with us translators, David can handle the SVN(our berlios or ipclos), Alessio is maybe good for leading keeping google code.....

Sounds crazy, or cool?

Zoltan

2008/10/18 Ramboz Pierre-Henri <did...@gmail.com>

[Alessio Adamo]

Maybe it's your way to communicate, but I felt it unnecessarily aggressive and I felt treated like a stupid. You're still asking me why we should have 2 svn and I've explained this so many times, I'm frankly exhausted. Read you're first post. You were the first proposing to use two svn! One for translations and one for side things.

David said it's better to have everything together and he's against emails as a way to submit commits. Since I agree with him, and since you're in favour of limiting SVN access, I proposed a way to make use of that google svn. And you keep asking me why two svn. You mean why svn and not ftp, http, messenger or skype? I say svn because we have it already and if it's used by all translation teams there must be a reason. Instead of using emails we would use that space, for which each team leader can have adiministrator access. It would be like a /tmp folder. How was it before? A po was sent by email, it was stored on the administrator's hard disk for a while and then it was uploaded to cvs. Now it would be like a po is uploaded to the tmp svn. After 5 minutes the contributor discovers a mistake (it happened to me many times). He doesn't have to send another mail and apologize, he just updates the po in the tmp svn. Maybe the administrator is busy and has no time to upload it to final svn. He can still work on it with the team and update it. The administrator doesn't have to sort out tens of emails after he comes from a holiday (let's be optimistic and imagine there are many teams working actively), when he decides to update the main svn, he takes whatever he finds in /tmp, update the main svn and delete everything but the directory three in /tmp. Since the /tmp svn has the same directory tree as the main svn it's easier to maintain than single emails with single po files.
You can either have the identical directory tree or have it inside replicated into language domains. It's so much different from our old cvs structure! But you keep telling me "the svn organisation as you introduced it isn't a good and practical option and is just a mimic of the current cvs on berlios wich has been a mess". How is it possible? The difference is so evident! Copying from

/languageX/packageX/po/X.po
/languageX/packageX/po/Y.po
/languageX/packageX/po/Z.po
/languageX/packageY/po/X.po
/languageX/packageY/po/Y.po
/languageX/packageY/po/Z.po
...

to

/packageX/po/X.po
/packageX/po/Y.po
/packageX/po/Z.po
/packageY/po/X.po
/packageY/po/Y.po
/packageY/po/Z.po
.....

is nothing but like copying from:

/languageX/packageX/packageX.po
/languageX/packageY/packageY.po
/languageX/packageZ/packageZ.po
/languageY/packageX/packageX.po
/languageY/packageY/packageY.po
/languageY/packageZ/packageZ.po

You need one instruction for the first, a complicated script for the second. I don't understand why with emails it would be more practical. And I even said we could not even use language domains, so I don't understand why insisting on this point.

I said this double svn organization is a good trade off between a shared administration and a restricted administration. I'm not in love with this idea, anything similar is fine, but not a single administrator mode. If my suggestion is discarded than I vote for a shared administration. I want people to learn as much as possible. Ideally everybody should be able to substitute everybody else. To achieve this, though, we should delegate stuff whenever it's possible. Using a tmp svn would even make it safer.

What does it mean "let me just remember you that i am the one who proposed the move to google code and groups"? So what? I'm missing something here.

The main point is shared administration or not? There are two votes for shared and one for restricted. Do you think the discussion is closed? You dropped everything even before coming to a conclusion. What kind of behaviour is that? If I had to insist repeating the same things, it was because apparently they weren't clear. It took one post for David to understand my position, but I'm keen on making it clear for everybody.

This is my last. My position on this I think is now perfectly clear. If not I don't care, I won't spend any more words. I vote for shared administration on an svn. Let's discuss something else.

You asked for opinions and I gave you. Why should you get upset?

2008/10/18 Ramboz Pierre-Henri <did...@gmail.com>

[Alessio Adamo]

Errata corrige:

Actually the structure of our cvs is like:

po/languageX/packageX.po

po/languageX/packageY.po
po/languageX/packageZ.po
po/languageY/packageX.po
po/languageY/packageY.po
po/languageY/packageZ.po

2008/10/18 Alessio Adamo <alessi...@gmail.com>

[devnet]

I've tried to keep up on everything and there really isn't any reason
to have more than one repository...because you can have multiple
branches of simultaneous development.

What is 'best of practice' in a corporate software engineering
environment is to have testing, devel, and main repositories. When
you get ready to bring main to the next version, you merge devel into
main. Testing is where all the crap is committed. Testing mergest
into devel (weekly if possible).

So, you give people full commit access to testing. If it is messed
up, you revert changesets back and then merge into devel to when
stable. Then let people go nuts on testing again. You make testing
be your volitale environment and only promote stability (or
semi-stability) into devel.

In this way, can give anyone commit access...but only let people
commit to a single testing repo. No merge or promote access should be
given outside of 2-3 people...they manage the workflow of the software
through testing, devel, and main.

We used Mercurial at rPath and I had to navigate through around 20-30
different repositories and one thing was certain...they all had
testing, devel, and main for their branch structure. Having 2
repositories is fine for proof of concept :) But we only really need
one to accomplish what we need to accomplish.

Just my 2 cents.