Re: FTP-Master Review Process
Hi fellow devs,
Just appending some of my side notes:
Michael's ftpmaster-proposal shares some common motivations with my
previous mail ("Intermediate representation ... license review"), and we
basically reached in an agreement on the problems existing in our
FTP-master working (NEW) process. The difference between our proposals
is that mine focuses on a small, specific, and dedicated problem, while
Michael's concerns problems in a larger-scale perspective -- a superset
of mine. Or say bottom-up v.s. top-down.
I'm still asynchronously working on my tool for helping NEW queue reviewing
process, and it may solve a portion of the issues pointed out by the proposal.
But note that my action on this will be slow due to my $college stuff.
When have enough time, I will document the core thoughts and
specifications of my work-in-progress project and post them here.
Simple demo code will come after that.
On Sun, Mar 29, 2020 at 05:37:01AM -0500, Michael Lustfield wrote:
> Hello fellow masochists,
> ... err, I mean Debian Developers,
>
> There has been a lot of talk lately about the FTP-Masters team and how some
> issues should be fixed. Back in December, I alluded to a proposal that I was
> working on. I hoped to get a little further into writing source prior to this
> point, but life happens and now seems to be a much more appropriate time than
> later.
>
>
> In my "proposal" [1], I outline the concerns that have been noted (from mailing
> lists, IRC, and private discussions) and then provide a few potential solutions.
>
> Although some source code exists, this is a discussion for later. I want to take
> a very systematic and structured approach to this.
>
> To outline...
> 1. Identify a problem
> 2. Evaluate the cause
> 3. Consider solutions
> 4. Evaluate the solution
> - Does it solve the problem?
> - Does it introduce new problems?
> - What will it take to implement?
> - Would any developer be willing to work on it?
> - Will it be maintainable in the long-term?
> - etc.
> 5. Build some prototypes
> 6. Re-evaluate the solution (copy #4)
> 7. Finish design requirements
> 8. Start building
> 9. Lotsa testing
> 10. Start discussing implementation
>
> Note... I am using the term proposal because very little of what I put forth is
> in any way a design document. It's just many thoughts tossed at a page that now
> require critical review. (critical -- be picky, not rude)
>
> Once the discussion is over (or degrades), I will begin writing a design
> document. After complete, I will ask for additional comment and interested
> developers.
>
>
> Side note-
> An important road block to be aware of is that implementing almost any of the
> proposed solutions will require significant (time & effort) changes to the main
> archive server. It will also likely require some legal counsel. I'll omit the
> gritty details since this is mostly just FYI, but it's also worth considering
> team size and availability (see: $current_issue) when it comes to implementation.
>
>
> [1] https://salsa.debian.org/mtecknology/ftpmaster-proposal
>
> --
> Michael Lustfield
Reply to: