X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Message-ID: <20151008040656.10998.qmail@stuge.se> Date: Thu, 8 Oct 2015 06:06:56 +0200 From: "Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Subject: Re: [geda-user] Re: Politics & Launchpad Mail-Followup-To: geda-user AT delorie DOT com References: <201510080255 DOT t982tqto018072 AT envy DOT delorie DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201510080255.t982tqto018072@envy.delorie.com> 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 DJ Delorie wrote: > This assumes, of course, that our project should be responsible for > Ubuntu packaging. Are we? No, and PPAs aren't "Ubuntu packaging" because no PPA packages will automatically be included in Ubuntu releases. PPAs are merely a way to make binaries easily available for Ubuntu users, which IMO is a fairly important task for any open source project. > What about Fedora? Suse? Debian? Gentoo? Windows? Mac? I think it would be great to also offer .deb and .rpm builds in sync with PPA builds. It would make binaries easily available for even more users, which may lead to even more testing and feedback. Investing time in making binaries available always runs the risk of being wasted effort in case noone downloads them, but for users it's a very important service that indeed is the responsibility of each respective project. Unfortunately, noone else will build snapshots. One can try to trick distributions into doing this job by making frequent releases. Some are happy with that. But if things are too broken too often then the project gets a bad rep. > > 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. I don't know about that? I consider gEDA one project, even though gschem and pcb aren't integrated. I consider it one community, and I think it makes perfect sense to have one bug tracker. > > A team which is as open as possible to everybody with good > > intentions. > > A goal I share. Thanks. For the record I don't think I've ever seen you demonstrate the contrary. > > 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. It's not about the distro, but about a service to the users of that distro. The distro do their own (far too infrequent) packaging and releases. > > 1) a single place to add and access bug reports of all geda tools > > Is this really what everyone wants? I think it would be an improvement to have everything in one place. > Have we addressed the extra work required? What work is that? > Does everyone know what the proper procedures for state changes > are, and how to coordinate those with packages and releases? What are the procedures? Packages and releases are few and far between anyway, so if there's a bit of a learning curve before a release can happen I think that's fine. > > 2) a low entrance barrier team to join and become involved > > This didn't require a new team. Maybe not, but it must have seemed that way. It's important not to dismiss that impression. > > 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 honestly can't see much disruption. A launchpad team with a halfway meaningful name was created to make a PPA and bug fixes available to the world immediately, that seems to be all. > I agree with #2 and #3, and still see no reason why a new team was > required to do them. This means that you haven't yet understood why others felt differently. I expect that you will not rest until you do understand that. I can't claim to understand fully, but at least one reason has been communicated clearly; there were multiple attempts to communicate with existing team members but no response was to be had. Of course noone must blame you for being on vacation, but it seems to me that the attempts stretched over a few weeks - which should be enough time to reach someone. > The projects are separate projects, I don't see it that way. The programs are separate programs but there's only one project. One mailing list. And one community. > separate bug trackers make sense, just like separate git repos make sense. Only if the LP bug tracker is so limited that it doesn't support some notion of components. Is that the case? (Personally I much prefer to both use and operate Trac over anything else, although its Git integration is quite mediocre. :\ ) //Peter