Hi guys! <div><br></div><div>Thanks for inviting me to the team! Junior developer should be fine for now. I thinks that's what I am on the debian games team as well. My main focus right now is developing oooark/ ardupilotmega/ and qgroundcontrol. Currently qgroundcontrol depends on osg 2.9.9 so as I told Manuel I used the existing sid package and did an upgrade to 2.9.9. I didn't make the package perfect but it at least works for me and is hosted here: <a href="http://hsl.dynalias.com/debian">hsl.dynalias.com/debian</a> </div>
<div><br></div><div>I have read your past few posts about git and separate folders or branches. I think it would make sense to have the different versions tied to exp/dev/master or possibly create branches name 2.9.9-dev/master/exp etc. If you use separate folders I think you lose the ability to use git merge to update stuff.</div>
<div><br></div><div>-James<br><br><div class="gmail_quote">On Tue, Jan 4, 2011 at 12:14 PM, Alberto Luaces <span dir="ltr"><<a href="mailto:aluaces@udc.es">aluaces@udc.es</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">"Manuel A. Fernandez Montecelo" writes:<br>
<br>
> On Monday 03 January 2011 21:57:05 Alberto Luaces wrote:<br>
>> Manuel, as you said, a very convenient way to take is to syncronize the<br>
>> source with every new debian package release. I think the natural "git<br>
>> way" would be to have versioning dependent on branches. That way, we can<br>
>> have experimental packages as well as security releases and the current<br>
>> release all in the same repository, only by switching branches. For<br>
>> example:<br>
<br>
</div>[...]<br>
<div class="im"><br>
><br>
> Despite I have experience with git, I'm not used to work with branches<br>
> really -- and I'm no expert in any VCS. So I am not aware of the day-to-day<br>
> pros and cons.<br>
><br>
> Doing as you say and having 3 directories in the same branch make things<br>
> works differently.<br>
<br>
</div>No, I meant a branch for every different version of the package that can<br>
coexist at the same time, that is, just one directory per branch.<br>
<br>
Right now in the repository we have the history of the packages as they<br>
were uploaded to Debian. The history only goes forward, so the last<br>
security release is not available in the changelog, and it is lost for<br>
our purposes. Why not creating a new branch collecting that change?<br>
<br>
In the same spirit, imagine we begin packaging experimental versions, in<br>
order to try new features. Some of them will be carried to unstable,<br>
some others don't. Isn't it more convenient to have a special branch for<br>
that purpose and later "cherry pick" the successful items to the master<br>
instead of having to revert things that didn't work in every unstable<br>
release? In addition, it makes the main development independent of the<br>
experimental one.<br>
<br>
[...]<br>
<div class="im"><br>
> (BTW again, I think that starting with 2.9 we should name the Debian package<br>
> as "openscenegraph-MAJOR.MINOR1" (never including "MINOR2") for the source<br>
> package, and the binary packages accordingly. That way, packages depending<br>
> on us wouldn't have problems since they would not depend on a generic<br>
> "openscenegraph" package, and maybe we can do away with renaming binary<br>
> packages due to SO changes. Another option would be to always name the<br>
> stable version as we do now, the devel versions with versions included in<br>
> the name, but I cannot see advantages in doing that other than packages<br>
> depending on us not having to change slightly their control files to depend<br>
> on newer versions. What do you think?).<br>
><br>
<br>
</div>Maybe I'm not fully understanding you proposition. As I see it, if we<br>
dropped the minor version, even for us it would be more difficult to<br>
understand which upstream version we would be matching, as the only tip<br>
would be our debian version numbers, which would then represent a<br>
mixture between our packaging work and the upstream release work.<br>
<br>
For source compatibility, usually a newer version will do. I have seen<br>
for instance that flightgear requires any version newer than 2.8.0, so<br>
they won't have to touch their control file regarding OSG version in a<br>
long time, unless their upstream required them to do so, or because an<br>
OSG non backward-compatible change has arisen.<br>
<div class="im"><br>
><br>
>> On a side note, maybe we should remove the OpenSceneGraph-2.8.3.zip file<br>
>> since the source will be already unpacked for every version. If we also<br>
>> get rid of the *orig.tar.gz one, can dpkg-builder regenerate it from the<br>
>> unpacked source as well without thinking it is not a third party<br>
>> package? The point is to automate the generation of those files in the<br>
>> less time consuming way, and avoiding possible errors.<br>
>><br>
>> That way, every changeset could be like<br>
>><br>
>> openscenegraph-x.y.z/<br>
>> →debian/<br>
>> →OpenSceneGraph<br>
><br>
> If I understood correctly, that's what you want:<br>
> <a href="http://www.debian.org/doc/debian-policy/ch-source.html" target="_blank">http://www.debian.org/doc/debian-policy/ch-source.html</a> (search for "get-<br>
> orig-source" within the page).<br>
><br>
> That way, we wouln't even need to import the .zip into our repository, only<br>
> adjust the URL for the new version in that section of the "rules" file.<br>
><br>
> Is that what you asked? I think that it's a good idea.<br>
<br>
</div>Yes, it is, thanks :) From the manual I have seen that it adresses http<br>
and ftp. As you found in the past :) , sometimes upstream packaging in<br>
zip files is not as good as it should be (mixed CR/LFs and so on). It<br>
would be ideal if we could use instead their svn repository as the<br>
source.<br>
<br>
Now that I'm thinking about it, maybe we could write a rule to get the<br>
source from our repository, craft the orig.tar.gz file and continue the<br>
build...<br>
<br>
Regards,<br>
<font color="#888888"><br>
Alberto<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
Pkg-osg-devel mailing list<br>
<a href="mailto:Pkg-osg-devel@lists.alioth.debian.org">Pkg-osg-devel@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/mailman/listinfo/pkg-osg-devel" target="_blank">http://lists.alioth.debian.org/mailman/listinfo/pkg-osg-devel</a><br>
</div></div></blockquote></div><br></div>