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

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: