Re: [Monotone-devel] branch management
Am 07.12.10 21:16, schrieb Ludovic Brenta: Thomas Keller m...@thomaskeller.biz writes: Now to the question which branches we really want to take care of. Since 0.48 is quite around I think it makes sense to support this a little longer - at least until Debian moves to a newer version - and backport important stuff as needed. Thanks a lot for that. Yes indeed, Debian 6.0 Squeeze will ship with monotone 0.48 and will be supported for at least 2.5 years (i.e. the life cycle of Squeeze plus one year after the release of its successor, Wheezy). It is a bug plus for us to know that you will provide long-term support for this version of monotone. Note however that the Debian maintainers have already done a very good job of backporting critical fixes from the main line, by means of Debian-specific patches; they maintain these patches in the branch org.debian.monotone. Thus, an upstream stable release branch is not absolutely necessary for Debian but it might prove very useful for other distributions. Thats right and thats also the idea behind it - to move the patches for older versions into some place where they're useful for a couple of parties. I'm still not 100% clear if we actually create releases from all the patches and bugfixes we apply to the nvm.monotone-* branches, but at least they are now all tracked in a common place. Originally we / I announced to make 1.0 the first LTS release, but this is still not out of the doors and I don't live behind a rock to notice that distros have other needs, namely need LTS support for older versions as well. The translation update of course did not break anything for us, but I don't know for example if Debian policies allow i18n updates at all in the lifetime of a package and if this work is actually seen for 0.48 users. (I do think its seen otherwise the original author wouldn't have send the patch probably, but I don't know the rules enough). Translation updates are specifically allowed as part of the deep freeze policy[1] that currently applies to Debian. Richard or Francis, could you please commit a suitable patch as an immediate descendant of t:debian-monotone-0.48-3 (fbfd33230edd751a48e33774dbfb4af434eb0910)? It is OK to use the branch org.debian.monotone.squeeze for that. [1] http://lists.debian.org/debian-devel-announce/2010/11/msg6.html Ok, thanks for that. Basically as upstream I felt a little fuzzy about including i18n updates in a (possible) patch release, but its nice to see that Debian people will profit from it (once you packaged it up). Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] branch management
Am 07.12.10 19:11, schrieb Hendrik Boom: On Tue, Dec 07, 2010 at 05:47:23PM +0100, Thomas Keller wrote: 1) If a new branch is created off trunk for a patch release and you make your first commit, its your responsibility to change the version number to 0.minor.patch + 1dev for mtn 1.0. If we follow the new proposed version numbering scheme, this would mean major.minor.patch.90 for new patch versions, which eventually gets major.minor.patch + 1, but I'm open for other - less ugly - suggestions here. Do we run the risk of several patch branches being extant simultaneously and ending up with the same 0.minor.patch+1 number? Presumably this would have to be changed when finally merging the patch. I'm not sure I understand what you mean with extant simultaneously - these releases are all made by a single person and the branches are probably also only touched by one person at a time, so there is little to no risk that two people start on a patch in some release branch without communicating with each other. Since 0.48 is quite around I think it makes sense to support this a little longer - at least until Debian moves to a newer version - and backport important stuff as needed. That'll be a long time, sonce 0.48 is currentl;y Debian testing, and will be around as stable for a very long time. Unless we can get 1.0 into testing before the release. Which I consider unlikely. Right, 0.48 will haunt us just a little longer, thats why I vote to support it a bit more officially - see my other reply. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] branch management
On 07.12.10 17:47, I wrote: Questions / comments / clarifications? If you're ok with the things written above, I could move them into the wiki and / or document them in notes/release-checklist.txt. I clarified again the documentation on the proposed version numbering scheme[0] - again, speak up if you think that there is a logical error in there or that we can't hold the promises given there. I also added a small note at the end of notes/release-checklist.txt in cb66f912804c30108ca9731796d542bde2f7f27f so the release manager does not forget to bump the number for the next release. Thomas. [0] http://wiki.monotone.ca/RoadMap/#index2h1 -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] branch management
Hi all! I appreciate that people take care about older releases and open branches for them to backport fixes, but I think two things are easily forgotten and should be considered by anybody touching these: 1) If a new branch is created off trunk for a patch release and you make your first commit, its your responsibility to change the version number to 0.minor.patch + 1dev for mtn 1.0. If we follow the new proposed version numbering scheme, this would mean major.minor.patch.90 for new patch versions, which eventually gets major.minor.patch + 1, but I'm open for other - less ugly - suggestions here. 2) Likewise when the first change is made, a corresponding NEWS entry should be written, so we don't start to digg though the commit log of the particular branch for a patch release, but have something to build upon. 3) Usually one would fix a bug in a release branch and merge it into trunk, but this merge could bring over unwanted changes (like changes in NEWS, configure.ac and maybe others), so the best is probably to use pluck as most of you already did. Now to the question which branches we really want to take care of. Since 0.48 is quite around I think it makes sense to support this a little longer - at least until Debian moves to a newer version - and backport important stuff as needed. Richard recently added the updated French translation to 0.48 (probably because the original author created a patch against this version) and this was already kind of a corner case, because I think we should really try to keep calm in this area and avoid lots of work backporting non-crucial things to older branches. The translation update of course did not break anything for us, but I don't know for example if Debian policies allow i18n updates at all in the lifetime of a package and if this work is actually seen for 0.48 users. (I do think its seen otherwise the original author wouldn't have send the patch probably, but I don't know the rules enough). Other versions beside 0.48 are currently not quite on my agenda beside the most recent version / branch 0.99, so again, unless people start screaming very loud at us we should try and keep the work and ourselves calm. Questions / comments / clarifications? If you're ok with the things written above, I could move them into the wiki and / or document them in notes/release-checklist.txt. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] branch management
On Tue, Dec 07, 2010 at 05:47:23PM +0100, Thomas Keller wrote: Hi all! I appreciate that people take care about older releases and open branches for them to backport fixes, but I think two things are easily forgotten and should be considered by anybody touching these: 1) If a new branch is created off trunk for a patch release and you make your first commit, its your responsibility to change the version number to 0.minor.patch + 1dev for mtn 1.0. If we follow the new proposed version numbering scheme, this would mean major.minor.patch.90 for new patch versions, which eventually gets major.minor.patch + 1, but I'm open for other - less ugly - suggestions here. Do we run the risk of several patch branches being extant simultaneously and ending up with the same 0.minor.patch+1 number? Presumably this would have to be changed when finally merging the patch. 2) Likewise when the first change is made, a corresponding NEWS entry should be written, so we don't start to digg though the commit log of the particular branch for a patch release, but have something to build upon. 3) Usually one would fix a bug in a release branch and merge it into trunk, but this merge could bring over unwanted changes (like changes in NEWS, configure.ac and maybe others), so the best is probably to use pluck as most of you already did. Now to the question which branches we really want to take care of. Since 0.48 is quite around I think it makes sense to support this a little longer - at least until Debian moves to a newer version - and backport important stuff as needed. That'll be a long time, sonce 0.48 is currentl;y Debian testing, and will be around as stable for a very long time. Unless we can get 1.0 into testing before the release. Which I consider unlikely. Richard recently added the updated French translation to 0.48 (probably because the original author created a patch against this version) and this was already kind of a corner case, because I think we should really try to keep calm in this area and avoid lots of work backporting non-crucial things to older branches. The translation update of course did not break anything for us, but I don't know for example if Debian policies allow i18n updates at all in the lifetime of a package and if this work is actually seen for 0.48 users. (I do think its seen otherwise the original author wouldn't have send the patch probably, but I don't know the rules enough). Other versions beside 0.48 are currently not quite on my agenda beside the most recent version / branch 0.99, so again, unless people start screaming very loud at us we should try and keep the work and ourselves calm. I think 0.40 is in Debian stable right now, but that should be gone in a few months.(or at least become oldstable). Questions / comments / clarifications? If you're ok with the things written above, I could move them into the wiki and / or document them in notes/release-checklist.txt. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] branch management
Thomas Keller m...@thomaskeller.biz writes: Now to the question which branches we really want to take care of. Since 0.48 is quite around I think it makes sense to support this a little longer - at least until Debian moves to a newer version - and backport important stuff as needed. Thanks a lot for that. Yes indeed, Debian 6.0 Squeeze will ship with monotone 0.48 and will be supported for at least 2.5 years (i.e. the life cycle of Squeeze plus one year after the release of its successor, Wheezy). It is a bug plus for us to know that you will provide long-term support for this version of monotone. Note however that the Debian maintainers have already done a very good job of backporting critical fixes from the main line, by means of Debian-specific patches; they maintain these patches in the branch org.debian.monotone. Thus, an upstream stable release branch is not absolutely necessary for Debian but it might prove very useful for other distributions. The translation update of course did not break anything for us, but I don't know for example if Debian policies allow i18n updates at all in the lifetime of a package and if this work is actually seen for 0.48 users. (I do think its seen otherwise the original author wouldn't have send the patch probably, but I don't know the rules enough). Translation updates are specifically allowed as part of the deep freeze policy[1] that currently applies to Debian. Richard or Francis, could you please commit a suitable patch as an immediate descendant of t:debian-monotone-0.48-3 (fbfd33230edd751a48e33774dbfb4af434eb0910)? It is OK to use the branch org.debian.monotone.squeeze for that. [1] http://lists.debian.org/debian-devel-announce/2010/11/msg6.html -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] branch management
In message 4cfe651b.4080...@thomaskeller.biz on Tue, 07 Dec 2010 17:47:23 +0100, Thomas Keller m...@thomaskeller.biz said: me Richard recently added the updated French translation to 0.48 (probably me because the original author created a patch against this version) and (exactly) Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
