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.

guiguibonbon · 2008-01-15 17:17:45

thebombsite wrote:

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.

What’s most surprising about this whole thing is the numbers of ‘oh yeah’ you get to read on irc. Everyone is using textpattern so much so often that it looks like everyone also seems to have very similar ideas about what should be next. Looks like everyone is annoyed by similar things, and everyone has occasional dreams of similar features.

I was surprised about how spot on your first reaction was, although you weren’t on the chat. While we were wondering how to summarize our lengthy discussions, you beat us to it. That’s another evidence.

I would not be surprised the devs would sooner or later feel similar excitement and join in. Perhaps the old “let’s just build upon Dean’s 7-years old code” has lasted a little too long. Maybe it’s time to see if other obvious routes could work out too. Many of which have been pre-explored with some plugins.

As Iblastoff said, no-one seems to be really longing for crockery. The light at the end of the tunnel seems very dim, the tunnel itself being very long to begin with.

All in all, something just needs to change about the way devs and community interact. As a community, and with the help of IRC, we can jump back on user feed-back (and our own for that matter) so much more quickly. There’s non-stop brainstorming, non-stop helping and encouraging each other. Two patches were sent in two days, initiated by talks on IRC.

I’d really encourage devs (and anyone who hasn’t) to join the channel to talk about this, or you cat, or your favorite band.

‘cause I have a feeling this thing will happen, well, is happening, actually, no matter what.

ruud · 2008-01-15 17:51: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. :)

Since the devs were asked about this, I assume the idea is to host this community SVN branch on dev.textpattern.com. If so, I think it’s only reasonably to ask which pro/cons you’ve already come up with yourselves to speed up the discussion.

Please post an IRC log here.

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.

How does this differ from checking out a local copy of the 4.0 branch, applying your own changes and submitting that as a patch to txp-dev?
That is something you’ll have to do anyway if you want to be able to commit changes to the community SVN branch. The difference is that on the community branch you have commit privileges, while on the 4.0/crockery branch you do not. The tried/tested part has to happen locally anyway before committing a patch, otherwise the community branch will be in a semi-permanent state of brokenness.

As for including stuff from the community branch into mainline TXP, I think that’s not so easy, especially if there’s a lot of activity in the community branch. The community branch would have to be kept in sync with TXP mainline and even so, pulling an individual patch from a community branch that contains a wide variety of patches that are entwined, seems non-trivial to me… but perhaps that’s because I’m not really an SVN expert.

hakjoon · 2008-01-15 18:22:43

ruud wrote:
As for including stuff from the community branch into mainline TXP, I think that’s not so easy, especially if there’s a lot of activity in the community branch. The community branch would have to be kept in sync with TXP mainline and even so, pulling an individual patch from a community branch that contains a wide variety of patches that are entwined, seems non-trivial to me… but perhaps that’s because I’m not really an SVN expert.

That’s why I recommended looking at Bazaar or Mercurial. Doing this with SVN is a pain, doing it with other systems not so much.

Using a Decentralized system, the main Bazaar repo is kept in sync with svn.textpattern.com. people can then build their changes in their own private branches which track the main bazaar repo (which tracks svn) Changes from those branches can then be cherry picked into the main bazaar trunk for occasional community releases or some such. If those changesa re deemed good they can be moved into a svn working copy and submitted as a patch. Since the Bazaar repo has been tracking the SVN repo most upstream changes are already incorporated decreasing merge pain.

Bazaar
Bazaar for SVN users

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

#13 2008-01-15 17:17:45

Re: Community driven SVN branch

#14 2008-01-15 17:51:32

Re: Community driven SVN branch

#15 2008-01-15 18:22:43

Re: Community driven SVN branch

Board footer