Formal Complaint about off-list development discussions.
matthew at linuxfromscratch.org
Thu Jul 1 01:17:10 PDT 2004
On Thu, 1 Jul 2004 09:06:38 +0100
Ian Molton <spyro at f2s.com> wrote:
> On Thu, 01 Jul 2004 08:23:12 +0100
> The Old Fellow <nowhere at all.com> wrote:
> > I would like the 'management' to institute an editor's rule that
> > says:
> > "Discuss changes all you want, and in any way that works. But,
> > before committing a major change, email lfs.dev with a summary of
> > the discussion for the LFS archives."
> No. not AGAIN. why isnt this understood by now?!
> The way it was decided to be done, after LENGTHY discussion was that
> the unstable book was a playground, allowed to have ANYTHING done
> without discussion at that exact moment, etc. This is the way it was
> decided allowed people to develop quickly. the .hackers list is a
> place where *unstable* devs can (if they like) discuss stuff more
> formally. (I dont entirely agree with this setup but the majority of
> developers like to work that way, so...)
> It was decided that the deadline for discussion ON LISTS was before
> inclusion in the *testing* book, and that no change owuld be allowed
> to be merged with testing until it had been aired on the .dev
> no part of the above process is hidden or closed. if you want to
> follow the leading edge you will have to keep up with it on IRC and in
> .hackers. If you dont want to follow the leading edge, thats OK, you
> can still be sure that changes wont ultimately be given the nod
> without public airing on .dev
The only problem I've got with the above is that when we branch unstable
to become testing then we'll bring *all* these changes with us. At that
point folks won't have had a chance to see what the changes were and
more importantly *why* they were made.
This might just be a one off due to the migration to the new development
process, as it just so happens that all of unstable is ready/suitable
for testing (with the possible exception of the dropping of some
packages - another change that never made discussion on lfs-hackers or
had reasoning given for it).
That's my main concern at the moment - I don't mind the rate of change
at all, it's refreshing in fact. I do feel, however, that at I for
one am unable to maintain an overview of what's going on because there
are no reasons archived *anywhere public* as to why the changes are
being made. No, I don't want IRC logged for reasons I'll go into when I
return from my sisters wedding on Monday. So, the only alternative is
to at least provide a summary of the change on -hackers just prior to
(or alongside) the corresponding commit. This way development isn't
stifled. If people raise reasonable concerns with the change, we just
revert it or amend it as appropriate.
More information about the lfs-dev