X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f Date: Wed, 7 Oct 2015 22:55:52 -0400 Message-Id: <201510080255.t982tqto018072@envy.delorie.com> From: DJ Delorie To: geda-user AT delorie DOT com In-reply-to: (message from Kai-Martin Knaak on Thu, 08 Oct 2015 04:13:38 +0200) Subject: Re: [geda-user] Re: Politics & Launchpad References: Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > 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).