mailing-list reorganisation, round 4 on this list

Axel Thimm Axel.Thimm at ATrpms.net
Sun Jan 7 13:52:38 UTC 2007


On Sun, Jan 07, 2007 at 02:28:12PM +0100, Thorsten Leemhuis wrote:
> Axel Thimm schrieb:
> > On Sun, Jan 07, 2007 at 11:15:19AM +0100, Thorsten Leemhuis wrote:
> >> Axel Thimm wrote:
> >>> On Sat, Jan 06, 2007 at 01:53:22PM -0600, Jason L Tibbitts III wrote:
> >>>>>>>>>>>>>>> "WT" == Warren Togami <wtogami at redhat.com> writes:
> >>>>> [Regarding fedora-packaging]
> >>>>> WT> How was the signal to noise ratio on this list?
> >>>>>
> >>>>> fedora-packaging has always had a very high signal to noise ratio,
> >>>>> since it's used primarily for Packaging Committee discussions.  If we
> >>>>> lose it and it becomes difficult to perform committee business due to
> >>>>> additional discussion on fedora-devel, there's a good chance that
> >>>>> someone will just set up a private list elsewhere.  Many PC members
> >>>>> are short on time as it is.
> > 
> >>> I'd second keeping fedora-packaging as is. The charter is discussing
> >>> about packaging, not (specific) packages.
> >>> But Thorsten has a point: All packagers need to know what happens over
> >>> there - same is true for some other lists, too.
> >> Axel, tibbs, does the new idea (fedora-extras traffic mostly goes to
> >> fedora-packaging to cover both packaging in practice and the guidelines
> >> on one list) suite your needs better?
> > 
> > On the contrary, what tibbs and I didn't like is that committee
> > discussions get mangled with additional discussion. Your previous
> > suggestion had this list merge with fedora-devel, now it's
> > fedora-extras, in both cases you get very different content killing
> > the other's SNR.
> > 
> > I still think most organizational bodies need a list primary for their
> > daily work.
> >
> > That is not to say that other people should not subscribe
> > and discuss there, too, but the topic should be defined in that way.
> > 
> > I liked the way it was until now: Packagers would consult each other
> > on fedora-extras or other lists and if some issue escalated for the
> > packaging committee to look at it would do so. That's why we have such
> > a good SNR.
> >
> > Please keep fedora-packaging as is - it is one of the split off lists
> > that served its purpose rather well IMHO.
> 
> Well, I on the contrary heard complain that the split made everything
> way more complicated and that we have to many lists.

Where there complaints about fedora-packaging in particular? Could the
people with these complaints perhaps speak up and detail them? If
there are some issues I'd rather deal differently than merging all
lists into a list soup. To be honest, I'm not really aware that there
were any such issue (at least compared to other list fragmentation),
but maybe that's part of the problem (although I'm on almost every
list and should have picked up any larger dissatisfaction about
fedora-packaging).

> So I'll leave it there until I hear more complains

You mean, you will leave the list as is and wait for more complaints
about merging it into something else, or that you will leave sour
suggestion to merge it into something and wait for
counter-complaints. In the later case you already have two.

> Hmm, I send my "how to govern and manage the new combined
> repository" out already and proposed two groups (one that takes care
> of the repo and one that takes care of the guidelines) there. I now
> think that was wrong.
> 
> The packaging committee was created because FESCo had a lot to do
> already and we needed the guidelines for both Core and
> Extras. That's history now. So why not have one Committee again that
> handles both theoretical and practical packaging. That's less
> overhead.

Even if the FPC were dissolved and the resposibilities moved back to
higher level organizational entities you still have different
topics. Discussing packaging guidelines and repo structure has very
little in common, what is important for one group is the noise for the
other.

You have a dillema: On the one hand you want to off-load work from
fesco/cabal or any successing entity at their places, but on the other
you are thinking of merging the groups back together, which may lead
to everyone being unsatisfied with the SNR as their perceive it.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20070107/376f5280/attachment.bin 


More information about the advisory-board mailing list