[3dprinter-general] 3D-printer packaging

[Elena ``of Valhalla'']

On 2014-01-23 at 00:08:42 +0100, Bas Wijnen wrote:
> We just got a new request from Elena to join.  Welcome to the team. :-)

thanks!

> To record the state of this discussion, I started
> https://wiki.debian.org/3D-printer
> Please edit it with anything that should be there.


> So about the packaging.  On the wiki I added an initial list of packages
> which we should maintain.  Some of them are already packaged; some by
> me, some by others.  If you know of other packages, please add them to
> the list.  Once we have our git repository organized, we should split
> this list in "things we maintain" (with links) and "things we should
> maintain".

I've added two packages, one of which has an ITP by someone not in the 
team, so I'm going to suggest again that he joins it (expecially 
now that there is some traffic).

Andrea has also written a script to keep track of the status 
of some packages *including ITPs* and we were planning to use it 
also with a list of 3D printing related packages, expecially since 
their status seemed to be mostly as ITPs (and thus not visible 
e.g. in the maintainer dashboard)

> How do we organize our repository?  I have limited experience with
> git-buildpackage, and I don't like it.  It's too hard to set up, and
> that scares potential contributers away.  So either we write a very
> short and simple list of instructions on the wiki, or we don't use it.
> Did I mention you should say so if you disagree with me? ;-)

as somebody who was almost scared away by the use of svn in the 
python-(module|apps) team... :)

This link was suggested on the python teams list a few days ago 
as an example of good documentation for a team workflow based 
on git-buildpackage:

http://openstack.alioth.debian.org/

> My suggestion for the repository is to use a directory for each package,
> which has the name of that package, 

my understanding is that git-buildpackage requires one repository 
for package; mr can be used to manage multiple repositories 
with a single command. (I'm still stuck using svn-bp in the
above mentioned teams, and I've only tried gbp once)

> When packaging a new upstream version, the tree should be moved to the
> new version number.  If the old version need to stay around for updates
> to stable or whatever reason, it can be copied instead.

No need for this in git, where branches for stable mainteneance 
can be created out of every commit (expecially tagged ones)

-- 
Elena ``of Valhalla''