Mail Archives: geda-user/2015/10/11/15:34:37
--001a11c25b488726f50521d94c9b
Content-Type: text/plain; charset=UTF-8
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. 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?
>
If somebody wants to do it, it would probably be beneficial. It seems to
me this would make it more likely to get packaged neatly for other distros
as well. 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. But I think just be alert to that potential problem, but
otherwise go for it.
> > 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.
Integrated BTS very good I think.
> > 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.
>
I agree, but I don't understand why Markus was declined. That was the
mistake that causes all the problems IMO.
> > 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
>
I think yes. gEDA docs and BTS are so scattered it makes it much harder
to get started with them.
> 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
>
Separate repos is a different case, and only people doing patch/devel
want them, and they work harder to get them.
> sense. The only real "global" benefit would be if bugs could be moved
> from there to their individual trackers after triage, but that would
>
People can more easily find the damn BTS and use it. 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).
--001a11c25b488726f50521d94c9b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Oct 7, 2015 at 6:55 PM, DJ Delorie <span dir=3D"ltr"><<a hre=
f=3D"mailto:dj AT delorie DOT com" target=3D"_blank">dj AT delorie DOT com</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br>
> You have to be an administrator or owner of a launchpad team to<br>
> associate a PPA.<br>
<br>
</span>I didn't know this.=C2=A0 We switched to launchpad for the bug t=
racker, not<br>
because we wanted to give preference to Ubuntu packaging.=C2=A0 If I knew<b=
r>
this was a goal, I would have pushed for bugzilla instead ;-)<br>
<span class=3D""><br>
> In case of the gEDA_Developers<br>
<br>
</span>The right place for PPAs would have been geda for the geda-gaf packa=
ge<br>
and pcb for the pcb package.=C2=A0 There are no projects associated with<br=
>
the developers team, and there is no one "geda" package.=C2=A0 Th=
e various<br>
geda packages don't even have similar release schedules.<br>
<br>
This assumes, of course, that our project should be responsible for<br>
Ubuntu packaging.=C2=A0 Are we?=C2=A0 What about Fedora?=C2=A0 Suse?=C2=A0 =
Debian?<br>
Gentoo?=C2=A0 Windows?=C2=A0 Mac?<br></blockquote><div><br></div><div style=
=3D"">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.</div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><span class=3D"">
> In addition, he revitalized a long standing idea to have a single<br>
> place to deal with bugs in all of geda's projects.<br>
<br>
</span>Given the strong opposition to integration between gschem and pcb, I=
<br>
can see how this idea would find resistance.<br></blockquote><div><br></div=
><div style=3D"">Integrating the BTS and integrating the software isn't=
the same.=C2=A0 Integrated BTS very good I think.</div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><span class=3D"">
> A team which is as open as possible to everybody with good<br>
> intentions.<br>
<br>
</span>A goal I share.<br>
<span class=3D""><br>
> And of course a place to present a PPA of the most current version<br>
> of the geda tools.<br>
<br>
</span>What about other distros?=C2=A0 Typically, supporting a distro is<br=
>
independent of supporting the upstream package itself.<br>
<span class=3D""><br>
> Note, that these bugs are exactly the same as those seen in the bug<br=
>
> trackers for the individual tools.<br>
<br>
</span>I see no benefit of having a second tracker.=C2=A0 Everything that w=
as done<br>
in the new tracker could have been done in the old trackers also.<br>
Having two trackers only adds confusion and extra work.<br></blockquote><di=
v><br></div><div style=3D"">I agree, but I don't understand why Markus =
was declined.=C2=A0 That was the mistake that causes all the problems IMO.<=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">
> 1) a single place to add and access bug reports of all geda tools<br>
<br>
</span>Is this really what everyone wants?=C2=A0 Have we addressed the extr=
a work<br></blockquote><div><br></div><div style=3D"">I think yes. =C2=A0gE=
DA docs and BTS are so scattered it makes it much harder</div><div style=3D=
"">to get started with them.</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
required?=C2=A0 Does everyone know what the proper procedures for state<br>
changes are, and how to coordinate those with packages and releases?<br>
<span class=3D""><br>
> 2) a low entrance barrier team to join and become involved<br>
<br>
</span>This didn't require a new team.=C2=A0 I've been trying to in=
crease<br>
involement with the existing setup already.<br>
<span class=3D""><br>
> 3) a weekly build of the geda tools to be used on ubuntu systems and<b=
r>
> by extension on any debian related distro.<br>
<br>
</span>This did not require any leadership changes or disruptions.<br>
<span class=3D""><br>
> I feel like these are steps in the right direction.<br>
<br>
</span>I agree with #2 and #3, and still see no reason why a new team was<b=
r>
required to do them.=C2=A0 Most of the people on the new team were on the<b=
r>
old teams anyway.<br>
<br>
#1 is of debatable benefit.=C2=A0 The projects are separate projects,<br>
separate bug trackers make sense, just like separate git repos make<br></bl=
ockquote><div><br></div><div style=3D"">Separate repos is a different case,=
and only people doing patch/devel</div><div style=3D"">want them, and they=
work harder to get them.</div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
sense.=C2=A0 The only real "global" benefit would be if bugs coul=
d be moved<br>
from there to their individual trackers after triage, but that would<br></b=
lockquote><div><br></div><div style=3D"">People can more easily find the da=
mn BTS and use it.=C2=A0 That's huge.</div><div style=3D"">Most of the =
time for most software I don't bother to report unless they</div><div s=
tyle=3D"">make it really easy (e.g. debian's reportbug).</div><div>=C2=
=A0</div></div></div></div>
--001a11c25b488726f50521d94c9b--
- Raw text -