Re: ImpressCMS IRC channel

Suggestion:

Add the PJIRC applet here. It's open-source, and provides access to IRC without the need for an installed IRC client application.

Topic | Forum


Re: A proposition for a true opened developement !

  • 2007/12/10 10:40:43
  • Tom

Are we entertaining the idea of a dev.impress gforge, svn type site, I mentioned something similar before and I know James brought up some possible complications, but would this not be an idea for people to work openly.

Or is this a bad idea?

Topic | Forum


Re: german files in SVN?

Sudhaker also developed somethig about this last year.

Sudhaker, can you give your input here ?

Marc-André Lanciault
Founder and CEO INBOX International inc.
Co-Founder ImpressCMS


Re: A proposition for a true opened developement !

Quote:

People can simply pick combination of followings and hit build.


Awesome !

And I'm sure there are other great things we could do because of centralized code that we still ignore.

Marc-André Lanciault
Founder and CEO INBOX International inc.
Co-Founder ImpressCMS


Re: ImpressCMS IRC channel

Okay, since only three people turned up (as far as I can see) in the irc channel, may I bring it once again to your attention.

Gatherings on Irc channels is something communities (big and small, software, game or whatever community) really love to do because it's a quick way to get answers fast without mis-using a forum. (Alot of small questions can be answered that aren't forum "worthy".) And, it's a way to just meet and chat with all the others that are interested in ICMS, which is well,.,.uhh fun^^



Re: german files in SVN?

There is a language tool module for xoops. Currently is doesnt handle different encodings :(
What do you think about an on-line translation system, I have to browse some ot such solutions.



Re: A proposition for a true opened developement !

Great idea Marcan.

We should prepare set of "Subversion HOWTOs" videos / tutorials for different crowd. Anyone touching the code should go through this training.

I see another possible advantage of proposed centralization - "dynamic build process".

People can simply pick combination of followings and hit build.

* core
* core-hacks
* languages
* modules
* cloned modules
* themes
* editors

We can do this only if we have them at some central location i.e. our SVN.

Thanks,



Re: International (local?) support

Hello, first post here, it seems I'm a tester of iCMS :)

I fully agree with herko, having centralised local support sites is very convenient. I think duting the growing of iCMS more countries will want to join and support it. As a xoops.pl we would like to support both: XOOPS and iCMS. I'm aware there is a long way for iCMS to became a popular script.



Re: A proposition for a true opened developement !

I agree that SVN as a learning curve but it is not that difficult.

But anyway, there is nothing that will stop anyone to get the latest language files, make correction and send it as a patch on SF so someone else understanding SVN can commit it.

Quote:

otherwise, this project is turning into a developers only project again, which isn't truly open IMHO.



Language files, like themes and like module, are part of the code, so yes, it is related to developers but it does not need to be done by a developer...

I believe it makes sens that all code is centralised in the same place. But we need to put mechanism in place so that anyone can contribute without knowing code or SVN. Anyone can submit a patch to the tracker...

Marc-André Lanciault
Founder and CEO INBOX International inc.
Co-Founder ImpressCMS


Welcome Kurak !

We'd like to welcome another newcomer to the ICMS ranks: Kurak.

Kurak is a regular contributor to the XOOPS Wiki and other projects - and has offered his support in helping beta-test the releases as they are made.

Welcome in my friend !



Welcome Sudhaker !

A warm welcome to another great developer who has now joined our project : Sudhaker Raj !

Welcome my friend !



Re: A proposition for a true opened developement !

  • 2007/12/10 9:13:42
  • herko

Like I said in another post: SVN has a learning curve and requires specialised tools. Making a translation only requires a text editor. If there is a simple way to add and check language files, then I'd be ok with it. otherwise, this project is turning into a developers only project again, which isn't truly open IMHO.

Herko

Tomorrow never comes until it's too late




Re: A proposition for a true opened developement !

It's a great idea - but scarey!

But I would suggest one change:

Have a "Live" branch which is the one where any issues and so forth are correct... and the "development" branch which any can contribute to.

The "Live" would always be a few days behind the "development" in order for errors to be reported and acted on...



A proposition for a true opened developement !

Sato-san brought the subject of the language files in another post, and it made me think about this.

I would like to see a lot more "integration" and "centralization" of code in the ImpressCMS project. I would like to see "more things" in "1 place" then everything spread around the internet.

In that regards, I would like to see the languages files as well as modules and themes all centralized in one location. Ideally SVN. But I know this would be a big change from the "XOOPS" way as it would require many people to have commit acces on SVN.

This might scare some people but not me. With SVN it is very easy to revert anything that needs to. So I do not see real problems with this...

And the more people we have on the SVN, the more quickly bugs will naturally be fixed.

So my suggestion would be to have new folders in our SVN :

- Languages
- Modules
- Themes

Then we provide everyone who requests it with commit access to our SVN so they can commit their modules, their language files, etc...

Maybe we need to think about the tree structure of our SVN, but the idea would be to have everything in one place, and give commit access to everyone who requests it.

A TRUE opened development. Everyone who wants to contribute will now be able to do so ! And if he does something very wrong, because we have many people using it, it will be reverted, fixed or improved quickly after.

Of course, we would have some mechanism to "eject" a user who is just playing dumb...

This would be a clear separation from the "XOOPS way", a clear statement of our true enforcement of our OPENED vision !

Now I know this will scare some of you, but let's discuss it



Rules to follow when using ImpressCMS SVN

Hi everyone, I would like to propose a few basic rules for all of us to follow when it comes to committing in the ImpressCMS SVN. This is a few rules I gattered from Dave_l post a few days ago.

1. Be informed of our discussions

Every developer need to stay informed of our discussions here. So we all need to make a commitment of reading everything that is posted on the Current and Future release forums. It is the only way we can all work together towards the same goal, and bringing synergy in our efforts.

2. Documenting our code

That means that every function has a phpDocumentor-compliant header comment, which is both correct and understandable, states the purpose of the function and describes the parameters and return value.

The same applies to class properties. The header comment for a function (or a class) is intended to be a "mini user manual" for the function that provides all the information needed to call that function, without having to examine the body of the function.

3. Use our trackers for nearly everything

Use the ImpressCMS trackers for everything you do. Bugs, Features, Tasks, everything.

For example, adding the Multilanguage features needs to have a task related. Same thing for the security audit or the removal of the XOOPS word all around.

4. Create 2-ways links

Create as many two-way links between Subversion changesets and ImpressCMS trackers as possible:

- In your commit message, refer to the tracker item ID.

- When you edit the tracker item on SourceForge, refer to the revision number of your commit in th SVN.

5. Commit logical changesets

When you commit a change to the repository, make sure your change reflects a single purpose: the fixing of a specific bug, the addition of a new feature, or some particular task. Your commit will create a new revision number which can forever be used as a "name" for the change.

6. About branching

We will use the "Branch-when-needed" system :

- Users commit their day-to-day work on /trunk.

- Rule #1: /trunk must compile and pass regression tests at all times. Committers who violate this rule are publically humiliated.

- Rule #2: a single commit (changeset) must not be so large so as to discourage peer-review.

- Rule #3: if rules #1 and #2 come into conflict (i.e. it's impossible to make a series of small commits without disrupting the trunk), then the user should create a branch and commit a series of smaller changesets there. This allows peer-review without disrupting the stability of /trunk.

Thoughts ?



Remember me

There are number of hacks for "remember me" feature. Most famous is by GIJOE.

Can we extend this feature to have something what LinkedIn (and many other sites) already using.

* Once you login, you should have full access until session timeouts.
* After timeout, you have read-only access to your allowed contents.
* It prompts to login again if you want to do something transactional - say submit post.

Can we have built into new CORE?

Thanks,



Re: Using the trackers to document changes in the SVN

Ok good, we have started to use it. I saw others here have started to use it and I'm very glad !

Please document as much as possible everything you do with the tracker.

I also have another request. When one fixed a bug documented in the bug tracker, when you close the bug item, please post a message to document what you did, something like :
Quote:

Fixed and committed, revision XX


Where XX us the revision number associated with your changes.

And of course, in your commit message, you would have written something like :
Quote:

Fixing bug #12346 by implementing blablabla


That way, the bug and the fix are linked in 2 ways.

Any objection ?

Thanks !

Marc-André Lanciault
Founder and CEO INBOX International inc.
Co-Founder ImpressCMS


Re: Auditing Code (security wise)

  • 2007/12/10 5:46:00
  • herko

Should we also review where queryf is used in key modules, as this is often misused by developers who want a quick way to access core tables.

Herko



Re: GoPHP5

and what about mysql5 too?

but in particular mysql5 has some functions that could be utilised (if used correctly, and that input is validated and sanitized before hand)

especially as mysql5 is able to use multiple queries in 1 session whereas mysql4 can only accept single queries at 1 time.. it could speed things up if multiple query ability is introduced.

I see someone has worked on adding mysqli support too, so even with mysqli, multiple queries can be utilised by the function mysqli_multi_query() instead of mysqli_query().

certainly something to look at tho either way.

Live as if you were to die tomorrow, Learn as if you were to live forever

The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!