Mail Archives: geda-user/2015/10/08/00:07:24
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
- Raw text -