Limitations of Ports System

[Aryeh M. Friedman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Skip Ford wrote:
> Aryeh M. Friedman wrote:
>> Developing in a vacuum is a recipe for disaster.... we are making
>>  fairly good progress believe it or not I only see an other 1 or
>> 2 threads being needed before actual coding starts, *BUT*
>> producing a system no one wants is pointless thus it is wise to
>> gather as much input as possible...
>
> And that's fine if that's how you prefer to work, but everyone's
> point is that it has nothing to do with the current ports system at
> all so the talk doesn't belong on a mailing list dedicated to the
> current ports system. It's just noise here.  Research for a new
> system from ports@ users belongs on a list dedicated to the new
> system.

First of all not everyone has said a number of people (not including
me) have said it is the proper place.... one thing is clear though
there really is no proper mailing lists and wiki's have some problems
covered below
>
>> why is it that everyone who sees the whole concept as being
>> negative has offered no input what so ever about what should be
>> done (even saying "the current system is fine" is useful to us)
>
> You've been told over and over what should be done.  You need a
> ports-ng wiki (or whatever you want to call your new system) and/or
> your own mailing list.  Posting a single message occasionally on
> ports@ to point others to a new system in the works is perfectly
> fine, but using a mailing list dedicated to one system to develop
> another competing system isn't. If you need research from ports@
> readers, you post a message pointing them elsewhere, you don't do
> it in a way that floods this list with 100+ messages.

The simpler case is the seperate mailing list.... once there is a good
idea of what is needed then moving to such a forum makes a great
amount of sense and the 3 volunteers (including me) that have made
firm commitments to work on the project do just this... but in the
early design phases (deciding if the project is needed, the scope and
gathering top level requirments/features) public input is critical and
taking stuff out of a well established forum reduces the amount of
useful input... btw we are basically somewhere between scope and top
level requirement gathering (the internal mailing list is attempting
to settle on a final scope statement so we can move to the final truly
public phase which is systematic gathering of requirements)

The wiki poses some issues due to the medium of wiki's vs. the medium
of mail... the first of these issues is wiki's are terrible for
discusssions and a very lively on topic discussion is the best way to
iron out the 3 public phases... what wiki's are very good at is
recording decisions and we defently plan to use a wiki for this... but
besides for "the project should be done" not enough decisions have
been made to justify a record of them currently, as soon as the scope
is decided internally we will produce some docs that will justify a
wiki (and since they are still in the public phases I will post them
here for discussion purposes)... as soon the second set of docs (top
level requirements) is produced all the work will occur privately
except for one final post that details the conceptual model for public
comment
>
> You've been given lots of sound advice on how to proceed and you've
>  listened to none of it.  You haven't heard what anyone has said
> thus far. Just start a wiki already like you've been told to do by
> those who already know exactly what they're doing, and aren't still
> trying to figure out how to figure out what it is they might want
> to do someday.

On techinical issues I have heard almost all of it and have
substantially revised my mental conceptual model based on it.  But as
far as what should be public and what should be private good software
engineering not only says the minority is wrong but I am using what is
considered the industry standard method (as much as possible when it
is not f2f).  If the industry standard doesn't agree with FreeBSD's
method then it does make sense to check if the FreeBSD model can not
be improved in light of newer data.   In sort the main metadebate is
on cultural differences and that is sad because culture should have
nothing to do with the tech aspects.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYxvQzIOMjAek4JIRAsRSAJ9YBTglveSohfNWAaKdvG3JrKUq7gCfUI3H
v65HbjHbwZs+JryHeOqXOr4=
=353C
-----END PGP SIGNATURE-----