On 2013-02-11 02:36, Joshua Root wrote: > On 2013-2-11 09:40 , Clemens Lang wrote: >> Hi, >> >> while I was writing a patch for #32542 [1] I noticed that base could >> benefit from some refactoring. As a first measure, I'm proposing the >> removal of port submit. Since I assume not everybody on the list is >> familiar with what port submit does, let me run port help submit for >> you: >> >>> $ port help submit >>> Usage: submit >>> Submit a port to the MacPorts Web Application (unimplemented) >> >> The last change related to what port submit used to do (did this >> actually ever work?) was more than 6 years ago, back in the time when >> org.macports.submit was still called com.apple.submit[2]. >> >> If nobody objects to the removal, I will start working on this >> Wednesday. >> >> [1] https://trac.macports.org/ticket/32542 >> [2] >> https://trac.macports.org/changeset/26177/trunk/base/src/port1.0/portsubmit.tcl > > Well... I still want to get MPWA operational, and I don't know that port > submit is inherently a bad idea. Of course, much of the current code is > likely to be unusable with the new MPWA.
The functionality of 'port submit' should not be vital for the deployment of MPWA. The initial goal of MPWA should be to have a better list of available ports online and then we can think of such advanced features as 'port submit'. Additionally I want to note that there are features in the current base that are untested by developers and most probably not used by anyone. This 'port submit' is one example for that, another one would be using a remote ports tree over HTTP/FTP and also the alternate work source path I proposed to be removed last year already [1]. Also, with each addition of such experimental features, the code base has become harder to understand for new developers and lots of cross-references between port1.0 and macports1.0 were introduced, which is not how they were meant to work in my opinion. So ripping out unused features reduces complexity in the code base and hopefully makes it easier to understand, maybe even allows separation of macports1.0 and port1.0 in the future. Rainer [1] https://lists.macosforge.org/pipermail/macports-dev/2012-March/018052.html _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
