Community driven SVN branch

hcgtv · 2008-01-14 18:34:47

Dear Devs,

The folks hanging out on IRC, came up with a novel idea – Let’s create a community driven SVN branch.

This new community branch would in no way affect the stable or crockery branches, it would just be a place for those that are not official devs to let off some coding steam.

The offshot of this would be twofold:

Community devs could one day be promoted to official status, thus bringing in more coding help.
Ideas implemented in the community branch could one day make their way towards the official branches, if they are proven to be secure and stable.

Discussing this on IRC, we came away with more advantages for the Textpattern community than any disadvantages that this may pose.

Thanks,
TxParty

ruud · 2008-01-14 21:10:51

The downside of IRC is that people who didn’t attend have no idea what was discussed. Can you post the advantages and disadvantages here as well?

As it stands, I vote “no”, because we don’t recommend using SVN revisions of TXP in production environments.

hakjoon · 2008-01-14 21:14:19

If this were to go forward, any thought on using something like Bazaar or Mercurial instead of SVN? The decentralized nature of those I think makes it easier for various devs to work on it at once without immediate commit access being given. It’s also easier for cherry picking changesets from various developer branches etc.

Launchpad would allow us to create a bazaar repo that tracked the main TXP svn repo. I’ve been thinking of doing it for a while now but wasn’t sure anyone would care.

Last edited by hakjoon (2008-01-14 21:15:01)

thebombsite · 2008-01-15 01:12:32

Not wanting to be in any way disrespectful here Ruud but none of us really get to know what the devs have discussed before they commit changes to the development branch and there’s a lot less of you than there are of us. And that is not meant to be in any way antagonistic. :)

With what is being proposed here a lot of us will be able to actually try out some ideas and discuss them before putting them up to the devs for possible/probable inclusion into the base code. A lot of that discussion could take place in the forum, maybe in a section of it’s own? Not to mention that the code will have already been tried, tested and written.

Last edited by ruud (2008-01-15 17:48:12)

guiguibonbon · 2008-01-15 02:25:56

thebombsite wrote:

With what is being proposed here a lot of us will be able to actually try out some ideas and discuss them before putting them up to the devs for possible/probable inclusion into the base code. A lot of that discussion could take place in the forum, maybe in a section of it’s own? Not to mention that the code will have already been tried, tested and written.

That’s exactly how I saw things too. The point is to have a more engaging discussion with the dev team regarding the future of textpattern. We would just be un-orthodoxly messing around with it. Time will tell if something releasable comes out of it or if parts could be merged with crockery.

Ruud wrote:

As it stands, I vote “no”, because we don’t recommend using SVN revisions of TXP in production environments.

I guess the above answers that already : neither would we.

mrdale · 2008-01-15 02:32:08

It’s really simple. There’s a whole lot of energy in this forum that is underutilized.

This is a way to channel this energy in a way that allows “what ifs” to be quickly explored without affecting the core, while also keeping those efforts close at hand so the core team can see what happens and offer occasional advice and direction.

I envision it as a positive way to speed up new features, new takes, etc by…

accepting and working on a lot of new ideas, that are based on real world needs
channeling a lot of coding resources at these ideas
channeling a lot of testing at these ideas
allowing those who are interested to play with core in a community setting.

If I worked for a small dev team, working on a big project with a growing userbase, I’d be overjoyed to have a group of talented coders interested in throwing their energies at our common goals. More testing. Quicker dev cycles. Methods I hadn’t considered. I’d be even more happy to have it happen close by where I could easily see what they’re coming up with, and discuss. But that’s me.

lee · 2008-01-15 08:24:07

I still think the official dev team needs to be increased so that more can get done in less time. How do devs get on the official team? is it by other devs inviting them (which I think it is), or should it be a community decision made amongst it’s respected members.

Bloke · 2008-01-15 09:48:36

mrdale wrote:

I envision it as a positive way to speed up new features, new takes.

I agree in principle as long as it’s a co-ordinated effort. I wasn’t in on the IRC channel so I don’t know what was discussed exactly; co-ordination may be implicit in the way SVN — or those tools Hakjoon suggested — work. I really should try and make time to set up a repo of my own to play with.

My only minor concern is that with a tonne of potential developers and a vast wealth of ideas it could very easily snowball and create incompatibilities or mods that are not possible to be brought back into the core/crockery because they rely on many other changes. Or a bunch of people all attempt the same thing at the same time and waste effort. “Too many cooks” and all that.

I suppose if a feature idea was decided upon, written against the current dev branch (or current SVN), tested to destruction, submitted as a patch and the codebase archived, potential incompatibilities could be minimised as well as maybe increasing the chances of a patch being accepted into core? Plus, the many ways of achieving the end goal could be pooled and refined until the most efficient solution was found without introducing bloat. The next community patch project could then start from the latest official SVN baseline if required, and so on… building patches on patches leads to the fork side :-p

Please correct me if I’ve misunderstood or I’m over-complicating it (as is my wont). Can someone who was present on IRC give a more detailed outcome of what was discussed please, or do mrdale’s/guiguibonbon’s/thebombsite’s posts sum it up already?

lee wrote:

I still think the official dev team needs to be increased so that more can get done in less time

Maybe, but a lean team is usually a more efficient team. Throwing resources at a problem is not always the best solution.

How do devs get on the official team? is it by other devs inviting them

I believe so. Certainly they are the best people to judge who in the community has the right mentality and team skills to bring real benefit to the core.

Like, I’d never be invited in a bajillion years because I’m too much of a loose cannon, don’t think a problem hard enough up-front, and don’t do things right [The TextPattern Way™]. To the community — on the surface as a plugin author — I look alright, but I’ve proved many times I’m a liability so it’s safer if the devs have the final say imho!

Last edited by Bloke (2008-01-15 09:50:11)

iblastoff · 2008-01-15 10:58:06

Bloke wrote:

My only minor concern is that with a tonne of potential developers and a vast wealth of ideas it could very easily snowball and create incompatibilities or mods that are not possible to be brought back into the core/crockery because they rely on many other changes. Or a bunch of people all attempt the same thing at the same time and waste effort. “Too many cooks” and all that.

I suppose if a feature idea was decided upon, written against the current dev branch (or current SVN), tested to destruction, submitted as a patch and the codebase archived, potential incompatibilities could be minimised as well as maybe increasing the chances of a patch being accepted into core? Plus, the many ways of achieving the end goal could be pooled and refined until the most efficient solution was found without introducing bloat. The next community patch project could then start from the latest official SVN baseline if required, and so on… building patches on patches leads to the fork side :-p

Please correct me if I’ve misunderstood or I’m over-complicating it (as is my wont). Can someone who was present on IRC give a more detailed outcome of what was discussed please, or do mrdale’s/guiguibonbon’s/thebombsite’s posts sum it up already?

although it’d be nice to bring certain changes that the irc group so far has proposed to the official 4.0.x/crockery codebase, i think the reality is this wily group formed specifically to be more lenient on the ‘don’t break plugins/no more major features’ rule thats currently in effect. these changes (some possibly major. like redoing the backend for one) are to be committed to the 4.0.x branch since i don’t think any of the irc folk are interested in crockery at all at this point.

since the official stance on 4.0.x is that its frozen and crockery being nowhere near complete, the chances of official/community merges are really going to be up to the devs. either way, i think this is a good move and i’m excited as to what may come of it.

Last edited by iblastoff (2008-01-15 10:58:43)

Bloke · 2008-01-15 11:14:52

Thanks for the clarification iblastoff. In that case, consider me duly excited too :-)

hcgtv · 2008-01-15 11:53:38

ruud wrote:

The downside of IRC is that people who didn’t attend have no idea what was discussed.

Hey, I’m in attendance and I have a hard time keeping up!

Can you post the advantages and disadvantages here as well?

The other posters to this thread have summed up the advantages pretty well, with Bloke playing devil’s advocate.

As it stands, I vote “no”, because we don’t recommend using SVN revisions of TXP in production environments.

Neither do we, but the branch could lead the way to a new release, just look towards eZ publish:

The nextgen_php5 repository contains a PHP 5 port of eZ Publish 3.9. It was started by the eZ Publish Community. eZ Systems has adopted the port and based on the initial work done by the community, they were able to release eZ Publish 4 in December 2007.

Thanks for hearing us out.

thebombsite · 2008-01-15 12:59:44

I wasn’t at the IRC meet , I was just picking up the idea and running with it.

I agree with some of what Bloke said. In particular the “community team” should concentrate on one thing at a time and once completed and tested the idea and code can be put to the devs for inclusion or otherwise. Dependent on that decision the “community SVN” can be synced to the newest “development SVN” and the next idea worked on. As Bloke suggests, if you build new code that relies on other new code it could soon become a mess or a fork. I’m not sure I want either.

Textpattern CMS

Textpattern CMS support forum

#1 2008-01-14 18:34:47

Community driven SVN branch

#2 2008-01-14 21:10:51

Re: Community driven SVN branch

#3 2008-01-14 21:14:19

Re: Community driven SVN branch

#4 2008-01-15 01:12:32

Re: Community driven SVN branch

#5 2008-01-15 02:25:56

Re: Community driven SVN branch

#6 2008-01-15 02:32:08

Re: Community driven SVN branch

#7 2008-01-15 08:24:07

Re: Community driven SVN branch

#8 2008-01-15 09:48:36

Re: Community driven SVN branch

#9 2008-01-15 10:58:06

Re: Community driven SVN branch

#10 2008-01-15 11:14:52

Re: Community driven SVN branch

#11 2008-01-15 11:53:38

Re: Community driven SVN branch

#12 2008-01-15 12:59:44

Re: Community driven SVN branch

Board footer