On Wed, Oct 7, 2015 at 6:55 PM, DJ Delorie <dj AT delorie DOT com>= wrote:

> You have to be an administrator or owner of a launchpad team to
> associate a PPA.

I didn't know this.=C2=A0 We switched to launchpad for the bug t= racker, not
because we wanted to give preference to Ubuntu packaging.=C2=A0 If I knew this was a goal, I would have pushed for bugzilla instead ;-)

> In case of the gEDA_Developers

The right place for PPAs would have been geda for the geda-gaf packa= ge
and pcb for the pcb package.=C2=A0 There are no projects associated with the developers team, and there is no one "geda" package.=C2=A0 Th= e various
geda packages don't even have similar release schedules.

This assumes, of course, that our project should be responsible for
Ubuntu packaging.=C2=A0 Are we?=C2=A0 What about Fedora?=C2=A0 Suse?=C2=A0 = Debian?
Gentoo?=C2=A0 Windows?=C2=A0 Mac?

If somebody wants to do it, it would probably be beneficial.=C2=A0 It= seems to me this would make it more likely to get packaged neatly for othe= r distros as well.=C2=A0 The only down side would be if that turned out not= to be the case: a bunch of special hacks to make ubuntu packages that make= packaging elsewhere harder.=C2=A0 But I think just be alert to that potent= ial problem, but otherwise go for it.

=C2=A0

> In addition, he revitalized a long standing idea to have a single
> place to deal with bugs in all of geda's projects.

Given the strong opposition to integration between gschem and pcb, I=
can see how this idea would find resistance.

Integrating the BTS and integrating the software isn't= the same.=C2=A0 Integrated BTS very good I think.

=C2=A0

> A team which is as open as possible to everybody with good
> intentions.

A goal I share.

> And of course a place to present a PPA of the most current version
> of the geda tools.

What about other distros?=C2=A0 Typically, supporting a distro is independent of supporting the upstream package itself.

> Note, that these bugs are exactly the same as those seen in the bug > trackers for the individual tools.

I see no benefit of having a second tracker.=C2=A0 Everything that w= as done
in the new tracker could have been done in the old trackers also.
Having two trackers only adds confusion and extra work.

I agree, but I don't understand why Markus = was declined.=C2=A0 That was the mistake that causes all the problems IMO.<= /div>

=C2=A0

> 1) a single place to add and access bug reports of all geda tools

Is this really what everyone wants?=C2=A0 Have we addressed the extr= a work

I think yes. =C2=A0gE= DA docs and BTS are so scattered it makes it much harder

to get started with them.

=C2=A0

required?=C2=A0 Does everyone know what the proper procedures for state
changes are, and how to coordinate those with packages and releases?

> 2) a low entrance barrier team to join and become involved

This didn't require a new team.=C2=A0 I've been trying to in= crease
involement with the existing setup already.

> 3) a weekly build of the geda tools to be used on ubuntu systems and > by extension on any debian related distro.

This did not require any leadership changes or disruptions.

> I feel like these are steps in the right direction.

I agree with #2 and #3, and still see no reason why a new team was required to do them.=C2=A0 Most of the people on the new team were on the old teams anyway.

#1 is of debatable benefit.=C2=A0 The projects are separate projects,
separate bug trackers make sense, just like separate git repos make

Separate repos is a different case,= and only people doing patch/devel
want them, and they= work harder to get them.
=C2=A0
sense.=C2=A0 The only real "global" benefit would be if bugs coul= d be moved
from there to their individual trackers after triage, but that would

People can more easily find the da= mn BTS and use it.=C2=A0 That's huge.
Most of the = time for most software I don't bother to report unless they
make it really easy (e.g. debian's reportbug).
=C2= =A0

--001a11c25b488726f50521d94c9b--