Mail Archives: geda-user/2015/10/07/22:56:12
> You have to be an administrator or owner of a launchpad team to
> associate a PPA.
I didn't know this. We switched to launchpad for the bug tracker, not
because we wanted to give preference to Ubuntu packaging. 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 package
and pcb for the pcb package. There are no projects associated with
the developers team, and there is no one "geda" package. The various
geda packages don't even have similar release schedules.
This assumes, of course, that our project should be responsible for
Ubuntu packaging. Are we? What about Fedora? Suse? Debian?
Gentoo? Windows? Mac?
> 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.
> 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? 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. Everything that was done
in the new tracker could have been done in the old trackers also.
Having two trackers only adds confusion and extra work.
> 1) a single place to add and access bug reports of all geda tools
Is this really what everyone wants? Have we addressed the extra work
required? 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. I've been trying to increase
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. Most of the people on the new team were on the
old teams anyway.
#1 is of debatable benefit. The projects are separate projects,
separate bug trackers make sense, just like separate git repos make
sense. The only real "global" benefit would be if bugs could be moved
from there to their individual trackers after triage, but that would
require configuring it to do so instead of acting like an independent
tracker (i.e. it could be limited to pre-commit states, requiring a
move to the project tracker before committing a patch to git).
- Raw text -