And whatever you do, get a proposal in SOON.
I made some slight changes. Working on official GSoC application now.
Deploy into production needs to be a week. Then leave a week for bug hot-fixes.
Really, post release things are going to be nebulous – how well the release went will define what else needs to be done, so I’m fine with a vague schedule for the latter half.
/me hits ignore proposal
The student has submitted their final proposal for review. You will be able to view it immediately after the deadline:
We’re not certain why this is in place. Would you do me a favor and mail me a copy?
The official proposal is this [Google doc] (https://docs.google.com/document/d/1eOMvBtNygeLmwjiRKy1n-RyQOooZxpPONM8tn2h4l7w/edit?usp=sharing) in pdf form.
Here is the abstract I posted.
It looked to me like we can submit a draft for review (which would be redundant with the MB community page we’re on) and then upload a final proposal. In my case, they are identical.
OK, getting there.
I’d to see less technical detail about tuning the schema - for once.
I’d like to see more information on what steps are required to get this into production. Less about turning, more about show stopped bugs. You should also talk about your plans to pick CJ_'s brain to finish debugging the remaining bugs while he doesn’t have time to do so.
I’d also like to see a stated goal of using the community bonding period to determine the list of critical issues that the community believes need to be fixed before going into production. I see the following steps for this:
- Ensure the test VM is up and running.
- Write blog post about currently known issues. Threaten to release immediately after fixing these issues, which will bring more people out of the woodwork.
- Curate feedback into a final list of bugs. Announce final list of bugs and short of regressions appearing, that we plan to push this into production on date X.
This ought to generate enough interest (read: panic) in the community to get a clear feeling for what is needed for actually getting a first version of search out the door. The clear list of things that are required to be done for release should be clear at the beginning of the summer.
Finally, you should talk more about your plans to work closely with zas so that zas can work on the sysadmin related issues and monitoring this new service.
You have a lot of plans to document still.
Can I continue that here post deadline?
I was under the impression that that was possible, but it isn’t.
Alright…I’ll do what I can in the next 3 hours (minus doctors appt., and nurishment). The purpose of including the schema technical details was to document where the project stands.
I admittedly got bogged down with and hyper focused on the schema details last year…but they’re fun. I get your point though. Just get it done.
Don’t get me wrong – tuning is important, but getting it out the door, more so.
I resubmitted with your suggested timeline edits (both here and the GSoC page).
Not to be presumptuous or anything, but would it be acceptable to go ahead and start a Community topic/conversation with Zas, CJ_, and Mineo (and anyone else of course) regarding the Solr project in general? …or would it be best to just wait?
We’re allowed to say that no one else has made a proposal for working on the Solr search server/mbssssssssssss, so whether or not your proposal is going to pull through, any work you do on it will not conflict with another student’s. So I’d say you’d be most welcome to start talking with people about the Solr project, as long as you keep in mind that there’s a very real chance you’re not going to get picked.
Sorry if i am slightly off topic, could you turn your MBID texts into links?
2 posts were merged into an existing topic: Unable to link a MusicBrainz hosted discussion