Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
1981
The Pub / Re: Repository name poll! Yayer!!
« on January 15th, 2014, 09:38 PM »
I just tested on github, and you can type the URL any way you want, it's case insensitive.
1982
The Pub / Re: Repository name poll! Yayer!!
« on January 15th, 2014, 06:19 PM »
Another close fight!
1983
The Pub / Repository name poll! Yayer!!
« on January 15th, 2014, 01:59 PM »
Advantages of wedge/forum: better URL, and if you fork the project, your repo's description has 'forked from Wedge/forum' in it. It's descriptive.
Drawbacks: if someone forks your fork, nowhere can you see that it's a fork of Wedge.
Advantages of wedge/wedge: see above. Drawbacks: it's repetitive, repetitive. But it's the convention around software built from an organization repo (phpbb/phpbb, mybb/mybb...)
Advantages of wedge over Wedge: none, it's just a matter of taste.
Choosing one of these isn't a big deal, but once it's chosen, I can't change it anymore. (Except for the casing in the organization name. But that's all.)
Drawbacks: if someone forks your fork, nowhere can you see that it's a fork of Wedge.
Advantages of wedge/wedge: see above. Drawbacks: it's repetitive, repetitive. But it's the convention around software built from an organization repo (phpbb/phpbb, mybb/mybb...)
Advantages of wedge over Wedge: none, it's just a matter of taste.
Choosing one of these isn't a big deal, but once it's chosen, I can't change it anymore. (Except for the casing in the organization name. But that's all.)
1984
The Pub / Re: Name poll! For something useless! Yay!
« on January 15th, 2014, 12:28 PM »Set a date to complete functions, than add two weeks for testing and debug. Push day after the two week mark for better or worse. Don,t forget to remind everyone it is the first beta of many to come.
You will NEVER make it 100% perfect. Any software that is perfect and does not have bugs is obsolete.
Believe me, I know how handling a project works. My first project release was 23 years ago. And all I know is that if it's way past its expiration date (mostly thanks to Pete), it's pretty much impossible to get the 'momentum' back, so you have to accept that it'll never be successful beyond a tiny, very minor niche audience. I've had my share of professional successes and failures, so I can deal with either of these fairly well enough. Not a big deal. But it sure is better when it's a success, of course.
The only thing that worries me is that niche audience = requires financial involvement from users to make it a viable long-term solution, = less likely to acquire new 'customers' (and I don't like seeing my users as customers, so it's bad to begin with), = more likely to go out of funds.
But it's not really time to consider this. Right now, I'd like to focus on the positive things, i.e. the Wedge repo will soon be public, which I'm the only one to hate, so... Everyone rejoice, eh..?
I just finished moving my branches out of the way, they're now (for the most part) moved to the stash repo, so I can now reduce the repo's size, probably by cloning it, and I'm all set for a last check.
The sooner you release a beta, the sooner you will find out about bugs when running on other configurations. You will also find out what us users like, dislike and want added.
This would have been possible if Wedge was a public repo from day one. Which wasn't possible, because of the SMF 2 beta license at the time we started the project, so... No need to look behind.
1985
The Pub / Re: Name poll! For something useless! Yay!
« on January 15th, 2014, 08:24 AM »
Sure! Now I need to:
- determine whether I keep the $sourcedir variable or upgrade it to an APP_DIR constant.
- fix all other branches (see rebasing topic).
- make a fake install, and fix the process.
- do a quick overview of Wedge, try to determine what will surprise/disappoint users, and try to fix that. :P
- make a quick list of all areas in Wedge that are NOT finished yet but will be finished in the coming weeks, such as notifications, privacy, contact lists, etc. (Is that all? :P)
- determine whether I use github.com/Wedge/wedge or githubhom.com/wedge/forum as the main repo (what? wedge/forum is better, but then it means Wedge forks will show up as 'myaccount/forum', with no mention of Wedge whatsoever...)
- determine whether I use github.com/Wedge or github.com/Wedge (the latter looking better in hardlinks, but not in the actual github page where you have to cope with a lowercased title... It may be stylistic, but...)
- write a blog post.
- push the actual thingy.
- pray that it doesn't underwhelm, after 3 years of work.
Estimated date: January 20.
Personal goal: January 16.
- determine whether I keep the $sourcedir variable or upgrade it to an APP_DIR constant.
- fix all other branches (see rebasing topic).
- make a fake install, and fix the process.
- do a quick overview of Wedge, try to determine what will surprise/disappoint users, and try to fix that. :P
- make a quick list of all areas in Wedge that are NOT finished yet but will be finished in the coming weeks, such as notifications, privacy, contact lists, etc. (Is that all? :P)
- determine whether I use github.com/Wedge/wedge or githubhom.com/wedge/forum as the main repo (what? wedge/forum is better, but then it means Wedge forks will show up as 'myaccount/forum', with no mention of Wedge whatsoever...)
- determine whether I use github.com/Wedge or github.com/Wedge (the latter looking better in hardlinks, but not in the actual github page where you have to cope with a lowercased title... It may be stylistic, but...)
- write a blog post.
- push the actual thingy.
- pray that it doesn't underwhelm, after 3 years of work.
Estimated date: January 20.
Personal goal: January 16.
1986
The Pub / Re: git rebase is a joke...
« on January 15th, 2014, 08:17 AM »
ema, can you help with this?
After I rebased my master branch, the other branches were not updated, so they're all still referring to the original untouched master, and thus take more space in the .git folder...
I need to find out how to update the OTHER branches to use the MASTER branch as their 'original' branch. That is, basically, these branches all have a 'starting point' (the commit ID when they were created), I suppose I just need to move that commit ID to the new master branch. But how do I do that without rebasing the entire branch? Playing with reflogs?
Or is there another, even smarter way of updating these branches?
After I rebased my master branch, the other branches were not updated, so they're all still referring to the original untouched master, and thus take more space in the .git folder...
I need to find out how to update the OTHER branches to use the MASTER branch as their 'original' branch. That is, basically, these branches all have a 'starting point' (the commit ID when they were created), I suppose I just need to move that commit ID to the new master branch. But how do I do that without rebasing the entire branch? Playing with reflogs?
Or is there another, even smarter way of updating these branches?
1987
The Pub / Re: git rebase is a joke...
« on January 15th, 2014, 12:52 AM »
We all went through that (for me, it was in August and September 2010, after which we never got any problems again, except in late 2012 because of a new program I used that rewrote all my files in CRLF, and I only realized it after committing.... and SVN doesn't allow history rewrites, so I was screwed at the time. git is too complicated of a beast, but at least it gives me a lot more flexibility in cases like this one.)
One other solution would be to run a git filter-branch that gets rid of any CRLF combos. And yes, that exists, and it's doable in one line, IIRC... :^^;:
One other solution would be to run a git filter-branch that gets rid of any CRLF combos. And yes, that exists, and it's doable in one line, IIRC... :^^;:
1988
Features / Re: One theme to rule them all?
« on January 15th, 2014, 12:49 AM »
Oh, scratch that... Looks like making a fake commit (core/app/Admin.php needed some fixing, so I fixed it) somehow fixed my problem.
That gets the prize for fix of the day. And most uses of the word 'fix' in a short post.
That gets the prize for fix of the day. And most uses of the word 'fix' in a short post.
1989
The Pub / Re: Name poll! For something useless! Yay!
« on January 15th, 2014, 12:47 AM »
I'd rather waste 2 days waiting on the 'right' combination of folder names, than not renaming them, and ending up screaming at my screen every time I want to do a commit.
Unfortunately, as I just posted on the 'One theme' topic, even renaming folders wasn't enough of a safe strat. I'm a bit lost now.
(That, plus the fact that even after moving files around, I still have some fixing to be done. Even, a lot.)
Oh, scratch that... Looks like making a fake commit fixed my problem.
Unfortunately, as I just posted on the 'One theme' topic, even renaming folders wasn't enough of a safe strat. I'm a bit lost now.
(That, plus the fact that even after moving files around, I still have some fixing to be done. Even, a lot.)
Oh, scratch that... Looks like making a fake commit fixed my problem.
1990
Features / Re: One theme to rule them all?
« on January 15th, 2014, 12:36 AM »
So, err... The whole point of renaming folders was to get the same usual file order (Sources < Themes < languages < scripts < skins) in my commit log, so that I could quickly find 'core' changes.
With the new structure, I was hoping for app < html < languages < scripts < skins.
Here's the result...
For some reason I don't know, core/app files are located at the END of my changeset list. I can reset the ordering by clicking the 'Path' area in the selector's title of course, but then if I hit Cancel and then re-commit, it's back to that order.
Anybody knows how to fix this..? It's just unacceptable to me!
With the new structure, I was hoping for app < html < languages < scripts < skins.
Here's the result...
For some reason I don't know, core/app files are located at the END of my changeset list. I can reset the ordering by clicking the 'Path' area in the selector's title of course, but then if I hit Cancel and then re-commit, it's back to that order.
Anybody knows how to fix this..? It's just unacceptable to me!
1991
The Pub / Re: git rebase is a joke...
« on January 15th, 2014, 12:33 AM »Ehhh... I understand.
Remove the CRLF from the history is a PAIN and I have to fight with them every time... No idea how to fix them "easily".
Still, that's a lot better than the 50+ fixed files I used to have, of course.
The only way is prevent them to begin with, I think there are a couple of options you can enable to ignore CRLF and force the repo to LF only.
1992
Features / Language revs
« on January 14th, 2014, 06:57 PM »
I'll be using this topic to 'tip' translators that some updated files are available on the languages repo. I may not do it all the time, though. For safety, just read through all New Revs posts, and see if I mention any language modifications. ;)
* Reflect folder structure changes. (Home, Install, ManageSettings)
* Reflect folder structure changes. (Home, Install, ManageSettings)
1993
The Pub / Re: Name poll! For something useless! Yay!
« on January 14th, 2014, 06:53 PM »
'kay, I'm going for app/html.
I did some more tests, planned a 'fake' commit, and it all looked good to me, so it's on.
I can still change my mind before I push to github, thanks to the magic of git filter-branch, but right now, I'd rather focus on getting the thing out, and then getting used to the new structure... :P (Which should be easier, now that I've been able to magically retain exactly the same folder order inside /core compared to the old theme system era.)
I did some more tests, planned a 'fake' commit, and it all looked good to me, so it's on.
I can still change my mind before I push to github, thanks to the magic of git filter-branch, but right now, I'd rather focus on getting the thing out, and then getting used to the new structure... :P (Which should be easier, now that I've been able to magically retain exactly the same folder order inside /core compared to the old theme system era.)
1994
The Pub / Re: Name poll! For something useless! Yay!
« on January 14th, 2014, 04:22 PM »
Last error is. Because loadSource is now defined in index.php (otherwise I can't minify Load.php later), so i need to load that too.
Anyone who voted before I updated the poll, can you revote? Just click 'remove my vote'. Thanks! A bit too tied right now...
Anyone who voted before I updated the poll, can you revote? Just click 'remove my vote'. Thanks! A bit too tied right now...
1995
The Pub / Re: Name poll! For something useless! Yay!
« on January 14th, 2014, 01:02 PM »Still think /app and /html would be best.
Adopting app for this poll choice, so all those who voted for the engine/html combo are now in the app/html combo. Feel free to change your votes.
Quite honestly, I'm 50/50 between app/html and backend/frontend, right now. Slight advantage towards the crowd's current preference. Sources/Themes is still a favorite of mine too, but it's unrealistic to keep it. The only 'remainder' of Sources will be the loadSource function, which I'm not planning to rename. (Otherwise, loadTemplate should have been called 'loadTheme' from the start, but that name's taken... So, 'app/backend' has Source files, and 'html/frontend' has Template files, so loadSource and loadTemplate, and that's all.)
Thank you guy to putting up with my silly polls and questions. I know it doesn't REALLY matter to you guys, but I appreciate that you're not too judgmental on the fact that it matters to me... :^^;:
I'm pretty much set on an official public source code release of Wedge tomorrow. But that's my personal goal. If I can do it by January 20, I won't be too mad at me. I still haven't tested installing the forum from scratch, which is probably going to break horribly, ah ah.