I have misunderestimated your strategery of utilising acclimating with young internpersons. I gather onboarding was only partially successful, with one left on the pier and the other been thrown a lifebuoy.
@Bleistivt I do, and every week I install the new master version and it breaks my plugins and I have to redo everything . I need a "stable point" to work from. That's why I am so impatient!
And no, I can't use 2.1 since some plugins I need, like the API plugin doesn't work in 2.1.
I know that asking for it once and again won't probably accelerate the process, and my intention is not to push you. I just want to communicate my vision as a newcomer, which is that 2.2 really needs to be released ASAV (as soon as viable), because as per now, Vanilla is in a very unstable place, with the 2.2 tags being way older than the 2.1 and deprecated; important plugins requiring 2.2+ and the current 2.2 (master branch) changing in a big way (or small but breaking stuff) every week. As a newcoming developer this is a really unfriendly environment to develop a REALLY big application around it, but, for some reason, I REALLY want to use Vanilla in my project.
@phreak said:
xDaizu: Wow, sounds like a love letter. Big application? Let us know.
At least, pi times better than a hate later!
Oh, you'll know. Eventually. Or at the very least, you'll see some plugins and themes coming as soon as we can start developing. (Well... actually a few weeks later, because, you know, development time...)
@xDaizu said:
Bleistivt I do, and every week I install the new master version and it breaks my plugins and I have to redo everything . I need a "stable point" to work from. That's why I am so impatient!
And no, I can't use 2.1 since some plugins I need, like the API plugin doesn't work in 2.1.
I know that asking for it once and again won't probably accelerate the process, and my intention is not to push you. I just want to communicate my vision as a newcomer, which is that 2.2 really needs to be released ASAV (as soon as viable), because as per now, Vanilla is in a very unstable place, with the 2.2 tags being way older than the 2.1 and deprecated; important plugins requiring 2.2+ and the current 2.2 (master branch) changing in a big way (or small but breaking stuff) every week. As a newcoming developer this is a really unfriendly environment to develop a REALLY big application around it, but, for some reason, I REALLY want to use Vanilla in my project.
I can sympathize with this. I recently imported from another platform, and in the process have been working on integrating some plugin features and whatnot in ways that please me. I quickly learned that I have no clue if master == stable in this case (or rather, it's not as stable as I'd normally expect a master branch to be). Plugins like the ProfileExtender don't work in 2.1.10, and there are simple patches mentioned in threads (which do fix it, but require you to manually change the plugin source), but they are patches that don't appear to be applied in GitHub, nor are there issues for them despite it being a known bug, which means either it's not being tracked, or the 2.1.x released version of the plugin is actually configured for 2.2. Either way, what? And then there's info that says it's actually being merged into the core, even though it's still included as a plugin in the repo and there don't seem to be issues logged for it. Master has code and plugins in it that aren't in the 2.1.10 release, but that appear to require 2.2 even though it's not released (Google+ logins come to mind, if you pull that off GitHub, it just breaks social logins on the platform).
I try to avoid asking too much of folks devoting their time to developing an open source project because I know it's a labor of love, and I don't want to tell them how to keep their house, but it makes it super challenging to solve your own problems and discourages community from helping and contributing back if it's not clear what the development methodology is. And the fact of the matter is, I might just be too used to how my teams use GitHub, which would totally be my problem, not theirs.
What I think would be AWESOME, is once 2.2 tags, if the Vanilla team started an apprenticeship/mentor program for the platform. I've seen this with other larger open source projects, where community members interested in helping with maintenance and development can spend time shadowing one of the core team members to learn the process and standards they use. That makes the entire community better then, while helping ensure the plugins and themes and such are meeting a standard (which is another confusing issue, when you see super old addons in the repo that are "verified," but haven't been touched in 3+ years).
@fienen good points well stated. I'm really hoping that the 2.2 release will put us in a position for open source & staff to work together a great deal more since our code bases will be back in sync for the first time in 4+ years. The 2.1 boondoggle of a release schedule really messed up a lot of the cross-benefits. 2.2 should also be the last long (years) gestation period for a release.
Speaking of which. These coding standards changes are now the last thing on my blockers list. We've fixed the spacing & inline doc formatting, now we're down to capitalization. This is import to finish before the fork so that we can backport fixes easily to 2.2 as needed without big merge conflicts.
@Linc said:
fienen good points well stated. I'm really hoping that the 2.2 release will put us in a position for open source & staff to work together a great deal more since our code bases will be back in sync for the first time in 4+ years. The 2.1 boondoggle of a release schedule really messed up a lot of the cross-benefits. 2.2 should also be the last long (years) gestation period for a release.
What does this mean in practice? Does it mean that you are going to make 2.2 as best as can be before moving on to the next incarnation?
The reason I have asked is there has been great progress with fixes. Just some of them were fixed in a different stream, or far in the future. So didn't make necessarily it into updates.
I flavour smaller incremental releases for sure. You only have the resource an manpower you have, though you do get to choose what you prioritise on.
There is something to said for taking a leaf out of phpBB's book, giving a higher priority (and turnaround) to stability, over new features an major architectural changes. This doesn't mean you don't revamp the the framework at all.
I think there is feel good factor with more releases, with more fixes, over new features any day. You already have a way of categorising issues. I think certain issues, that seem non-critical, but day to day stuff, are the sorts of thing that should get a priority over new features, or major architectural changes.
Obviously these fixes still have to go through review process so they don't get released right away. But as you said you want to move away from massive code releases, to more incremental.
There are always going be gripes that people have, you can't stop that. In my book if you have more uncommon gripes than common gripes especially with intended features you are doing well.
@x00 said:
What does this mean in practice? Does it mean that you are going to make 2.2 as best as can be before moving on to the next incarnation?
2.2 is going to fork as soon as our standards changes are done (less than a week, I hope). I'd like to see 2.3 6-12 months later. That could change depending on our priorities during that time.
Just some of them were fixed in a different stream, or far in the future. So didn't make necessarily it into updates.
A big factor in whether fixes make it into an incremental update is how close the open source version is to the one it got fixed in. My narrowing the time between releases (from years to months) we'll have a lot more flexibility in what can be backported with limited time.
@Linc said:
A big factor in whether fixes make it into an incremental update is how close the open source version is to the one it got fixed in. My narrowing the time between releases (from years to months) we'll have a lot more flexibility in what can be backported with limited time.
Yep, there should be some rule of thumb especially if the problem is existent in the stable branch, that it is fixed in that branch or major version.
@x00 said:
Yep, there should be some rule of thumb especially if the problem is existent in the stable branch, that it is fixed in that branch or major version.
I think a general guideline is that fixes for issues that are regularly noticeable in day-to-day usage of the software are good candidates for backport (and, of course, security issues). I definitely don't want to get into a scenario where we backport stuff every day. Better to do the next version sooner if there are that many fixes.
Comments
Americans use water-boarding
Oh wait...
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
Some circle use "acclimating"
acclimating wth? acclimatising or acclimatizing if you must.
That is like people who use of the word 'utilize' all the time when 'use' is adequate.
grep is your friend.
I have misunderestimated your strategery of utilising acclimating with young internpersons. I gather onboarding was only partially successful, with one left on the pier and the other been thrown a lifebuoy.
grep is your friend.
Yeah, "onboarding" is a great word. Now, please please please release.
@xDaizu: you should star the GitHub repository so that you get the notifications of what is going on there. That's really insightful!
@xDaizu It's not like they are keeping it secret. Nothing stops you from just installing master from github. Just try it out locally first.
My themes: pure | minusbaseline - My plugins: CSSedit | HTMLedit | InfiniteScroll | BirthdayModule | [all] - PM me about customizations
VanillaSkins.com - Plugins, Themes and Graphics for Vanillaforums OS
@Bleistivt I do, and every week I install the new master version and it breaks my plugins and I have to redo everything
. I need a "stable point" to work from. That's why I am so impatient! 
And no, I can't use 2.1 since some plugins I need, like the API plugin doesn't work in 2.1.
I know that asking for it once and again won't probably accelerate the process, and my intention is not to push you. I just want to communicate my vision as a newcomer, which is that 2.2 really needs to be released ASAV (as soon as viable), because as per now, Vanilla is in a very unstable place, with the 2.2 tags being way older than the 2.1 and deprecated; important plugins requiring 2.2+ and the current 2.2 (master branch) changing in a big way (or small but breaking stuff) every week. As a newcoming developer this is a really unfriendly environment to develop a REALLY big application around it, but, for some reason, I REALLY want to use Vanilla in my project.
Never use a large word when a diminutive one would suffice.
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
burglarize vs. burgle
gotten vs. got
1:2
grep is your friend.
@xDaizu: Wow, sounds like a love letter.
Big application? Let us know.
At least, pi times better than a hate later!
Oh, you'll know. Eventually. Or at the very least, you'll see some plugins and themes coming as soon as we can start developing. (Well... actually a few weeks later, because, you know, development time...)
But long obscure words makes you seem more clev...intellig... sagacious!
I can sympathize with this. I recently imported from another platform, and in the process have been working on integrating some plugin features and whatnot in ways that please me. I quickly learned that I have no clue if master == stable in this case (or rather, it's not as stable as I'd normally expect a master branch to be). Plugins like the ProfileExtender don't work in 2.1.10, and there are simple patches mentioned in threads (which do fix it, but require you to manually change the plugin source), but they are patches that don't appear to be applied in GitHub, nor are there issues for them despite it being a known bug, which means either it's not being tracked, or the 2.1.x released version of the plugin is actually configured for 2.2. Either way, what? And then there's info that says it's actually being merged into the core, even though it's still included as a plugin in the repo and there don't seem to be issues logged for it. Master has code and plugins in it that aren't in the 2.1.10 release, but that appear to require 2.2 even though it's not released (Google+ logins come to mind, if you pull that off GitHub, it just breaks social logins on the platform).
I try to avoid asking too much of folks devoting their time to developing an open source project because I know it's a labor of love, and I don't want to tell them how to keep their house, but it makes it super challenging to solve your own problems and discourages community from helping and contributing back if it's not clear what the development methodology is. And the fact of the matter is, I might just be too used to how my teams use GitHub, which would totally be my problem, not theirs.
What I think would be AWESOME, is once 2.2 tags, if the Vanilla team started an apprenticeship/mentor program for the platform. I've seen this with other larger open source projects, where community members interested in helping with maintenance and development can spend time shadowing one of the core team members to learn the process and standards they use. That makes the entire community better then, while helping ensure the plugins and themes and such are meeting a standard (which is another confusing issue, when you see super old addons in the repo that are "verified," but haven't been touched in 3+ years).
@fienen good points well stated. I'm really hoping that the 2.2 release will put us in a position for open source & staff to work together a great deal more since our code bases will be back in sync for the first time in 4+ years. The 2.1 boondoggle of a release schedule really messed up a lot of the cross-benefits. 2.2 should also be the last long (years) gestation period for a release.
Speaking of which. These coding standards changes are now the last thing on my blockers list. We've fixed the spacing & inline doc formatting, now we're down to capitalization. This is import to finish before the fork so that we can backport fixes easily to 2.2 as needed without big merge conflicts.
What does this mean in practice? Does it mean that you are going to make 2.2 as best as can be before moving on to the next incarnation?
The reason I have asked is there has been great progress with fixes. Just some of them were fixed in a different stream, or far in the future. So didn't make necessarily it into updates.
I flavour smaller incremental releases for sure. You only have the resource an manpower you have, though you do get to choose what you prioritise on.
There is something to said for taking a leaf out of phpBB's book, giving a higher priority (and turnaround) to stability, over new features an major architectural changes. This doesn't mean you don't revamp the the framework at all.
I think there is feel good factor with more releases, with more fixes, over new features any day. You already have a way of categorising issues. I think certain issues, that seem non-critical, but day to day stuff, are the sorts of thing that should get a priority over new features, or major architectural changes.
Obviously these fixes still have to go through review process so they don't get released right away. But as you said you want to move away from massive code releases, to more incremental.
There are always going be gripes that people have, you can't stop that. In my book if you have more uncommon gripes than common gripes especially with intended features you are doing well.
grep is your friend.
2.2 is going to fork as soon as our standards changes are done (less than a week, I hope). I'd like to see 2.3 6-12 months later. That could change depending on our priorities during that time.
A big factor in whether fixes make it into an incremental update is how close the open source version is to the one it got fixed in. My narrowing the time between releases (from years to months) we'll have a lot more flexibility in what can be backported with limited time.
Yep, there should be some rule of thumb especially if the problem is existent in the stable branch, that it is fixed in that branch or major version.
grep is your friend.
I think a general guideline is that fixes for issues that are regularly noticeable in day-to-day usage of the software are good candidates for backport (and, of course, security issues). I definitely don't want to get into a scenario where we backport stuff every day. Better to do the next version sooner if there are that many fixes.
Sure that's good. and if you are releasing more often anyway it shouldn't be as big a problem
grep is your friend.