[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Savannah-hackers] Re: Plan for today

From: Mathieu Roy
Subject: [Savannah-hackers] Re: Plan for today
Date: Thu, 18 Dec 2003 18:19:59 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

"Bradley M. Kuhn" <address@hidden> said:

> Mathieu Roy wrote:
>> 2) What kind of adaptation do you think you would need? The savannah
>> software has been designed to enough generalistic to avoid beeing
>> specific, as it was at first. No change reversing
>> that process should ever be commited to the CVS. If the current code
>> does not allow a required configuration, configurability of the software
>> should be changed, not the software itself.
> Allowing the software to be configurable into a chroot environment seems
> like a good feature to add.  Don't you think so?  If not, why not?

The faster way to develop something is to make it unconfigurable. The
more configurable it is, the more configuration parameters you have to
handle. For a chroot, I guess that there are numerous parameters.

I think that first, you should have something working as soon as
possible. It implies that configurability should not be a concern
right now.

But to be included in Savannah, this work will have to be

The result is simple: if you want to have something working, you have
to write it outside of the project savannah for now, and it will be
anyway not a problem to include it later. I'd like to point that
Savannah sotfware is developed by using the Savannah software. No real
development should be made until Savannah is running, because tools to
track bugs, commits, changes are just not existing.

>> (I insist on the fact that this kind of change must not be commited on
>> the Savannah CVS itself)
> If we do make changes that are specific, what would be
> the harm on putting them on a branch?

Since the tools to coordinate the development are currently
non-existent, I think inappropriate to develop the software right
now. A project that other people rely on must be carefully managed,
and we are not in a situation where we can carefully manage it.

I, with CERN people, established rules for the development of
Savannah. Branches should be made for a specific purpose, in normal
conditions, with a defined roadmap, defined plans. 

As I said, we're not in that situation, so currently, if change need
to be made, it must be outside the Savannah project.

But sure, at a later point, once it will be polished, it will be ok
for them to enter Savannah.

> However, I would hope that we don't need to do that.  It seems to me it
> would better to improve the savannah software so that it can work with
> chroot'ed environments.  If you think this is a bad change, we would
> certainly like to hear why.
> The only change that's been discussed here that would
> specific would be to add the field in the database we mentioned that would
> indicate whether or not the software would be audited.  The request for
> that feature came from RMS himself, actually.

I mentioned, in the another mail I just sent, how to handle that. I
insist on the fact that this kind of change must not enter the
Savannah code, unless it achieves a general and interesting
purpose, not specifically due to the savannah compromise. 

Mathieu Roy

  | General Homepage:              |
  | Computing Homepage:           |
  | Not a native english speaker:                                       |
  |  |

reply via email to

[Prev in Thread] Current Thread [Next in Thread]