Re: Subject: Re: New Maintainer for MC Project??

[Leonard den Ottolander <leonard den ottolander nl>]

Hi Terry,

On Sat, 2005-06-04 at 21:22, Fudoki Wilkinson wrote:
> Our research indicated that the Maintainer being saddled with
> programming duties had actually not been helpful in the MC Project. 

Well, "as such" this is not true. I see no problem with a maintainer
actively participating in the development process as a programmer, but
his first objective should be managing the project.

> scheduling and deploying the support personnel to make sure both
> Development Teams have the resources they need in a timely manner.

I'm not sure we should be managed and scheduled in conjunction at this
point. Of course I have no problem with people from both teams joining
in the development of the other project.

As I have expressed before, time tables are not important to me.
Milestone targets are. We can always adjust the next target depending on
whether we got to the first at a snails pace or like a greased lightning
;) .

> I can also guarantee that the MC Team, should they accept our offer,
> will be able to enjoy the excellent, fun, production environment that
> the Krew calls "home".

> The MC Development Team will be separate from the Krew, yet will have
> the benefit of the Krew's services, in the different units mentioned
> above.

I'm not quite sure which "services" you refer to, except of course for
you managing the project. Care to elaborate?

> > I don't think we need a new infrastructure for the development
> > process, just some fine tuning of the existing would suffice.
> 
> Well Leonard, we just have an honest difference of opinion here.

Let's focus on this aspect then ;-) .

> Simply put, we are not interested in maintaining two sets of
> standards, two different "looks", two of everything when it comes to
> websites, documentation, etc.

You cover quite a few different aspects with this blanket statement.
Maybe we don't need two of everything, but we might need two of some.
F.e. I can imagine we'll use the same CMS for our websites, but we might
want to use a layout with a different kind of blue so people will be
able to distinguish between the two projects.

If we'd decide to move from Savannah to Sourceforge we would do this as
a different project anyway. I don't think anyone on this list wants the
midnight commander to become a sub item on the Krusader page. We'll need
a separate CVS and bugzilla as we have a different code base. I'm not
quite sure how you think this can be integrated. And as these are
separate entities anyway I don't see how the "two standards" would
obstruct you in maintaining the project. It's not like one bugzilla is
much different from the other. And both Sourceforge and Savannah share
the oddity of having separate sections for bugs and patches (I've always
thought that every valid bug report needs a patch eventually, so I've
always found this distinction rather artificial not to say confusing).

Regarding the documentation, mc currently only comes with man pages and
an internal help file. Do you suggest we start using docbook instead?

And then there are coding standards. Do you suggest we synchronize these
as well? Although I personally don't like to use a space between a
function and its parameters this seems to be the standard used in the mc
codebase. I don't think anybody is willing to go over the whole codebase
and fix this.

> The MC Development Team will have the benefit of the Krew's
> infrastructure,

AFAICT Krusader is "just another" (not meant to be demeaning) project
hosted on Sourceforge. Could you be more specific on what the Krew's
infrastructure is exactly, and how we could benefit from it (more than w
we do from bugzilla and CVS on Savannah, and the mailing lists at
gnome.org)?

> and that comes in one flavor - the best we can possibly produce.  If
> this is more than you are used to, sorry!

Well, I agree the current scattering of mc web pages is a disgrace, but
wrt to bugzilla and CVS the Savannah infrastructure is just fine.

> We believe that there is considerable synergy between the two products
> now, and given the right environment and some time, that there could
> be a great deal of synergy between the two products.

Given time maybe, yes. But I don't think many mc developers are
interested to have a look at Krusader's codebase at this point in time.
Which I think is a necessity if you want to share code between the
projects.

> We cannot help but believe that if we get an additional development
> team of file management experts working with us, even in "different
> parts of the house", that this will lead to breakthroughs in file
> management technology

Wow <g>. I appreciate your enthusiasm but I don't think you should have
such high hopes ;) . I personally enjoy the midnight commander because
of its versatility and the twin panel approach which is an old and
proven concept.

I see the development of the midnight commander as evolutionary.
Improvements in the VFSes, the subshell, syntax highlighting, code
cleanup and hopefully extended charset support in the foreseeable
future.

> AND make both products better and more desirable - even if all the two
> different teams do is talk and compare "war stories'.

This indeed is a possible benefit. Assuming the teams indeed get
involved with each others development. Otoh developers could just join
in in each others development already.

> To at least see if 
> anyone wanted to have a conversation about the possibility.

Yes. I appreciate your effort in this matter. I hope the members of this
list will also try to have a constructive discussion on this matter.

> and the MC Project will get a fresh 
> start and be able to leave all the trouble of the past three years in 
> the past,

We still have a score of bug reports in bugzilla that have gathered over
the last few years. Those should be addressed. So in that sense I don't
believe we can leave the past behind. We have to do some catching up
first.

> Any member of the MC Development Team that is not 
> into that idea will not be happy around the Krew, and may want to 
> think about some other hobby than writing free software.....

This is an odd statement... I'm not quite sure what to make of it, but
it can be misconstrued easily.

> But 
> there is really no gradual, incremental way to do this kind of thing. 

Well of course there is. There needs to be. Moving infrastructure over
is not a job that should be taken lightly. It's best done in steps.

> > What the project needs is a maintainer (or maintainers) that not
> > necessarily does a lot of development himself, but one that oversees
> > the project development,

> I hope I have covered these concerns.

These you have indeed. But wrt infrastructural changes there is still a
lot to discuss. And I would like to get some input from others who
frequent this list.

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research