Difference between revisions of "Web Site Infrastructure Discussion"
|(4 intermediate revisions by 3 users not shown)|
|Line 3:||Line 3:|
= Redmine =
= Redmine =
== /Losses ==
|Line 100:||Line 100:|
08:01 < Crofton|work> yeah
08:01 < Crofton|work> yeah
Latest revision as of 12:45, 7 April 2010
Discussion about using a project management tool like Redmine. Would likely replace bugzilla, and some wiki functionality. It seems likely the main OE web site would remain in mediawiki.
- easy to automatically reference issues from commits: refs #123
- easy to close issues from commits: closes #123
- everything is in one place, milestones, tickets, wiki, and it is easy to cross reference everything. With everything in one place, it is more likely that all the tools will get used.
- one place to look for all project activity, Issue changes, wiki edits, source code changes, etc
- very good multiple project support
- additional features such as news, roadmap, etc.
- Redmine does not have a concept of workflow in tickets (not sure we use this anyway)
- what to do with the wiki? With two wikis, it is very clumsy to have stuff in two places.
- spam protection, security. Mediawiki and bugzilla are robust apps. Redmine is relatively new.
- bug linking, example: http://bugs.openembedded.net/show_bug.cgi?id=3591
- To think about
- Redmine is geared toward "projects" where everyone is working toward the same goal. OSS projects typically involve a lot of people with different goals. Would there be any benefit to integration?
- would roadmap planning help us set goals for the next release and get more people working toward common goals? As OE is combination of many things, I'm not sure this is applicable.
 IRC Discussion
That started this.
07:21 < zecke> cbrake: do you use the accounting part of it? 07:21 < otavio> accounting of what? 07:21 < cbrake> zecke: I use the time estimation part, percent done, but I don't log time on task. 07:22 < otavio> ah 07:22 < cbrake> zecke: my needs are primarialy to estimate remaining work on a project. 07:22 < otavio> cbrake: same here 07:22 < otavio> cbrake: we don't use the time planning 07:22 < otavio> cbrake: but few internal projects, when we hire external consultants, we use 07:23 < zecke> cbrake: yes, that is good enough. Do you manage to update this information? Or, is your busines context forcing you to update it anyway? 07:23 < cbrake> zecke: the Gantt chart stuff is pretty elementary, but is still fairly useful for mapping out tasks on a weekly basis 07:24 < cbrake> zecke: not sure I understand your question 07:25 < zecke> cbrake: The issue most of the time is updating the information once the project is going 07:25 < zecke> cbrake: combining this with the fact that humans are lazy, most projects I know stop the book keeping... so how easy is it to keep the information up to date? 07:26 < cbrake> zecke: yes thats a problem to keep up to date, and I'm as lazy as the next :-) 07:26 < cbrake> zecke: but redmine is the least painful method I've found so far -- UI is excellent. Even small things like back arrow is truely back instead of the last for change, etc. 07:27 < cbrake> zecke: I do other things that help me like record every commit in a ticket (redmine can do some of this automatically), but it forces me to look at tickets often, and keep everything up to date. 07:28 < cbrake> zecke: that is probably the most useful process I've found yet -- every commit references a ticket, and the ticket lists all changsets. 07:29 < cbrake> zecke: its tough to get people to buy into that, but when they do, it really works well. 07:30 < Crofton|work> gm 07:31 < CIA-5> Koen Kooi <firstname.lastname@example.org> org.openembedded.dev * rd74bc04b79 openembedded.git/contrib/angstrom/build-feeds.sh: angstrom feed builder: add geda 07:34 < CIA-5> Koen Kooi <email@example.com> org.openembedded.dev * rf0678db614 openembedded.git/packages/xorg-xserver/ (xorg-xserver-common.inc xserver-xorg_1.5.3.bb): xserver xorg: split of Xfbdev to make it parallel installable with kdrive 07:35 < otavio> cbrake: and it is quite easy to close a ticket too; using commits. That is very helpful too :-) 07:36 < otavio> zecke: redmine does a great job and is much more active then trac and other alternatives. 07:36 < otavio> zecke: even though trac still has a larger installed basic, redmine has evolved fastly 07:37 < cbrake> otavio: interesting, I'll have to get that working 07:38 < otavio> cbrake: same place where you adds refs, there is a place to add the closes and other words to be used to close a ticket. 07:39 < otavio> cbrake: it is quite easy 07:41 < cbrake> otavio: ok, I see that. So is the sytax simply: closes 342 07:41 < cbrake> otavio: what is "plugonrails" ? 07:42 < Crofton|work> you guys aren't thinking we should use this for OE? 07:43 * Crofton|work really likes the idea, but isn't sure how well it would in practice for a large diverse group 07:43 < otavio> cbrake: closes #342 07:43 < otavio> cbrake: it is a place where we put our internal plugins to others to use 07:43 < cbrake> Crofton|work: I'm not sure it would add much value to OE. I'm more talking in the context of smaller, commercial projects 07:43 < Crofton|work> yeah 07:43 < otavio> cbrake: we use rails for our client painel 07:44 * Crofton|work thinks OE might benefit from it, but implementation would be challenging 07:45 < cbrake> Crofton|work: one of the challenges with commercial projects is they move fast, and there has to be close teamwork and high visibility to build trust. Redmine helps build this. It seems like OSS projects are somewhat different. 07:46 < cbrake> * perhaps transparency is a better word 07:46 < Crofton|work> similar but different 07:46 < Crofton|work> on commercial projects everyone has the same goal 07:46 < cbrake> with OSS projects, there is by default transparency, where with commercial projects its often very difficult to achive this 07:47 < Crofton|work> on OSS projects there are different goals for each participant 07:47 < cbrake> nod 07:48 < zecke> pb_: ping 07:48 < otavio> right but different goals doesn't means we shouldn't have a milestone, bug tracking, bug assignation and like 07:49 < otavio> and bugzilla makes it somewhat boring, while new tools (redmine included) makes it easier and neat 07:49 < Crofton|work> otavio, agreed 07:50 < Crofton|work> bugzilla is very good at managing bugs 07:50 < cbrake> otavio: interesting point 07:51 < cbrake> media wiki and bugzilla are obviously more capable as stand-alone tools, so the question is the integration of the tools worth more than the features we would lose? 07:51 < Crofton|work> I really like having good history (beyond commit messages) for all commits, but I have been accused of being a control freak at times :) 07:51 < otavio> cbrake: I believe it is worth 07:52 < otavio> cbrake: I never like bugzilla mostly because it doesn't help to track project improvement. It just track issues 07:52 < otavio> cbrake: a project is more the issues ... 07:53 < otavio> cbrake: and redmine, trac and others make all this integrated. It is easy to find what is needed to be done 07:54 < otavio> cbrake: I dislike media wiki and bugzilla and prefer a integrated and a single environment for all this. 07:54 < otavio> cbrake: this also makes easier to write supporting tools to integrate with it 07:56 < Crofton|work> I have seen good rsults with people using trac 07:56 < cbrake> otavio: I think I agree, and I've had lots of good experience using trac/redmine. 07:56 < Crofton|work> but any tool system is only as good as it users 07:56 < Crofton|work> do you knwo a good redmine example? 07:57 < cbrake> well, why don't we paste this discussion on a wiki page, and start listing pluses/minuses and see what everyone else thinks. 07:57 * Crofton|work was going to say post to the list, but maybe trying to flesh the ideas out on a wiki page would be good 07:58 < cbrake> I think we need a clear list of benefits and losses. 08:01 < Crofton|work> yeah