If you notice any definite duplicates, please let me know. I do not expect that we will be able to complete all 50, but if we can it will be a monumental effort :)
Please read through the accepted list and if you like one or more, do the following: - create a Tracker Task for it - set the Status to "Planning" - set "you" as the assignee if you want to be responsible for the Task - link the Task back to the white paper on the forum - reply to the forum white paper with a link back to the Tracker Task
Now, ensure there is enough information in either the Tracker Task or the White Paper so that the goals are clear. If you are happy they are post a message on this list to ask for a review. If it looks ok we will set the status to "Open" and you can start committing.
When a task is finished we should add a summary of what has been done from a 3pd point-of-view and also the user point-of-view.
SVN
Each task will be marked to commit to a certain part of the SVN repo.
1. The simplest of tasks will be allowed to be committed directly to Trunk
2. The majority of tasks will be committed to the "refactor" branch
3. More complex tasks, like ACL, will have their own branch
I think ACL is the only real contender for its own branch at this stage. If we need another one please let me know.
Once a task is "complete" and tested it will be merged back to trunk.
MERGING
There will be a fair bit of merging going on.
* 1.5 Release will merge back to Trunk
* Branches will merge from Trunk when Trunk updates
* Trunk will do a partial merge from a Branch when a task is complete
ANCILLARY
As we go through we will also need to work out the finer details of documentation, unit test, etc. I think we should tackle this as we get to those points rather than try to do too much pre-planning. With everything listed on the tracker it should be easy to compile a "what's new" page when we near release.
If there are any other suggestions, questions or comments please let don't hesitate to reply.
Thanks for setting all that up Andrew. WRT backend component refactoring, I will continue to work my way through them, but I will not assign a task to me until I start working on it, so others can join in if they want - just assign the task to you and get started :)
Also, how do we want to handle the "Minor API changes" task(s)? Should we create a separate tracker entry for each, or does someone want to tackle them all?
On 20/04/2008, Ross Crawford <ross.crawf...@gmail.com> wrote:
> Thanks for setting all that up Andrew. WRT backend component > refactoring, I will continue to work my way through them, but I will not > assign a task to me until I start working on it, so others can join in > if they want - just assign the task to you and get started :)
I've put all the refactoring tasks on the Tracker. They are currently open. I would encourage everyone who is active to pick up at least one of them. Many hands make light work and all that, and I'd like them finished in the next four weeks.
> Also, how do we want to handle the "Minor API changes" task(s)? Should > we create a separate tracker entry for each, or does someone want to > tackle them all?
I think for those, we just post a topic in this mailing list and deal with them one by one. I don't think they need a task. Well, actually, maybe we do need one task so that we can put the documentation comments on them.
libraries/joomla/document/feed/renderer/rss.php has the following code & comment:
/* // on hold if ($data->items[$i]->source!="") { $data.= " <source>".htmlspecialchars($data->items[$i]->source, ENT_COMPAT, 'UTF-8')."</source>\n"; } */
I'm just wondering if anyone knows why this is marked "on hold"? I don't wanna screw with it if there's a reason.
Update and various installation rewrites will be a moving target for a while, and its got its own branch. I'd like to see anything in that Library installer post put there, including the external library updates as well. That way we can see quickly if anyone of them break without disturbing a whole heap more people.
> If you notice any definite duplicates, please let me know. I do not > expect that we will be able to complete all 50, but if we can it will > be a monumental effort :)
> Please read through the accepted list and if you like one or more, do > the following: > - create a Tracker Task for it > - set the Status to "Planning" > - set "you" as the assignee if you want to be responsible for the Task > - link the Task back to the white paper on the forum > - reply to the forum white paper with a link back to the Tracker Task
> Now, ensure there is enough information in either the Tracker Task or > the White Paper so that the goals are clear. If you are happy they > are post a message on this list to ask for a review. If it looks ok > we will set the status to "Open" and you can start committing.
> When a task is finished we should add a summary of what has been done > from a 3pd point-of-view and also the user point-of-view.
> SVN
> Each task will be marked to commit to a certain part of the SVN repo.
> 1. The simplest of tasks will be allowed to be committed directly to Trunk
> 2. The majority of tasks will be committed to the "refactor" branch
> 3. More complex tasks, like ACL, will have their own branch
> I think ACL is the only real contender for its own branch at this > stage. If we need another one please let me know.
> Once a task is "complete" and tested it will be merged back to trunk.
> MERGING
> There will be a fair bit of merging going on.
> * 1.5 Release will merge back to Trunk
> * Branches will merge from Trunk when Trunk updates
> * Trunk will do a partial merge from a Branch when a task is complete
> ANCILLARY
> As we go through we will also need to work out the finer details of > documentation, unit test, etc. I think we should tackle this as we > get to those points rather than try to do too much pre-planning. With > everything listed on the tracker it should be easy to compile a > "what's new" page when we near release.
> If there are any other suggestions, questions or comments please let > don't hesitate to reply.
JDocumentFeed::AddItem() currently puts the article link in this field, which is clearly incorrect, and may be the reason for the "on hold". Should we look at providing an article parameter for users to enter this info?
Actually, looking more closely at the feed specs, source seems to be for articles that are directly copied (ie aggregated) from another feed. As Joomla! doesn't currently support that, I don't think there's any reason to support the source element in our feeds. ATOM does support manual source using <link rel="via">, maybe we could look at supporting that in future with article parameters.
Ross Crawford wrote: > JDocumentFeed::AddItem() currently puts the article link in this field, > which is clearly incorrect, and may be the reason for the "on hold". > Should we look at providing an article parameter for users to enter this > info?
> ROSCO
> Ian MacLennan wrote: >> I'm not sure what you would put in the source field, as it is intended >> for use if the article came from another feed.
>> Ideas?
>> Ian
>> On Sun, Apr 20, 2008 at 5:23 AM, Andrew Eddie <mambob...@gmail.com >> <mailto:mambob...@gmail.com>> wrote:
>> No idea here.
>> Regards, >> Andrew Eddie
>> On 20/04/2008, Ross Crawford <ross.crawf...@gmail.com >> <mailto:ross.crawf...@gmail.com>> wrote:
|
