Community driven SVN branch

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

guiguibonbon · 2008-01-16 06:35:56

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?

There are a few. Firstly, it seems expected that patches submitted to the mailing list aught to be polished pieces of code. That’s ok for one community-member to manage when it’s a small patch. It’s a whole other matter if it’s something a bit more ambitious. Currently, the solution to something more ambitious is to simply suggest it in a forum post, to have very long discussions about it, to wait ages for dev’s opinions, and in the end the whole coding relies solely on the three of you who have your own, legitimate, priorities. Meaning it never happens. This is a solution to over-bridge that situation. To be able to work on patches as a community.

Another thing discussed on IRC is that many of us would find it very useful to enable and use the ticketing system on trac. It’s a much more convenient for both community and developers to interact than forums. Here’s for instance how it looks like when used by mootools.

guiguibonbon · 2008-01-16 06:43:15

To illustrate my point, just look at Manfre’s last patch re the setup folder. He just had an idea, didn’t have time to polish it, and submitted as a half baked thing to the mailing list. What he gets in response is : “nah, you didn’t think of that and that”. Solution dismissed or postponed. Had this been posted to a community svn, those “nah” would have turned into “how about this?”. It could already have made it to the main svn branch by now.

Last edited by guiguibonbon (2008-01-16 06:46:27)

Mary · 2008-01-16 13:05:25

First, about a community SVN branch

…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.

That is a fork.

these changes (some possibly major. like redoing the backend for one) are to be committed to the 4.0.x branch…
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).

The answer for major feature improvements/changes in dev/4.0.x is the same as it was before: no.

…I assume the idea is to host this community SVN branch on dev.textpattern.com.

I’m not interested in supporting users of that, so if that were to ever happen it would have to be private and not publicly available.

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.

Well-said.

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 the purpose of txp-dev, but if you want to leave that list for only “official patch submissions”, there’s nothing stopping you from setting up your own Google Group or something for that purpose. But seriously, I think you shouldn’t bother with your own SVN repo for that, but share patches back and forth. That’ll be far more practical and easier to manage.

My conclusion

It sounds like different people want it for vastly different reasons, which I think indicates that as it is, it would self-destruct as group because you don’t know what this mysterious entity would actually be. You gotta decide what it is you as a group want before you can assess if the group would be successful. Do you really want to “utilize a lot of underused energy”… to achieve nothing?

About the core developers

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.

FYI: Any time I’ve ever dropped in (most recently was a couple days ago), in all of Txp history, there several people, but no talking. I was very disappointed to see no steaminess when I last dropped by. ;)

Is it by other devs inviting them (which I think it is)…

It’s by the current team as a whole inviting that person to join.

…or should it be a community decision made amongst it’s respected members.

No. The majority of the respected community aren’t developers (unless you want to use that term in a very restrictive sense), so how can they possibly be qualified to make that kind of judgement? It’s not a popularity contest, and I would dearly hope it never becomes so.

To illustrate my point, just look at Manfre’s last patch re the setup folder. He just had an idea, didn’t have time to polish it, and submitted as a half baked thing to the mailing list. What he gets in response is : “nah, you didn’t think of that and that”. Solution dismissed or postponed. Had this been posted to a community svn, those “nah” would have turned into “how about this?”. It could already have made it to the main svn branch by now.

I suggest that people read the actual exchange rather than take sir’s word for that. You’re reading in attitude and snarkiness that isn’t there. I thought the point was “so the core team can see what happens and offer occasional advice and direction.” You can’t have it both ways: you either want our feedback or you don’t. Which is it? Developers shouldn’t need their hands held, and I am quite certain Manfre is mature enough to have not taken constructive and mild criticism in such a ~~childish~~ manner.

Last edited by Mary (2008-01-16 13:06:07)

guiguibonbon · 2008-01-16 13:34:18

I wrote:

To illustrate my point, just look at Manfre’s last patch re the setup folder. He just had an idea, didn’t have time to polish it, and submitted as a half baked thing to the mailing list. What he gets in response is : “nah, you didn’t think of that and that”. Solution dismissed or postponed. Had this been posted to a community svn, those “nah” would have turned into “how about this?”. It could already have made it to the main svn branch by now.

Mary wrote:

I suggest that people read the actual exchange rather than take sir’s word for that. You’re reading in attitude and snarkiness that isn’t there. […] I am quite certain Manfre is mature enough to have not taken constructive and mild criticism in such a ~~childish~~ manner.

FYI, I didn’t say the responses were not constructive or not mild. They very much were both. Ok, so I shouldn’t have added those “nah“s but it did come down to “you didn’t think of that and that”. And the solution being dismissed or postponed, probably because you have other things to work on. Here’s where a community effort could help the situation. Plus, there’s plain verbal miscommunication. You’re never clear about whether you plan or do not plan to work on something. Why not reply “hey, I like the idea, but it has some pitfalls, could you try to solve that” (meaning “I currently can’t”) OR “I’ll try to work on it. Unless you could send a solution ?”.

And that’s something I think is missing on the forum too. Don’t make false promises, but don’t constantly leave people in the blue, guessing, feeling useless.

Edited to add :

…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.

Mary wrote:

That is a fork).

Oh. So crockery is a fork too ?

Last edited by guiguibonbon (2008-01-16 14:08:52)

hakjoon · 2008-01-16 15:28:01

Mary wrote:
That is a fork

Technically if the work performed there was merged back into the mainline it really becomes a branch.

A kind of fork that is standard practice in many projects is a stable or release version, modified only for bug fixes, while a development tree develops new features. Such forks are often referred to instead as “branches” both to avoid the negative connotations of a fork and because it is closer in intent and function to the common software engineering meaning of branching.

Last edited by hakjoon (2008-01-16 15:31:42)

Manfre · 2008-01-16 15:59:25

For the record, I saw nothing wrong with the email exchange on the dev list, ~~except maybe wet responding to Ruud’s email and not my second one. We all don’t use threaded email clients, so no harm.~~ Note to self, double check to make sure you hit Reply to All.

Last edited by Manfre (2008-01-16 16:20:27)

TheEric · 2008-01-24 03:21:44

Community driven SVN? Nice idea, but in all reality it is a fork. Forks are good.

milkshake · 2008-01-25 15:00:42

Instead of umming and ahhing about it, why don’t we just try it and see how it goes?

Last edited by milkshake (2008-01-25 15:17:20)

jm · 2008-01-25 16:23:55

milkshake, see this

Textpattern CMS

Textpattern CMS support forum

#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

#16 2008-01-16 06:35:56

Re: Community driven SVN branch

#17 2008-01-16 06:43:15

Re: Community driven SVN branch

#18 2008-01-16 13:05:25

Re: Community driven SVN branch

First, about a community SVN branch

My conclusion

About the core developers

#19 2008-01-16 13:34:18

Re: Community driven SVN branch

#20 2008-01-16 15:28:01

Re: Community driven SVN branch

#21 2008-01-16 15:59:25

Re: Community driven SVN branch

#22 2008-01-24 03:21:44

Re: Community driven SVN branch

#23 2008-01-25 15:00:42

Re: Community driven SVN branch

#24 2008-01-25 16:23:55

Re: Community driven SVN branch

Board footer