No subject
Wed Jan 10 20:24:04 GMT 2007
requirements.
The current policy/processes are mandatory for enterprise/business IT
managed environments where sw and hw upgrades are (slow) business driven an=
d
the key factors are security, stability, certification and support.
At home, upgrades are user's driven and the key factors are features, peopl=
e
want to be able to use their latest gadget and to export files to the newes=
t
online service they have subscribed, etc, etc., for those this strict polic=
y
may be an adoption blocker.
I believe Ubuntu/Debian packaging aims business IT, while I am aiming home
users.
Answering your questions:
The sources are not available online yet, I have this pending with the
script which is not yet implemented that will take care of populating the
getdeb database and upload all the files, please note that I am not using a
repository and the associated tools.
I am providing the sources every time I get a request, which is rare, most
of getdeb visitors are end users which have no use for the source.
I understand the benefits on working a greater team like the MOTU but to be
honest I don't believe I would be able to participate to the Ubuntu users a=
s
much I believe I am doing with GetDeb. Browsing on REVU I don't see that
much activity and I see packages introduced from September which are
pending, to be honest, such "Welcome to REVU" is not encouraging for someon=
e
willing to provide the newest applications to the users.
Please don't get me wrong but in my opinion the best hands to fix bugs are
the software developers not the software packagers, if it's a trivial bug, =
I
will fix it and contact the author, if is not trivial it should be up to th=
e
upstream developers to fix it, turning the packagers into co-developers is
not very efficient, specially for bug fixing. Ideally it would be the way
around, developers providing and updating their own packages.
I have not decided yet about the bug reporting system, it will point to a
launchpad entry or I will use the upstream bug reporting system.
Despite our different approaches and concerns I am sure we will be able to
cooperate.
Best regards,
2007/3/8, Daniel Holbach <daniel.holbach at ubuntu.com>:
>
> Hello Jo=E3o,
>
> On Do, 2007-03-08 at 13:33 +0000, Jo=E3o Pinto wrote:
> > I have been a software developer for a long time and just recently got
> > interested into software packaging, mostly because during my Ubuntu
> > forum's participation I realized there is a lot of non-developers
> > spending too much time to get a specific application or feature which
> > is not yet available on the repositories.
> > I am not an experienced packager but I did understood the strict
> > policy/requirements to be a Debian/Ubuntu maintainer by looking into
> > REVU and Debian mentors, I would never be able to keep
> > updating/creating packages with such quality requirements and be able
> > to have "0 days" packages together with the site building and
> > packaging requests scouting.
>
> I can see your point. It often takes a while to get packages
> * conform to the packaging policy
> * reviewed
> * included.
>
> Each of these steps takes a certain amount of time, but that for a
> reason.
>
> 1. Packages which conform to the packaging policy are less likely
> to cause problems on the user's machines.
> 2. Reviewed packages are less buggy, contain all the necessary
> information and reviewer and package maintainer both learn
> during the process.
> 3. Packages that went through the archive admins' hands are
> redistributable and won't cause problems for the user or the
> distributor of those packages.
>
> It's clear that our current process it not optimal. Therefore we're
> working on a new process that will make step 2 easier and shorter
> because of collaboration on the packaging. [1]
>
> Documentation could be easier and better, to make step 1 quicker. It'd
> be nice if you could check [2] and give feedback on it.
>
> [1] https://wiki.ubuntu.com/MOTU/Processes/REVU
> [2] https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/index.html
>
>
> > Today I have added RSS Feed to GetDeb
> > (http://www.getdeb.net/rss.php?distro_id=3D3 , the id is based on the
> > distro selection) I think it could be a good start to monitor package
> > releases, however I am still missing a core requirements:
> > 1. The debian diffs are not (yet) available
> > 2. Internal revision/notification in case an already published
> > package needs to be updated (I am justing uploading the new .deb now)
>
> Do you publish the source somewhere?
>
>
> > Right now I am working on accounts support I am planning to provide
> > future services like new releases emails, users rating, comments, etc.
> > once user login/register is finished I will work on the above points,
> > I will let you know when it's ready, hopefully next week.
> >
> > I was already very motivated because I get frequent feedback from
> > getdeb users, most of the packages and features are based on them. I
> > am happy to know that I will be able to cooperate even more with the
> > Ubuntu community.
>
> The packages you provide seem to fall into three categories:
>
> 1. NEW packages. It'd be interesting for us to know about those and
> get the source somewhere. That way we could work with you on
> including them in Ubuntu.
> 2. Backported packages. You seem to know quite well what would be
> interesting for backports and what not. What do you think about
> https://wiki.ubuntu.com/BackportRequestProcess ?
> 3. Changed packages. If you apply changes or fix packages in
> certain ways, it'd be great to get the source for the change
> somewhere.
>
>
> I encourage you to get as much of these changes done in Ubuntu. The
> reasons for that are pretty simple:
>
> * If you encounter problems or bugs here are a lot of hands who
> can help you with that.
> * Where do your users report bugs? Right: most likely in
> Launchpad. Who will fix those bugs? -- Sorry if this sounds
> provocative. It's merely meant to start the discussion about the
> practise of working together.
> * Reach even more users with your fixes and changes - get those
> fixes installed by default.
>
>
> Let us know what you think about it.
>
> Have a nice day,
> Daniel
>
>
>
--=20
Jo=E3o Pinto
GetDeb Packager
http://www.getdeb.net
------=_Part_228532_2989933.1173374427585
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Daniel,<br>before answering to your questions let me explain better the con=
text of my comments regarding the packaging and updates policy.<br><br>From=
my experience, home PCs and enterprise PCs don't share the same requir=
ements.=20
<br>The current policy/processes are mandatory for enterprise/business IT m=
anaged environments where sw and hw upgrades are (slow) business driven and=
the key factors are security, stability, certification and support.<br>
At home, upgrades are user's driven and the key factors are features, p=
eople want to be able to use their latest gadget and to export files to the=
newest online service they have subscribed, etc, etc., for those this stri=
ct policy may be an adoption blocker.
<br><br>I believe Ubuntu/Debian packaging aims business IT, while I am aimi=
ng home users.<br><br>Answering your questions:<br><br>The sources are not =
available online yet, I have this pending with the script which is not yet =
implemented that will take care of populating the getdeb database and uploa=
d all the files, please note that I am not using a repository and the assoc=
iated tools.
<br>I am providing the sources every time I get a request, which is rare, m=
ost of getdeb visitors are end users which have no use for the source.<br><=
br>I understand the benefits on working a greater team like the MOTU but to=
be honest I don't believe I would be able to participate to the Ubuntu=
users as much I believe I am doing with GetDeb. Browsing on REVU I don'=
;t see that much activity and I see packages introduced from September whic=
h are pending, to be honest, such "Welcome to REVU" is not encour=
aging for someone willing to provide the newest applications to the users.
<br><br>Please don't get me wrong but in my opinion the best hands to f=
ix bugs are the software developers not the software packagers, if it's=
a trivial bug, I will fix it and contact the author, if is not trivial it =
should be up to the upstream developers to fix it, turning the packagers in=
to co-developers is not very efficient, specially for bug fixing. Ideally i=
t would be the way around, developers providing and updating their own pack=
ages.
<br><br>I have not decided yet about the bug reporting system, it wil=
l point to a launchpad entry or I will use the upstream bug reporting syste=
m.<br><br>Despite our different approaches and concerns I am sure we will b=
e able to cooperate.
<br><br>Best regards,<br><br><div><span class=3D"gmail_quote">2007/3/8, Dan=
iel Holbach <<a href=3D"mailto:daniel.holbach at ubuntu.com">daniel.holbach=
@ubuntu.com</a>>:</span><blockquote class=3D"gmail_quote" style=3D"borde=
r-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-le=
ft: 1ex;">
Hello Jo=E3o,<br><br>On Do, 2007-03-08 at 13:33 +0000, Jo=E3o Pinto wrote:<=
br>> I have been a software developer for a long time and just recently =
got<br>> interested into software packaging, mostly because during my Ub=
untu
<br>> forum's participation I realized there is a lot of non-develop=
ers<br>> spending too much time to get a specific application or feature=
which<br>> is not yet available on the repositories.<br>> I am not a=
n experienced packager but I did understood the strict
<br>> policy/requirements to be a Debian/Ubuntu maintainer by looking in=
to<br>> REVU and Debian mentors, I would never be able to keep<br>> u=
pdating/creating packages with such quality requirements and be able<br>
> to have "0 days" packages together with the site building an=
d<br>> packaging requests scouting.<br><br>I can see your point. It ofte=
n takes a while to get packages<br> * co=
nform to the packaging policy
<br> * reviewed<br> &nb=
sp; * included.<br><br>Each of these steps takes a certain amoun=
t of time, but that for a<br>reason.<br><br> 1. Pac=
kages which conform to the packaging policy are less likely<br> =
to cause problems on the user's mac=
hines.
<br> 2. Reviewed packages are less buggy, contain a=
ll the necessary<br> informa=
tion and reviewer and package maintainer both learn<br> &n=
bsp; during the process.<br> =
3. Packages that went through the archive admins' hands are
<br> redistributable and won=
't cause problems for the user or the<br> =
distributor of those packages.<br><br>It's clear that=
our current process it not optimal. Therefore we're<br>working on a ne=
w process that will make step 2 easier and shorter
<br>because of collaboration on the packaging. [1]<br><br>Documentation cou=
ld be easier and better, to make step 1 quicker. It'd<br>be nice if you=
could check [2] and give feedback on it.<br><br>[1] <a href=3D"https://wik=
i.ubuntu.com/MOTU/Processes/REVU">
https://wiki.ubuntu.com/MOTU/Processes/REVU</a><br>[2] <a href=3D"https://h=
elp.ubuntu.com/6.10/ubuntu/packagingguide/C/index.html">https://help.ubuntu=
.com/6.10/ubuntu/packagingguide/C/index.html</a><br><br><br>> Today I ha=
ve added RSS Feed to GetDeb
<br>> (<a href=3D"http://www.getdeb.net/rss.php?distro_id=3D3">http://ww=
w.getdeb.net/rss.php?distro_id=3D3</a> , the id is based on the<br>> dis=
tro selection) I think it could be a good start to monitor package<br>> =
releases, however I am still missing a core requirements:
<br>> 1. The debian diffs are not (yet) available<br>>&nb=
sp; 2. Internal revision/notification in case an already published<br=
>> package needs to be updated (I am justing uploading the new .deb now)=
<br><br>Do you publish the source somewhere?
<br><br><br>> Right now I am working on accounts support I am planning t=
o provide<br>> future services like new releases emails, users rating, c=
omments, etc.<br>> once user login/register is finished I will work on t=
he above points,
<br>> I will let you know when it's ready, hopefully next week.<br>&=
gt;<br>> I was already very motivated because I get frequent feedback fr=
om<br>> getdeb users, most of the packages and features are based on the=
m. I
<br>> am happy to know that I will be able to cooperate even more with t=
he<br>> Ubuntu community.<br><br>The packages you provide seem to fall i=
nto three categories:<br><br> 1. NEW packages. It&#=
39;d be interesting for us to know about those and
<br> get the source somewher=
e. That way we could work with you on<br> &nbs=
p; including them in Ubuntu.<br> 2. Back=
ported packages. You seem to know quite well what would be<br> &=
nbsp; interesting for backports and what not. =
What do you think about
<br> <a href=3D"https://wiki=
.ubuntu.com/BackportRequestProcess">https://wiki.ubuntu.com/BackportRequest=
Process</a> ?<br> 3. Changed packages. If you apply=
changes or fix packages in<br> &n=
bsp;certain ways, it'd be great to get the source for the change
<br> somewhere.<br><br><br>I=
encourage you to get as much of these changes done in Ubuntu. The<br>reaso=
ns for that are pretty simple:<br><br> *=
If you encounter problems or bugs here are a lot of hands who<br>
can help you with that.<br>=
* Where do your users report bugs? Righ=
t: most likely in<br> Launch=
pad. Who will fix those bugs? -- Sorry if this sounds=
<br> provocative. It's m=
erely meant to start the discussion about the
<br> practise of working tog=
ether.<br> * Reach even more users with =
your fixes and changes - get those<br> &=
nbsp; fixes installed by default.<br><br><br>Let us know what you thin=
k about it.<br><br>Have a nice day,
<br> Daniel<br><br><br></blockquote></div><br><br clear=3D"all"><br>-- <br>=
Jo=E3o Pinto<br>GetDeb Packager<br><a href=3D"http://www.getdeb.net">http:/=
/www.getdeb.net</a>
------=_Part_228532_2989933.1173374427585--
More information about the Ubuntu-motu
mailing list